Verification Methods

The catalog of checks you can run inside a flow — pick the combination that fits your risk and friction budget.

---

Verification methods

A verification flow is built from one or more methods. Each method answers a specific question about the user.

Method	Question it answers	Friction
Document verification	Is the document the user submitted real, current, and unmodified?	Low–Medium
Biometric & liveness	Is the person holding the document the same person pictured on it — and present right now?	Medium
Database verification	Do authoritative sources (AAMVA, SSA) corroborate the submitted data?	None (passive)
SSN verification	Is the SSN provided real, and does it belong to the verified user?	Low
Notarized document bypass	Has this user already been verified by a trusted notary or partner?	None
Web-to-mobile handoff	Can the user finish capture on a phone after starting on desktop?	Low

Picking a combination

Higher friction generally means higher assurance. The right combination depends on what you're protecting.

Low risk — newsletter, free tier

Email verification only (no IDV).

No need for document verification. Save the user the friction.

Medium risk — paid SaaS

Document verification + biometric & liveness.

Bind a real person to a real ID. Adequate for most B2C consumer apps and SaaS sign-ups.

High risk — banking, healthcare

Document + biometric & liveness + database + SSN.

Document scan with face-match, AAMVA lookup against the issuing DMV, and SSN check. Equivalent to NIST IAL2.

Run a Kantara IAL2 flow →

Very high risk — federal, classified

Two STRONG documents + biometric & liveness + database + SSN + in-person or supervised remote.

Required for IAL3. Often combined with an in-person notary step, which 1Kosmos accommodates via notarized document bypass.

What happens at runtime

When a session runs against a flow, each configured method becomes a step in the user's UI and a check on the server. The user-facing order is fixed (document → selfie → optional SSN entry), but the server-side checks run in parallel where possible.

A failure in any required method fails the overall session. A failure in an advisory method (e.g. AAMVA where the upstream is unreachable) is downgraded to not_performed and doesn't block the result, unless your flow's strictness explicitly requires it.