Identity Verification for KYC/AML

Overview

Identity Verification for KYC/AML Onboarding establishes a verified identity for applicants who are entirely new to your institution — no prior account, no existing data. This is the Unknown → Verified transition in the Trust Progression Model, scoped to run alongside your Customer Identification Program rather than replace it.

The workflow performs the identity verification component of customer onboarding and adds OFAC/SDN screening through authoritative databases so that sanctions exposure surfaces during verification rather than after. It leads with low-friction phone-based identity matching and automatically steps up to government ID document capture for applicants who cannot be corroborated via authoritative data. Most applicants are verified in seconds. The document path ensures coverage for everyone else.

On approval, the applicant's verified identity can be linked to a credential, and their device can be fingerprinted and bound to that credential. These device fingerprints enable frictionless re-authentication in Continuous Re-Authentication and provide a device signal for ongoing monitoring.

Level of Assurance

Medium-High to High. Phone path: authoritative-data-corroborated PII including SSN and date of birth, plus device possession. Document path: government ID with biometric liveness. Both paths run OFAC/SDN screening at the PII Validation step.

User Friction Level

Low for most applicants. Medium for applicants who reach the document step-up.

End User Requirements

Phone path: full name, date of birth, residential address, SSN, and a mobile phone with an active line registered in the applicant's name with the ability to receive SMS.

Document path: government-issued photo ID (passport, driver's license, or ID card) and a mobile device with a camera.

Speed

Seconds for the PII validation and phone possession checks. One to two minutes for the document step-up.

Supported Countries

Phone path: US only in practice, since the authoritative databases and the SSN-keyed authoritative checks are US data sources. The Session Risk step evaluates an allowed-countries condition and routes applicants outside that list directly to the document path.

Document step-up: 180+ countries, 5,000+ document types.

Use Cases & Fraud Prevention

New account onboarding at banks, credit unions, broker-dealers, and money services businesses, as the IDV and OFAC screening component of the institution's CIP.
Fintech and neobank onboarding operating under a sponsor bank's BSA/AML program.
Digital asset and lending platforms that need verified identity plus sanctions screening at account opening.
Fraud prevention: synthetic identity, stolen identity, account takeover, SIM swap, document fraud, impersonation, sanctions evasion.

How It Works

flowchart LR
    Start([Applicant begins]) --> SR[Session Risk<br/>Device + network signals]
    SR -->|High risk| Deny([Denied])
    SR -->|Country not supported| Bio[Government ID and Selfie Match<br/>Document + selfie]
    SR -->|Passes| PII[PII Validation + OFAC<br/>Authoritative data]
    PII -->|OFAC match| Deny
    PII -->|Verified, clean| FT[SMS Link<br/>Device possession check]
    PII -->|Not verified, clean| Bio
    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. This step also evaluates whether the applicant's country is supported for authoritative data verification; unsupported countries route directly to document capture.

PII Validation + OFAC Screening: The applicant submits full name, date of birth, residential address, SSN, and phone number. These are cross-referenced against an authoritative identity database, and mobile carrier records simultaneously. ID Dataweb screens the resolved identity against the OFAC SDN list across five attribute combinations. A verified, clean applicant proceeds to the device possession check. A clean applicant who cannot be verified routes to document step-up. An OFAC match denies.

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

Government ID and Selfie Match (step-up): For applicants who cannot be verified against authoritative data, or whose country is not supported. Government ID capture and biometric selfie matching. The document is authenticated and the selfie is compared biometrically to the document photo.

OFAC Screening Detail

Precise ID evaluates the resolved identity against the SDN list across five attribute combinations, all of which must clear:

Assertion	Match tested
`test.candidateNoOFACMatchToSSN`	SSN
`test.candidateNoOFACMatchToNameAndSSN`	Name + SSN
`test.candidateNoOFACMatchToNameAndDOB`	Name + DOB
`test.candidateNoOFACMatchToSSNAndDOB`	SSN + DOB
`test.candidateNoOFACMatchToNameSSNAndDOB`	Name + SSN + DOB

These are grouped in the TEMPLATE: Watchlist Risk policy component. Because screening is keyed on name, SSN, and date of birth, all three are mandatory attributes on this workflow.

What Gets Established on Approval

Verified identity attributes — resolved name, date of birth, address, SSN, and phone, with the data sources consulted and the verification method applied.
OFAC screening result — the disposition of each of the five match tests and the screening date.
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 devices are recognized. A returning applicant 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 the phone path, lower assurance)
Document-first — for higher-risk products or where the institution's risk assessment requires it

Optional Add-ons

SIM Swap detection on the PII Validation step
Recycled Number / Number Deactivation on the PII Validation step
Email Risk on the PII validation step
Persistent ID (LexID) — stable cross-session identifier, useful as a key for ongoing monitoring
KBA as a secondary step-up option for applicants 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 applicant took.

Step-by-step Setup

Navigate to the Workflow page in the Admin Console.
Click Add Workflow, select Identity Verification for KYC/AML Onboarding, name it, and deploy.
Configure asyncUIRedirect — required for the document capture path.
Confirm the allowed-countries list on the Session Risk step matches your Precise ID coverage.

Integration: ID Dataweb API

Steps chain via forwardApiKey. The /slverify response after the PII Validation step signals which path applies — SMS Link (verified) or Government ID and Selfie Match (not verified). 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 Applicant

    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, DOB, address, SSN, phone)
    IDW-->>App: forwardApiKey₂ + OFAC result + obligation

    alt Verified and clean — 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 Not verified — 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.
Persist the OFAC screening result and verification method alongside your CIP record.

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