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.

Reusable KYC can be implemented in two main approaches:

📘

Note

While both approaches are supported, the SDK version requires less technical orchestration and ensures explicit user consent is collected for the data transfer.

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.

You can implement Reusable KYC via SDK in two ways:

Regardless of the implementation, the applicant experience remains the same and contains the following steps:

  1. If the applicant has been verified previously, Sumsub will check that the verification data with the donor will be reusable in the recipient's specific level configuration.
  2. 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.
  3. To confirm the document data ownership, the applicant must pass a Liveness check.
  4. Sumsub reuses transferred data to complete recipient verification checks wherever it is possible, for example, 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.

Email address based implementation

In this implementation, 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:

  1. Donor enriches all their applicant records with email addresses and ensures emails will be added to all new applicants verifying with them.
  2. Recipient ensures the applicant email is passed through to Sumsub when SDK is initialised.

Enrich applicant records with email addresses

Donor can enrich all their applicant records with email addresses 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": "[email protected]",
          "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 the 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": "[email protected]",
                "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.

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.

Share token based implementation

In this implementation, every time the recipient client uses Reusable KYC for a streamlined verification, the following steps should be completed:

  1. Donor generates a new share token for a specific applicant. To generate a share token, use this API method:
curl --request POST \
     --url https://api.sumsub.com/resources/accessTokens/shareToken \
     --header 'content-type: application/json' \
     --data '
            {
              "applicantId": "63e092c51b7b4030f2e01154",
              "forClientId": "CoolCoinLtd",
              "ttlInSecs": "600"
            }
      '
NameTypeRequiredDescription
applicantIdStringYesApplicant ID in Donor company.
forClientIdStringYesClient ID for Recipient. You can find your clientId in the Dashboard in the applicant profile (field Created for) and in the response (field clientId).
ttlInSecsIntegerNoTime 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.

  1. Donor passes the share token to the recipient.
  2. Recipient includes the share token when generating an access token, which will be automatically used to start a Reusable KYC flow where possible, whenever that access token is used. For more information on how to generate an access token, see this article.

Request example:

curl --request POST \
     --url https://api.sumsub.com/resources/accessTokens/sdk \
     --header 'content-type: application/json' \
     --data '
            {
              "applicantIdentifiers": {
                "email": "[email protected]",
                "phone": "555-1111"
              },
              "ttlInSecs": 600,
              "userId": "johndoeID",
              "levelName": "basic-kyc-level",
              "shareToken": "eyJhbGciOiJub25lIn0.eyJqdGkiOiJfYWN0LTZmODI2ZTU0LTE2MzctNDViMS05NzMyLWY1MjZiN2YxNWE3YyIsInVybCI6Imh0dHBzOi8vYXBpLnN1bXN1Yi5jb20ifQ.",
            }
      '

📘

Note

The donor and recipient must coordinate on the timing and method of generating and providing the share token to ensure that it corresponds to the same applicant across both platforms.

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 [email protected] 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: Add sharing partners

Once the service is enabled, you can add sharing partners directly in the Dashboard. For more instructions, see this article.

Step 3: Choose approach

Implement either a share token or email based approach as described above.

How to test Reusable KYC via SDK in Sandbox

You can test Reusable KYC via SDK in Sandbox mode without the need to create a new level. Switch to the Sandbox as described here and use your existing level.

Before sharing agreements are set up, you can test sharing using Reusable KYC within the same key, which means your client key is both the donor and recipient.

Email address based implementation

The following is a sequence of steps to be taken to test the email address based implementation of the Reusable KYC via SDK.

Step 1: Create applicant

Create an applicant in Sandbox in your chosen level. Make sure the applicant is approved, has reusable documents, and meets the requirements of level you want to test with.

Add an email address to the applicant. This can be done directly in the applicant profile.

Step 2: Add Reusable KYC preset

Add Sandbox testing preset with Reusable KYC option:

  1. Switch to Sandbox mode and go to a level.
  2. Go to Sandbox mode for verification testing.
  3. Select preset. You can either modify an existing preset or create a new one by clicking Edit.
  4. Tick the checkbox Enable Reusable KYC. Make sure this preset is applied to the level you want to test.

Step 3: Initiate SDK

Initiate the SDK with the applicant email address added in Step 1 using one of the following methods.

  • Initialise the SDK by including the email address as part of the access token as described here.
  • In the Dashboard, open Integrations and select the level of interest. In the top menu, click Verification links, go to the Permalinks, and select Additional link options. In the Email field, enter the email address from Step 1.

You should now see the Reusable KYC flow.

🚧

Attention

The flow will still only start if the applicant matching the email address is approved, has enough documents to meet the requirements for the level, and the level has Liveness in it.

Share token based implementation

The following is a sequence of steps to be taken to test the share token based implementation of the Reusable KYC via SDK.

Step 1: Create applicant

Create an applicant in Sandbox in your chosen level. Make sure the applicant is approved, has reusable documents, and meets the requirements of level you want to test with.

Step 2: Generate share token

Generate a share token for the applicant using one of the following methods.

  • Use this API method. Make sure to include an app token configured for Sandbox environment in the request.
  • In the Dashboard, go to the Applicants page and select the applicant of interest. In the drop-down menu on the top of the page, click Generate share token.

Step 3: Initialise SDK

Initialise the SDK with the share token using one of the following methods.

  • You can initialise the SDK with the share token included, by including the share token when creating an access token as described here.
  • In the Dashboard, open Integrations and select the level of interest. In the top menu, click Verification links, go to the Permalinks, and select Additional link options. In the Share token field, enter the share token you generated in Step 2.

You should now see the Reusable KYC flow.

🚧

Attention

The flow will still only start if the applicant matching the share token is approved, has enough documents to meet the requirements for the level, and the level has Liveness in it.

How Reusable KYC via API works

Reusable KYC via API will always recheck applicant data to make sure it meets the recipient level requirements. It is recommended for clients requiring a regulatory compliant KYC on the recipient side.

👍

Tip

If needed, you can copy applicant data without rechecks with the Copy Applicant solution.

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.

Our Reusable KYC via API solution uses a share token based approach to transfer verified applicant data from the donor to the recipient. Upon receipt, all shared data is always rechecked against the specific level settings and requirements of the recipient.

For example, the identity document will be rechecked to ensure it matches the accepted document type, remains valid (i.e., not expired), and, if required by the recipient’s verification level, applicable AML checks are run again.This approach guarantees that this will count as a KYC for the recipient by regulatory standards and meets the specific compliance requirements of our clients.

Only applicant data that is reusable under the recipient’s verification level settings is transferred, ensuring full compliance with end-user data privacy. Three main cases:

  • Approved applicant. If the donor applicant profile contains enough data to meet requirements of all recipient verification steps, the system completes all checks and assigns the applicant an Approved status.
  • Documents requested. If the donor applicant profile contains data that meets some, but not all of the requirements of recipient verification steps, then the applicant will be assigned with a Documents requested status to fulfill the remaining steps at a later point.
  • No applicant created. In the case the applicant data from the donor meets none of the requirements of the recipient verification steps, an applicant will not be created and no data will be copied. We will return an error with information on why no data was transferred.

📘

Note

We do not require Liveness check for Reusable KYC via API. If the provided recipient’s verification level includes a liveness step, the system reuses the selfie from the donor applicant profile to perform the check again.

If no selfie is available, the system sets the applicant status to documents requested, so the applicant can complete liveness at a later point.

Reusable KYC via API involves the following steps:

  1. Donor generates a new share token for a specific applicant. To generate a share token, use this API method:
curl --request POST \
     --url https://api.sumsub.com/resources/accessTokens/shareToken \
     --header 'content-type: application/json' \
     --data '
            {
              "applicantId": "63e092c51b7b4030f2e01154",
              "forClientId": "CoolCoinLtd",
              "ttlInSecs": "600"
            }
      '
NameTypeRequiredDescription
applicantIdStringYesApplicant ID in donor company.
forClientIdStringYesClient ID for recipient. You can find your clientId in the Dashboard in the applicant profile (field Created for) and in the response (field clientId).
ttlInSecsIntegerNoTime 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.

  1. Donor passes the share token to the recipient.
  2. Recipient includes the share token when using this API method to attempt to reuse verification data from the donor.
curl -X POST \
    'https://api.sumsub.com/resources/api/reusableIdentity/reuse?shareToken=_act-jwt-eyJhbGciOiJub25lIn0.eyJqdGkiOiJfYWN0LTE3YjM5YTljLWRhOWUtNGY2MS04Y2ZjLTYwNzViNWM2NDk5MSIsInVybCI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA5MCJ9.&levelName=liveness-id-poa'
NameTypeRequiredDescription
shareTokenStringYesA token used to access the shared KYC data.
userIdStringNoExternal user identifier.
levelNameStringYesThe name of the level on the recipient's side for which the KYC data is being reused.

Response

If at least one document or part of the applicant’s data meets the requirements of the recipient’s level, the system creates an applicant on the recipient side and reuses all eligible documents. In this case the applicant profile data will be returned:

{
    "id": "689223ed75b5d1bc2bb38gdg",
    "createdAt": "2025-08-05 15:31:57",
    "key": "UUBSGJZXJDFXXW",
    "clientId": "DonorCompany"
…
}

If no documents meet the recipient’s level requirements, the system returns an error message and does not create an applicant. See this article for the full list of possible errors.

{ 
  "code": 400,
    "errorCode": 10513,
    "errorName": "reusable-kyc-not-compatible-doc-type",
    "description": "Not Reusable KYC for level: id-liveness-preview",
    "type": "de.smtdp.commons.service.exceptions.ServiceException"
}

📘

Note

We support reuse of identity documents, PoA documents, and liveness data. Questionnaire and applicant data reuse is not yet supported, but this functionality is planned for a future release.

Enable Reusable KYC for API

The following is a sequence of steps to be taken to turn on the data-sharing functionality.

Step 1: Sign contract

Contact our support team at [email protected] so that the donor and recipient can each sign a one-time contract to use the service. You will not have to sign any additional documents.

Step 2: Add sharing partners

Once the service is enabled, you can add sharing partners directly in the Dashboard. For more instructions, see this article.

Step 3: Use share token

Implement the share token approach as described here.

How to test Reusable KYC via API using Preview

To simplify integration testing, use this API method to simulate the Reusable KYC via API flow. This method performs validation and preview logic only—it does not create applicants or transfer any data. You can use this method with production data.

curl -X POST \
    'https://api.sumsub.com/resources/api/reusableIdentity/reuse/preview?shareToken=_act-jwt-eyJhbGciOiJub25lIn0.eyJqdGkiOiJfYWN0LTE3YjM5YTljLWRhOWUtNGY2MS04Y2ZjLTYwNzViNWM2NDk5MSIsInVybCI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA5MCJ9.&levelName=liveness-id-poa'

This method allows you to verify that your integration is correctly set up to handle all possible responses, create applicants, and reuse documents appropriately. The method utilises the same query parameters and follows the same requirements as the live flow.

How to test Reusable KYC via API in Sandbox

You can test Reusable KYC via API in Sandbox mode without the need to create a new level. Switch to the Sandbox as described here and use your existing level.

Before sharing agreements are set up, you can test sharing using Reusable KYC within the same key, which means your client key is both the donor and recipient.

The following is a sequence of steps to be taken to test the share token based implementation of the Reusable KYC via API in Sandbox.

Step 1: Create applicant

Create an applicant in Sandbox in your chosen level. Make sure the applicant is approved, has reusable documents, and meets the requirements of the level you want to test with.

Step 2: Generate share token

Generate a share token for the applicant using one of the following methods:

  1. Use this API method. Make sure to include an app token configured for the Sandbox environment in the request.
  2. In the Dashboard, go to the Applicants page and select the applicant of interest. In the drop-down menu on the top of the page, click Generate share token.

Step 3: Reuse applicant via API

Use this API method and include an app token configured for the Sandbox environment in the request.

This should now trigger the Reusable KYC via API flow and create an applicant. You can reuse any documents with your client key acting as both the donor and recipient.

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 applies 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 behavior 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.