Reusable KYC
Boost your verification conversion rate — enable your applicants to seamlessly reuse data from previous verifications.
With Reusable KYC, you can conclude an agreement with other Sumsub clients to share verification data, and enable applicant data reuse to complete your specific verification checks. It will allow you to speed up verification for your applicants, while still maintaining the same level of compliance:
- Your applicants will complete repetitive verifications faster, which means a better onboarding experience and higher conversion rates.
- Your compliance requirements will be met, and data privacy regulations will be adhered to at all times.
How Reusable KYC via SDK works
Once clients agree to share verification data, they become the donor and recipient. You can have an unlimited number of sharing partners, and Sumsub also supports bidirectional sharing.
Reusable KYC setup for both the donor and recipient involves enabling automatic matching of applicants across sharing partners. To do so, Sumsub uses applicant email addresses. You will need to perform the setup only once and after that you will not have to perform any additional actions:
- Donor enriches all their applicant records with email addresses and ensures emails will be added to all new applicants verifying with them.
- Recipient ensures applicant email is passed through to Sumsub when SDK is initialised.
Once this is complete, whenever an applicant needs to verify with the recipient company, Sumsub will automatically identify if an applicant has verified previously with any data sharing partners, by matching the email address.

For the applicants, the process contains the following steps:
- If the applicant has verified previously, Sumsub will check that the verification data with the donor will be reusable in the recipient specific level configuration.
- If the data is reusable, the applicant will see a consent screen to collect explicit permission from them to transfer and reuse the verification data with the recipient.
- To confirm the document data ownership, the applicant must pass a Liveness check.
- Sumsub reuses transferred data to complete recipient verification checks wherever it is possible, e.g. ID verification or PoA.
Note
If any remaining checks require more or updated documents, we will directly ask the applicant to provide the requested data.
This approach is designed with data privacy in mind. We are collecting explicit consent for data transfers on behalf of our clients, to strengthen the legality of data transfers and provide transparency to their applicants.
Reusable KYC provides a great user experience that boosts your verification conversion, all while maintaining the same high level of compliance you expect from Sumsub.

Enable Reusable KYC for SDK
Note
Reusable KYC via SDK only works on WebSDK 2.0. To migrate from WebSDK 1.0 to WebSDK 2.0, follow the instructions given in this article.
Step 1: Sign contract
Contact our support team at business-support@sumsub.com so that the donor and recipient can sign a one-time contract to use the service. You will not have to sign any additional documents.
Step 2: Provide written confirmation
Both the donor and recipient need to provide us written confirmation of which companies you want to share data with. Specify if it is a directional or bidirectional sharing.
Step 3: Enrich applicant records with email addresses
Donor enriches all their applicant records with email addresses. They can do it either by providing Sumsub a CSV file with the required data or directly using this API method.
curl -X PATCH \
'https://api.sumsub.com/resources/applicants' \
-H 'Content-Type: application/json' \
-d '{
"id": "5e9ad53d0a975a656d67e4d0",
"externalUserId": "userIdOnYourSide",
"email": "new@email.com",
"phone": "+49 123456789",
"sourceKey": "newSourceKey",
"metadata": [
{
"key": "keyFromClient",
"value": "valueFromClient"
}
],
"lang": "en"
}'
Donor also needs to enrich any new applicant profiles with email addresses moving forward, while recipient needs to make sure applicant email addresses are passed through to Sumsub when SDK is initialised.
Both donor and recipient can do this by simply passing through an email address when the SDK is initialised. To do so, they can generate an access token with the email address.
Example of such a request:
curl --request POST \
--url https://api.sumsub.com/resources/accessTokens/sdk \
--header 'content-type: application/json' \
--data '
{
"applicantIdentifiers": {
"email": "john.doe@domain.com",
"phone": "555-1111"
},
"ttlInSecs": 600,
"userId": "johndoeID",
"levelName": "basic-kyc-level"
}
'
You can also do this by pre-creating an applicant with the email address, and then initialising SDK for them.
Note
Sumsub currently supports implementations in both SDK and API, however using the SDK version will provide the most compliant and streamlined experience.
How Reusable KYC via API 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.
Enable Reusable KYC for API
To turn on the data sharing functionality:
- Contact our support team at business-support@sumsub.com 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.
Step 1: Generate share token
Must be done by
Service X
.
To generate a share token, use this API method:
## 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.
Step 2: 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 9 days ago