APP Fraud Reimbursement UK: The 50:50 Rules

If a scammer's account sits on your books, you owe half of the victim's refund within five business days of being told, even though the victim was never your customer. That is the part of the UK's APP fraud reimbursement rules that catches receiving-side teams out, and it applies to EMIs and indirect participants as much as to the high street banks.

Most explainers of the regime are written by law firms for compliance teams. They cover the £85,000 cap and stop there. This guide is for the people who have to build the claim clock, the contribution calculation and the reporting feed. Figures come from the Payment Systems Regulator's consolidated policy statement (PS25/5, May 2025), Specific Requirement 1, Pay.UK's RCMS product outline and the PSR's published data. Where I could only confirm something through a secondary source, I say so.

What Are the UK APP Fraud Reimbursement Rules?

An authorised push payment (APP) scam is one where the customer sends the money themselves after being deceived. Since 7 October 2024, payment service providers must reimburse victims of APP scams sent over Faster Payments or CHAPS. Payments made before that date are out of scope.

The legal plumbing has four layers, and it helps to know which one binds you:

The headline numbers:

Which Payments Are Covered by APP Fraud Reimbursement?

The payer must be an individual, a micro-enterprise (fewer than 10 staff and turnover or balance sheet of €2 million or less) or a charity with annual income under £1 million. Larger businesses are not covered.

What falls outside:

• Civil disputes, where the customer paid a real supplier and is unhappy with the result
• International payments
• Payments to an account the customer controls (the "me-to-me" leg of a multi-step scam)
• Card, cash and crypto legs
• Unauthorised payments, which the Payment Services Regulations 2017 already cover
• Accounts at credit unions, municipal banks and national savings banks, plus Channel Islands and Isle of Man accounts

For how these two rails differ in limits and messaging, see my comparison of Faster Payments, Bacs and CHAPS. Bacs is not covered by this regime at all.

How Does the 5 Business Day Clock and Stop-the-Clock Work?

There are two clocks, and only one of them pauses.

The five-day clock starts when the customer reports the scam. The sending PSP can pause it, as many times as it likes, but only for five reasons listed in Specific Requirement 1 (paragraph 5.4):

1. Waiting for information from the victim, their agent or the receiving PSP 2. Verifying a claims management company 3. Assessing whether the customer is vulnerable 4. Gathering evidence of first-party fraud 5. A multi-step scam that involves other PSPs

The pause begins when the request is sent and ends when the response arrives. The 35-day clock never pauses. Whatever is outstanding, the claim must be closed by the end of the 35th business day after the report.

Model it as an event log, never as a mutable "days remaining" counter. Something like this is the minimum I would accept in review:

{
  "claim_id": "c_01JD3",
  "reported_at": "2026-11-12T10:14:00Z",
  "hard_deadline": "2027-01-05",
  "receiving_psp_notify_by": "2026-11-12T12:14:00Z",
  "clock_events": [
    { "type": "pause", "reason": "INFO_FROM_RECEIVING_PSP", "at": "2026-11-13T09:00:00Z" },
    { "type": "resume", "at": "2026-11-17T15:30:00Z" }
  ],
  "business_days_elapsed": 1,
  "vulnerable": false,
  "excess_applied_gbp": 100
}

Field names here are mine, not Pay.UK's. The points that matter are that the pause reason is an enum of exactly five values, that every pause has a timestamped trigger you can show an auditor, and that hard_deadline is computed once from the report date using the English bank holiday calendar. The PSR's data shows 82% of claims closing within five business days and 98% within 35, so roughly one claim in six runs past the five days. Design for that path, because it is common.

How Is the 50:50 Split Calculated Between Sending and Receiving PSPs?

The split is not half of what the victim received. Under Specific Requirement 1 (paragraph 5.15), the receiving PSP's contribution is always calculated as if the £100 excess had been applied, whether or not the sending PSP actually charged it.

So waiving the excess is a cost the sending firm absorbs alone. Where the money went to several receiving PSPs, the £50 deduction is pro-rated across them in proportion to what each received.

Recovered money follows a waterfall (paragraph 5.17). Repatriated funds are split 50:50 between the two PSPs, each capped at what it paid out, and any remainder goes to the victim. Take a £100,000 scam: the cap limits reimbursement to £85,000, so the sending PSP is out £42,550 and the receiving PSP £42,450. If £90,000 is later recovered, each firm is made whole and the remaining £5,000 goes to the customer, who was £15,000 short.

For CHAPS claims the contribution itself is paid over Faster Payments, and claims that mix both rails are dealt with only in the CHAPS rules. Keep the rail on each payment line, not on the claim.

What Is the RCMS and Do PSPs Have to Use It?

The Reimbursement Claims Management System is Pay.UK's platform for the regime. It comes in two tiers:

Registration with Pay.UK was mandatory by 20 August 2024. Using RCMS to manage claims is not. Many articles still say it becomes compulsory on 1 May 2025, but on 10 April 2025 the PSR said it would not mandate any particular system. The consequence is in Pay.UK's July 2025 product outline: if either party to a claim is not on Core+Claims, the claim runs offline, by whatever channel the two firms can agree.

Two practical limits from the same document. Free-text comments cap at 2,000 characters and the system takes no attachments, so evidence packs travel separately. And the API specifications sit behind Pay.UK's DataSite, so you need to be onboarded before you can read them. Reporting Standard B, the automated feed, still has no confirmed date. CHAPS reporting remains a spreadsheet emailed to the Bank of England.

When Can a PSP Refuse an APP Fraud Claim?

Outside the scope exclusions, there is one route: the consumer standard of caution. The customer is expected to have regard to interventions from their PSP or the police, report promptly, answer reasonable information requests, and report to the police or let the PSP do so.

Failing one of those is not enough. The PSP must show gross negligence, the burden of proof is entirely on the PSP, and the exception cannot be used against a vulnerable customer at all. In the PSR's data to 31 March 2026, only 3% of claims were rejected on this ground.

A rejected claim becomes a complaint, then a Financial Ombudsman Service case. The FOS can look at the receiving firm's conduct and at losses above £85,000, and its award limit is £455,000 for complaints referred from 1 April 2026. So the cap bounds the scheme, not your exposure.

The related tool on the prevention side is the Payment Services (Amendment) Regulations 2024, in force since 30 October 2024. They let a PSP hold an outbound payment for up to four business days where it has reasonable grounds to suspect fraud or dishonesty by someone other than the payer. If you build that hold, log the grounds at decision time, because "we intervened and the customer ignored it" is the first limb of the caution standard and you will have to evidence it.

Is APP Fraud Reimbursement Working? The 2026 Data

The PSR's dashboard (updated 30 July 2026) covers the 18 months to 31 March 2026: about 438,300 claims, 301,500 of them in scope, and 88% of in-scope money returned, worth £316 million. The PSR puts the equivalent figure before the regime at 66%, when reimbursement rested on the voluntary CRM Code.

Frontier Economics' independent evaluation, published 1 July 2026, found APP losses down by about £73 million a year and roughly 35,000 fewer scams. Over 99% of claims fall under the cap.

The more useful findings for anyone building this are about inconsistency. One firm used the caution exception in over 25% of cases while others never used it. The share of claims flagged as vulnerable ranged from 2% to 38% between firms. Firms that had not signed the old CRM Code applied the excess in 93% of cases, against 53% at former signatories. Those gaps are too wide to be explained by different customer bases. They are different rule engines.

UK APP Reimbursement vs EU PSR, Zelle, Australia and Singapore

The UK is the outlier on two counts: breadth of scam types, and making the receiving firm pay. The EU text, which I covered in my PSD3 and PSR guide, gives the PSP 15 business days and adds liability for verification-of-payee failures; as of November 2026 it had not been published in the Official Journal, so treat the article numbers as provisional. In the US, the CFPB's lawsuit against Zelle's operator and three banks was dismissed in March 2025, which leaves the network's own policy as the only protection.

My view: the receiving-side charge is the part that works, and other regimes will copy it before they copy the cap. A sending bank can only warn. The receiving firm onboarded the mule, and a 50% bill per claim is the first incentive that prices weak onboarding directly. The trade-off is friction, since firms now hold and question more legitimate payments.

What Changes in 2027: PSR Consultation and the FCA Transfer

The PSR's roadmap lists a consultation for December 2026, a decision in May 2027 and implementation within six months. In scope: claims still unresolved at 35 days, how "returns" paid out by investment scams are treated, guidance on the caution standard, civil disputes and me-to-me transfers, and compliance data reporting, including a deadline for Reporting Standard B.

Separately, the PSR is being folded into the FCA. The legislation was still before Parliament in November 2026, and until it commences the PSR enforces Specific Directions 20 and 21. The directions transfer; the obligations do not lapse. I found no public enforcement action under SD20 so far, which I would not read as a signal that none is coming.

What This Means for Engineers at UK PSPs and EMIs

1. Build the receiving side first if you are an EMI. You probably send fewer scam payments than you receive. You need an inbound claim queue, a two-hour-aware alert, and a five-business-day payment obligation with its own SLA. 2. Claim your sort codes in the RCMS directory. Otherwise claims default to your sponsor and your clock runs while nobody is looking. 3. Store clock events, not clock state. Pause reasons as a five-value enum, timestamps on both ends, and a hard deadline that no code path can extend. 4. Calculate the contribution as if the excess applied. Pro-rate the £50 across receiving PSPs, and run repatriation as a capped waterfall with the remainder to the customer. 5. Tag every payment with how it settled. Scheme or book transfer, Faster Payments or CHAPS, PISP-initiated or not. Scope depends on all three. 6. Record vulnerability and intervention evidence as structured data. The Frontier figures suggest firms decide these very differently, and the 2027 guidance is aimed squarely at that. 7. Support the offline path. A counterparty not on Core+Claims means email and spreadsheets, and your case system still has to hold the timestamps. 8. Pair it with payee checks. Confirmation of Payee and the EU's verification of payee are where a warning becomes evidence.

I'm Tom Wang, and I write about the engineering underneath payment rules. If your scheme documents say something different from this guide, trust the documents and tell me.