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:

• By using the applicant email address.
• By using a share token.

How Reusable KYC via SDK works

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.

Personal identifier 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 personal identifiers (phone or email). 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 personal identifiers and ensures they will be added to all new applicants verifying with them.
2. Recipient ensures the applicant personal identifier is passed through to Sumsub when SDK is initialised.

Enrich applicant records with personal identifiers

Donor can enrich all their applicant records with personal identifiers 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 personal identifiers moving forward, while the recipient needs to make sure applicant personal identifiers are passed through to Sumsub when SDK is initialised.

Both donor and recipient can do this by simply passing through a personal identifier when the SDK is initialised. To do so, they can generate an access token with the personal identifier.

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 personal identifiers, 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 personal identifier.

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"
            }
      '

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.

2. Donor passes the share token to the recipient.
3. 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.",
            }
      '

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.

📘

Note

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

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 personal identifier 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 a personal identifiers 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 personal identifier added in Step 1 using one of the following methods.

• Initialise the SDK by including the personal identifier 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 or Phone field, enter the personal identifier from Step 1.

You should now see the Reusable KYC flow.

🚧

Attention

The flow will still only start if the applicant matching the personal identifiers 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 to reuse questionnaires

Reusable KYC via API supports reuse of questionnaires. The system reuses individual question responses when the donor and recipient questionnaires match on structure and answer options.

To reuse a question response, all of the following must match:

• Question and section IDs. The question ID and section ID on the donor questionnaire must exactly match the question ID and section ID on the recipient questionnaire.
• Response value. The response value from the donor applicant must exactly match one of the response options configured for the same question ID on the recipient side.

When these conditions are met, the system copies the donor’s response to the corresponding question in the recipient questionnaire. If the system can copy responses for all required questions in a questionnaire, it treats that questionnaire as completed.

📘

Note

The questionnaire step only gets the Approved status when the applicant itself reaches the approved state.

To make sure the donor and recipient questionnaires match, we recommend using the Export and Import questionnaire functionality available in the Dashboard.

The following steps describe how to align the questionnaires on the donor side:

1. In the Dashboard, open Integrations and go to the Questionnaires section.
2. Find the questionnaire that you want to reuse.
3. Open the actions menu on the right and click Export.
4. Save the exported questionnaire data by clicking the Copy to clipboard button in the pop-up window.
5. Send the export to the recipient.

The following steps describe how to align the questionnaires on the recipient side:

1. In the Dashboard open Integrations and go to the Questionnaires section.
2. Click Import questionnaire.
3. Paste the questionnaire data you received previously and click the Create questionnaire button.
4. Add the imported questionnaire to the relevant verification level. For more instructions, see this article.

Once these steps are completed, the donor and recipient questionnaires will contain the same data.