External Vendor KYC/KYB Verification

Using an External KYC / KYB Vendor overview

This document outlines how to use external know your customer (KYC) and know your business (KYB) vendors with the Synctera platform.

Banks and other financial institutions are required to perform KYC/KYB processes on customers wishing to perform most financial transactions, such as moving money. These procedures are required by US banking regulators to reduce the risk of fraudulent or bad actors performing malicious transactions in the banking system.

These programs require:

1. Data Collection: name, date of birth, address, and government issued ID.
2. Disclosures: notifying customers about the collection and retention of data.
3. Verification: verifying that the information collected is current, valid, and up-to-date.
4. On-going monitoring: verifying that the customer is not on a known watchlist.

While Synctera offers an integrated option to perform KYC and KYB, fintechs may also use an external vendor to perform KYC / KYB checks. Fintechs must gain approval to use an external vendor from the sponsor bank before going live. For each end customer or business that goes through the KYC / KYB process, the fintech must also submit the vendor’s response to Synctera (see create verification API), so we can monitor the overall risk.

External Vendor KYC / KYB Process

1. Customer enrolls with fintech.
2. Fintech calls person or business API to enroll customer with Synctera.
3. Customer acknowledges KYC/KYB and other disclosures.
4. Fintech calls Synctera’s disclosure API to record customer acknowledgement of disclosures.
5. Fintech submits customer details to their KYC / KYB vendor.
6. Vendor responds indicating customer passed or failed KYC / KYB.
7. Fintech submits vendor’s response into Synctera’s create verification API.
8. Synctera or fintech reviews the vendor's KYC / KYB response and approves the customer.
9. Customer creates an account.

📘

Updates as of October 31, 2024

As of October 31, Synctera is requiring certain fields in the persons and businesses APIs mentioned in step 2. Please see the section Required fields for fintechs using their own KYC or KYB vendor at the bottom for further details.

Prerequisites

This guide assumes that you have:

1. Created a personal customer or business customer.
2. Created a KYC collection disclosure.
3. Identified a KYC / KYB vendor and had it approved by your sponsor bank.
4. Integrated the KYC / KYB vendor into your customer onboarding workflow.

Please see the personal customer and business customer guides, for an integrated workflow on creating a customer and collecting KYC disclosures. These must be completed before calling the create verification API.

Create Verification API Call

Fintechs may request multiple categories of KYC and KYB checks from their external vendors - such as watchlist, document verification, identity, among others. In doing so the external vendor will verify that the persons & businesses are not on any government watchlists, their documents are authentic, and they are living. The vendor will respond with an overall status as well details about the different attributes that were verified.

Once the vendor has responded, fintechs may use the create verification API to submit the vendor’s KYC / KYB response to Synctera for review. This API allows for submitting the type of KYC / KYB review, the status of the call as well as pertinent details about the end customer information that was provided to the vendor.

Please note the three items below, when preparing your submission:

Result

The result indicates the overall status or outcome of the KYC / KYB verifications that is returned by the external vendor. A customer must have a result of ‘ACCEPTED’ to move money and perform most business transactions.

1. UNVERIFIED – record representing the absence of a verification.
2. PENDING – verification is in progress for this customer.
3. PROVISIONAL – partially verified or verified with restrictions.
4. ACCEPTED – the customer has been verified.
5. REVIEW – verification has run and issues have been identified and require review.
6. VENDOR_ERROR – verification did not successfully run due to an unexpected error or failure.
7. REJECTED – the customer was rejected and should not be allowed to take certain actions e.g., open an account.

For further details see the create verification API.

Verification Type

Fintechs may use this attribute to indicate the type of KYC/KYB check that was performed. You may submit multiple create verification requests, each corresponding one of the verifications below.

1. IDENTITY: This verifies that the information provided by the customer is associated with the identity of a real person or business, by checking attributes such as name, dob and ssn, among others. While performing identity checks, we recommend that fintechs compare the profile (e.g., name, address, DOB etc) information provided by the customer with the details read off any documents (license or passport) and with third party verification services. See examples 9, 10 and 11 in the Miscellaneous Examples section below.
2. WATCHLIST: Checks the information submitted by the customer (via manual entry or document verification) against watchlists for known fraud, money laundering, and other suspicious activity.
3. DOCUMENT_VERIFICATION: Verifies the authenticity of a document, such as a driver's license, or another government-issued identification document.
4. RELATED_ENTITIES: This represents dependent verification checks for related parties (e.g. all beneficial owners must pass KYC for a business to pass KYB).
5. MANUAL_REVIEW: This represents the outcome of a manual review of the verification done on a party (note: overrides the outcome of other verification types).

For further details see the create verification API.

Details Object

The details object allows fintechs to include the external vendor’s responses to specific attributes. Synctera’s risk team will review these details in assessing whether to approve or reject the customer. We recommend providing as much information as possible via the details object so Synctera’s risk team may conduct a thorough review.

As an example, if the fintech submits a 'DOC_VERIFICATION' check, the external vendor would extract the details of the document (e.g., passport or license) and return them. The fintech would include those attributes in 1 or more details objects as well as the overall outcome (in result).

• Category: Indicates the type of data that is included in this object, CIP, address, phone number, email etc. See the API and learn site for more details.
• Description: A human readable description of the outcome, e.g., “Individual not found on US OFAC watchlist”
• Result: WARN, PASS, FAIL
• Score: Submit numeric scores from the vendor pertaining to the category.
• URL: Submit URL from the vendor pertaining to the category.
• Vendor code: Submit any codes provided by the vendor.

Example 1: The following example shows document verification (e.g., passport or driver's license).

In the description attribute, please provide as much information as you can regarding which document was examined or extracted, if there was forgery and whether or not the attempt was successful. Please adjust this based on your vendor’s response.

curl \
  -X POST \
  $baseurl/v0/verifications \
  -H "Authorization: Bearer $apikey" \
  -H 'Content-Type: application/json' \
  --data-binary '{
  "person_id": "7ef75751-e372-4c12-9b02-b9e4b1faaac9",
  "result": "ACCEPTED",
  "details": [
    {
      "category": "DOC_VERIFICATION",
      "description": "No evidence of tampering or forgery",
      "result": "PASS"
    },
    {
      "category": "DOC_DETAILS",
      "description": "Received passport as supporting documentation",
      "result": "PASS"
    },
    {
      "category": "DOC_DETAILS",
      "description": "Successful OCR extraction of document number, expiration date, and nationality",
      "result": "PASS"
    }
  ],
  "vendor_info": {
    "vendor": "Synctera",
    "content_type": "application/json",
    "json": {
      "key1": "value1",
      "key2": "value2"
    }
  },
  "verification_time": "2024-10-07T12:00:00Z",
  "verification_type": "DOCUMENT_VERIFICATION"
}'

Example 2: The following example shows watchlists checks (e.g., OFAC or US Marshalls Service).

While there is no need to include a details object for each watchlist that was checked, we recommend highlighting the results of the check on the primary watchlists such as OFAC and PEP. Any remaining watchlists that were checked can be grouped into 1 details object with a description such as ‘Individual not found on any other watchlists’. This can be tailored based on your vendor’s response.

curl \
  -X POST \
  $baseurl/v0/verifications \
  -H "Authorization: Bearer $apikey" \
  -H 'Content-Type: application/json' \
  --data-binary '{
  "person_id": "7ef75751-e372-4c12-9b02-b9e4b1faaac9",
  "result": "ACCEPTED",
  "details": [
    {
      "category": "WATCHLIST",
      "description": "Individual not found on any watchlists",
      "result": "PASS",
      "vendor_code": "I708",
      "url": "www.synctera.com"
    },
    {
      "category": "WATCHLIST",
      "description": "Individual not found on US OFAC watchlist",
      "result": "PASS",
      "vendor_code": "I708"
    },
    {
      "category": "WATCHLIST",
      "description": "Individual not found on any PEP watchlists",
      "result": "PASS",
      "vendor_code": "I708"
    }
  ],
  "vendor_info": {
    "vendor": "Synctera",
    "content_type": "application/json",
    "json": {
      "key1": "value1",
      "key2": "value2"
    }
  },
  "verification_time": "2024-10-07T12:00:00Z",
  "verification_type": "WATCHLIST"
}'

Example 3: The following example shows an identity check (e.g., address, email, phone).

In the description attribute, please provide as much information as you can regarding which attributes (e.g., name, address, SSN, email) were checked and the outcome (e.g., address can be resolved to the individual). Please adjust this based on the attributes your vendor checks.

curl \
  -X POST \
  $baseurl/v0/verifications \
  -H "Authorization: Bearer $apikey" \
  -H 'Content-Type: application/json' \
  --data-binary '{
  "person_id": "7ef75751-e372-4c12-9b02-b9e4b1faaac9",
  "result": "ACCEPTED",
  "details": [
    {
      "category": "CIP",
      "description": "Individual's provided documentation was verified successfully.",
      "result": "PASS",
      "vendor_code": "I708"
    },
    {
      "category": "ADDRESS",
      "description": "Address can be resolved to the individual",
      "result": "PASS",
      "vendor_code": "I708"
    },
    {
      "category": "EMAIL",
      "description": "Email address is more than 1 year and less than 2 years old",
      "result": "PASS",
      "vendor_code": "I708"
    }
  ],
  "vendor_info": {
    "vendor": "Synctera",
    "content_type": "application/json",
    "json": {
      "key1": "value1",
      "key2": "value2"
    }
  },
  "verification_time": "2024-10-07T12:00:00Z",
  "verification_type": "WATCHLIST"
}'

Miscellaneous examples of submitting the details object.

The following examples demonstrate the use of the details object across various use cases.

1. Example of individual being found on watchlist

{
    "category": "WATCHLIST",
    "description": "Individual found on 1 or more watchlists",
    "result": "WARN",
    "url": "www.synctera.com",
    "vendor_code": "I708"
}

2. Example of individual being found on US OFAC watchlist

{
    "category": "WATCHLIST",
    "description": "Individual found on US OFAC watchlist",
    "result": "WARN",
    "vendor_code": "I708"
}

3. Example of individual being found on PEP watchlist

{
    "category": "WATCHLIST",
    "description": "Individual found on PEP watchlists",
    "result": "WARN",
    "vendor_code": "I708"
}

4. Example of evidence of tampering or forgery on a passport or other document

{
    "category": "DOC_VERIFICATION",
    "description": "Evidence of tampering or forgery",
    "result": "WARN",
    "vendor_code": "I708"
  }

5. Example of drivers license

{
    "category": "DOC_DETAILS",
    "description": "Received license as supporting documentation",
    "result": "PASS"
  }

6. Example depicting failed extraction of OCR entries

{
    "category": "DOC_DETAILS",
    "description": "Failed OCR extraction of name, dob, sex, and country",
    "result": "WARN",
    "url": "www.synctera.com"  
}

7. Example of Selfie capture success

{
    "category": "SELFIE_CAPTURE",
    "description": "Successfully matched selfie to document portrait",
    "result": "PASS",
    "score": 100
}

8. Example of Selfie capture failed

{
    "category": "SELFIE_CAPTURE",
    "description": "Selfie failed to match to document portrait",
    "result": "WARN"
}

9. Example of successfully matching customer provided information

{
    "category": "DOC_DETAILS",
    "description": "Successfully matched customer information to OCR extracted data fields",
    "result": "PASS"
}

10. Example of failure to match customer provided information with OCR extracted data fields

{
    "category": "DOC_DETAILS",
    "description": "Failed to match customer information to OCR extracted data fields name, dob, sex and country",
    "result": "WARN"
}

11. Example of customer provided information (via document or entered into fintech) matching 3rd party verification services (e.g., name, DOB, SSN and address are associated with each other)

{
    "category": "CIP",
    "description": "Individual’s provided documentation was verified successfully.",
    "result": "PASS"
}

12. Example of failure to match address

{
    "category": "ADDRESS",
    "description": "Address cannot be resolved to individual",
    "result": "WARN"
}

Required fields for fintechs using their own KYC or KYB vendor

Due to more stringent sponsor bank requirements, as of October 31, 2024 the following fields will be required on the persons and businesses APIs. Please be sure to provide these attributes, otherwise the customer may fail KYC/ KYB.

For personal customers, we will require the following (see persons API and persons guide):

1. dob
2. email, phone: At least 1 of email or phone number is required
3. first_name
4. last_name
5. legal_address: address line 1, city, state, postal code, country
6. shipping_address: address line 1, city, state, postal code, country
7. personal_ids: type, id, and country code

For business customers, we will require the following (see businesses API):

1. ein: not required for sole proprietors
2. email, phone: At least 1 of email or phone number is required
3. entity_name
4. legal_address: address line 1, city, state, postal code, country; PO Box is not acceptable

Please see Using your own KYC or KYB vendor for further details on using an external KYC or KYB vendor.