KYC
Overview
Due to banking regulations, users must have their identity verified and checked against various watchlists before they are able to open any accounts or transact on our system.
Our KYC policy requires the following information from users:
- Name
- Date of Birth
- Address
- Social Security Number*
*Note - customers without SSNs are able to upload passport or government IDs to pass KYC
KYC Information Security Standards
Clients using our KYC services must adhere to the Federal Reserve's guidance on information security outlined here: www.federalreserve.gov/supervisionreg/interagencyguidelines.htm.
Prerequisites
Before KYC can be performed, verify the following requirements must be met:
- Person exists in Productfy system
- Person has name, date of birth and social security number filled out
- Person has an address associated with them
See the Getting Started implementation guide (step 4) for information on our APIs to create customers with the right information in the system.
KYC Standard Waterfall
Productfy’s standard KYC waterfall is designed to reduce friction for the customer by favoring non-documentary verification over documentary verification. Level 1 of the waterfall validates the customer's Name, Date of Birth, Address and Social Security Number. Depending on the results of that validation, customers may pass KYC at that point or move on to Level 2 (Knowledge-based questions) or Level 3 (Document Verification Service), as shown in the diagram below.
KYC starts by calling the executeKycVerification API and then proceeding by following instructions returned in the nextStep
field until the identityVerified
field returns either true or false.
Note that nextStep
has the following possible return values which outline the different KYC tools that Productfy offers:
- Knowledge-Based Authentication (KBA)
- Document Verification Service (DVS)
ACH Identity Verification
For certain use cases that are considered low-risk, a simpler version of KYC, known as “ACH Identity Verification'', can be used instead of standard KYC. To perform ACH Identity Verification, your specific use case must be reviewed and approved by Productfy before your environment can be configured to utilize ACH Identity Verification. One potential use case would be paying bills from an external payment method where the end-user is not opening a deposit account or issuing a debit card on the Productfy system.
ACH Identity Verification follows the same waterfall as standard KYC, except that it performs identity verification checks based only on the following information:
- Name
- Address
Step 1 - Execute KYC Verification
Use the Execute KYC Verification API to run KYC on a specific person.
This step performs all required watchlist checks and attempts to verify the person’s identity. The API call will return important information on the user's KYC validation results.
Under the watchlistsCheckResult object, the watchlistsCheckPassed field which will return true if the user was not found on any of the relevant watchlists, false if a match was found, and null if this check has not yet been completed.
Under the identityVerification object, the identityVerified field will return true if the user’s identity has been verified and false if the user’s identity was determined to be invalid. If identityVerified is null, that means there are still additional steps that must be completed for KYC. In that case, the nextStep field will determine which of the following KYC steps to perform next:
- nextStep value of 'K' = Knowledge-Based Authentication (KBA)
- nextStep value of 'D' = Document Verification Service (DVS)
Testing Execute KYC API in QA
If you are in a QA environment and want to see the different pass and fail scenarios of each of these KYC levels, the system allows you to do this based on the last letter of the first name of the Person ID you are testing with. See the chart below for which letters at the end of the first name will trigger which KYC scenario.
Last Letter of First Name | KYC Scenario |
---|---|
A - G | Automatic pass of level 1 |
H - I | Will fail when KBA answers are submitted |
J - L | Will pass when KBA answers are submitted |
M - O | Will fail if the DVS images are uploaded |
P - R | Will pass if the DVS images are uploaded |
S - V | Will take the actual DVS result from our vendor when DVS images are uploaded |
Step 2 - Knowledge-Based Authentication (KBA)
If a user’s identity has not yet been verified, the nextStep field returned from the executeKycVerification API call might point you to use Knowledge-Based Authentication (KBA) to complete KYC.
In this step, you must use the kbaQuestionnaire API to retrieve KBA questions and present them to the user to answer. The questions are generated from various data sources and are specific to each user. Some users may be required to answer a higher percentage of KBA questions correctly in order to be verified, depending on the outcome of the previous KYC step.
To submit the answers, you must use the kbaAnswers API and pass in the questionnaireId returned from the kbaQuestionnaire API that was used to retrieve the KBA questions. Additionally, each answer must be associated with a questionId that ties it to the relevant KBA question. NOTE - to view the nextStep and identityVerified fields after submitting KBA Answers, you must call the executeKycVerification API again.
Step 3 - Document Verification Service (DVS)
If a user’s identity has not yet been verified, the nextStep field returned from the executeKycVerification API call might point you to use Document Verification Service (DVS). In this step, the user must upload a photo ID, such as passport or driver’s license, to verify their identity. The information in the user’s identification documents are compared against the data provided at signup to verify the user. Validation checks are also performed on the photo IDs to ensure the IDs are authentic and unaltered. DVS is the final step in the KYC flow.
Native Mobile Integrations - Integrate IDScan Web Libraries Directly
For native mobile app implementations, integrate IDScan's web libraries to your app. We will point you to specific sections of IDScan's web library documentation here: https://docs.idscan.net/dvs/dvs-web-api/web-library-v1.html
You will need the following additional configuration value for your IDScan setup:
- DVS License Key - Send your Productfy representative the URL of the page in your app (this includes native mobile apps) where you will execute the DVS web library from to obtain the License Key. You will use the License Key in your web library installation. The web library will check the URL it’s running on, obtain the domain, and validate the domain via IDScan’s license server.
- Verification Token - Use this value:
pk_4c258a95-864a-478c-b153-ccd8d0ef6d51
for QA andpk_e72417e2-4a7c-4559-8408-ca23d712322b
for Production. NOTE - IDScan may refer to this as the Secret Key in their documentation.
Here is the process to follow within IDScan's documentation:
- Install web libraries - follow instructions here.
- (Optional) Decide on configuration settings and style customizations.
- Code to event handlers
- Integrate web libraries to your app
Give Productfy the IDScan Request ID
After the user has submitted their images via the web libraries above, you should have the IDScan Request ID returned to you. You will need to call the Process DVS API to send Productfy the IDScan Request ID. Productfy will update its system with the results of the DVS scan.
Desktop Web Integrations - Implement Mobile Handoff from Desktop Web
For desktop web implementations, we need to execute a 'mobile handoff' to send the user from your desktop app to the user's mobile phone to complete drivers license and selfie photo submission. This will take advantage of the higher quality cameras on mobile phones (versus desktop/laptop computers) to increase the pass rate of your users. To do this mobile handoff, we leverage IDScan's SMS text message solution which sends users a link on their mobile phone to complete online document submission via the browser on their phone and a generic IDScan site that invokes the phone camera and collects the images.
Your web app should present the user a page that informs them they need to enter their mobile number to get a URL texted to them for completion of their identity validation. To initiate this process you will use IDScan's DVS Online Rest API (step 4, #2) to send the user a text message.
Your web UI could look something like this:
NOTE - To comply with TCPA regulations, you need to display this message on the same screen where the user is providing their mobile phone number: Consistent with the terms of your Card Agreement and to prevent fraud, you authorize us to authenticate you by sending you a text message when you attempt to log into your account. Text messaging rates may apply.
Upon submitting, you could display a message like this:
Your customer will get a text message to the number provided that looks like this:
The link will take them to an IDScan site that invokes the phone camera to gather the images and verify identity:
When the user has submitted their images, Productfy receive results from IDScan and will do 2 things:
- Update the identityVerified field to true or false depending on the results of the user's submission. This is the key field the Productfy system looks at to ensure a user has passed identity validation.
- Trigger a KYC Status Webhook to your application. This will inform you the results of the user's submission from their phone.
ID Scan API Call:
See IDScan's documentation on their DVS Online Rest API here (step 4, #2). This is the API that will be used to send the user a text message to their phone, along with metadata identifiers that tell IDScan and Productfy which user on the system is using DVS.
You will need the following additional configuration value for your API call:
- SMS API Token - Use this value:
sk_e98e56f2-75ad-4220-8a02-5760deb00f59
for QA andsk_e3d57c10-cc0b-4c8a-8440-984b5b4f96f6
for Prod.
You will need to provide the following information in the header of the ID Scan API:
Header Field | Value |
---|---|
Host | Your HTTP client URL or IP address that will send the request |
Accept | application/json |
Authorization | Bearer <your IDScan SMS API token provided above here> |
Content-Type | application/json |
Content-Length | Calculated by your HTTP client code |
You will need to provide the following information from the user in the request body of the ID Scan API:
Field | Value |
---|---|
First Name | firstName |
Last Name | lastName |
Phone Number | phone |
sendSms | true |
You will need to provide the following information from the user in the metadata section of the request body of the ID Scan API:
Field | Value |
---|---|
personId | Include the Productfy person ID (format = Pfy_P-XXXXXXXX) |
tenantDeploymentEnvironmentId | Include your Productfy environment ID (format = Pfy_TnntDeployEnv-XXXXXXXX) |
See the code snippet below to get started:
POST https://api-dvsonline.idscan.net/api/ValidationRequests HTTP/1.1Host: sampleapp.comAccept: application/jsonAuthorization: Bearer <YOUR_TOKEN_HERE>Content-Type: application/jsonContent-Length: 106Request body:{"firstName": "John","lastName": "Smith","phone": "+12133458345","email": "test@email.com","sendSms": true,"metadata": {"personId": "Pfy_P-ciUUC444G","tenantDeploymentEnvironmentId": "Pfy_TnntDeployEnv-sub1M2istage"}}
Once a POST call is made to the ID Scan API above, the user will receive a text message as outlined above.
In IDScan's response message to the API, they will include their request ID value, which may be useful in troubleshooting. See sample response message: