The Three-Way Decision

In one line: framing fraud as approve-or-decline throws away the option that resolves most of the uncertainty, which is to ask.

Why binary is the wrong frame

A binary decision forces every borderline case into a confident answer the model does not have. The transaction that scores at 0.4 is exactly the one you know least about, and both available answers are likely wrong.

The third option is a step-up challenge: ask the customer to prove they are who they say. A one-time code, a 3-D Secure flow, a push notification to a known device, a security question.

This changes the shape of the problem. Instead of one threshold splitting the score into approve and decline, there are two, and the middle band gets resolved by evidence rather than by guessing.

The same two-threshold structure as a guardrail cascade or a search relevance policy, arriving from a third direction — whenever you have a confident band and an uncertain band, spend the expensive resolution only on the middle.

What a challenge actually costs

Not free, and quantifying it is what separates a real design from a diagram.

Abandonment. A meaningful share of legitimate customers drop out at a challenge — they do not have their phone, the code does not arrive, the flow is confusing, or they simply lose patience. That share is the real cost, and it varies enormously by channel and demographic.

Support load. Failed challenges generate contacts, which cost money and staff time.

Latency. The transaction now takes seconds to minutes instead of milliseconds, which matters for some products and is fatal for others.

It is not free against fraud either. An attacker with a stolen phone, a SIM swap, or a social-engineered victim passes the challenge. A step-up raises the cost of the attack; it does not settle the question.

Not all challenges are equal

The strongest version of this answer treats friction as a spectrum rather than a switch.

So the decision is not "challenge or not" but "how much friction is justified by the score and the amount". A £30 order at a moderate score gets a push notification; a £3,000 order at the same score gets a full authentication flow.

That produces a two-dimensional policy — score against exposure — rather than a threshold, and it is a genuinely better answer than a single challenge band.

Where challenges do not apply

Worth naming, because the technique is not universal.

Asynchronous fraud — a fraudulent listing, a fake review, a money-laundering pattern — has no user waiting for a decision, so there is nobody to challenge in the moment.

The user is the one being deceived. In authorised push payment fraud, a challenge succeeds: the customer really is who they say and really does intend to send the money. Authentication answers the wrong question entirely, and the useful intervention is a warning about the payee rather than a proof of identity.

Enumeration attacks. An attacker testing stolen card numbers does not care about challenges — they will abandon that card and try the next. Here the correct response is rate limiting on the attempt pattern rather than authentication of any single one.

The reverse direction

The option most designs forget entirely: allow with monitoring.

Approve the transaction, and flag it for asynchronous review. If it turns out to be fraud you can often reverse it — cancel the order before dispatch, freeze the account, claw back the transfer.

This is powerful wherever the outcome is not instantaneous. A physical goods order has hours before dispatch, and hours is enough for an analyst to look. Choosing to approve now and review before shipping converts a synchronous decision under uncertainty into an asynchronous one with more evidence.

That is the same design move as making an action reversible so it does not need a confirmation gate — a pattern that recurs whenever a system must decide under uncertainty.

Designing the bands

Four practical points.

The challenge band's width is set by capacity and abandonment, not by the score distribution. Widen it until either the abandonment cost exceeds the fraud avoided, or the step-up infrastructure saturates.

A passed challenge should update state. If a customer authenticates successfully, subsequent transactions from that device and session should be treated more favourably — otherwise you challenge them repeatedly and manufacture your own abandonment.

A failed challenge is a strong label. It is one of the few clean fraud signals available in near-real time, and it is worth far more than the transaction it blocked. Feed it back deliberately.

Never challenge on something the fraudster controls. Sending a code to the email address on the account is useless if the account was taken over and the email was changed. The challenge must go to a factor established before the suspicious activity started.

That last point is the one interviewers probe on account takeover, and it is the difference between a challenge that authenticates and one that theatrically confirms the attacker is the attacker.

Next: the signals, and why they must be computed rather than fetched.