Risk-Based Authentication and Step-Up

What it is

Risk-based authentication has two inputs that teams often merge but should keep separate:

1. Context risk. How likely is it that this session is not the customer? This comes from Device Reputation and Linkage, IP Reputation and Proxy Detection, Login Anomalies, Session Behavior Anomalies, Behavioral Biometrics, Remote Access Tool Detection, and recent Account Change Events.
2. Action risk. How bad would it be if this action were fraudulent? The answer depends on amount relative to balance, whether the action can be reversed (an RTP or crypto send can't), whether the destination is new, and how much of the balance is exposed.

Step-up is the response: ask for a stronger or fresher factor before the action goes through. The key design choice is to authorize the transaction rather than the session. A session that is genuine at login can be hijacked, remotely controlled or socially engineered by the time a withdrawal is requested.

What it stops (and what it doesn't)

Design considerations

1. Classify every money-moving action by risk tier, and do it ahead of time. A working default:

2. Choose the step-up factor based on what the context signal suggests. If the risk signal points to a likely SIM swap, an SMS step-up is useless. If it points to a remote-access tool or scam coaching, a step-up the victim can complete adds nothing. Map signal families to response families:

• Device or network anomaly: fresh possession factor, preferably a passkey.
• Phone-risk anomaly: a non-SMS factor.
• Remote control or coaching indicators: a hold, a scam interstitial or a callback instead of a challenge.

3. Bind step-up to the transaction. The challenge should name the action, payee and amount, and the resulting token should be good for that action only. This is what SCA dynamic linking requires. It also blunts relays, because the victim sees what they are approving.

4. Recency windows. "Authenticated within N minutes" is a useful policy input, but a stolen session token can satisfy it. Let Tier 3 actions require a factor presented for this action.

5. Escalate across events. A challenge that is passed should lower the risk. A challenge that fails, is abandoned, or is passed from a high-risk device should raise the risk for every later action in the session and for a window afterward.

6. Log challenge outcomes as features and labels. Pass, fail, abandon and fallback-used are among the strongest features for Real-Time Transaction Risk Scoring and Machine Learning Models. Make sure labels separate "passed step-up then confirmed ATO" from "passed and genuine".

7. Enforce in one place. Step-up policy should live in the decision layer (Real-Time Decisioning Architecture), and every channel should call it instead of re-implementing it per app.

Industry lens.

• Brokerage: step-up on bank-link change, withdrawal, outbound ACATS and unusual trading in illiquid names (the Ramp-and-Dump via Account Takeover pattern).
• Neobanks / P2P: step-up on new payee, first send, and limit raises.
• Cashback / rewards: step-up on changing the cash-out destination, and on the first cash-out after a dormant period.
• Marketplaces: step-up on seller bank-account change, payout acceleration, and the buyer side of store-credit cash-out.
• Retail: step-up on gift-card balance transfer and loyalty-point redemption.

Implementation path

Customer friction and trade-offs

• Concentrate challenges. The goal is low challenge rates overall with high rates on the riskiest few percent of actions. If more than a small fraction of genuine payouts are challenged, the context model isn't separating risk well.
• Timing. Challenging at payout is friction the customer understands. Challenging at login on every new device costs logins and pushes people to support.
• False security. Every challenge a scam victim passes adds confidence to a fraudulent payment, both in your logs and in any later liability argument. Do not use step-up as your scam control.
• Accessibility and coverage. Customers without smartphones or reliable SMS need an alternative path that is not a weak backdoor.

Measuring effectiveness

• Step-up capture rate. Of confirmed ATO cash-out attempts, the share that hit a step-up, and the share stopped by it.
• Genuine challenge rate per 1,000 Tier 2/3 actions, and abandonment after a challenge (a cost proxy).
• Attacker pass rate. Confirmed-fraud cases that passed a step-up, by factor. Track this monthly as the key drift metric.
• Loss per action tier. Losses should fall most where step-up applies. If losses concentrate in Tier 1, the tiering is wrong.
• Challenge-to-fraud lift. Fraud rate among challenge-failed and challenge-abandoned events compared with baseline, to validate the outcomes as features.
• See Fraud Metrics and KPIs and Friction and Customer Experience Tradeoffs.

Common failure modes

• Login-only scoring. Risk computed at login and never recomputed at payout.
• Wrong factor for the threat. SMS step-up on accounts with recent phone changes or carrier risk.
• Reusable tokens. Step-up tokens not bound to the action; one challenge authorizes every later action in the session.
• Unprotected bypass paths. API, partner or legacy endpoints that skip the policy service.
• Fail-open on timeouts. When the policy or scoring call times out, the payout goes through. Define per-tier fallbacks: fail closed or hold for Tier 3 (see Real-Time Transaction Risk Scoring).
• Passed challenge treated as proof. Downstream monitoring suppresses alerts because the customer "passed MFA".
• No feedback loop. Challenge outcomes are not stored, so the policy never learns.

Regulatory and policy notes

• FFIEC 2021. The Authentication and Access guidance expects authentication controls to follow a risk assessment and be layered. It names MFA or controls of equivalent strength as more effective for higher-risk access. Transaction-time step-up is a direct way to show layered, risk-based authentication.
• NIST SP 800-63B-4. Covers session reauthentication timeouts and allows risk signals to inform authentication decisions. Under NIST, risk signals inform the decision but cannot replace an authentication factor. Your policy documentation should reflect that.
• EU PSD2 / UK SCA. These require strong customer authentication for electronic payments, with dynamic linking to amount and payee. The transaction-risk-analysis exemption (RTS Delegated Regulation 2018/389, Arts. 18–19) lets a PSP skip SCA on remote card payments up to €100, €250 or €500 only if its overall card fraud rate is at or below 0.13%, 0.06% or 0.01% respectively, and its real-time risk analysis finds no listed risk indicator. The EBA has confirmed the rate is the PSP's overall card fraud rate, not a per-band rate. Remote credit transfers have their own reference rates in the RTS Annex.
• PSD3 / PSR status. As of October 2026 the package had political agreement (November 2025) and final compromise texts (April 2026) but had not been published in the Official Journal; adoption is expected around December 2026, with most PSR rules applying about 21 months after entry into force. Until then the PSD2 RTS governs. The PSR keeps the two-of-three-factor SCA model and the TRA exemption, with conditions to be set in new EBA technical standards.
• Reg E. Step-up evidence helps in disputes, but liability turns on whether the transfer was authorized by the consumer. A passed step-up does not automatically make a transfer "authorized" (see Regulation E and Unauthorized Transfers).

Mechanisms addressed

• Account Takeover (ATO) and Session Hijacking and Infostealers: transaction-time assertions defeat session reuse.
• Payout Redirection and Account Recovery Abuse: step-up plus cooling-off on change events.
• Real-Time Payment Rail Fraud, ACATS Transfer Fraud, Ramp-and-Dump via Account Takeover: Tier 3 action handling.
• Loyalty and Rewards Redemption Fraud and Digital Wallet Provisioning Fraud: step-up at redemption and provisioning.
• MFA Bypass and OTP Interception: partially; pair with phishing-resistant factors.
• Credential Stuffing: step-up when an exposed credential logs in from a new device, and again at the first payout.

Related controls

• Multi-Factor Authentication (MFA)
• Passkeys and Phishing-Resistant Authentication
• Device Binding and Trusted Devices
• Contact Change Cooling-Off Periods
• Real-Time Transaction Risk Scoring
• Withdrawal and Payout Controls
• Payee Confirmation and Payment Friction
• Velocity and Exposure Limits
• AI Agent Verification (Know Your Agent) (step-up to the human when an agent acts outside its mandate)
• Playbooks: Playbook - Account Takeover Members, Playbook - Payout and Withdrawal Risk Members

Sources and further reading

• NIST SP 800-63B-4: AAL definitions, reauthentication, risk signals as optional measures; phishing-resistant option at AAL2.
• Federal Reserve SR 21-14 (FFIEC Authentication and Access, 2021): risk-assessment-driven, layered authentication; MFA or equivalent controls.
• NCUA: FFIEC authentication guidance press release: push-payment risk and single-factor weaknesses.
• LegalClarity: NIST AALs and step-up authentication: secondary explainer; action-based vs environment-based triggers, and environment signals not replacing factors.
• CFPB: Regulation E § 1005.6: consumer liability framework that step-up evidence feeds into.
• legislation.gov.uk: Delegated Regulation 2018/389, Chapter III: SCA exemption conditions, including Art. 18 transaction risk analysis.
• EBA Single Rulebook Q&A 2018_4043: TRA reference fraud rates and how the rate is measured.
• Adyen: PSD3 and PSR explained: PSD3/PSR status as of October 2026 and SCA direction.