When the bank must refund the scam, what is proof of intent worth?

Mandatory reimbursement changed the question British banks are answering. It is no longer only how to stop a scam payment, because the customer authorised it, but who absorbs the loss and on what evidence. This is an argument about the artifact that evidence should be, and an honest account of what it cannot do.

The payment that every control approved

Picture a customer, mid fifties, who receives a call on a Thursday evening from somebody presenting themselves as their bank's fraud team. The caller already knows the last four digits of the customer's card and the name of the branch where the account was opened, because that information has been in circulation for years. The caller explains that an insider at the bank has been compromising accounts and that the customer's funds must be moved to a safe account in their own name while the investigation runs.

The customer opens their banking app. They enter the sort code and account number the caller reads out. The app runs its checks. A warning appears explaining that criminals sometimes impersonate banks and that the bank will never ask a customer to move money to a safe account. The customer reads it, or looks at it, and taps to continue, because the person on the phone anticipated this exact screen forty seconds earlier and explained that it appears for every internal transfer of this type.

They select a payment reason from a dropdown. They authenticate with their face. The payment goes. It is, by every technical measure available to the bank, a perfectly legitimate transaction: the right customer, on the right device, in a genuine session, having passed strong customer authentication, having been shown a relevant warning, having confirmed.

Nine days later the customer discovers the truth and files a claim, and a disputes analyst at the bank has to decide whether this loss belongs to the bank or to the customer. The analyst opens the file. What is in it? A transaction record. A device fingerprint. A risk score that was elevated but below the block threshold. And a log line asserting that warning template WRN_IMPERSONATION_04 was rendered at 19:42:11 and dismissed at 19:42:19.

Eight seconds. The bank's system says it showed a warning and the customer went past it in eight seconds. The customer says they were told the warning was routine and does not clearly remember reading it. Both accounts are plausible. The only record of what happened on that screen was written by one of the two parties to the dispute.

What the reimbursement regime actually requires

On 7 October 2024 the United Kingdom's Payment Systems Regulator brought into force a mandatory reimbursement requirement for authorised push payment scams, set out in its policy statement PS24/5. The core of it is straightforward and, by international standards, unusually strong.

Payment service providers participating in Faster Payments and CHAPS must reimburse victims of in scope APP scams. The maximum reimbursement level was set at 85,000 pounds per claim, having been reduced from a substantially higher figure proposed during consultation. The cost is split evenly between the sending firm and the receiving firm, which is the design choice that most changed institutional behaviour, because for the first time the bank that received and paid away the criminal's funds carries half the bill. Firms may apply a claim excess and must meet defined timelines, and reimbursement can be refused where the customer acted with gross negligence, a standard the regulator frames through a consumer standard of caution.

The regulator has published data on the first period of operation, and it commissioned an independent review from Frontier Economics that reported in July 2026. The published findings describe a substantial sum reimbursed to victims, reported at 243 million pounds by the end of 2025, and a reduction in in scope losses, reported at 73 million pounds over the first year, with the regulator presenting the policy as delivering net benefits. Those are published regulatory findings rather than independent measurements of fraud volume, and they should be read as such.

Two things follow. Losses appear to have fallen, which suggests the liability shift did change firm behaviour. And a large amount of money is now moving from firms to victims through a claims process whose outcomes turn on an evidentiary question.

Why no signature prevents this loss

Now the part that has to be said plainly, early, and without hedging, because this series has spent a lot of words arguing that per action signatures stop entire classes of fraud, and this is the category where that argument mostly does not apply.

In an APP scam the customer is the authoriser. They are not impersonated. Their session is not stolen. Their device is not compromised. They are deceived about the purpose of a payment they genuinely intend to make, and then they make it, competently, using their own credentials on their own phone. Requiring them to sign the payment with a cryptographic key held on that phone changes nothing about the outcome, because they will sign it. They believe they should.

Anyone selling a cryptographic control as a fix for romance fraud or investment fraud is selling something that does not work, and the fastest way to lose a fraud director's attention is to pretend otherwise. A lock on a door does not help when the homeowner has been persuaded to carry the television out to the van themselves. What you need in that situation is not a better lock. It is a reliable record of what the homeowner was told before they picked it up.

So this post is not about prevention. It is about the two things that do move under a reimbursement regime: the quality of the evidence, and the small, specific set of moments where friction the customer chose in advance actually changes an outcome.

Why is the evidence so weak today?

Return to the disputes analyst and the eight second warning. The problem with that log line is not that it is false. It is almost certainly true. The problem is structural: it is an assertion by one party to a dispute about what the other party experienced, unverifiable by anybody else, and produced by a system the asserting party controls.

Consider what it does not establish. It does not establish which warning variant was rendered, if the firm runs experiments on warning copy, which most large firms do. It does not establish whether the warning was displayed above the fold on that customer's screen size, or whether the continue control was reachable without scrolling past the text. It does not establish whether the customer's session was on a device with a small display where the material text was truncated. It does not establish what the customer saw, only what the server intended to send.

This is a general failure that appears throughout this series in different costumes, and it is worth naming: evidence without provenance. A record exists, it is probably accurate, and it cannot be verified by anyone who was not already trusted. The same shape appears in electronic signature audit trails, in merchant chargeback evidence, and in change approval records. In every case the artifact is a log written by an interested party.

The asymmetry cuts both ways, which is the part that makes this worth fixing rather than merely worth complaining about. A firm that genuinely rendered a clear, specific, well designed warning has no way to prove it beyond its own records. A customer who genuinely was shown nothing useful has no way to prove that either. Both parties are arguing from the same unverifiable substrate, and the adjudicator is left weighing plausibility.

What would a better artifact look like?

An intent receipt is a signature produced on the customer's own device, at the moment of confirmation, over a payload that includes not just the payment but a hash of the warning text that was actually rendered on that screen.

The inclusion of the warning hash is the whole idea, and it is a small change with a disproportionate effect. Once the exact bytes of the displayed warning are inside the signed payload, the artifact stops being a claim about what the customer saw and becomes a commitment by the customer that they saw it.

warning_shown = "We will never ask you to move money to a safe account. "
                "Banks, police and government bodies do not do this. "
                "If someone has told you to make this payment, it is a scam."

intent = {
  "payee_name":     "MR J OKONKWO",
  "sort_code":      "04-00-04",
  "account_last4":  "7712",
  "amount_pence":   1850000,
  "payment_reason": "moving_to_safe_account",
  "cop_result":     "no_match",
  "warning_hash":   sha256(warning_shown),
  "displayed_at":   "2026-09-17T19:42:11Z"
}

# The customer confirms on their enrolled device. The assertion covers this hash.
challenge = sha256(canonical_json(intent))
receipt   = device.sign(challenge)

The verification any third party can run, including an ombudsman, a regulator, or the receiving firm in a cost allocation argument, needs no cooperation from the bank that produced it:

def customer_saw_and_confirmed(intent, receipt, warning_text, customer_key):
    if sha256(warning_text) != intent["warning_hash"]:
        return False                    # this is not the text that was signed
    if not verify(customer_key, receipt, sha256(canonical_json(intent))):
        return False                    # not this customer's device
    return True

Now look at what changes in the dispute. If the firm claims it displayed a specific impersonation warning, it produces the text, and the hash either matches the signed payload or it does not. If the firm cannot produce text that hashes correctly, the firm did not show what it says it showed. If the customer claims they were shown nothing about safe account scams, and the receipt contains a hash matching a clear, specific, on point warning that they confirmed alongside a payment reason of moving to a safe account, that is a materially different conversation.

Note carefully that this is symmetric, and the symmetry is the reason it is credible rather than a vendor pitch dressed as a consumer protection. It constrains the firm as much as the customer. A firm running a deliberately vague warning, or burying it, or shipping a variant that omits the operative sentence, now leaves a permanent record of exactly that. Most fraud technology sold to banks helps the bank argue. This helps whichever party is telling the truth.

It also creates something the regulator does not currently have: a comparable, machine readable corpus of what customers were actually shown across firms, at the moment of loss, rather than screenshots supplied in response to information requests.

The mechanics of producing and checking an assertion like this are not exotic. You can watch the signing step run in the signing demo, and the payload and verification surface are set out in the developer docs. For a bank the integration point is a single call at the payment confirmation screen, and the artifact it returns is stored with the payment record rather than replacing anything in the payment rails.

Where does proof of intent actually change the outcome?

APP fraud is not one thing, and the value of an intent receipt varies enormously across its subtypes. This is where most commentary flattens the problem and where a practitioner needs precision.

Two conclusions come out of that table, and they point in opposite directions.

The first is that the top two rows are not really consumer APP fraud at all. They are the business payment cases covered elsewhere in this series, and in those the payee signed instruction genuinely prevents the loss rather than merely documenting it. If your APP exposure is concentrated in business customers paying suppliers, the relevant control is the one described in the supplier bank change piece and in the callback teardown, and it is preventive.

The second is that for the long grooming categories, honesty requires admitting that no evidentiary control helps very much. A victim who has been cultivated for four months over an investment will click past any warning, will lie to a branch employee who asks, and will sign anything. Some of these victims have been coached specifically on how to answer the bank's questions. For that population the answers are elsewhere: at the receiving end where mule accounts are opened, in the platforms where the approach happens, and in the slow work of law enforcement.

What about a second signer?

The second lever is friction that the customer chose in advance, and the reason it is worth taking seriously is that it inverts the usual objection to friction. Nobody is imposing a delay on the customer. The customer set the rule, at a calm moment, on their own terms.

The shape is simple. A customer opts in to a rule: payments above a chosen amount to a payee they have never paid before require a second signature from a person they nominate, on that person's own device. Both signatures are cryptographic assertions from enrolled devices, so a caller who has persuaded the account holder cannot satisfy the rule by persuading the same person twice.

This is the same mechanism described in the piece on protecting an older relative without taking over their account, applied to a broader population. What makes it work against APP fraud specifically is timing. The single most reliable feature of these scams is urgency, because the criminal needs the payment completed inside the emotional window they created. A rule that introduces a delay and a second human, both of which the customer configured months earlier, attacks urgency directly rather than trying to out argue a persuasive stranger in real time.

It also fails in ways worth naming. The nominated second signer may be asleep, unavailable, or persuaded themselves. They may become an instrument of financial control in an abusive relationship, which is a serious harm and means the rule must be removable by the account holder alone, immediately, without the second signer's agreement. And uptake is the open question: consent based friction is only useful if people consent to it, and there is little public evidence yet on how many will.

Does Confirmation of Payee solve this?

Confirmation of Payee is the United Kingdom's account name checking service, and it deserves credit. Before it existed, a payer could enter any name at all and the payment would route purely on sort code and account number, which meant the name field was decorative. Now the payer is told whether the name they entered matches the name on the receiving account, with responses covering full match, close match, no match, and cases where the check could not be performed.

It has measurably helped with a specific attack: the criminal who supplies account details for an account in an unrelated name. It also produces something an intent receipt should capture, which is why the payload above includes a Confirmation of Payee result field. A customer who proceeded past a no match response has done something different from a customer who received a full match, and that difference is relevant to any assessment of the standard of caution.

Where it stops is equally clear. Criminals adapted by opening accounts in names that match what the victim expects, by using company names that look right, and by exploiting the mule networks that supply accounts in arbitrary names. A full match tells you the account is named as expected. It does not tell you the person behind it is who the victim thinks, or that the payment purpose is genuine. It is an account level check, not an intent level one, and the two are complementary rather than substitutes.

Honest limits

• This does not stop a determined, fully persuaded victim. That is the central limit and it applies to every category in the lower half of the table. An intent receipt improves the record of a loss it did not prevent.
• Better evidence can cut against consumers. If receipts show that clear warnings were confirmed, some claims that would previously have been reimbursed on the balance of plausibility may be refused. Anyone proposing this should say so rather than presenting it as purely pro consumer. The defensible position is that accurate adjudication is better than inaccurate adjudication in both directions, and that the same artifact protects customers against firms that overstate what they displayed.
• Regulators may not accept the artifact. Whether a signed warning hash carries weight in a claim assessment is a matter for the regulator and the ombudsman, not for a vendor. Nothing here should be read as an assertion that it does today. It does not.
• Warning design still determines the value. A signed hash of a vague, generic warning proves that a vague, generic warning was shown. The control raises the evidentiary quality of whatever the firm chose to display, and cannot substitute for displaying something useful.
• Second signer uptake is unproven at scale. The mechanism is straightforward, the adoption question is not, and there is limited public data on how many customers will opt in to friction.
• Manav has shipped no bank connectors. Per action signatures, companion device enrollment and offline verifiable receipts exist today. A regulator recognised receipt format for consumer payments and any integration with a specific bank's confirmation flow are proposals, not products. Second signer policy sits with the firm.
• This is not legal or regulatory advice. Firms should take their own advice on the consumer standard of caution and on what evidence they may rely on in claim assessment.

What to do this week

1. Pull twenty recently refused claims and twenty reimbursed ones, and for each write down the single artifact the decision turned on. If most of them turn on a log line your own systems wrote, you have found the exposure.
2. Check whether your warning framework records the exact rendered text per session, including which experiment variant the customer received. Many do not, and that is a one sprint fix worth doing regardless of anything else here.
3. Instrument the gap between warning render and dismissal, and look at the distribution. A large mass of sub two second dismissals is telling you the warning is furniture.
4. Split your APP loss data by scam type against the table above, and calculate what share sits in categories where prevention is genuinely possible versus categories where only evidence and delay help. Fund accordingly.
5. Review your business customer payment flows separately from consumer ones. Mandate and invoice scams are preventable and probably represent a large share of value.
6. Design a second signer feature and test it with real customers before building it, focusing on whether people will opt in and on the abuse case where a controlling partner becomes the second signer.
7. Capture the Confirmation of Payee response as a first class field in your dispute record rather than a transient interface state.
8. Ask your disputes team what evidence they wish they had. They will answer immediately and specifically, because they have wanted it for years.

Frequently asked questions

How do banks reduce APP fraud losses and liability under mandatory reimbursement? By improving evidence and offering consent based friction, not primarily by improving detection. The customer authorised the payment, so detection can only slow or annoy them. A signed intent receipt records what the customer was actually shown and confirmed on their own device, and opt in rules such as a second approver for first time payees attack the urgency the scam depends on.

Does a cryptographic signature prevent authorised push payment fraud? No, and any vendor claiming otherwise is misleading you. In an APP scam the genuine customer, on their genuine device, in a genuine session, deliberately makes the payment. They will sign it, because they believe they should. Signatures prevent impersonation and session theft. Deception of the real account holder is a different problem requiring different tools.

What counts as gross negligence under the reimbursement rules? The Payment Systems Regulator frames the exception through a consumer standard of caution, and applying it in a specific case is a matter for the firm, the ombudsman and ultimately the regulator rather than for a technology vendor. What is clear is that any assessment depends on what the customer was told and how they responded, which is precisely the evidence that is weakest today.

Does Confirmation of Payee prevent APP fraud? It prevents a specific slice of it, where criminals supply an account held in an unrelated name, and it produces a signal worth recording. It does not prevent scams using accounts opened in expected names or supplied through mule networks. It is an account name check rather than a check on intent or on the legitimacy of the payment purpose.

Will the United States adopt APP fraud reimbursement? There is active litigation and regulatory attention around scam losses on instant payment services, and the European Union has been moving toward liability provisions in its payments package. Whether any jurisdiction adopts a regime resembling the United Kingdom's is a policy question that remains open, and firms outside the United Kingdom are watching the published outcomes closely.

Could signed warning evidence be used against victims? Yes, and that should be stated openly. If a receipt shows a clear, specific warning was confirmed, some claims may be assessed differently. The counterweight is that the same artifact protects customers against firms that assert warnings they did not adequately display. The argument for it is accuracy in both directions rather than advantage for either party.

What is an intent receipt? A signature produced on the customer's own enrolled device covering a payload that includes the payee, the amount, the payment reason, the Confirmation of Payee result, and a hash of the exact warning text rendered on that screen. It verifies offline against a published key, so a third party can check what was displayed and confirmed without trusting either the bank's records or the customer's memory.

Sources

1. Payment Systems Regulator, policy statement PS24/5 on the APP scams reimbursement requirement: psr.org.uk policy statements
2. Payment Systems Regulator, published reimbursement data and one year review materials: psr.org.uk news and updates
3. Frontier Economics, independent review of the APP reimbursement policy commissioned by the Payment Systems Regulator, July 2026: frontier-economics.com
4. Financial Conduct Authority, Consumer Duty materials: fca.org.uk consumer duty
5. Pay.UK, Confirmation of Payee service information: wearepay.uk
6. UK Finance, annual fraud reporting: ukfinance.org.uk publications
7. Financial Ombudsman Service, complaints data and approach to APP scam cases: financial-ombudsman.org.uk

Under mandatory reimbursement, the bank is no longer arguing about whether it could have spotted the scam. It is arguing about what the customer saw, and it wrote the only record of that itself.