Reusable KYC
Make it simple for your applicants to pass verification — reuse existing verification results.
With Reusable KYC, Sumsub clients can partner up with each other to simplify and speed up verification for their applicants that have already passed it.
Such an approach minimizes onboarding drop-offs and verification cost and enables your applicants to avoid repeat verification when they need to access multiple services.
How it works
Let's assume an applicant A
passed user verification in Service X
and is now registering at the partner Service Y
. If Service X
agrees to share the information about A
with Service Y
, it can be done as follows:
Service X
generates a new share token and passes it toService Y
.Service Y
imports the applicant with the received share token and obtains information on applicantA
with all of its data and documents.
Tip
You can also request to reset a document type if the verification flow is different for the client and partner.
There are two ways Sumsub processes reusable KYC data:
- Applicant copying. Sumsub copies the applicant data from one partner dataset to another in case their check flows coincide. As all applicants have unique IDs, you will be able to see the source ID from which your applicant was imported. If the applicant profile has a questionnaire attached, a copy of this questionnaire will be created and attached to the new applicant profile.
- Applicant copying with rechecks. Sumsub copies the applicant data from the partner’s dataset and runs all required checks again to ensure compliance. Note that if your flow includes an AML check, you cannot use applicant copying without rechecks.
Get started
To turn on the data sharing functionality:
- Contact our support team at [email protected] and sign a tripartite agreement on personal data sharing between you, Sumsub, and your partner service.
- Generate a share token and import applicants.
- Conduct verification and review verification results.
Generate share token
Must be done by
Service X
.
To generate a share token, use any of the following API methods:
## applicantId and Y's client ID must be provided
curl -X POST \
'https://api.sumsub.com/resources/accessTokens/-/shareToken?applicantId=5ce412012b4da877b2d910bd&forClientId=CoolCoinLtd'
## applicantId and Y's client ID must be provided
curl --request POST \
--url https://api.sumsub.com/resources/accessTokens/shareToken \
--header 'content-type: application/json' \
--data '
{
"applicantId": "63e092c51b7b4030f2e01154",
"forClientId": "CoolCoinLtd",
"ttlInSecs": "600"
}
'
Name | Type | Required | Description |
---|---|---|---|
applicantId | String | Yes | Applicant ID in Service X . |
forClientId | String | Yes | Client ID for Service Y . You can find your clientId in the Dashboard in the applicant profile (field Created for) and in the response (field clientId ). |
ttlInSecs | Integer | No | Time to live in seconds. Default 1200 . |
Response
A new share token is returned.
{
"token": "eyJhbGciOiJub25lIn0.eyJqdGkiOiJfYWN0LTZmODI2ZTU0LTE2MzctNDViMS05NzMyLWY1MjZiN2YxNWE3YyIsInVybCI6Imh0dHBzOi8vYXBpLnN1bXN1Yi5jb20ifQ.",
"forClientId": "CoolCoinLtd"
}
Info
Make sure your integration code does not validate or analyze the access token content, as the format is not fixed and may undergo further changes in the future. The token must be treated as an arbitrary string with the maximum length of 1KB.
Import applicants
Must be done by
Service Y
.
To import the applicant data, use this API method:
curl -X POST \
'https://api.sumsub.com/resources/applicants/-/import?shareToken=_act-0b8a43f6-b70f-4ad3-bda9-7ce904589380'
Name | Type | Required | Description |
---|---|---|---|
shareToken | String | Yes | Share token generated by Service X . |
resetIdDocSetTypes | String | No | Specify one or few comma-separated document types if an applicant has to resubmit the documents. Examples, SELFIE , IDENTITY , etc. |
trustReview | Boolean | No | If you trust your partner check results, use true . If it is false , then the applicant will be rechecked. Default false . |
userId | String | No | Sets your own externalUserId for the imported applicant. In case of an empty value, we will generate a random one. |
levelName | String | Yes | Sets the specified levelName to the imported applicant and sets init in case not all required documents are present. |
Response
An applicant entity in Service Y
. A new applicant ID is returned.
{
// Applicant in service Y
"id": "5d08a63239b79354a2ebaa1d",
"createdAt": "2019-06-18 10:52:02",
"clientId": "CoolCoinLtd",
...
}
Important
Share tokens are invalidated once used.
Data sharing restrictions
Any organizations that possess the data of those who are located in the EU/UK or to which the EU GDPR/UK GDPR apply must obey the data sharing rules of these acts.
If you operate in the European Economic Area (EEA) or offer goods and services to individuals or monitor the behaviour of individuals there, the EU GDPR may still apply to you.
Before any data sharing between the organizations, these organisations must check whether it’s legitimate to share such data and whether it is necessary to enter into the appropriate legal arrangement.
Sometimes, the organisations must implement appropriate safeguards for international transfers if such occurs.
Updated about 1 month ago