Sensitive Transactions

Overview

Sensitive Transaction is a real-time re-verification check applied when a signed-in user attempts a high-value or high-risk action — a wire transfer, a beneficiary change, a large withdrawal. It confirms the user at the moment of the action, not just at sign-in.

It starts the same way as Login Authentication: a silent session risk check that denies high-risk sessions, approves trusted devices with no challenge, and steps everyone else up to SMS Link. What's different is the action=highRisk flag. Your application can send it for any transaction that warrants more than a possession check, and an untrusted device must then also pass PII Validation, with Government ID and Selfie Match as the fallback. The logic:

• High risk → deny.
• Low risk + device trusted in the last six months → approve, no challenge.
• Low risk + device not trusted in the last six months → SMS Link to confirm possession of the user's phone.
• Low risk + device not trusted + action=highRisk → PII Validation. A match continues to SMS Link; no match steps up to Government ID and Selfie Match.

This is a re-verification step performed within the Trusted tier of the Trust Progression Model — the user is already signed in, and the transaction itself is what's being authorized.

Level of Assurance

Low (trusted device, no challenge) to Medium (SMS Link) to High (Government ID and Selfie Match).

User Friction Level

None for trusted devices. Low for the SMS Link step-up — one tap on a link. Medium for flagged transactions — PII confirmation plus SMS Link. High for the document fallback — ID and selfie capture.

End User Requirements

Trusted path: none. SMS Link: a mobile phone able to receive an SMS link. PII Validation: the user's identity attributes, ideally prefilled by your application. Government ID and Selfie Match: a government-issued photo ID and a device with a camera.

Supported Countries

Session risk assessment: global. SMS Link: broad international coverage. PII Validation: dependent on the attribute set and data sources configured. Government ID and Selfie Match: 180+ countries.

Use Cases & Fraud Prevention

• Step-up re-verification for high-value transactions — wire transfers, ACH changes, beneficiary or payee additions, large withdrawals.
• Re-verification before account changes tied to money movement, such as changing the destination account on a recurring payment.
• Confirms the person, not just the session, at the exact moment of risk.
• Prevents: account takeover executing a fraudulent transfer, session hijacking during an authenticated session, and social engineering that has already defeated login-time controls.

How It Works

flowchart LR
    Start([Sensitive transaction initiated]) --> SR[Session Risk<br/>Device + credential check]
    SR -->|High risk| Deny([Denied])
    SR -->|Low risk + trusted<br/>in last 6 months| Approve([Approve — transaction authorized])
    SR -->|Low risk + not trusted| SMS[SMS Link<br/>Confirm phone possession]
    SR -->|Low risk + not trusted<br/>+ action=highRisk| PII[PII Validation]
    PII -->|Match| SMS
    PII -->|No match| Bio[Government ID<br/>and Selfie Match]
    SMS -->|Confirmed on mobile| Approve
    SMS -->|Not confirmed| Deny
    Bio -->|Pass| Approve
    Bio -->|Fail| Deny

Session Risk. Device fingerprint, IP reputation, velocity, and credential match are checked silently, with no user interaction. The step has three outcomes:

• High risk → Deny. Sessions flagged for TOR, a blocklisted IP, or a velocity violation are denied immediately. No challenge is presented.
• Low risk, trusted → Approve. The device and credential were trusted within the last six months. The transaction is authorized with no challenge, whether or not it was flagged high risk.
• Low risk, not trusted → Step-up. Unflagged transactions go to SMS Link. Transactions flagged action=highRisk go to PII Validation first.

PII Validation. Runs only for flagged transactions on untrusted devices. Your application can prefill and lock the user's PII through an encrypted login hint, so the user confirms rather than types — recommended, since you already hold this data for a signed-in user. A match continues to SMS Link. No match steps up to Government ID and Selfie Match rather than denying outright.

SMS Link. A one-time link is sent by SMS to the user's phone. Tapping it on the mobile device confirms possession. Confirmed → approve, and the device can be trusted so future transactions from it skip step-up for six months. Desktop opens and timeouts → deny.

Government ID and Selfie Match. The user captures a government ID and a selfie. The document is authenticated and the selfie is compared biometrically to the portrait. Pass → approve. Fail → deny.

Risk Routing Reference

Integration: Gateway (OIDC)

Standard OIDC flow. See Gateway (OIDC) Integration. Your application sends one /authorize request. To flag a transaction, include action=highRisk as a claim in the encrypted login hint, along with any prefilled PII. The hosted UI runs the session risk check and handles all routing.

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 to carry action=highRisk and prefilled PII.
• Configure risk thresholds in Policy Manager — what counts as high risk and what counts as a trusted device and credential.
• Configure asyncUIRedirect — required for Government ID and Selfie Match.

Integration: ID Dataweb API

Your app calls the Verify API directly rather than redirecting. Session Risk returns approve, deny, or an obligation naming the next step — SMS Link, or PII Validation when action=highRisk is sent.

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

    App->>IDW: POST /slverify (Session Risk key, action=highRisk if flagged)
    IDW-->>App: policyDecision (approve / deny / obligation)

    opt Flagged + not trusted
        App->>IDW: POST /slverify (PII Validation key + PII)
        IDW-->>App: obligation (SMS Link or Government ID and Selfie Match)
    end

    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)
        opt Trust the device
            App->>IDW: POST /trustdevice (asi from approved run)
        end
    else Government ID and Selfie Match
        App->>IDW: POST /async-ui/send-link (Government ID and Selfie Match key)
        User->>IDW: Captures ID + selfie
        App->>IDW: POST /slverify (Government ID and Selfie Match result)
        IDW-->>App: policyDecision (approve / deny)
    end

Step-by-step Setup

• Call Session Risk, passing action=highRisk for flagged transactions. If approve or deny, handle directly.
• If obligation is returned, call the step it names and re-submit the result to /slverify until you receive approve or deny.
• On an approved SMS Link run, call /trustdevice with that run's asi so transactions from the same device skip step-up for the next six months.
• As always: 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 | → Login Authentication | → SMS Link | → PII Validation | → Government ID and Selfie Match | → Gateway (OIDC) Integration