KYC and identity verification in a fintech product

A founder once told us their fintech onboarding converted at 31 percent. Not because the product was bad, but because somewhere between "create account" and "you're in" sat an identity check that asked for a passport, a selfie, and a utility bill, then rejected people with a blunt red error and no way forward. Two thirds of the people who wanted to be customers gave up at the door.

That is the central tension of identity verification in fintech. You are legally required to know who your customers are, and every step you add to prove it costs you customers. Getting this right is not about choosing friction or conversion, it is about spending friction where it is genuinely needed and removing it everywhere else. This goes deeper than our general fintech build guide on a single, conversion-critical part of the product.

KYC and AML in plain terms

KYC, Know Your Customer, is the requirement to verify that a customer is who they claim to be before you let them move money. At minimum that means confirming a real identity exists and matches the person in front of you, usually through an identity document and sometimes a selfie matched against it. AML, Anti-Money-Laundering, is the broader obligation to make sure you are not helping move illicit funds, which adds screening against sanctions lists, watchlists, and politically-exposed-person databases, plus ongoing monitoring of behaviour that looks like laundering.

The honest framing matters here, so we will be blunt about it. No agency, library, or vendor "makes you compliant." Compliance is a legal posture your business holds, shaped by your jurisdiction, your licences, and your regulator, and it is defined by your compliance officer or counsel, not your engineers. What software does is support those requirements: it implements the checks your compliance team specifies, captures the evidence they need, and does it in a way that holds up. Build to support your requirements, work with your compliance team, and treat anyone who promises to "handle compliance" for you with deep suspicion.

Where it fits in onboarding

The instinct is to verify everyone fully, up front, before they see anything. That is the 31-percent-conversion path. A better model treats verification as something you escalate to meet the risk of what the user is actually trying to do.

Let people sign up and look around with a light touch, an email and a password. Trigger the heavier identity check at the moment it is actually required, typically the first time they try to fund an account or move money, when their intent is clear and they are most motivated to push through friction. This is the same step-up principle that governs good fintech auth, which we cover in our web application security checklist: the bar to log in is one height, the bar to move money is higher. Match the verification to the risk and you stop punishing curious visitors for a requirement that only applies to active customers. Your compliance team sets what must be verified and when, you build the flow that delivers it at the least costly moment.

Integrating a verification provider, not building one

This is unambiguous: you buy identity verification, you never build it. Providers like Persona, Onfido, Alloy, and Sumsub spend their entire existence on document authenticity, liveness detection, watchlist data, and the fraud arms race you have no business fighting alone. Rebuilding that is not just wasted effort, it is a worse outcome, because their models see millions of documents and yours will see hundreds.

What you actually build is the orchestration around the provider. The cleanest pattern keeps the heavy lifting off your own systems:

// 1. Your server asks the provider to start a verification session.
const session = await kyc.createSession({ userId, level: "full" });
 
// 2. The user completes the flow in the provider's hosted UI or SDK,
//    so raw documents and selfies never touch your servers.
 
// 3. The provider tells you the outcome via webhook. This is the
//    record of truth, not whatever the browser claims happened.
async function onKycWebhook(event: KycEvent) {
  const fresh = await db.recordEventId(event.id); // idempotent
  if (!fresh) return;
  await db.updateVerificationStatus(event.userId, event.status);
}

Notice that the result arrives by webhook, never by trusting the browser. A user can fake what their client reports, they cannot fake the provider's signed callback. That makes this the same problem as payment events, which is why the discipline in webhooks done right, idempotency, signature checks, tolerating retries and out-of-order delivery, applies here exactly as it does to money movement. This orchestration is everyday API and backend engineering, and it is most of the work.

Handle sensitive data by holding as little as possible

Identity documents are the most toxic data you can hold. A passport scan, a face image, a national ID number, these are catnip for attackers and a regulatory landmine if they leak. The senior move is to handle them by not handling them.

• Let the provider hold the raw documents. Their hosted flow collects the passport and selfie directly, so the sensitive files never land on your servers. You store the outcome, verified or not, and a reference ID, not the underlying images.
• Store the minimum the law requires, no more. You usually need to retain proof that you performed verification and when, not a copy of everything you saw. Your compliance team defines the retention obligation, and "we kept everything just in case" is a liability, not a safety net.
• Encrypt, scope, and log access to whatever you do keep. The few fields you must retain belong behind least-privilege access where every read is logged, the same way we treat any sensitive file handling.

The principle is simple: data you do not hold cannot leak, and data you must hold should be the smallest, least sensitive version that satisfies your actual requirement.

Never strand a user on a failed check

This is the part most teams get wrong, and it is the part that quietly kills the product. Verification is not pass or fail, it has a messy middle. A blurry photo. A document the provider cannot read. A name that does not quite match because of a marriage or a transliteration. A genuine flag that needs a human to review. If any of those dead-ends a user with a red error and no next step, you have lost a real customer to a fixable problem.

Design for the edge cases as first-class states, not exceptions:

• Retryable failures (bad photo, glare, wrong document) should say exactly what went wrong and let the user try again immediately, not start over from scratch.
• Manual review (a soft flag, a near-match) should park the user in a clear "we're checking, here's what happens next, here's when to expect an answer" state, not a spinner that never resolves.
• Genuine rejections still deserve a defined path, an appeal, a support contact, a way to submit a better document, because some real customers fail an automated check for innocent reasons.

The underlying rule: a verification flow that can only succeed or hard-fail will strand the people in the middle, and there are always more of them than you expect. Building those intermediate states well is the difference between a web app people complete and one they abandon, and it is exactly the depth we bring to fintech products.

The takeaway

KYC is verifying who your customers are, AML is making sure you are not moving dirty money, and software supports those requirements rather than satisfying them for you, your compliance team owns that line. Escalate verification to match risk instead of gating everyone up front. Buy the provider, build the orchestration, and let the provider's webhook be the record of truth. Hold the least sensitive data you can, ideally none of the raw documents. And design the messy middle, retries, manual review, appeals, as first-class states so a fixable check never costs you a real customer.

This is the kind of flow we build with founders and the kind we get called in to repair when conversion is bleeding at the door. If you want help getting identity verification right without strangling your onboarding, tell us what you are building and we will give you a straight answer.