Your Scam Warnings Pass Review. Do They Stop a Customer Mid-Scam?

Most banks and payment firms can show a regulator that they warn customers before a risky payment. Far fewer can show that the warning works on the customer it exists for: someone who is, at that moment, on the phone with a scammer who has already predicted the warning and told them how to get past it.

That gap matters more now than it did two years ago, and it is cheaper to measure than most teams assume.

Why the warning screen now carries money

The UK reimbursement requirement for authorised push payment (APP) scams, introduced by the Payment Systems Regulator, went live on 7 October 2024, with reimbursement up to £85,000 per claim. The cost is shared 50:50 between the sending and the receiving firm. So a scam payment that gets through is now a direct loss on both sides of the transfer, not a complaint to be argued over.

The firm can refuse reimbursement only in narrow cases, the main one being a customer who was grossly negligent, the "consumer standard of caution" exception. In the PSR's first-three-months snapshot, only 2% of claims were rejected on that ground. In practice, a warning is a weak defence against a claim. Its value lies mostly in whether it stops the payment in the first place.

The FCA is pushing in the same direction from the conduct side. Its March 2026 review of consumer understanding under the Consumer Duty said that testing of communications needs to be thorough, documented and inclusive, and that firms should check whether a change actually worked. A warning that was approved in a design review but never tested against a coached customer is hard to defend under that standard.

How warnings fail in practice

Warnings are usually written and tested by people who are calm, reading slowly, and not being manipulated. The real reader is none of those things. The failure patterns that recur:

• The scammer pre-empts the warning. "Your bank will show a message saying this could be a scam. That is standard, the fraud team is watching, just tick 'I understand'." Once the warning has been predicted, it confirms the script instead of breaking it.
• The payment-purpose question is coached. Many flows branch the warning on the purpose the customer selects. A coached customer picks "paying a friend" or "paying a bill", and receives the mildest warning in the stack.
• The warning describes the wrong scam. A generic "is someone pressuring you?" message does little against an investment scam that has been building trust for six weeks with small, successful returns.
• The friction is all on the first screen. The customer learns the path once. On the third payment in the same scam, they move through it in seconds.
• Nobody measures the outcome per warning. The team knows the overall scam loss rate, but not which warning variant was shown on the payments that later became claims.

The receiving side: the message to suspected mules

The 50:50 split also changes the receiving firm's position. Many scam payments land in accounts run by money mules, and some of those account holders were recruited with a "job" or a favour and do not fully understand what they are part of. Firms already send these customers a restriction or account-review message. That message is usually written by legal and operations, and its only goal is to inform. It is rarely tested for whether the customer understands what happened and stops before the next payment arrives.

A self-check your team can run this month

None of these needs a vendor. They need a fraud analyst, a copy of the payment journey in a test environment, and an honest afternoon.

1. Write the scammer's version of your warning. For each of your top three scam types, write the sentence a scammer would say to get the customer past your warning. If that sentence is easy to write, the warning is predictable.
2. Pick the "safest" payment purpose. Go through your flow choosing the purpose that triggers the least friction. Note what a coached customer would see. That is your real warning for most coached scams.
3. Time the third pass. Have a colleague go through the same flow three times in a row. If the third pass takes under ten seconds, the friction is not doing its job on repeat payments.
4. Join warning shown to claim outcome. Take the last quarter's reimbursed APP claims and look up which warning variant was displayed on each payment. If you cannot do that join, you cannot tell which warnings work.
5. Read a warning out loud to someone on a phone call. Scam victims are often on a call while paying. If the warning only works when read in silence, it will not work in the real situation.
6. Check the mule message for one action. Read your restriction message as a 19-year-old who was offered "easy money". Does it say plainly what happened, why it matters to them, and the one thing they should do now?
7. Find the owner. Ask who owns the warning copy, who owns the thresholds that decide when it fires, and who is told when claims rise. If those are three teams that do not meet, that is the first fix.

How Riskernel runs this as a fixed-scope assessment

The Scam Warning Lab is a three-week engagement. You get a lab where a scripted scammer plays against a copy of your real warning screens, and a report on which warnings hold and which fail. As an option, it includes a pilot of a short explainer in the message you already send to suspected money mules.

The work runs on a copy of your screens, not on live customers. It produces evidence your fraud, product and conduct teams can act on, and the kind of documented testing the FCA's review describes. Scope and fees are agreed on a short call.