H7.11.3step-up authentication paymentdesignresearch

Large or anomalous payments need step-up identity checks

Aliases: step-up auth · SCA · anomalous payment

What it is

Everyday small amounts can ride a signed-in session or biometrics. When the amount jumps, the device or place does not look like this person, or the payee is new, step up identity: password, OTP, biometric, or a rail challenge. It is not a lock icon on the page, and not how many warning sentences you stack—it is raising authentication strength on this capture.

Why it happens

A session proves “this device was you a moment ago,” not “this payment still is you.” Theft often grabs the session then changes payee or amount. Challenging every payment abandons small ones; challenging none lets a stolen session empty the store. Step-up concentrates cost on high loss or low familiarity. People need to know why the extra step: “large amount” or “new device” beats vague “security check.” The challenge must land on a channel they can receive, or step-up becomes a decline.

Studying it

Vary amount threshold, new device, new payee. Compare never challenge, always challenge, risk-based. Watch completion, intercept under a simulated steal, rate of skipped challenges.

Independent variables: trigger, challenge type, whether lowering amount avoids the challenge. Dependent variables: legitimate completion, abandon, whether an attacker session passes, naming why they were challenged.

Labs know it is a test account; stolen sessions are hard to simulate. Role-play “hand the phone to someone else to pay,” but do not treat that as a real theft rate. Do not invent intercept percentages.

Where it stops holding

Mandated strong customer authentication may challenge most remote payments, leaving less room for thresholds, but still avoid stacking two equivalent challenges on one capture. People without a phone cannot receive SMS; keep a backup factor. Paying on behalf of a company is not a “my device” model; step-up the authorized role. Subscription renewals follow an existing mandate; they are not anomalous each period unless amount or payee changed.

Applying it

  • Define triggers: over threshold, new device, new payee, many captures in a short window; say which one hit.
  • Challenge with a second factor already on file; failure offers a backup, not a loop.
  • Allow lowering amount or reverting to a known payee to drop this step-up; do not offer “skip verification.”
  • Verify: same account pays a usual small amount (no challenge), then one over threshold or on a new device. No challenge, or no explanation, fails. Handing the session to someone else for a large amount should stop.

Related

  • Within the group: H7.11.1 Payment pages need recognizable security cues · H7.11.2 Sensitive payment entry needs anti-shoulder-surf and anti-screenshot · H7.11.4 Too many security warnings desensitize people to real ones
  • Adjacent: H6.12 Multi-factor authentication · H6.05 Biometrics · H7.06 Payment failure
  • Search terms: step-up authentication · SCA · anomalous payment

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/H7.11.3