Reusable KYC Share
Reuse verified applicant's data from trusted partners for faster, compliant onboarding.
cReusable KYC Share lets you securely transfer and reuse applicant verification data from trusted partners. This helps you onboard users without asking them to upload documents or pass the same checks again.
After the client authorizes data sharing, the parties establish a donor-recipient relationship. Clients can configure multiple sharing partners in the Dashboard. Reusable KYC Share also supports bidirectional data sharing.
When the recipient reuses applicant's data, Sumsub runs fresh checks against the recipient’s level settings to make sure the reused data meets their compliance requirements.
How Reusable KYC Share works
Reusable KYC Share uses a share token to transfer verified applicant's data from the donor to the recipient.
The flow includes the following steps:
- Donor generates a share token for a verified applicant and sends it to the recipient.
- Recipient uses the share token to reuse applicant profile.
- Sumsub maps verification requirements between the donor and recipient's profiles and transfers only the matching data intersection.
- Sumsub runs fresh checks against the recipient’s level settings.
- Sumsub assigns the applicant status on the recipient side based on the reuse result and request parameters.
For example, Sumsub can check whether the reused identity document:
- Has an accepted document type.
- Was issued by an accepted country.
- Meets age requirements.
- Has not expired.
These checks help the recipient treat the reused verification as a fresh KYC verification.
Step matching and data transfer
Sumsub transfers data only for verification steps that overlap between the donor and recipient levels.
For each matching step, Sumsub can transfer the following data:
| Data type | Description |
|---|---|
| Check results | Document images, selfie images, verification states, and related data. |
| Data fields | Text attributes and applicant profile data extracted on the donor side. |
| OCR results | Existing text recognition results. |
If the donor and recipient levels do not have matching verification steps, Sumsub does not create an applicant profile on the recipient side and returns a reuse error.
Reuse outcomes
Depending on the donor data and the recipient level configuration, the reuse attempt can result in one of the following outcomes.
| Outcome | Description |
|---|---|
| Approved applicant | The donor profile contains all required steps, passes the required share checks, or the recipient chooses to inherit the status automatically. Sumsub completes the process and assigns the applicant an Approved status. |
| Documents requested | The donor profile does not contain all required data, additional steps are required, or share checks detect discrepancies. Sumsub assigns the applicant a Documents requested status. |
| No applicant created | The donor and recipient levels do not have matching verification steps. Sumsub does not create an applicant profile, does not transfer data, and returns a reuse error. |
Request parameters
When the recipient uses this API method, they can control how Sumsub processes reused applicant data with the following request body parameters.
| Parameter | Type | Default value | Description |
|---|---|---|---|
preserveVerificationStatus | Boolean | false | Defines whether Sumsub preserves the donor verification status or evaluates the reused data against the recipient level settings.
|
requireFreshSelfie | Boolean | false | Defines whether Sumsub resets the selfie step on the recipient side. This parameter works only when preserveVerificationStatus=false. If preserveVerificationStatus=true, Sumsub ignores this parameter.
|
Share checks
After Sumsub transfers matching data, it generates a Reusable KYC Report with fresh verification timestamps.
NoteWhen conducting fresh checks of POA and POI documents, Sumsub utilizes OCR results from the previous checks made on the donor side.
The Report includes the results of fresh share checks and transferred data.
| Check name | UI result | Description |
|---|---|---|
Proof of Identity (POI) | ||
| Document type accepted / not accepted | Checks whether the document type is allowed by the recipient level. |
| Issuing country accepted / not accepted | Checks whether the document issuing country is accepted by the recipient level. |
| Age accepted / not accepted | Checks whether the applicant meets age requirements. |
| Document not expired / Document expired | Checks whether the identity document is valid and not expired. |
| Required document sides uploaded / missing | Checks whether all required document sides are available. |
Proof of Address (POA) | ||
| Document type accepted / not accepted | Checks whether the address document type is allowed by the recipient level. |
| Address country accepted / not accepted | Checks whether the address country is accepted by the recipient level. |
| Document name accepted / not accepted | Checks whether the document name matches level settings. |
| Language accepted / not accepted | Checks whether the document language is supported. |
| Document not expired / Document expired | Checks whether the document is within the allowed issue date range. |
| Address format is valid / is not valid | Checks whether the extracted address has a valid format. |
| Organization accepted / not accepted | Checks whether the issuing organization is trusted. |
| POI and POA are different / same document | Checks whether the same file can be used for POI and POA. |
Cross-Check | ||
| Matched rules | Checks whether applicant data passes custom cross-verification rules. |
Duplicate Check | ||
| No duplicates | Checks whether the recipient account contains duplicate applicant profiles. |
NoteEach POI or POA check can return one of the following statuses:
GREEN— Sumsub conducted a fresh check for the document, and the document meets the recipient level requirements.RED— Sumsub conducted a fresh check for the document, and the document does not meet the recipient level requirements.YELLOW— Sumsub does not have enough donor data to complete a specific POI or POA check.These statuses apply to a specific check, not to the entire step or level.
If
preserveVerificationStatus=false, Sumsub sets the applicant status to Documents requested.If
preserveVerificationStatus=true, the applicant remains approved regardless of the check status.
Use this API method to get the Reusable KYC Report. Request example:
curl -X GET \
'https://api.sumsub.com/api/reusableIdentity/69ce35c7b776d140bb500000/reports?levelName=basic-kyc-level' \
-H 'Authorization: Bearer token' \
-H 'Content-Type: application/json' \
-H 'X-App-Token: <your-app-token>' \
-H 'X-App-Access-Sig: <your-signature>' \
-H 'X-App-Access-Ts: <unix-timestamp>'Reuse of specific level steps
In addition to documents and verification results, Sumsub can reuse specific applicant data objects from the donor profile. This includes face match and liveness, confirmed email and phone verification results, standard applicant profile fields, and questionnaire data.
Sumsub transfers these level steps to the recipient profile when the donor and recipient configurations support the same data structure or verification step. Some level steps, such as email and phone verification, can be reused without asking the applicant to complete the same check again.
Email and phone
If the donor applicant passed email or phone verification, Sumsub transfers these values and their confirmation results to the recipient profile.
The recipient applicant receives the confirmed email or phone status without passing OTP verification again.
Applicant data
Sumsub transfers text attributes and core profile data from the donor profile without running OCR again on the recipient side.
Note
- Only fields supported by the provided level are reused.
- Custom fields are not transferred or reused.
Questionnaires
Sumsub can transfer individual questionnaire answers to the recipient profile if the donor and recipient questionnaires have matching structure and response options.
For successful mapping, the following properties must match exactly:
- Question and section IDs. The question IDs must be identical in both questionnaire configurations.
- Response options. The applicant’s answer on the donor side must match one of the predefined options on the recipient side.
To align questionnaire structures, use the following export and import options in the Dashboard.
Export questionnaire on donor side
The following steps describe how to align the questionnaires on the donor side:
- In the Dashboard, open Integrations and go to the Questionnaires section.
- Find the questionnaire that you want to reuse.
- Open the actions menu on the right and click Export.
- Save the exported questionnaire data by clicking the Copy to clipboard button in the pop-up window.
- Send the export to the recipient.
Import questionnaire on recipient side
The following steps describe how to align the questionnaires on the recipient side:
- In the Dashboard open Integrations and go to the Questionnaires section.
- Click Import questionnaire.
- Paste the questionnaire data you received previously and click the Create questionnaire button.
- 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.
Workflow Builder
Reusable KYC Share supports multi-stage document and data reuse across custom levels configured in Workflow Builder.
As the applicant moves through the workflow, Sumsub does the following:
- Re-evaluates step matching at each stage and carries forward matching data.
- Generates Reusable KYC Share Report at each workflow level.
AML screening handling
Reusable KYC Share handles AML screening differently depending on the preserveVerificationStatus value.
| Parameter value | AML screening behavior |
|---|---|
preserveVerificationStatus=false | Sumsub automatically starts AML screening if AML screening is enabled in the recipient level. Sumsub screens only applicants who qualify for the Approved status on the recipient side. |
preserveVerificationStatus=true | Sumsub does not start automated AML screening during reuse. If you need to run AML screening check, trigger it separately using this API method. |
Enable Reusable KYC Share
The following is a sequence of steps to be taken to turn on the data-sharing functionality.
Step 1: Generate share token
The donor generates a temporary share token for a verified applicant. To generate a share token, use this API method:
Request example:
curl --request POST \
--url https://api.sumsub.com/resources/accessTokens/shareToken \
--header 'content-type: application/json' \
--data '{
"applicantId": "63e092c51b7b4030f2e01154",
"forClientId": "CoolCoinLtd",
"ttlInSecs": 600
}'Request body parameters:
| Parameter | Type | Required | Description |
|---|---|---|---|
applicantId | String | Yes | Applicant ID on the Donor side. |
forClientId | String | Yes | Client ID of the Recipient account. |
ttlInSecs | Integer | No | Share token time to live, in seconds. Defaults to 1200. |
Response
A new share token is returned.
{
"token": "eyJhbGciOiJub25lIn0.eyJqdGkiOiJfYWN0LTZmODI2ZTU0LTE2MzctNDViMS05NzMyLWY1MjZiN2YxNWE3YyIsInVybCI6Imh0dHA6Ly9hcGkuc3Vtc3ViLmNvbSJ9.",
"forClientId": "CoolCoinLtd"
}
NoteDo not validate, parse, or analyze the access token content in your integration code. The token format is not fixed. Treat the token as an arbitrary string with a maximum length of 1 KB.
The donor must send a new share token to the recipient to proceed with the reuse flow.
Step 2: Reuse applicant data
The recipient sends the share token to Sumsub to create a reused applicant profile and run background checks using this API method.
Request example:
curl 'http://localhost:8080/resources/api/reusableIdentity/reuse?shareToken=_act-snsId-56e87868-e249-43eb-98ce-30fd116b196d&levelName=selfie-id-otps' \
--header 'Content-Type: application/json' \
--data '{
"requireFreshSelfie": false,
"preservedVerificationStatus": false
}'Request parameters:
| Parameter | Type | Required | Description |
|---|---|---|---|
shareToken | String | Yes | Share token provided by the donor. |
levelName | String | Yes | Verification level on the recipient side. |
preserveVerificationStatus | Boolean | No | Defines whether the applicant inherits the donor verification status or receives a status based on share checks. Defaults to false. |
requireFreshSelfie | Boolean | No | Defines whether Sumsub reuses the donor liveness result or asks the applicant to pass a new liveness check. Defaults to false.Applicable only when the preserveVerificationStatus value is false. |
userId | String | No | External user identifier from your platform. |
sourceKey | String | No | Authorized tracking source key configured on your account. |
Response example:
{
"id": "689223ed75b5d1bc2bb38gdg",
"createdAt": "2026-07-08 21:28:40",
"key": "UUBSGJZXJDFXXW",
"clientId": "RecipientCompany",
"status": "init"
}Track share token consumption
Donors can track applicant share token processing by configuring the following webhooks in the Dashboard.
| Webhook | Description |
|---|---|
| applicantShareTokenConsumed | Triggered when an applicant share token is successfully consumed and applicant data is reused. |
| applicantShareTokenFailed | Triggered when applicant data reuse fails. |
NoteThese webhooks support applicant share tokens only. They do not apply to Sumsub ID share tokens.
Test Reusable KYC Share
You can test Reusable KYC Share in Sandbox without a legal agreement. For testing purposes, the same Sandbox client key can act as both the donor and the recipient.
Step 1: Configure Sandbox verification preset
Create a verification preset and apply it to the required verification level:
- Switch to the Sandbox in the Dashboard.
- Navigate to the Sandbox mode for verification testing page.
- Click on an existing preset or select Create new verification preset.
- Adjust the preset settings:
- Select the Automated applicant review option.
- From the Face match drop-down list, select Always approve.
- Check the Enable Reusable KYC box.
Note
If you use a verification preset, you must enable Reusable KYC in the preset settings. Otherwise, Reusable KYC will not work for the level where this preset is applied.
If no preset is applied, Reusable KYC can still work when you pass a valid share token. However, in this case, Face match returns
REDby default. To avoid this during testing, use a preset with Face match set to Always approve.
- Save the preset.
- Apply the preset to the relevant verification level.
Step 2: Run reuse flow
- Create an applicant in Sandbox using the selected verification level.
- Make sure the applicant receives the
Approvedstatus. - Generate a share token for the applicant using one of the following options:
- Use this API method. Make sure to include an app token configured for the 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.
- Use this API method and include an app token configured for the Sandbox environment in the request.
Request example:curl -X POST \ 'https://api.sumsub.com/resources/api/reusableIdentity/reuse?shareToken=_act-jwt-eyJhbGciOiJub25lIn0.eyJqdGkiOiJfYWN0LTE3YjM5YTljLWRhOWUtNGY2MS04Y2ZjLTYwNzViNWM2NDk5MSIsInVybCI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA5MCJ9.&levelName=liveness-id-poa' \ -H 'X-App-Token: <your-app-token>' \ -H 'X-App-Access-Sig: <your-signature>' \ -H 'X-App-Access-Ts: <unix-timestamp>'
This triggers the Reusable KYC Share flow and creates a new reused applicant profile instantly.
Updated about 2 hours ago