KYC provider integration for crypto projects: Sumsub, Onfido, Jumio

KYC provider integration: where the user journey breaks

Integrating a KYC provider in a typical project looks like a method call from the signup form: get a session link, send the user, wait for the response. Everything breaks at the junction — where identity verification meets the logic of accounts, limits, and payouts.

The first gap is status mismatch.

The provider and your database each live their own life: a notification did not arrive or arrived late, a retry was delivered twice and, without idempotency, overwrote an already accepted decision, or an application got stuck in manual review with an operator. At that moment the user sees “verification in progress,” although the verdict was made long ago.

The second is drop-off during verification, and it is rarely tied to document forgery. People leave at the requirement to take a selfie before the document type is selected, at a camera with no guidance on lighting and framing, at re-upload after an unclear error.

For user verification in a crypto project, this is especially costly: a failed check is not a delayed customer but a lost one.

The third is manual reviews and stuck applications. Every case stuck between two systems is checked manually by someone, response time grows from minutes to hours, and by then the user has already opened an account with a competitor.

Providers — Sumsub, Onfido, Jumio — return statuses and rejection reasons differently, and without a unified state model on your side this turns into a constant stream of such reviews.

Below we break down how this is addressed: where to place status control points, how to design retries, and what to consider when integrating identity verification so it does not eat into the funnel.

What integrated verification delivers: speed, rejections, manual work

Verification speed is set not by the provider but by where verification sits in the signup flow. When the request is sent after form submission, the person waits for the verdict on a loading screen: the pass takes 40–90 seconds, and some users simply close the page.

We move verification into a separate step with explicit statuses and return control to the flow once the response arrives.

The main engineering work is status handling. The result arrives asynchronously; a response may repeat or be delayed; without idempotent processing and retries, stuck applications and duplicates appear.

We keep a single source of truth for the customer and separate intermediate and final statuses — the class of errors “verification passed, access closed” goes away along with manual checks.

Manual review rules are configured separately.

The risk threshold and triggers are tailored to your profile: the share of applications reaching a human specialist drops from the majority to a few percent, and every decision is explainable — you can see the rule that fired, not just the verdict.

Repeat verifications are a hidden support time cost.

If a rejection is caused by image quality, the user returns to the same session with saved state instead of starting over: repeat contacts per customer become one instead of three or four, and signup conversion grows due to those who previously dropped off on the second attempt.

The logic is portable across providers: Sumsub, Onfido, and Jumio differ in method sets and thresholds, but the contour for handling statuses, retries, and review remains the same — switching vendors does not require rewriting the product.

Three ways to integrate identity verification and their limitations

Identity verification is integrated at launch, but project requirements diverge: one jurisdiction or five, standard passports or a mixed document flow, willingness to keep an in-house support team. Hence three working schemes that teams actually choose between.

A hybrid is not a compromise but a separate operating mode: if the primary vendor fails or is delayed, the application goes to the backup route, and responses are brought to a unified format on our side.

This normalization layer determines whether the business gets continuous signup or downtime during an outage.

Implementation stages: from verification flow audit to handover to support

The work sequence hardly depends on the provider: Sumsub, Onfido, and Jumio differ in the set of ready-made checks and the status notification format, but the engineering sequence is the same.

We start with an audit of the verification flow — where the user drops off, which routes are mandatory, and which can remain optional.

1. Verification flow audit — walk the user journey step by step, record drop-off points and places where a document is requested again; the output is a map of statuses and bottlenecks.
2. Verification route scheme — determine which levels are needed for whom: minimal for deposits, extended for withdrawals and corporate accounts.
3. Verification rule configuration — set trigger thresholds, auto-acceptance of simple cases, manual review of disputed ones; rules are versioned so a decision can be explained.
4. Roles and access — the review operator sees only the required scope of data, actions are written to a log; this removes questions during external audits.
5. Verification test environment — run scenarios in the provider's sandbox: success, rejection, re-submission, expired session, document mismatch; separately check that a repeated notification does not create duplicates.
6. Launch with gradual rollout — first a share of traffic on the new route, comparison of pass rate and verification time; rollback is done by switching rules, without code changes.
7. Handover to support — review procedures, response templates, escalation procedure to the provider, status dashboard; the first line resolves typical cases on its own.

What you keep after implementation: configurations, schemes, procedures

We hand over not “access to the provider's dashboard” but a reproducible package: using it, your engineer or support team can stand up the verification process in a new environment without asking us for verbal explanations. Every artifact is versioned in your repository — changes go through review like regular code.

• Verification integration scheme — call sequence, result retrieval points, handling of repeated deliveries and external service failures, behavior when the provider is unavailable.
• Rules and roles matrix — which verification level triggers for which jurisdiction and amount tier, which operators see personal data, and which see only the verdict.
• Manual review procedure — criteria for sending a case to a human, procedure for reviewing questionable documents, response times, escalation points, and rejection rules.
• Verification documentation — dictionary of statuses and codes, description of report fields, explanation of discrepancies between the provider's response and your user state.
• Threshold configurations — attempt limits, verification lifetime, lists of prohibited jurisdictions, notification templates — in files, not in the interface of someone else's dashboard.
• Secrets handling procedure — where keys are stored, how they are rotated, who owns access, and what to do when an employee is offboarded.
• Set of test scenarios — sandbox environment and a selection of cases: unreadable document, sanctions list match, re-submission by the same person.
• Decision log for audit — what and when was recorded for each case, with what wording and on what basis.

We attach a short maintenance guide to the package: typical support requests and what to edit where. After that, the process lives with you — enhancements, provider changes, or adding a second verification environment happen without us.

Case study: integrating a second provider without stopping signup

The project is a crypto platform with mandatory identity verification at onboarding. The entire signup flow went through one vendor: when response delays grew on its side, signup stopped entirely, applications piled up, and support reviewed them manually. There was no second verification route — nowhere to switch to.

Verification was moved into a separate orchestrator service with a unified contract, and behind it we placed two providers — Sumsub and a backup.

Each application is assigned an idempotency key: a repeated request does not create a second verification, and the decision result is stored in our user profile and remains available even when the external service is unavailable.

Statuses arrive as asynchronous notifications, and lagging applications are picked up by periodic polling — no verification hangs without a response.

Routing was set by rules: traffic share, document region, required verification level — document, biometrics, sanctions lists. Traffic migration went in shares: 5%, 25%, 50%, 100%; at each step we compared the success rate of verifications and the share of manual reviews. Signup did not stop for a minute.

Result

The share of verifications completed on the first attempt grew from 71% to 92%, median time from document submission to decision was halved, and degradation of any single provider no longer affects user intake: switching is a configuration parameter, rollback takes minutes and does not require a deploy.

What to do if verification is already deployed on another solution?

A full migration is rarely needed.

If verification is already deployed on another solution, as a first step we split the flow by subject type, jurisdiction, and stage of the user lifecycle — and migrate not everything at once, but the areas where the new logic gives a measurable gain. The rest keeps working as is until coverage gaps are closed.

KYC and KYB differ in migration cost and in the volume of data that must be transferred. For an individual, this is a set of documents, the result of screening against sanctions and reputational lists, and a risk assessment — their migration is predictable.

For a legal entity, ownership structure, beneficial owners, director roles, and registry documents are added: here verification is more often left on the previous service, and only new registrations and repeat checks are moved to the new side.

Parallel verification is the main operating mode. The new flow goes through the target provider; existing users and disputed cases remain on the previous one.

Then we compare verdicts on a control sample: discrepancy rate, frequency of manual review, and time from start to final status. As long as discrepancies are explainable and not growing, we do not switch off the previous service.

Verification history is transferred not as a check but as its result and evidence: status, risk level, timestamp, links to stored documents and their fingerprints, and event identifiers.

The user does not go through verification again — an internal identifier links the profile across the two systems, and the decision on it can be presented to a regulator or partner at any time.

The criterion for switching off the previous service is consistent verdict matching and no growth in manual reviews across the entire control sample, not only on new registrations.

Rollback at this stage comes down to switching the verification route: the user does not lose access, and the history remains in place. This is exactly how we handle partial migration — we determine what to move and what to leave.

Technical concerns: data security, rejections, repeat verification

Customer documents do not have to sit in your database. The verification provider accepts the file, stores it in its own environment, and returns the result to you: passed, rejected, sent to manual review — plus a verification identifier.

Files are issued via signed links with a short lifetime, so personal data does not settle in your service's logs and backups, and access to it is restricted by the role model.

False rejections more often come not from forgery but from input data: a blurry photo, glare on a hologram, a mismatch in name transliteration. Sanctions screening adds a second class — a surname match with a list entry despite different dates of birth.

This is resolved by a match threshold, a manual queue, and a repeat run against updated lists, rather than rejection on the first trigger.

How does repeat verification affect account access?

Triggers are expiration of the verification validity period, a change of jurisdiction, or a sharp increase in account turnover.

During repeat verification, access logic switches the account to read-only mode but does not block login: otherwise the customer would not be able to upload an additional document.

Let's discuss the task: we'll review your verification flow and come back with a plan

Verification is the most visible part of the customer journey: the share of completed signups depends on how many steps they go through and how quickly they get a response.

To make the review concrete rather than generic, send the inputs for your flow — we will use them to assemble a scheme and come back with an estimate and implementation plan.

• Verification scenarios: whom we verify (individual, company, representative, ultimate owner) and at which step — signup, first transaction, withdrawal.
• Required levels: which documents and confirmations are mandatory and which are optional, for which jurisdictions.
• Current data path: where customer data is collected now and where the result should return — to the user dashboard, to the accounting system, to the manual review queue.
• Provider statuses: which responses need to be supported (success, rejection, additional action, manual review) and what to do next for each.
• Retention policies: personal data retention periods, deletion procedure, and who is responsible for processing customer requests.
• Provider and access: chosen from the pool (Sumsub, Onfido, Jumio) or an open question, test keys, and a support contact on the provider side.
• Constraints: launch date, customer response window, expected daily load.

Then the order is as follows. First we review your verification flow and show exactly where verification breaks the funnel. Then — an estimate and implementation plan: stages, traffic switch point, and rollback procedure to the previous flow.

After approval, we name the timeline for integrating verification and start; until then, the decision remains yours.