Productfy logoLog In

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

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-Waterfall-Diagram.png

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

Note: In your onboarding flow it's recommended to have an extra step for users to verify the information they entered before calling our KYC service. This will reduce the amount of typos submitted
Note: In your onboarding flow please include guidance for your users to submit information exactly as it matches their government issued ID. This will ensure a higher pass rate through KYC

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 NameKYC Scenario
A - GAutomatic pass of level 1
H - IWill fail when KBA answers are submitted
J - LWill pass when KBA answers are submitted
M - OWill fail if the DVS images are uploaded
P - RWill pass if the DVS images are uploaded
S - VWill 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 and pk_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:

  1. Install web libraries - follow instructions here.
  2. (Optional) Decide on configuration settings and style customizations.
  3. Code to event handlers
  4. 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:

DVS SMS Handoff.png

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:

DVS SMS Handoff submit.png

Your customer will get a text message to the number provided that looks like this:

DVS SMS sample.png

The link will take them to an IDScan site that invokes the phone camera to gather the images and verify identity:

DVS Widget Photo.PNG

When the user has submitted their images, Productfy receive results from IDScan and will do 2 things:

  1. 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.
  2. 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 and sk_e3d57c10-cc0b-4c8a-8440-984b5b4f96f6 for Prod.

You will need to provide the following information in the header of the ID Scan API:

Header FieldValue
HostYour HTTP client URL or IP address that will send the request
Acceptapplication/json
AuthorizationBearer <your IDScan SMS API token provided above here>
Content-Typeapplication/json
Content-LengthCalculated 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:

FieldValue
Emailemail
First NamefirstName
Last NamelastName
Phone Numberphone
sendSmstrue

You will need to provide the following information from the user in the metadata section of the request body of the ID Scan API:

FieldValue
personIdInclude the Productfy person ID (format = Pfy_P-XXXXXXXX)
tenantDeploymentEnvironmentIdInclude your Productfy environment ID (format = Pfy_TnntDeployEnv-XXXXXXXX)

See the code snippet below to get started:

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: