Overview
In this page we have provided the answers for the frequently asked question. If you do not find your question in this page the please contact the support and submit your question.
Technical questions
-
Reason codes explain the reason behind the Instnt Accept's decision of "Accept,"
"Reject," or "Review" status of end-user signup. All the information collected
when a user submits a signup form is verified against
Personally Identifiable Information (PII) and other data collected from various
vendors in different scenarios.
For more information read, Reason Code. -
Yes, please make sure images are not larger than 2MB, and the format is JPEG.
-
It largely depends on the environment in which you are testing.
If you are testing in our Sandbox environment, it only assesses the provisioned
synthetic identities. And any real identity is automatically rejected in this
environment. Please make sure you are testing real identities in production. -
This occurs when we do not get enough information from our vendors.
We are unable to verify the phone number and address; this is most likely due to
insufficient sources.
See reason code: NA102, NP103 in Reason Code glossary. -
The error may be due to what you put in the Trusted Domains during your workflow
creation in the Instnt dashboard. Please use the wildcard (*).
If you still are receiving the same error, reach out to support.
For more information, read Instnt CORS Implementation. -
This may be due to our KYC watchlist checks picking up on adverse media for the applicant.
Other possible reasons for someone sent to review would be that one or more pieces of personal information
could not be verified to a high degree of confidence, so Instnt Accept's decision is to send it to
review for further human verification.
The reason codes provided should provide insight into which pieces of personal
information may need further checking.
For more information on reason codes read, Reason Code.
Common product questions
-
Financial institutions are required to implement the Customer Identification Programs (CIP),
and this makes Anti-Money Laundering (AML) compliance and Know Your Customer (KYC) verification for onboarding new customers compulsory.
Instnt facilitates KYC Check at the time of creating the customer onboarding workflow in Instnt Accept's dashboard.
You can create a signup workflow that mandates the KYC check for an applicant.
Refer to the KYC article to understand how Instnt processes KYC. Please refer to the Customer identification program requirements for banks.
In KYC, adverse media is when a negative article is found on an individual. -
No, there is no compulsion to use any of the aforementioned features. You can choose any one or none of these.
Using them completely depends on your discretion and business needs.
Refer to the KYC and Field Data articles to understand the features better. -
No, the order in which you would like this to flow on your onboarding is completely up to your team.
-
No, you can integrate Instnt with the help of one of the SDK or the APIs provided by us.
And, the data that you collect from your customer and submit to Instnt is the only data we have access to.
It is just a signup process; users will not be aware of Instnt. -
One Time Password (OTP) is a feature that, when enabled,
can be used to verify if the end-user possesses the phone for which they provided the info. During the OTP process, Instnt sends an SMS to the applicant's phone number they have
provided while filling out your application to ensure that the phone is present with them.
The user should input the code in the field that you provide them, and via our API, we validate the OTP. -
Instnt has built internally predictive models for different modes of fraud which we have categorized
as 1st, 3rd party fraud model, based on historical data. The scores produced by these models are combined with other signals in our aggregate models to produce
a final decision. These fraud models are periodically retrained as we collect more data and labels,
adapting to changing fraud patterns. Please find the brief explanation for each: Aggregate Decision: The final decision that takes each separate machine learning model's score and combines
them to the customer-specific decision heuristics for a final result.
1st Party Fraud Model: A machine learning model trained and deployed periodically using real-time customer data
that specifically detects transactions made mostly with legitimate personal information but triggering subtle anomalies
in device usage, from signup behavior or velocity metrics at some point of the first or a consecutive transaction.
3rd Party Fraud Model: A machine learning model trained and deployed periodically using real-time customer data that
specifically detects transactions made with real but stolen or mixed personal information, such as combining somebody's
legitimate email address with some other person's phone numbers, and physical address.
Synthetic Fraud Model: A machine learning model trained and deployed periodically using real-time customer data
that specifically detects transactions made with non-real / synthetic personal information such as made-up
names and fake addresses.