User Onboarding

Overview

Identity Verification establishes a verified identity for users who are entirely new to your system — no prior account, no existing data. This is the Unknown → Verified transition in the Trust Progression Model.

The workflow leads with low-friction phone-based identity matching and automatically steps up to government ID document capture for users who cannot be corroborated via carrier data. Most users are verified in seconds. The document path ensures coverage for everyone else.

On approval, the user's verified identity is linked to a credential, and both their devices — the desktop browser and the mobile device used for SMS Link — are fingerprinted and bound to that credential. These device fingerprints enable frictionless re-authentication in Continuous Re-Authentication.

Level of Assurance

Medium-High to High — phone path: carrier-corroborated PII + device possession. Document path: government ID + biometric liveness.

User Friction Level

Low for most users (phone path). Medium for users who reach the document step-up.

End User Requirements

Phone path: mobile phone with an active line registered in the user's name, ability to receive SMS.
Document path: government-issued photo ID (passport, driver's license, or ID card), mobile device with camera.

Speed

Seconds for the phone path. 1–2 minutes for the document step-up.

Supported Countries

Phone path: US, UK, CA. Document step-up: 180+ countries, 5,000+ document types.

Use Cases & Fraud Prevention

New account onboarding (KYC, CIP, AML) — regulated industries, financial services, healthcare, government.
Any use case where a user is unknown and a verified identity must be established from scratch.
Fraud prevention: synthetic identity, account takeover, SIM swap, document fraud, impersonation.

How It Works

flowchart LR
    Start([User begins]) --> SR[Session Risk<br/>+ Passive Risk]
    SR -->|High risk| Deny([Denied])
    SR -->|Passes| PII[PII Validation<br/>Phone-based identity match]
    PII -->|Match| FT[SMS Link<br/>Device possession check]
    PII -->|No match| Bio[Government ID and Selfie Match<br/>Document + selfie step-up]
    FT -->|Confirmed on mobile| Approve([Verified])
    FT -->|Not confirmed| Deny
    Bio -->|Pass| Approve
    Bio -->|Fail| Deny

Session Risk: Device fingerprint and network signals are assessed silently. High-risk sessions — TOR, flagged IPs, velocity violations, bot signals — are denied before any user input is collected.

PII Validation: The user submits their name, address, and phone number. Cross-referenced against mobile carrier records and authoritative databases simultaneously. A confirmed match proceeds to device possession check. A failed match routes to document step-up.

SMS Link: A one-time link is sent via SMS to the user's registered phone. The user must tap the link on their mobile device. Desktop opens or timeouts result in denial.

Government ID and Selfie Match (step-up): For users who cannot be matched via carrier data. Government ID capture and biometric selfie matching. The document is authenticated and the selfie is compared biometrically to the document photo.

What Gets Established on Approval

On a successful verification, two things are bound to the user's credential:

Desktop device — the browser fingerprint collected during Session Risk is registered against the credential.
Mobile device — the phone used to complete SMS Link is fingerprinted and registered as a trusted device.

On future sessions via Continuous Re-Authentication, these fingerprints are recognized. A returning user on a trusted device with clean session signals is approved with no challenge.

Configuration Options

Template Variations

Phone match + device possession → document step-up on match failure (default)
Phone match only → document step-up (no possession check on phone path, lower assurance)

Optional Add-ons

SIM Swap detection on the PII Validation step
Recycled Number / Number Deactivation on the PII Validation step
Email Risk on the Session Risk step
Persistent ID (LexID) — stable cross-session identifier on approval
KBA as a secondary step-up option for users who cannot complete document capture

Integration: Gateway (OIDC)

Standard OIDC flow. See Gateway (OIDC) Integration. Step-up routing between the phone and document paths is handled automatically by the hosted UI — your application receives a single authorization code regardless of which path the user took.

Step-by-step Setup

Navigate to the Workflow page in the Admin Console.
Click Add Workflow, select Identity Verification, name it, and deploy.
Configure asyncUIRedirect — required for the document capture path.

Configuration Options — Gateway-specific

📝
Content coming soon.

Integration: ID Dataweb API

Three steps chain via forwardApiKey. The /slverify response after the PII Validation step signals which path applies — SMS Link (match) or Government ID and Selfie Match (no match). See PII Validation and Government ID and Selfie Match for detailed API reference.

sequenceDiagram
    participant App as Your Application
    participant IDW as ID Dataweb API
    participant User as End User

    App->>IDW: POST /token (apiKey:secret)
    IDW-->>App: access_token

    App->>IDW: POST /slverify (Session Risk key)
    IDW-->>App: forwardApiKey₁

    App->>IDW: POST /slverify (PII Validation key + name, address, phone)
    IDW-->>App: forwardApiKey₂ + obligation (SMS Link or Government ID and Selfie Match)

    alt Phone match — SMS Link possession check
        App->>IDW: GET /async-ui/send-link (SMS Link key)
        IDW->>User: SMS link
        User->>IDW: Taps link on mobile
        App->>IDW: POST /slverify (SMS Link result)
    else No match — Government ID and Selfie Match document step-up
        App->>IDW: POST /async-ui/send-link (Government ID and Selfie Match key)
        IDW->>User: Document capture link
        User->>IDW: Captures ID + selfie
        App->>IDW: POST /slverify (Government ID and Selfie Match result)
    end

    IDW-->>App: policyDecision (approve / deny)

Step-by-step Setup

Obtain an access_token — see API Authentication.
Check the obligation field after the PII Validation step to determine which path to route.
Pass transaction_id from the first response as asi in all subsequent calls for session continuity.

Configuration Options — API-specific

📝
Content coming soon.

Testing in Preproduction

Test Credentials and Values

Scenario	Input	Expected Result
Phone path — approve	Andrew Roshell data, tap SMS link on mobile	`approve` via phone match
Document step-up — approve	Cause PII failure → Andrew Roshell + Passport	`approve` via document
Deny — document	Andrea Roshell + Driver's License	`deny` at Government ID and Selfie Match
Deny — possession	Andrew Roshell, open SMS link on desktop	`deny` at SMS Link

Step-by-step How to Test

Phone path: Enter Andrew Roshell data, receive the SMS link, tap on mobile.
Document step-up: Cause a PII failure (name mismatch), then complete Government ID and Selfie Match with Passport using Andrew Roshell.
Deny (document): Use Andrea Roshell with Driver's License.
Deny (possession): Open the SMS Link on a desktop browser.

Related Resources