How KYC and AML Actually Work Behind the Scenes

When I tell people I build fintech platforms, the second question is usually some version of “how does the KYC stuff actually work?” The first question is “are you hiring?” so I will skip that one.

KYC and AML look like a checkbox on the surface. Submit a passport, take a selfie, get approved. Behind that surface is a set of moving parts that together decide whether your platform passes a regulator review or fails it. I have shipped these flows at neobanks, payment platforms, and marketplaces, and the architecture is more consistent than people think.

This is what the inside of a production KYC and AML pipeline looks like in 2026.

What KYC is for

KYC — Know Your Customer — is the regulator’s way of asking your platform to verify that a person is who they claim to be before you let them move money. The claim is two-part: they exist as a real person, and they are not on a sanctions or PEP list.

The output is a verified-customer record with a tier (basic, full, enhanced) and a risk score. Downstream systems read those two values and decide what the customer is allowed to do. Tier 1 might be allowed to receive small payments. Tier 2 might be allowed to send and receive larger amounts. Tier 3 might unlock high-value transactions or cross-border flows.

KYB — Know Your Business — is the same thing for businesses. It verifies the entity, the ultimate beneficial owners, and runs KYC on each owner. Most B2B platforms run both flows in parallel.

The six phases of a real KYC flow

A production flow has the same six phases everywhere I have built it. The vendors change, the UX changes, the order of phases stays the same.

Phase 1: Personal information capture. Name, date of birth, address, country, government identifier (SSN, PAN, NIN, or local equivalent). This is just structured data — the validation here is mostly format and country-specific rules.

Phase 2: Document upload. A photo of a government-issued ID, sometimes proof of address. Captured via webcam or file upload. Vendors run optical character recognition, document tamper detection, and cross-check the extracted data against what the user typed in phase 1. Onfido, Persona, Stripe Identity, Sumsub, Veriff, Jumio — they all do this part well now.

Phase 3: Liveness check. A short selfie video or interactive prompts. The vendor verifies the person is real (not a printed photo or a video replay) and matches the ID. This is the single biggest abandonment cliff in most flows. Different vendors have very different SDK quality on mobile devices.

Phase 4: AML screening. Sanctions lists (OFAC, UN, EU), PEP lists (politically exposed persons), adverse-media indices. Hits route to manual review. Clean returns advance the state machine.

Phase 5: Risk scoring. A composite score combining geography, document quality, screening results, and behavioral signals. Some vendors return a score; some platforms compute their own. The platform owns the policy.

Phase 6: Tier assignment and persistence. Map the score to a tier, persist the verified record with the regulator-required retention policy.

What AML screening actually does

AML screening is the part most people outside the industry assume is straightforward. It is not. It is fuzzy matching against constantly-updated lists, run with carefully-tuned strictness sliders, with manual review for everything that lands in the gray zone.

The lists themselves: OFAC SDN in the US, UN Sanctions globally, EU consolidated list, UK HM Treasury, plus country-specific equivalents. PEP lists from Refinitiv, Dow Jones, ComplyAdvantage. Adverse-media indices that summarize news mentions of fraud, corruption, or sanctions violations.

The matching is the hard part. Names are different across alphabets and transliterations. “Sergei” and “Sergey” are the same person. “Ahmed bin Salman” might have his name written in five different orders. Production matching engines use phonetic algorithms (Soundex, Metaphone, sometimes proprietary), edit-distance comparisons, transliteration libraries, and date-of-birth proximity checks.

The strictness is the other hard part. Set the threshold too tight and your false-positive rate balloons — analysts get fatigued, real hits get missed. Set it too loose and you let through hits that should have been caught. Most production systems target around a 95% true-positive rate at the manual-review stage, with a steady tuning loop that compliance owns.

The manual review surface

Anywhere screening can return a “maybe,” there is a human in the loop. The manual review tool is one of the load-bearing internal surfaces in any fintech platform. I have built versions of this on every fintech engagement.

What it has to do, concretely:

• Surface the hit and the reason. “This name matched a PEP list entry with 87% confidence.”
• Show the supporting evidence. The list entry, the source, the date it was added, related metadata.
• Let the analyst make a structured decision. Approve, reject, escalate, request more info — never free-text outcomes.
• Capture a reason code on every decision. “False positive — different person,” “True hit — escalate to compliance lead,” “Insufficient information — request bank statement.”
• Log everything. Actor, timestamp, decision, reason, before/after state. The audit log is what regulators read first.

Reason codes matter more than people expect. Free-text reasons turn into noise within a quarter; structured codes turn into compliance metrics that compliance teams actually use. We typically ship 20 to 40 reason codes per engagement, owned by the compliance lead, gated by a PR process so nobody adds a reason “approved — looks fine” out of frustration.

Engineering decisions that matter

A few production decisions are worth being deliberate about up front.

Vendor as driver, not vendor as platform. The orchestration layer is yours. The vendor handles document capture and screening. Swapping vendors later is a config change, not a rewrite. I have lived through a vendor migration that took six months because someone wired Onfido SDK calls into half the codebase. We do not do that anymore.

Webhook idempotency on every callback. Vendors retry. The idempotency key is the vendor’s event id, persisted with the result. If you skip this, the first webhook retry double-writes your KYC state.

Tier policy as data, not code. A tier_policies table maps (country, product, risk_score) to tier. Compliance updates the policy without an engineering deploy. The platform reads the policy at decision time. This single decision saves more time than anything else over the life of the platform.

Encrypted document storage with a separate key hierarchy. PII documents live in a separate KMS-protected bucket. Application code never reads them; only the manual-review tool does, and every read is logged to a separate audit stream. If you store PII in your main database, every incident becomes a discovery event.

Re-screening cadence. Sanctions lists update daily. A monthly re-screen is the regulator’s expectation; nightly is better. Build the loop on day one — bolting it on later is awkward because the customer state machine has to handle the transitions.

What progressive KYC actually looks like

The classical KYC flow front-loads everything: complete every phase before any action is allowed. The conversion cost on this is brutal. Flows that ask for a passport at signup lose 40 to 60 percent of users in the document-upload step.

Progressive KYC is the pattern most platforms move to once they have shipped the basic version. Collect just enough at signup to allow basic actions (a name, an email, a phone number, maybe a partial ID), then unlock higher tiers when the user wants higher limits.

The trade-off is more state machines and tier transitions to engineer. The upside is materially higher activation rates without compromising the regulator-facing record. We typically ship the basic flow first, then add the progressive tiers in the second sprint cycle once the team has data on where the conversion cliff actually is.

What ships in the first sprint

When a team comes to us asking for a fintech platform, the first KYC sprint typically delivers:

1. Personal-info capture form, structured by country.
2. One vendor integrated for document + liveness (usually Onfido or Persona).
3. AML screening through one of: ComplyAdvantage, LexisNexis Bridger, vendor-bundled (Sumsub, Persona Cases).
4. The state machine that ties them together, with append-only state transitions.
5. A minimal manual-review surface — a queue, a detail view, structured reason codes.
6. Webhook handlers with idempotency.
7. Audit logging on every state transition.

That is enough to onboard real users in production. Tier management, re-screening loops, secondary vendors for failover, and the more sophisticated risk-scoring models come in subsequent sprints.

Common ways teams get this wrong

A short list of mistakes I have seen often enough to flag:

• Treating KYC as a one-time event. Re-screening is required. Build the loop early or it ships months late under deadline.
• Mixing PII into the main application database. Document images and full ID numbers belong in a separate, encrypted store.
• Hard-coding tier rules in application code. Compliance teams need to change them. Move to a policy table.
• Ignoring vendor outage handling. When Onfido has an outage, KYC stops. Build a documented degraded-mode early.
• Saving raw document images forever. Retention is regulator-mandated and bounded. Automate deletion.
• Missing the abandonment funnel. Most KYC failures are device or UX issues, not fraud. Instrument every step.

Frequently asked questions

How long does a production KYC flow take to build?

The basic flow with one vendor takes 6 to 10 weeks with a senior engineering pod. Multi-vendor failover, full re-screening loops, and a polished manual-review tool typically add another 4 to 6 weeks.

Which KYC vendor should I pick?

It depends on geography and risk tolerance. Onfido and Persona dominate in most Western markets. Sumsub has stronger coverage in CIS and APAC. Stripe Identity is the easy choice if you are already on Stripe and have basic needs. For the highest-volume regulated platforms, multi-vendor setups are standard.

How do you handle abandonment in the KYC flow?

Three patterns. Persist partial state so users can resume on a different device. Use progressive KYC so the heaviest verification only blocks the actions that need it. Instrument every step so you can see where the cliff is and pick a vendor SDK that handles that step better.

Does KYC apply if I just take payments through Stripe?

Stripe handles KYC for the buyer. If your platform is a marketplace or moves money between users, you are responsible for KYC on the parties you onboard — even if Stripe handles the underlying payment. This catches teams off-guard often enough that it is worth checking with a compliance advisor before you ship.

Closing thought

KYC and AML are infrastructure, not features. Built well, they are invisible to most customers and pass audits without drama. Built poorly, they are the reason your platform stops being able to serve a country or stops being able to onboard new users for a quarter.

If you want this thinking applied to your platform, our fintech development team ships KYC and AML pipelines as part of every payment-platform build. A 30-minute strategy call is the fastest way to figure out the shape that fits your geography and risk profile.