Verification flow

A reusable configuration that defines which checks run, on which documents, with what strictness.

Overview

A verification flow (also called a journey) is the reusable recipe that drives every session. You define one flow per use case, say, "high-risk onboarding for US banking" and reference it from your sessions by its unique tag.

A flow answers four questions:

1. What can the user submit? Allowed countries, regions, and document types.

2. What checks must pass? Document authenticity, face match, liveness, database lookups, name comparison.

3. How strict is each check? Standard vs. Strict policy, liveness level, face-match score threshold, fuzzy-match tolerance.

4. What happens to the data? Retention policy, retry count, session expiry.

Flow types

1Kosmos ships three pre-built flow types. Pick the one that matches your assurance and friction budget.

KYC with Selfie

Document + biometric. The user scans an ID and takes a selfie. 1Kosmos runs document authenticity, passive liveness, and face comparison against the photo on the ID.

Use when: You need to bind a person to a document, onboarding, account recovery, age verification. This is the default for most consumer use cases.

Document Only

Document, no biometric. The user scans an ID and 1Kosmos validates it, but no selfie or face match is performed.

Use when: You only need to confirm the document is genuine, for example, age gating, document re-enrollment, or B2B contexts where a biometric is overkill.

IAL2

Two documents + biometric + SSN. A Kantara-certified flow that produces a NIST 800-63-3 IAL2 result in one session. Sessions expire after 30 minutes by default and data is not persisted to a wallet unless you explicitly enable it.

Use when: You're subject to federal identity proofing requirements, or you need the highest level of assurance for a one-time event.

Flow lifecycle

1

Create

An administrator with idproofing.add-journey opens Verification → Verification Flows in AdminX and walks through the three-step wizard. The flow is saved with a unique tag that your API callers use to start sessions.

2

Test

Generate sessions directly from the flow card in AdminX to QA the experience before going live.

3

Promote

Promote the same flow tag from your staging to production tenant, your application code doesn't change.

4

Tune

Edit the flow at any time. Existing in-flight sessions continue with the configuration they started with; new sessions pick up the change immediately.

5

Retire

Delete the flow when no session generation references it. You'll be prompted to confirm. Past sessions and their results are preserved.

Anatomy of a flow

Every flow regardless of type exposes the same configuration surface:

Group	What you configure
Use case	Context (remote vs. in-person), Document Verification Policy (Permissive → Very Strict), and Retry Count.
Identification	Journey name (human-readable) and unique tag (machine-readable, immutable).
Allowed documents	Allow-list or block-list of document types, scoped by country and region. National vs. state formats are selected separately.
Expiration	"From Session Creation" (how long the URL stays valid if untouched) and "From Session Start" (how long after the user opens it before it times out).
Data comparison	Which user-provided fields are compared against extracted document fields. Fuzzy matching, ignore-middle-names, and DOB comparison live here.
Biometric (KYC with Selfie only)	Liveness Level (Soft / Regular / Hardened) and Face Matching score threshold (0–100%, default 50%).
Data retention	Discard immediately, discard after result is retrieved, or discard after N days/minutes. Applies per outcome (Success, Failed, Review, Abandoned).