Reusable KYC: Fixing the double verification problem in payments

Asking a new user for an ID scan and a selfie once is onboarding. Asking twice is a drop-off risk. Yet that's often what happens when a wallet, neobank or remittance platform runs on a payment provider. The provider holds the account and has its own legal duty to know its customers. It can't take the platform's word for it, so it runs its own check, often adding items the platform never asked for.

In practice, a user passes KYC at signup, then gets asked for the same passport again when they open a USD account, plus a proof of address and a source-of-funds question. To them it's one product, so the support tickets land on yours.

Reusable KYC fixes this. Your platform sends the provider a one-time token for the KYC check the user already passed. The provider re-checks what it receives and asks only for what's genuinely missing. Due supports this for platforms that verify users with Sumsub.

This guide covers how share tokens work, what to ask your provider before you start, how to set sharing up, and how the same flow lets you switch providers without re-verifying your user base.

Why users get verified twice

The double check comes from how most fintech platforms are built. The platform your users see is often not the company that holds their money. It runs on a payment provider that holds the accounts, licenses and banking relationships, and that provider sits outside the user's view.

That provider is regulated, so it must identify every user it serves. Your platform usually runs its own KYC too, either because it has its own obligations or to manage fraud. Without a way to share results, each company checks the same person separately, and the user uploads the same documents twice.

What is reusable KYC?

Reusable KYC means passing a user's completed identity check from one company to another, so the user does not repeat it. Between a platform and its payment provider, this usually runs on a one-time share token from a KYC vendor both companies use. Sumsub calls the sharing company the donor and the receiving company the recipient.

This is different from wallet-based reusable KYC, where users hold a verified credential in a digital identity wallet, such as the wallets EU member states must offer under eIDAS 2. This guide covers the token model that payment providers use today.

Does your payment provider still have to check the user?

Yes, because the provider that receives shared data stays responsible for its own checks. FATF Recommendation 17, EU AMLR Article 48 and the US bank CIP rule all let one regulated firm rely on another's KYC under set conditions. All three leave ultimate responsibility with the firm doing the relying.

In practice, your provider treats your shared data as an input rather than a verdict, so expect it to re-check documents, re-screen against sanctions and PEP lists, and ask for anything its own rules need. The difference is that the user no longer has to start from scratch. For the wider picture, see our guide to KYC and AML requirements for cross-border payments.

Is reusable KYC worth setting up for your platform?

It's worth it when a meaningful share of your users hit a second verification step, which you can measure from your own funnel before talking to anyone.

Start with two numbers:

• Second-check volume: how many users reach a second KYC request after passing yours, for example when they open an account or make their first payout
• Second-check drop-off: how many of those users never complete it

If both numbers are small, standard KYC at the provider may be fine. If they're not, these are the questions to put to your payment provider before you build anything:

1. Which KYC vendors do you accept tokens from? Token sharing only works when you and the provider use the same vendor.
2. What will you still collect? Ask for the list of fields, documents and questionnaire answers your users will see even after a successful share.
3. What does a shared check cost? Ask your KYC vendor whether reused checks are billed, and ask the provider whether it charges for verification.
4. Who carries the risk if my KYC was wrong? The provider stays responsible to its regulator, but your contract and the vendor's sharing agreement decide what you owe the provider.
5. How will rejections reach me? You need to know how you'll be told and what you can tell the user.

How a share token replaces the second KYC check

Most sharing between platforms and payment providers runs on a single-use token from the KYC vendor both companies use. This guide uses Sumsub's version, since it is the one Due's API supports.

First, you and your provider agree to share data and connect as partners in Sumsub. After that, each shared user follows the same five steps:

1. Your platform verifies the user: You run KYC in your own Sumsub account, as you do today.
2. Your platform creates a share token: It calls Sumsub's Generate share token endpoint with the user's applicant ID, your provider's Sumsub client ID and an optional lifetime in seconds. Tokens are invalidated after use.
3. Your platform sends the token to the provider: This happens server to server, as part of onboarding.
4. The provider redeems the token: Sumsub matches your verification steps to the provider's and copies only the data where they overlap.
5. The provider re-checks and decides: Sumsub states that it runs fresh checks against the recipient's level settings, such as accepted document types, issuing country and document expiry. The provider then approves, asks for more data or rejects.

What carries over and what you still collect

Shared KYC rarely covers everything your provider needs, because Sumsub only moves data where your verification setup and the provider's overlap.

Due's documentation lists what Sumsub may withhold even when the user completed full KYC on another platform:

• Certain document types
• Specific identity fields
• Questionnaire responses
• Verification results for particular checks

Gaps also come from the provider's own rules. Due's KYC requirements include country-specific identifiers, such as an SSN or TIN for US users, CPF for Brazil and BVN for Nigeria. They also include a financial profile covering purpose of use, expected monthly volume, occupation and source of wealth. If your platform never asked for these, it cannot share them.

The outcomes below are what a provider can return after redeeming a token. Plan your onboarding screens for each one.

How to set up reusable KYC with your payment provider

Removing the second check is mostly about handling partial results cleanly. Use this checklist when setting up sharing with any provider.

1. Confirm you use the same KYC vendor: Token sharing works between accounts on the same vendor. If you and your provider use different vendors, plan for standard KYC.
2. Put the agreements and disclosures in place: Sign Sumsub's sharing agreement, add each other as partners, and tell users their verification data will be shared with your payment provider. Sumsub notes that organizations holding EU or UK personal data must check whether sharing is legitimate under GDPR.
3. Map and pre-fill your gaps: Compare what you collect with what the provider requires, then send the fields you already hold, such as nationality, phone and declarations, with each sharing request.
4. Create tokens just in time: Generate each token at the moment of handoff, not at signup, because tokens expire and work only once.
5. Handle all three outcomes: Route users with open requirements to a short follow-up flow, and route rejected shares to full KYC without dead ends.
6. Gate features on the final decision: A completed submission is not an approval, so wait for the provider's decision webhook.
7. Keep an audit trail: Store which token was used, when, and what the provider returned.

For an end-to-end view of integration effort, see how long it takes to integrate a cross-border payment API.

How to switch payment providers without re-verifying users

Reusable KYC also matters when you change providers, not just when you add one. Moving to new stablecoin payment infrastructure usually means every existing user has to pass the new provider's KYC. Asking a whole user base to upload documents again is often what stalls a migration.

Share tokens can remove most of that work, with one condition: the KYC has to live in your own Sumsub account. If your current provider ran KYC in its own account through a hosted flow, the verification belongs to them, and you'd need them to share it.

If your KYC is yours, plan the migration like this:

1. Map gaps across the whole base: Compare what you collected with the new provider's requirements, so you know which users will land in "more data needed" before you start.
2. Run sharing as a batch job: Because tokens are single-use and expire, generate one per user at the moment you send it rather than in advance.
3. Migrate in waves: Start with a small group, check the share outcomes, then scale.
4. Prepare the follow-up flow first: Users with open requirements should get a short, specific request, not a full re-onboarding.

What happens when the provider rejects a user you approved

A share can pass your checks and still fail the provider's. Its rules, screening lists and risk appetite may differ from yours, so plan for this case before it happens.

Three things to get right:

• Expect limited reasons. A provider may not be able to tell you why, especially where a suspicion report is involved. FATF standards prohibit "tipping off" a customer about one.
• Don't route around it. Re-submitting the same user through a different flow to get a different answer is a red flag. On Due, sharing is unavailable once an account already has a passed or failed KYC status.
• Decide what the user can still do in your platform. Write a neutral message in advance, and define which features stay available when the provider can't serve them.

How reusable KYC works for business users

Sharing KYB is harder than sharing individual KYC because a company is a group of people, not one person. In Sumsub's model the company is the parent applicant, and directors, shareholders and ultimate beneficial owners are child applicants linked to it.

That structure creates more ways for a share to come back incomplete:

• Company-level gaps: registration number, address, website or company documents missing from your platform's records
• Related-party gaps: directors or owners who were never verified on your side
• Relationship gaps: ownership percentages and roles that must be set before the provider can review the case
• Questionnaire gaps: business risk questions specific to the provider

Due's docs describe a KYB sharing flow on the same endpoint as KYC, where the platform creates child applicants and links them to the company submission when required. Expect more business shares than individual shares to need follow-up, and design that flow for a company representative rather than an individual user.

How Due handles shared KYC and KYB

Due accepts Sumsub share tokens through one endpoint, POST /v1/kyc/sharing/sumsub, for platforms whose users already passed verification on Sumsub. The documented flow works like this:

• One request per user: the platform sends the share token, plus optional applicant info and questionnaire answers to pre-fill gaps.
• Two response states: completed when shared and pre-filled data meet every requirement, or resubmission_pending with a submission ID listing exactly what is still missing.
• Explicit fallback: an err_kyc_sharing_not_possible error means Sumsub refused the share, and the user goes through standard KYC.
• Hosted completion: open requirements can be filled via the submissions API, or through Due's hosted submission flow, which shows the user only the unfilled steps.
• Final decision by webhook: sharing imports data and does not guarantee approval. Due reviews the submission and sends the result as a webhook event.
• No overrides: sharing is unavailable for an account that already has a passed or failed KYC status.

Once an account is verified, platforms can attach virtual accounts and move money across local rails, SWIFT and stablecoins through the same API. Due holds MiCA authorization from Spain's CNMV, which shapes how its own verification requirements are set.

If you already verify users on Sumsub and want to stop asking them to do it twice, or you're planning a move to a new provider, book a demo with Due.