Common use cases

The same engine — document verification, liveness, face match, AML/PEP screening, NFC, proof of address — serves very different risk profiles depending on what you're onboarding a user for. This page maps common verticals to the module combinations and delivery patterns teams in that space typically reach for.

Warning

This page describes general integration patterns, not legal advice. Every regulatory driver below is described generally — confirm the specific obligations that apply to your business with your own compliance and legal counsel before finalizing a workflow. Nothing here is a real customer case study; treat it as a starting point for your own workflow design in Console → Config → KYC Workflows.

How to read this page

Each vertical below lists three things:

Typical regulatory driver — the general category of obligation that usually motivates identity verification in that space (framed generally, not tied to a specific jurisdiction).
Recommended modules — a starting module combination. Add or remove modules per your own risk appetite; see KYC modules for what each one does.
Integration pattern — whether a hosted-flow redirect, an embedded SDK, or a mix is the more natural fit, and why.

Info

Module choice and strictness live entirely in the workflow you build in the console and reference by workflow_id — nothing below requires different API usage, just a different workflow configuration. See Concepts → Workflows.

Fintech / neobank onboarding

A typical fintech onboarding flow verifies a new account holder before they can fund an account or move money, balancing conversion (every extra step drops completions) against the obligation to know who holds the account.


Typical regulatory driver	Customer due diligence obligations attached to opening a deposit or e-money account.
Recommended modules	`ID_VERIFICATION` + `LIVENESS` (passive, to minimize friction) + `FACE_MATCH` + `AML_SCREENING`
Integration pattern	Embedded SDK inside the signup flow, so verification feels like a native step rather than a redirect away from the app.

A typical pattern: the user completes basic account details, the app calls POST /v3/session/ from its backend, and the SDK opens the flow inline. The account activates on the identity.kyc.session.approved webhook, with AML_SCREENING results routing borderline matches to manual review rather than blocking outright. See Verify a user, end to end.

Traditional banking KYC

Bank account opening — especially for higher-value products (loans, business accounts) — generally carries a stricter identity assurance bar than a fintech wallet, often alongside proof-of-address and enhanced due diligence for higher-risk customers.


Typical regulatory driver	Formal customer identification programs and enhanced due diligence for higher-risk account types.
Recommended modules	`ID_VERIFICATION` + `LIVENESS` + `FACE_MATCH` + `AML_SCREENING` + `PROOF_OF_ADDRESS`, with `NFC_VERIFICATION` added for the highest-assurance tier
Integration pattern	Hosted flow via an emailed or branch-generated link works for branch-assisted onboarding; a mobile SDK is the better fit for full self-service digital account opening where NFC chip reads add meaningful assurance.

Tip

NFC_VERIFICATION reads and cryptographically validates the signed chip in an e-passport or biometric ID — materially stronger evidence than an OCR'd photo, but it needs a native mobile SDK (iOS, Android, Flutter); it's not available from a web-only hosted flow. See NFC verification.

Crypto exchange (Travel Rule context)

Exchanges generally need both to know their own customer and to be ready to exchange originator/beneficiary information with counterparty VASPs on qualifying transfers — which puts a premium on capturing clean, verified identity data up front rather than reconstructing it later.


Typical regulatory driver	Customer identification for account opening, plus counterparty data-sharing obligations on qualifying transfers between virtual asset service providers.
Recommended modules	`ID_VERIFICATION` + `LIVENESS` (3D-action or colour-flash, for a higher anti-spoofing bar) + `FACE_MATCH` + `AML_SCREENING` (sanctions + PEP + adverse media)
Integration pattern	Hosted flow or SDK both work; the distinguishing factor is usually the AML rolling re-screen — an approved customer who becomes sanctioned after onboarding should surface automatically, not just at signup.

Note

AML_SCREENING fails closed: if the screening engine is unreachable, the session lands in manual review rather than silently passing. For a higher-throughput exchange this makes the operator review queue a first-class piece of the launch plan, not an afterthought. See AML screening.

Marketplace / gig-economy identity

Two-sided marketplaces (delivery, rideshare, peer-to-peer rental, freelance) typically need to confirm that the person behind an account is a real, consistent individual — both to build trust between strangers transacting and to deter multi-accounting and fraud rings.


Typical regulatory driver	Platform trust-and-safety obligations rather than a single financial-services regime; often layered with sector-specific requirements (e.g. driver eligibility checks) depending on the marketplace.
Recommended modules	`ID_VERIFICATION` + `LIVENESS` + `FACE_MATCH`; add `AML_SCREENING` if the marketplace moves funds directly between users, `DATABASE_VALIDATION` where an authoritative eligibility check is available
Integration pattern	Embedded SDK inside the supply-side (driver/seller/host) onboarding app is the common pattern; demand-side (buyer/rider) verification, where used, is often a lighter hosted-flow step.

Telecom SIM registration

Many telecom markets require a verified identity behind every active SIM, generally to curb SIM-swap fraud and to support lawful-intercept and anti-fraud obligations. Volume is typically much higher and per-verification cost tolerance lower than in financial services.


Typical regulatory driver	Mandatory subscriber identity registration tied to SIM/line activation.
Recommended modules	`ID_VERIFICATION` + `LIVENESS` (passive, to keep unit cost and friction low at high volume); `FACE_MATCH` where the regime requires biometric binding to the ID
Integration pattern	Hosted flow at a retail point-of-sale kiosk or an agent-assisted link is common; a lightweight embedded SDK fits self-service e-SIM activation in a carrier's own app.

Healthcare patient identity

Confirming patient identity matters for both safety (matching the right person to the right record, especially for controlled substances or telehealth) and for preventing medical identity fraud — while handling correspondingly sensitive data.


Typical regulatory driver	Patient-matching accuracy expectations for medical records, and heightened data-protection obligations given the sensitivity of health data.
Recommended modules	`ID_VERIFICATION` + `LIVENESS` + `FACE_MATCH`; `AML_SCREENING` is typically unnecessary outside specific payer/provider risk contexts
Integration pattern	Embedded SDK inside a telehealth or patient-portal app, run once at registration and optionally re-confirmed at the start of a sensitive encounter (e.g. before an e-prescription for a controlled substance).

Warning

Evidence captured (documents, selfies) is sensitive PII regardless of vertical, but healthcare deployments often sit alongside separately regulated health data. Confirm your own data-handling obligations extend correctly to verification evidence — see Go-live → Compliance.

Rental / property tenant screening

Tenant screening generally combines identity verification (this platform) with separate background/credit checks (typically a different, specialized provider) — the identity step exists to confirm the applicant is who the rest of the screening report is actually about.


Typical regulatory driver	Fair-housing and consumer-reporting rules generally govern the screening decision, not identity verification itself — but confirming the applicant's identity is a prerequisite most screening providers require before running a report.
Recommended modules	`ID_VERIFICATION` + `LIVENESS` + `FACE_MATCH`; `PROOF_OF_ADDRESS` if verifying current residence matters for the application
Integration pattern	Hosted flow via an emailed link is typical — tenant screening is usually a one-time, asynchronous step in a broader application, not something embedded in a daily-use app.

Module combinations at a glance

Vertical	ID	Liveness	Face match	AML	NFC	Proof of address
Fintech / neobank	✅	✅	✅	✅	⚠️ optional	—
Traditional banking	✅	✅	✅	✅	✅ recommended	✅
Crypto exchange	✅	✅ (strict)	✅	✅	⚠️ optional	—
Marketplace / gig	✅	✅	✅	⚠️ if moving funds	—	—
Telecom SIM	✅	✅ (passive)	⚠️ if required	—	—	—
Healthcare	✅	✅	✅	—	—	—
Rental screening	✅	✅	✅	—	—	⚠️ optional

Hosted flow vs. SDK, by pattern

Pattern	Fits best when
Hosted flow (redirect or link)	One-time or low-frequency verification, agent-assisted flows, emailed/SMS/QR delivery, no NFC requirement.
Embedded SDK	Verification is a step inside a broader app experience (signup, driver onboarding, patient portal) and should feel native rather than a navigation away.
Mobile SDK specifically	NFC passport/eID chip reads are in scope — web has no NFC fallback other than routing to manual review.

See Hosted flow overview and SDKs → Overview for the full comparison.

FAQ

KYC modules

What each module does, where it runs, and what it costs.

Workflows

How modules combine into a workflow and get server-enforced.

Verify a user, end to end

The integration pattern every vertical above builds on.