UK Faster Payments and APP Fraud Reimbursement: An Analyst's Guide

Since 7 October 2024, UK firms must reimburse authorised push payment (APP) fraud victims on Faster Payments and CHAPS up to £85,000 per claim, within five business days unless they stop the clock, with a hard limit of 35 business days, and the cost splits 50:50 between the sending and receiving firm. Faster Payments messages have ISO 8583 roots with an ISO 20022 mapping, the New Payments Architecture has been replaced by a Bank of England-chaired design board, and the PSR still exists pending legislation to fold it into the FCA.

A customer pays £12,000 to what she believes is her solicitor’s client account. It is a fraudster’s account at another bank. Before October 2024 her outcome depended on which bank she used. Today it depends on rules every Faster Payments firm must follow, and on whether her bank captured the evidence those rules need.

That second part is analyst work. This piece sits in the scheme track of The ISO 20022 Reference, next to Verification of Payee, and treats the UK regime as requirements, data, and test cases.

What is Faster Payments, and where does it stand on ISO 20022?

Faster Payments (FPS) is the UK’s real-time retail interbank system, run by Pay.UK. It has been available day and night, every day of the year, since 2008. Pay.UK’s scheme maximum is £1 million per payment, and each firm sets its own lower limits. In 2025 FPS processed 5.55 billion payments worth £4.84 trillion.

On ISO 20022, the honest answer is: through a mapping. Faster Payments messages have their roots in ISO 8583, the card-messaging family. Pay.UK publishes a Faster Payment System ISO 20022 standards library that it describes as the recommended conversion of ISO 8583 messages to ISO 20022, intended as a guide for firms building an ISO 20022 interface to the FPS central infrastructure. Check the library for the exact position of your message set, because that is where Pay.UK maintains it.

That has two consequences for an analyst:

1. Your internal model may be ISO 20022 while the rail’s heritage is not. If your payments hub speaks pacs.008, there is a mapping layer between it and FPS, and every mapping layer is a place where data is truncated or dropped. The truncation ledger is the method for finding out what.
2. Sterling has two different standards. CHAPS, the Bank of England’s RTGS system, moved to ISO 20022 in June 2023 and carries enhanced data mandates, covered in RTGS on ISO 20022. The same customer’s £12,000 payment looks completely different depending on the rail your routing rules choose.

What happened to the New Payments Architecture?

For years the plan was the New Payments Architecture (NPA): Pay.UK would procure a replacement central infrastructure for FPS. That is no longer the delivery model. The authorities reset it under the National Payments Vision, and the timeline matters if you are scoping anything with a five year horizon.

Date	Milestone
14 November 2024	HM Treasury publishes the National Payments Vision and creates the Payments Vision Delivery Committee (PVDC)
15 July 2025	PVDC sets out a new model: the PVDC sets strategy, a Bank of England-chaired Retail Payments Infrastructure Board (RPIB) turns it into design, and a new industry-led Delivery Company procures and funds the infrastructure. Pay.UK keeps running the existing systems
2025	Pay.UK agrees contract extensions with Vocalink, the FPS infrastructure provider, giving continuity into the early 2030s
7 November 2025	PVDC publishes its Strategy for Future Retail Payments Infrastructure
26 February 2026	PVDC publishes the Payments Forward Plan, a sequenced three year regulatory roadmap
25 June to 11 September 2026	RPIB consults on the design of the future retail payments infrastructure

The RPIB consultation describes a single core clearing and messaging layer, settling in central bank money at the Bank of England, built on common standards that it gives examples of as “agreed approaches to using ISO 20022 message formats” and defined response timeframes. It says migration from today’s infrastructure is likely to run in parallel, possibly with a time-limited period of dual running, and that detailed transition planning comes later.

For a programme today: plan on the current FPS for several more years, keep your ISO 20022 mapping layer as an asset, and treat any FPS replacement date as unverified until the RPIB publishes one.

How does Confirmation of Payee fit?

Confirmation of Payee (CoP) checks the payee name against the sort code and account number before the payment is sent, and tells the payer whether the result is a match, a close match, or no match. It also carries a personal or business account indicator. It runs as an API service between firms, outside the FPS message flow, with a Pay.UK directory identifying participants. Pay.UK reports more than 300 organisations live and more than 2 million checks a day. The PSR’s Specific Direction 17 brought around 400 more firms into scope by 31 October 2024.

Verification of Payee covers the design of the check itself: four outcomes, warning fatigue, and why the record of what the payer saw decides liability. In the UK that last point is now concrete, because the reimbursement rules let a firm decline a claim under the consumer standard of caution only if it can show what the customer was told. The CoP result and the exact warning text are evidence, not logs.

What are the APP fraud reimbursement rules?

The PSR implemented the regime through three legal instruments: Specific Requirement 1 (SR1), which required Pay.UK to write the FPS reimbursement rules; Specific Direction 19, on Pay.UK’s compliance monitoring; and Specific Direction 20 (SD20), which directs every in-scope firm to follow them. CHAPS has an equivalent regime under Specific Direction 21 and the Bank of England’s CHAPS rules. Current as of October 2026:

Parameter	Rule
Start date	Payments made on or after 7 October 2024
Rails	Faster Payments and CHAPS, UK account to UK account
Who is protected	Consumers, microenterprises, and charities
Firms in scope	All PSPs providing relevant accounts on FPS, including e-money and payment institutions; credit unions, municipal banks, and national savings banks are excluded
Maximum reimbursement	£85,000 per claim (firms may pay more)
Excess	Optional, up to £100; never applied to a vulnerable customer
Cost split	50:50 between sending and receiving PSP
Reporting window	Customer must claim within 13 months of the payment
Reimbursement timing	Within five business days of the claim; stop the clock allowed in limited cases; outcome within 35 business days
Exceptions	Customer was party to the fraud (including first party fraud), or gross negligence under the consumer standard of caution; gross negligence never applies to vulnerable customers
Out of scope	Civil disputes, international payments, payments before 7 October 2024

The £85,000 figure has a history worth knowing because people still quote the old one. The PSR’s December 2023 decision set a higher cap; after a September 2024 consultation it confirmed £85,000 from day one, covering, by its estimate, 99.8 percent of FPS APP scams by volume.

Who pays what: the 50:50 split in practice

The sending PSP reimburses its customer. The receiving PSP, which provided the account the money landed in, then contributes half. The edge cases are where the requirements live.

Take the £12,000 case. Three variations:

Scenario	Sending PSP pays customer	Receiving PSP contributes
Sending PSP applies a £100 excess	£11,900	£5,950 (half of what was reimbursed)
Sending PSP chooses no excess	£12,000	£5,950 (half, less half of the £100 maximum excess, per SR1 paragraph 5.13)
Customer is vulnerable, no excess possible	£12,000	£6,000 (no deduction allowed)

The middle row is a PSR clarification: a receiving PSP may deduct 50 percent of the maximum excess when the sending PSP chooses not to levy one. When the customer is vulnerable, the sending PSP has no choice, so the deduction is not allowed. Your contribution calculation needs the vulnerability flag as an input, not just the reimbursed amount.

Two more rules from the PSR’s policy clarifications:

• Mule accounts. Where the victim paid a money mule who passed the money on, the in-scope payment is the first one, victim to mule. Liability sits with the victim’s PSP and the PSP that provided the mule’s account. The onward payment from the mule is not part of the claim.
• Recovered funds. If money is frozen and repatriated after the customer was reimbursed, it is shared between the two PSPs in the same proportions as the reimbursement. Neither may keep more than its loss.

What does the claim timeline look like?

The clock is the most common place claim systems are built wrong, because it is not a due date.

Day 0      Claim received (within 13 months of the payment)
Day 0..5   Default window: reimburse by end of business day 5
           STOP THE CLOCK (limited cases, e.g. information needed
           to assess the claim or the customer's vulnerability)
           RESUME when the information arrives
Day 35     Hard limit: an outcome must exist by business day 35

Requirements that follow:

1. Business days, not calendar days, with a UK bank holiday calendar.
2. A clock that pauses and resumes, with each stop recorded with its reason, its start, and its end. A stop without a recorded reason is a compliance finding.
3. A 35 business day ceiling that ignores stops.
4. Escalation before the ceiling, not at it.

The PSR has said its December 2026 consultation will cover the treatment of claims that cannot be resolved within 35 business days, so treat that branch as a configurable rule, not hard-coded logic.

What data does a reimbursement claim need?

Most of the data a claim needs was created before the payment was sent. That is the requirement teams miss.

Data	Captured when	Why the claim needs it
CoP result and the exact text shown	Payee setup or payment	Evidence for the consumer standard of caution
Fraud warnings displayed, with wording and timestamp	Payment journey	Same; a code is not enough
Customer’s answers to purpose questions	Payment journey	Shows whether the customer was given a relevant warning
Payment identifiers, amount, receiving sort code and account	Payment	Identifies the receiving PSP for the 50:50 claim
Vulnerability assessment	Claim handling	Blocks the excess and the gross negligence exception
Clock events (claim, stops, resumes, outcome)	Claim handling	Proves the five and 35 day rules were met
Police report or consent to report	Claim handling	Part of the consumer standard of caution
Contribution requested and received	Inter-PSP settlement	The 50:50 recovery

Inter-PSP communication runs through Pay.UK’s Reimbursement Claim Management System (RCMS): RCMS Core for the directory and compliance reporting, and an optional claim management layer for filing and managing claims. Sending PSPs report to Pay.UK monthly under the Compliance Data Reporting Standard (reporting standard A), covering claims closed in the previous month. If you are writing the specification for a claim system, turning a business requirement into a functional spec is the method for converting this table into numbered, testable rules.

Can a UK bank delay a Faster Payment it suspects is a scam?

Yes, within limits. The Payment Services (Amendment) Regulations 2024 (SI 2024/1013), in force since 30 October 2024, let the payer’s PSP delay crediting the payee’s PSP when it has reasonable grounds, established by the end of the business day after receiving the order, to suspect fraud by someone other than the payer. The delay must be no longer than necessary and never beyond the end of the fourth business day after receipt. The payer must be told, by the end of the next business day, that the payment is delayed, why, and what they need to do.

That creates a new payment state your system may not have: held for fraud enquiry, not rejected, not sent. It needs its own timer, its own customer message, and an exit to either release or refusal. State machines for payments is the right tool to model it before anyone builds it.

What about the PSR’s merger into the FCA?

It has been decided and not yet done. The government announced in March 2025 that it would consolidate the PSR primarily into the FCA, consulted from 8 September to 20 October 2025, and published its response on 21 April 2026, saying it will bring forward primary legislation when Parliamentary time allows. As of October 2026 the PSR still operates, and its own site notes that FCA staff increasingly support PSR functions.

For a programme, the practical rule: the reimbursement regime is set out in PSR legal instruments and Pay.UK rules that remain in force. Reference the instrument (SD20, SR1, SD21), not the regulator’s name, in your requirements, so the documents survive the transfer.

What is changing next?

The PSR’s independent evaluation by Frontier Economics, published on 1 July 2026, found APP fraud losses down by an estimated £73 million a year and firms reimbursing 97 percent of in-scope claims. The PSR’s roadmap that followed:

• August 2026: engagement with industry and consumer groups, including on the 13 month reporting requirement and some investment scams.
• December 2026: formal consultation, covering claims not resolved within 35 business days, “returns from investment”, guidance on the consumer standard of caution, civil disputes, and me-to-me payments, plus new data collection on the platforms fraudsters use.
• May 2027: decision and revised legal directions, with implementation within six months of the decision.

So a claim system built now should hold the 13 month window, the 35 day handling, and the consumer standard of caution criteria as configuration: the parameters most likely to move.

If turning a regulatory instrument like SD20 into a specification is the part you find hardest, From Vague BR to Functional Requirements walks through exactly that, and Break Into Banking covers the payments domain around it.

What should an analyst test?

• A claim reimbursed on business day 5, and one on business day 6 with no stop, asserting the second is flagged as a breach.
• A stop the clock with a reason, a resume, and an outcome on business day 34, asserting compliance; the same claim reaching business day 35 with no outcome, asserting escalation.
• A claim spanning a UK bank holiday, asserting business day arithmetic.
• The three contribution rows above, asserting £5,950, £5,950, and £6,000.
• A vulnerable customer, asserting no excess and no gross negligence exception are available in the workflow.
• A claim at £85,000 and at £85,001, asserting the cap and the Ombudsman message.
• A payment made on 6 October 2024, asserting out of scope.
• A mule chain of two payments, asserting only the victim to mule payment is in the claim.
• A partial repatriation after reimbursement, asserting the 50:50 share.
• A payment held for fraud enquiry, asserting the customer notice by the end of the next business day and release or refusal by the end of business day 4.
• A proceed-after-no-match CoP payment, asserting the stored evidence holds the displayed wording, not only the result code.

These are rule-boundary and state-transition cases, the core of negative test design and decision tables. To practise turning a vague requirement into checkable rules, the free Review Scorecard is a quick self-check.

The takeaway

The UK reimbursement regime turned APP fraud from a customer service problem into a set of hard rules: £85,000 per claim, five business days with a 35 day ceiling, 13 months to claim, and a 50:50 split that depends on the excess and the customer’s vulnerability. Every one of those is a requirement with data behind it, and most of the data was created in the payment journey before anyone knew it was a fraud.

Around it, the infrastructure is in transition. Faster Payments reaches ISO 20022 through a mapping from its ISO 8583 roots, the New Payments Architecture has given way to a Bank of England-chaired design board with no fixed replacement date, and the PSR is waiting for legislation to fold it into the FCA. Build to the instruments, keep the parameters configurable, and store what the customer saw. The rest of the scheme track is on The ISO 20022 Reference.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Faster Payments, APP Fraud, Payments Regulation, Requirements, ISO 20022, Banking