Every crypto platform lives with the same tension: the law requires you to know who your customers are before they move money, and every extra verification step loses a measurable slice of the users who started signing up. KYC and KYB for digital assets is the discipline of resolving that tension deliberately — choosing what to verify, when in the flow to verify it, and which vendor components to assemble — instead of bolting on whatever the first provider demo showed. This guide walks through what identity verification actually proves, how business verification differs from individual verification, the layer-by-layer stack, and the flow-design decisions that determine whether compliant onboarding converts.

Image: Jumio — the output of an ID-plus-selfie check in Jumio's demo app: structured fields extracted from the document, which downstream systems compare against sanctions lists and the customer's declared details.

Quick solution

If you need the short version: run a risk-tiered flow. At signup, collect the minimum — name, date of birth, address, and for US customers a taxpayer identification number — and screen it against sanctions and politically exposed person lists before the account can transact. Gate the document-plus-liveness check to the first deposit or a volume threshold rather than the first screen, because that single sequencing decision recovers a large share of abandoned signups without weakening the control. For business accounts, verify the entity against the corporate registry, then identify and verify every ultimate beneficial owner at or above the 25 percent ownership threshold plus one control person, exactly as the FinCEN customer due diligence rule requires. Re-verify on trigger events — new jurisdiction, new payment method, risk-score change — not on a calendar. Wire the outputs into your crypto AML compliance software so identity, screening, and monitoring share one customer record.

Individual verification in crypto is usually assembled from four checks, and it helps to be precise about what each one demonstrates.

Document verification proves that a government-issued credential is genuine: the fonts, security features, machine-readable zone, and data consistency all check out. Modern document checks read the MRZ or NFC chip and extract structured fields, which is why the output of a good check is data — name, date of birth, document number, expiry — not just a pass/fail flag.

Liveness and face match prove that the person presenting the document is physically present and matches its photo. This is the check that stops the classic fraud of a stolen ID photo attached to a new account, and it is where vendors differ most in quality — passive liveness that works from a short selfie video versus challenge-response flows that ask users to turn their heads.

Onfido selfie capture step showing a live face scan with a checkmark confirming the liveness check

Image: Onfido — the selfie liveness step that binds a physically present person to the document they submitted, the control that defeats stolen-ID fraud.

Database verification proves that the identity exists in the world: the name, date of birth, and address resolve against credit bureaus, government records, or telecom data. In several markets this check alone satisfies lower verification tiers, which is what makes deferred document checks possible.

Screening proves the verified identity is not prohibited: sanctions lists, PEP status, and adverse media. Screening is the piece with an ongoing obligation attached — a customer verified clean on Monday can be designated on Tuesday, which is why identity data must flow into the same rescreening loop described in our guide to crypto sanctions screening tools.

What none of these checks prove is intent. A perfectly verified customer can still launder money, which is why verification feeds monitoring rather than replacing it.

KYB: verifying the business behind the account

Business verification is not KYC with a company name in the form. It is a different problem with an extra recursion: you verify the entity, then you verify the humans behind it.

The entity layer confirms the business exists and is in good standing — registration number against the corporate registry, legal name, formation date, registered address, and status. For crypto platforms onboarding corporate customers, this layer also asks what the business does, because a money services business or another exchange as a customer changes your own risk profile and may make you a correspondent for their flows.

The ownership layer is where KYB gets hard. The FinCEN customer due diligence rule, in effect since May 2018, requires identifying every ultimate beneficial owner holding 25 percent or more of the entity, plus at least one individual with significant control, and then running full individual KYC on each of them. Ownership chains are frequently deliberate obstacles — entity A owned by entity B owned by a trust — and resolving them means walking registries across jurisdictions until you reach humans. A UBO who surfaces three layers deep in a jurisdiction with a closed registry is not an edge case; it is the reason KYB reviews take days when KYC takes minutes.

The judgment layer is deciding what to do with what you find: a clean entity with a sanctioned minority owner, a legitimate business registered in a high-risk jurisdiction, an ownership chain that ends in bearer shares. These are risk decisions, not data lookups, and they belong to a named compliance owner with documented rationale.

More in Guides

The verification stack, layer by layer

Because no single public comparison lays the verification components side by side for digital-asset platforms, we compiled one from FinCEN rule text, FATF guidance, and vendor documentation:

LayerWhat it provesWhen it runsTypical failure mode
Document verificationThe credential is genuine; extracts identity dataOnboarding or first-deposit gateTemplate fraud; expired or unsupported documents
Liveness + face matchThe presenter is present and matches the documentSame session as document captureCamera friction on desktop; injection and deepfake attacks
Database verificationThe identity exists and resolves to real recordsSignup, before first transactionThin-file customers: young, new to country, unbanked
Registry + UBO checks (KYB)The entity exists; the owners are identifiedBusiness onboarding, refreshed on triggersOpaque chains; closed foreign registries
Sanctions / PEP screeningThe person or entity is not prohibitedEvery onboarding, then continuouslyStale lists; name-match noise without date-of-birth context

The layers are cumulative, not alternative. A platform that runs document checks but never rescreens has a strong front door and no smoke detector; one that screens but accepts unverified documents has the reverse.

iDenfy verification method selection screen showing country selection and document type options including passport and

Image: iDenfy — country and document-type selection at the start of a verification flow; supported-document coverage per country is one of the quiet differentiators between providers.

The compliance requirements fix what must be verified. They say almost nothing about when, and sequencing is where platforms win or lose onboarding.

The pattern that converts is progressive verification. Let the user create an account and explore with nothing but an email. Collect identity data and run database verification plus screening before the first deposit. Trigger the document-and-liveness ceremony at a meaningful threshold — first fiat deposit, first withdrawal, or a cumulative volume line — when the user has demonstrated intent and tolerates friction. Jurisdictions differ on how much activity can precede full verification, so the thresholds are a legal decision, but the architecture of deferring the heaviest check until the user is invested is almost universally available and almost universally underused.

Jumio verification start screen listing preparation steps: use a valid government-issued document, find a well-lit surface,

Image: Jumio — the start screen of a verification ceremony; setting expectations before the camera opens measurably reduces abandonment during the capture step.

Three flow details matter more than vendor choice. First, native capture beats file upload: guided camera flows with real-time feedback on glare and framing cut retries dramatically, and retries are where users quit. Second, fallbacks must exist for the failure cases you will definitely see — expired documents, unsupported document types, thin-file users who fail database checks — and routing those to manual review beats hard-failing them. Third, status transparency: a user stuck at "verification pending" with no timeline contacts support or leaves; a user told "usually under two minutes, we will email you" waits.

Onfido document selection screen listing passport, driver's license, national identity card, and residence permit options

Image: Onfido — document-type selection inside an onboarding flow; offering every locally valid document type, not just passports, is a conversion decision as much as a coverage one.

What document fraud looks like now

The threat model behind verification has shifted twice in five years, and a program designed for the old one quietly stops working.

The first shift was from physical to synthetic. Classic document fraud meant altered physical cards photographed badly; the checks that caught it were template and font analysis. Today the dominant attack is fully synthetic imagery — a document that never existed, rendered convincingly, or a genuine template with substituted data — presented not to a camera but injected directly into the capture stream through a virtual camera or a modified client. Defenses moved accordingly: capture SDKs attest that the frames came from a real device camera, and document checks weigh capture provenance as heavily as the pixels themselves.

The second shift was deepfakes against liveness. A face-swap running in real time can pass a naive selfie comparison, which is why serious liveness vendors now analyze texture, lighting physics, and micro-movement rather than simple face geometry, and why platforms in higher-risk corridors layer a second signal — NFC chip reads of the document, device reputation, or behavioral biometrics — on top of the camera ceremony.

Regula demo app processing a scanned specimen identity document with the extracted document image highlighted for

Image: Regula — a document capture and processing step against a specimen ID; forensic-grade checks read security features and the machine-readable zone, not just the portrait.

The practical takeaway for a platform is not to become a forensics lab — it is to ask vendors the two questions that expose weak stacks: how do you detect injection attacks, and what happens when the document's NFC chip disagrees with its printed data. Vendors with real answers describe layered signals; vendors without them describe accuracy percentages from marketing benchmarks.

Common mistakes that surface in audits and churn dashboards

  • Verifying everything at signup. Front-loading the document ceremony maximizes drop-off at the moment users are least committed. Unless your legal analysis genuinely requires full verification before account creation, tier it — the control is the same, the conversion is not.
  • Treating KYB as a form instead of a resolution process. Collecting a company name and registration number without walking the ownership chain to humans satisfies nobody — the CDD rule explicitly requires beneficial-owner identification, and enforcement actions routinely cite programs that stopped at the entity layer.
  • One-time verification with no refresh triggers. Identities age: documents expire, owners change, customers move into sanctioned jurisdictions. Programs that never re-verify discover this in a lookback. Trigger-based refresh — jurisdiction change, dormancy then sudden volume, screening-list updates — is the defensible default.
  • Ignoring the travel rule intersection. Verified identity data is exactly what a travel rule compliance solution transmits with qualifying transfers. Platforms that verify identity in one silo and handle transfers in another end up unable to populate the messages they are required to send.

"We are a startup exchange doing our first compliance build" — this team buys a bundled provider that covers documents, liveness, database checks, and screening behind one API, because integrating four vendors before product-market fit is a staffing decision disguised as an architecture decision. They tier verification at the first-deposit gate, route edge cases to a shared manual-review queue, and revisit vendor choice when volume gives them negotiating leverage.

"We are an established platform adding corporate accounts" — this team keeps its individual KYC stack and adds a dedicated KYB layer: registry verification across its target jurisdictions, UBO resolution with document collection from each owner, and a named analyst owning every corporate file. They accept that business onboarding takes days, and they set customer expectations accordingly instead of pretending it is instant.

"We are a fintech offering crypto through a banking-as-a-service partner" — this team confirms in writing which party runs which check, because regulators hold both sides responsible when the answer is neither. They get read access to verification outcomes for their own customers, test the flow end to end with a real document quarterly, and keep their own screening refresh rather than assuming the partner rescreens.

Frequently asked questions

What is the difference between KYC and KYB?

KYC verifies an individual: their identity document, their physical presence via liveness, their existence in databases, and their absence from prohibited lists. KYB verifies a business — registry existence and standing — and then recursively applies KYC to the humans who own or control it, at the 25 percent beneficial-ownership threshold plus a control person under the US CDD rule.

Can a crypto platform let users trade before completing KYC?

Depends on jurisdiction and activity. Many regimes permit account creation and limited activity with basic data collection and screening, with full document verification required before fiat movement or at volume thresholds. The sequencing is a legal determination per market — what is nearly universal is that sanctions screening must precede any transaction, because sanctions liability is strict and has no de-minimis tier.

How long does business verification realistically take?

Entity-level checks against open registries return in minutes. The tail is UBO resolution: collecting documents from every qualifying owner, walking multi-layer ownership chains, and handling jurisdictions with closed or slow registries. Well-run programs complete straightforward corporate files in one to three days and communicate honestly that complex structures take longer.

Do decentralized platforms need KYC?

The obligation attaches to businesses conducting covered activity for customers, and regulators have increasingly looked through labels to function — FATF's 2021 updated guidance treats sufficiently controlled DeFi arrangements as VASPs with full obligations. Front ends, fiat ramps, and anything custodial sit clearly inside the perimeter; genuinely non-custodial protocol layers remain contested ground that counsel, not architecture diagrams, should settle.

What identity data must be kept, and for how long?

US recordkeeping rules require retaining the identifying information collected at verification — and the methods used to verify it — for five years after account closure, with similar periods in most other regimes. Retention obligations coexist with privacy law duties to minimize and protect the data, which is why verification records belong in an access-controlled system rather than scattered across support tools and email.

Sources

  • FinCEN — Customer Due Diligence Requirements for Financial Institutions (the CDD Rule), fully effective May 11, 2018.
  • FATF — Updated Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers, published October 28, 2021.
  • European Union — Markets in Crypto-Assets Regulation (MiCA), entered into force June 29, 2023, with CASP requirements applying from December 30, 2024.