Sensitive Transactions

Overview

Sensitive Transaction is a real-time re-verification layer applied at the moment a user — already authenticated and already in a Trusted session — attempts a high-risk or high-value action (e.g., a wire transfer, a beneficiary change, a large withdrawal). Unlike a login-time check, this workflow does not have a silent "no challenge" outcome: every session that isn't denied outright at Session Risk proceeds into PII Validation, because the transaction itself is what's being authorized, not just the session.

The workflow evaluates session risk first, then confirms the user's identity against PII that's prefilled and locked to the transaction itself, then closes with a possession or biometric step-up. The result is a transaction-specific authorization: the bank (or other relying party) never has to trust the session alone for a high-value action — ID Dataweb re-confirms the person and the possession at the point of risk.

This is a real-time re-verification step performed within the Trusted tier of the Trust Progression Model — a user who is already Trusted is required to re-prove identity for this specific transaction before it is authorized.

Level of Assurance

Medium (SMS Link confirmation path) to High (Government ID and Selfie Match fallback path). There is no None/no-challenge outcome on this workflow — see note under Session Risk below.

User Friction Level

Medium for the standard path (PII confirmation + SMS Link tap). High for the fallback path (document + selfie capture).

End User Requirements

PII Validation: the identity attributes prefilled by the relying party (name, phone, etc. — see Configuration Options). SMS Link: mobile phone, ability to receive SMS, matching the prefilled/registered number. Government ID and Selfie Match fallback: same as Identity Verification.

Supported Countries

Session risk assessment: global. PII Validation: dependent on the attribute set and data sources configured. SMS Link: broad international coverage. Government ID and Selfie Match fallback: US, UK, CA (phone path); 180+ countries (document path).

Use Cases & Fraud Prevention

• Step-up re-verification for high-value transactions — wire transfers, ACH changes, beneficiary/payee additions, large withdrawals.
• Re-verification before sensitive account changes tied to a monetary action (e.g., changing the destination account on a recurring payment).
• Confirms the person, not just the session, at the exact moment of risk, without requiring the relying party to hold or transmit the PII itself.
• Prevents: account takeover executing a fraudulent transfer, session hijacking during an authenticated banking session, social engineering that has already defeated login-time controls.

How It Works

flowchart LR
    Start([Sensitive transaction initiated]) --> SR[Session Risk<br/>Passive assessment]
    SR -->|High risk| Deny([Denied])
    SR -->|Obligation| PII[PII Validation<br/>Prefilled + locked attributes]
    PII -->|Match confirmed| FT[SMS Link<br/>Device possession check]
    PII -->|Not corroborated| Bio[Government ID and Selfie Match<br/>Document + selfie fallback]
    FT -->|Approve| Approve([Approve — transaction authorized])
    FT -->|Deny| Deny
    Bio -->|Approve| Approve
    Bio -->|Deny| Deny

Session Risk: Device fingerprint, IP reputation, velocity, and behavioral signals are assessed silently for the session initiating the transaction. Note the divergence from Continuous Re-Authentication: there is no "trusted device + low risk → approve" outcome here. Every session that isn't denied is obligated into PII Validation — the transaction always requires an identity re-confirmation step, not just a clean session.

High risk → Deny: Sessions flagged for TOR, OFAC match, velocity violation, or flagged IP are denied immediately. No challenge is presented.

Obligation → PII Validation: The relying party prefills and locks the user's PII into the transaction via an encrypted login hint (JWE), so PII Validation runs against known-good, transaction-bound data rather than data the user re-types. The user confirms rather than enters.

Match confirmed → SMS Link: A one-time SMS link (FastTap) is sent to the user's registered/prefilled phone number. Must be tapped on mobile — desktop opens or timeouts result in denial.

Not corroborated → Government ID and Selfie Match: If PII cannot be sufficiently matched, the user is stepped up to full document + selfie capture rather than denied outright. This mirrors the fallback relationship used in Continuous Re-Authentication's re-verification path.

Risk Routing Reference

Configuration Options

Template Variations

• Session Risk → PII Validation / deny (no direct-approve tier, by design — see note above)
• PII Validation → SMS Link / Government ID and Selfie Match (fallback) / deny
• Risk thresholds and PII-match sensitivity are configured per-deployment in Policy Manager

Optional Add-ons

• SIM Swap detection on the SMS Link step
• Email Risk on the Session Risk step
• Reference number echo — a client-side, on-page reference number can be generated and displayed on the result screen to make it visible to the end user that ID Dataweb never carries or stores the transaction's monetary details; that binding stays with the relying party.

Trust Device is not offered on this workflow. Sensitive Transaction re-verifies a specific transaction, not a session going forward, so there is no device-trust state to persist between transactions.

Integration: Gateway (OIDC)

Standard OIDC flow. See Gateway (OIDC) Integration. Your application sends one /authorize request with the transaction's PII carried in an encrypted login_hint (JWE, RSA-OAEP-256 / A128GCM, against the workflow's public key); the hosted UI handles all path routing and renders the prefilled, locked PII for confirmation. The token response reflects which path ran.

Step-by-step Setup

• Navigate to the Workflow page in the Admin Console.
• Click Add Workflow, select Sensitive Transaction, name it, and deploy.
• Enable Login Hint on the workflow and select Encrypted (not Signed) — Sensitive Transaction workflows use JWE prefill so PII arrives locked rather than user-entered.
• Configure risk thresholds in Policy Manager — which signals deny at Session Risk, and the PII-match sensitivity that routes to SMS Link vs. the Government ID and Selfie Match fallback.
• Configure asyncUIRedirect — required for the fallback path (Government ID and Selfie Match capture).

Integration: ID Dataweb API

Session Risk returns either a policyDecision (deny) or an obligation forwarding into PII Validation — there is no approve policyDecision at this step. PII Validation runs against the attributes the relying party submits (or against prefilled data carried through forwardApiKey), and its result determines whether the flow continues to SMS Link or falls back to Government ID and Selfie Match.

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

    App->>IDW: POST /slverify (Session Risk key)
    IDW-->>App: obligation + forwardApiKey, or deny

    App->>IDW: POST /slverify (PII Validation key + locked transaction data)
    IDW-->>App: forwardApiKey (SMS Link or Government ID and Selfie Match)

    alt SMS Link
        App->>IDW: GET /doccapture/send-link (SMS Link key)
        IDW->>User: SMS link
        User->>IDW: Taps link on mobile
        App->>IDW: POST /slverify (SMS Link result)
        IDW-->>App: policyDecision (approve / deny)
    else Government ID and Selfie Match (fallback)
        Note over App,IDW: Continues as Identity Verification flow
    end

Step-by-step Setup

• Call Session Risk first. If deny, stop. Otherwise follow the obligation into PII Validation.
• Submit the transaction's locked PII to PII Validation and check forwardApiKey to determine whether the user is routed to SMS Link or the Government ID and Selfie Match fallback.
• For the fallback path, follow the same API sequence as Identity Verification from the Government ID and Selfie Match step onward.
• As with every Verify API call: check the response body, never the HTTP status — a rejected call still returns 200.

See SMS Link, PII Validation, and Government ID and Selfie Match for code samples.

Testing in Preproduction

Related Resources

→ Trust Progression Model | → Continuous Re-Authentication | → Identity Verification | → Identity Binding | → SMS Link | → PII Validation | → Government ID and Selfie Match | → Gateway (OIDC) Integration