Deep Dive — KYC, Onboarding & Identity Verification

KYC vs KYB vs AML — what each means

These get conflated. Don't.

• KYC (Know Your Customer) — verifying the identity of an individual customer. Documents, biometrics, address, source-of-funds at higher tiers. Driven by national AML laws; the operational discipline of identity proofing.
• KYB (Know Your Business) — verifying the identity of a business customer and the people behind it. Company registration, beneficial owners (typically 25%+ ownership threshold), authorized signatories, source-of-wealth.
• AML (Anti-Money Laundering) — the umbrella program. KYC and KYB are inputs to AML. AML also covers transaction monitoring, suspicious activity reporting, sanctions screening, and the AML risk assessment.
• CDD (Customer Due Diligence) — the baseline due diligence performed during onboarding.
• EDD (Enhanced Due Diligence) — extra scrutiny applied to high-risk customers (PEPs, high-volume, sanctioned jurisdictions, certain industries).

Tiered KYC — basic → enhanced → corporate

Most exchanges use a tiered model: more verification unlocks more product. The tiers vary by company but the shape is recognizable.

Platform implications:

• Tier upgrade should not redo the lower tier's work. Grandfathering is a first-class primitive.
• Re-KYC (refresh) is a different shape than tier upgrade — typically triggered by time, risk-score change, or regulatory mandate.
• Some markets have legal definitions of "verified" (e.g. EU's eIDAS levels). Map your tiers to them explicitly per jurisdiction.

Identity verification — document, liveness, biometric

The three legs of modern eIDV (electronic identity verification):

• Document verification — OCR the document, validate the MRZ (machine-readable zone) checksums, detect tampering / template forgery, check the document against an issuer database where available.
• Liveness — proves the selfie is a live human, not a photo of a photo or a deepfake. Passive (no user instruction) or active (turn your head, blink). PAD (presentation attack detection) is the technical term.
• Biometric matching — face-match the selfie to the document photo. A similarity score, with a threshold tuned for false-accept vs false-reject.

Other building blocks that round out the modern IDV stack:

• Database checks — name + DOB + address against credit-bureau, electoral roll, telco, government sources. Coverage varies wildly by country.
• Mobile network operator (MNO) signals — SIM-swap risk, age of SIM.
• Device intelligence — emulator detection, location vs declared country, anomaly scoring.
• Behavioral biometrics — typing cadence, navigation pattern, signal of a bot.
• Reusable identity / decentralized ID — early; relevant for crypto-native flows.

Sanctions, PEP, and adverse-media screening

Every onboarded customer is screened against multiple lists. Failing to screen is a license-killer.

• Sanctions lists — OFAC SDN (US), EU consolidated, UN, UK HMT, plus country-specific. Updated daily-or-faster. Hits trigger immediate block or referral.
• PEP (Politically Exposed Persons) — current and former government officials, their family, close associates. Not auto-reject; triggers EDD.
• Adverse media — negative news mentions tied to financial crime, fraud, regulatory action. Source-aggregated; usually requires a human review.
• Ongoing screening — customers are re-screened on a cadence (daily for sanctions; monthly or quarterly for PEP/adverse). New hits on existing customers trigger an alert.

Screening data is fuzzy — names match imperfectly (transliteration, aliases, DOB tolerance). Platform implication: you need a match-confidence model and an operations workflow for the maybe-matches.

Onboarding orchestration patterns

An onboarding orchestrator is the platform component that runs a customer through the right steps in the right order for the right jurisdiction. Concepts:

• Step — a single primitive (collect doc, screen sanctions, verify address).
• Flow — a sequence of steps with branching rules.
• Decision engine — combines step outcomes into a final decision.
• State machine — every applicant is in some state (started, awaiting-doc, screening, referred, approved, rejected). Transitions are events, logged.
• Resume — abandoned applicants should be able to resume mid-flow, preserving state and not redoing already-done steps.

The orchestration layer is where the platform earns its keep — it's the difference between "five hardcoded flows" and "one engine that runs N flows."

Vendor waterfalls — why and how

No single IDV vendor is great at every market or every signal. Mature platforms run a waterfall: try the cheap/fast vendor first; on failure or low confidence, fall back to a second; sometimes route by document type or country.

Example:

Platform implications:

• The vendor interface must be uniform (the abstraction layer). Vendor-specific quirks live in adapters, not in app code.
• Each vendor's confidence score must be normalized — you can't compare a Jumio 0.85 to a Persona "approved" without a model.
• Per-jurisdiction routing matters: vendor A is best in EU, vendor B is best in LATAM.
• Per-document-type routing matters: passports route differently than national IDs.
• Vendor health monitoring drives auto-failover. If Persona's success rate drops, route to Jumio for the window.

Regulatory regimes — the names to know

You won't be quizzed on statute, but you should sound aware. The regimes most relevant to a global crypto exchange:

You're not the regulator-facing person; you're a partner to whoever is. The right posture: "we encode the policy interpretation that Compliance gives us, and we make it easy for Compliance to update."

Crypto-specific wrinkles

These are the things that distinguish this work from generic fintech onboarding. Memorize them.

• Travel Rule (FATF Recommendation 16) — when a customer sends crypto above a threshold (typically $1k or $3k depending on jurisdiction) to another regulated entity, the originating VASP must transmit originator + beneficiary info to the receiving VASP. This is solved by protocols like TRP, OpenVASP, Sumsub Travel Rule, Notabene.
• Wallet attestation — proving a customer controls a withdrawal-destination wallet (Satoshi test, signed message, or screening + risk score). Required in some jurisdictions for self-hosted wallet withdrawals.
• Source-of-funds for crypto — bank statement is easy; on-chain history requires chain analytics. "Where did your BTC come from?" may need to trace through a mixer.
• On-chain analytics — Chainalysis, TRM, Elliptic. Score addresses by exposure to sanctioned entities, darknet markets, mixers.
• Wallet-address sanctions screening — beyond name screening, you screen addresses on every deposit and withdrawal.
• Self-hosted vs custodial counterparty — Travel Rule data flows differ depending on whether the other side is a regulated exchange or a personal wallet.
• Stablecoins — issuer-level compliance overlay (e.g. USDC freezable by Circle on a sanctioned address).

What a good onboarding platform looks like — capabilities checklist

• One applicant model across consumer, business, institutional segments — same identity-resolution under the hood.
• Vendor abstraction layer hiding IDV providers behind a uniform interface.
• Jurisdictional rule engine — config-driven KYC requirements per country / market.
• Tier engine — explicit tiers, explicit upgrade paths, grandfathering rules.
• Screening service — sanctions, PEP, adverse media, wallet screening — uniform interface across providers.
• Decision engine — composes signals into approve / refer / reject with explainability.
• Audit-event firehose — every state transition, every signal, every decision, immutable.
• Resume / abandonment recovery — applicant can return mid-flow days later.
• Sandbox / test mode — downstream teams test without real vendor cost.
• Operations console — manual-review queue, escalation tooling, audit search.
• Travel-Rule integration — at the perimeter for crypto withdrawals.
• Self-serve config — downstream teams launch new flows without platform-team eng.

If the interviewer asks "what would you build in your first year?" — this list, prioritized against the named product launches, is the answer.