The case for challenge: step-up checks for the events you are unsure about

Four answers, not two

A fraud check that can only approve or decline forces a bad trade on every uncertain event. Approve it and you take the fraud risk. Decline it and you turn away a customer who may well be genuine, often one you will not see again.

A challenge is the third option. Instead of guessing, you ask the person to prove something: that they hold the registered phone, that they can sign in with a passkey on their own device, that their bank recognises the card payment, or that their face matches an identity document. A genuine customer can usually pass quickly. A fraudster holding only a stolen card number or a leaked password often cannot.

Review is the fourth. It sends the event to an analyst, which is right when a person needs to look but slow when the customer is waiting at checkout.

Where the challenge sits in a decision

In FRAPE, rules and lists run first and settle the clear cases. FRAPE Decision Core, the AI decision model, is consulted only when the rules score falls inside an uncertain band. Its answer is advice. Your policy turns the combined score into approve, challenge, review or decline using thresholds you set. Challenge is the first step above approve, so a typical policy sends the uncertain middle of the range there before anything reaches review or decline.

Decision Core never approves anything by itself. If it fails or times out, your configured fallback applies, and the fallback can be review, challenge, decline or your rules alone, never approve. Challenge is a sensible fallback for many teams: an outage then costs a few seconds of a genuine customer's time instead of an open door.

What the evidence says about strong authentication

Europe has the best public data on this, because the second Payment Services Directive made strong customer authentication (SCA) the default for electronic payments. The rules require authentication based on two or more elements categorised as knowledge, possession and inherence, and for remote payments the code has to be linked to the amount and the payee.

The EBA and ECB 2025 Report on Payment Fraud found that card payments authenticated with SCA had consistently and substantially lower fraud rates than those without it. In 2024, card fraud rates without SCA within the EEA were twice as high as with SCA, and for transactions outside the EEA they were three times higher by value and four times higher by volume.

UK Finance's Annual Fraud Report 2026 adds a caution. It says strong authentication and one-time passcodes have added friction for fraudsters, but criminals bypass them through social engineering, tricking customers into handing over passcodes that are then used to register cards in digital wallets.

Skipping the challenge is a risk decision too

The European rules let a payment provider skip SCA for a remote payment after a real-time transaction risk analysis, but only within limits. The annex to Commission Delegated Regulation (EU) 2018/389 sets reference fraud rates for remote card payments of 0.13% for payments up to about 108 US dollars, 0.06% up to about 271 US dollars and 0.01% up to about 541 US dollars. A provider whose own fraud rate is above the reference rate cannot use the exemption at that amount. Amounts converted from euros at the ECB's 2024 average reference rate of 1.08 US dollars per euro.

The EBA and ECB report shows why the limits exist. It found that around 29% of remote card payments without SCA in 2024 were exempted through transaction risk analysis, and that fraud rates for exempted remote card payments were generally above the overall card fraud rate. Fraudsters aim at the payments that are likely to go through without a check.

Not every challenge is equally strong

NIST's digital identity guidelines, SP 800-63B-4, published in final form in July 2025, are blunt about one-time codes. They state that OTP authentication is not phishing-resistant, that out-of-band authentication is not phishing-resistant, and that use of the phone network (SMS or voice) for out-of-band verification is restricted. Verifiers are told to consider risk indicators such as a device swap or number porting before relying on the phone network, and to offer at least one phishing-resistant option at their second assurance level.

The guidelines name WebAuthn, the standard behind FIDO2 security keys and passkeys, as an example of phishing resistance through verifier name binding: the credential only works on the site it was created for. The FIDO Alliance describes passkeys as phishing resistant and secure by design.

SIM swaps are the main reason to be careful with text message codes. Cifas reported a rise of 38% in unauthorised SIM swaps in 2025, and the FBI's 2025 Internet Crime Report counts 971 SIM swap complaints with losses of 17,366,758 US dollars. A text message code is still far better than no check, but a passkey or a 3-D Secure flow in the banking app is harder to steal.

Where a challenge will not help

Step-up checks prove who is acting. They do not prove the person is acting freely. In an authorised payment scam the real customer is the one passing the passcode or the passkey prompt.

UK Finance makes the same point. Confirmation of payee and warnings in the payment journey may help catch redirection scams earlier, it says, but someone who believes an investment scheme is genuine is likely to pay regardless of warnings. For those cases, review, a delay on a first large payment to a new payee, or a conversation with the customer does more than another authentication prompt.

Matching the check to the risk

A few patterns work well in practice. For logins and profile changes on an existing account, a passkey or the customer's banking app is the strongest prompt you can show. For card payments, 3-D Secure runs the check with the card issuer, and the issuer takes part in the decision. A one-time code by email or text remains a reasonable fallback when nothing better is set up. For a first large payout or a new account that will move money, a document and selfie check run by your identity verification provider gives the most assurance, at the highest cost to the customer.

Then watch the results. A rise in abandoned challenges on one method or one country tells you something, and so does a customer who passes a check and then fails the next one an hour later.

How FRAPE uses this

Your policy decides when the answer is challenge and which methods are allowed: one-time code by text or email, email or text link, 3-D Secure, passkey or identity verification. The score response then includes a challenge with its id, the allowed methods and an expiry. You run the check with your own tools and report the result as passed, failed or abandoned, with the 3-D Secure status or whether the passkey verified the user where that applies. FRAPE records the result as reported by you and never stores the codes themselves.

The next event you score can carry the challenge id. Your rules can then read the challenge status, the method and its age, and count an identity's passed and failed challenges. A challenge links only to the same customer identity and only once, within an hour. The result never decides on its own: your rules say what a pass means. In the console, each challenged event shows its challenge, the reported method, the assurance and the event that re-scored it, and the Challenges page shows outcomes per method.

• How a FRAPE decision is made
• Step-up challenges