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.

Sumsub Reusable KYC can be implemented in two main approaches:

• Reusable KYC via SDK
• Reusable KYC via API

📘

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:

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

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

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 initialising the WebSDK for the relevant applicant. For more information on how to initiate the WebSDK integration, see this article.

See the following example which includes share token in WebSDK initialization:

/**
 * @param accessToken - access token that you generated on the backend
 * @param shareToken - shareToken that generated from existing applicant (not required)
 */
function launchWebSdk(accessToken, shareToken) {
    let snsWebSdkInstance = snsWebSdk
        .init(
            accessToken,
            // token update callback, must return Promise
            // Access token expired
            // get a new one and pass it to the callback to re-initiate the WebSDK
            () => this.getNewAccessToken()
        )
        .withConf({
            lang: "en", //language of WebSDK texts and comments (ISO 639-1 format)
            theme: "dark" | "light",
        })
        .withOptions({ addViewportTag: false, adaptIframeHeight: true })
        .withReusableKycConf({ shareToken: shareToken})
        // see below what kind of messages WebSDK generates
        .on("idCheck.onStepCompleted", (payload) => {
            console.log("onStepCompleted", payload);
        })
        .on("idCheck.onError", (error) => {
            console.log("onError", error);
        })
        .build();

    // you are ready to go:
    // just launch the WebSDK by providing the container element for it
    snsWebSdkInstance.launch("#sumsub-websdk-container");
}

function getNewAccessToken() {
    return Promise.resolve(newAccessToken); // get a new token from your backend
}

📘

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: 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 directional or bidirectional sharing.

Step 3: Choose approach

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

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:

1. Service X generates a new share token and passes it to Service Y.
2. Service Y imports the applicant with the received share token and obtains information on applicant A 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:

1. Contact our support team at [email protected] and sign a tripartite agreement on personal data sharing between you, Sumsub, and your partner service.
2. Generate a share token and import applicants.
3. 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"
            }
      '

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'

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