APP Fraud Reimbursement: The Data and Decisioning System Behind a 5-Day Payout Rule

The five-business-day payout is the headline. The problem it creates for your technology function is that you have to make a defensible liability decision, on incomplete evidence, before the clock runs out — thousands of times a year.

Since 7 October 2024 a UK payment service provider in scope of the Payment Systems Regulator’s reimbursement requirement has had to refund most victims of authorised push-payment fraud, in principle within five business days of a claim. Most of what has been written about this treats it as a policy question — who pays, how much, which exceptions apply. That framing misses the operational reality. Reimbursement is a data and decisioning system running to a deadline, and the firms that are struggling are the ones treating each claim as a fresh act of judgement rather than a case moving through a machine they built on purpose.

What the clock actually is

Get the mechanics right before you design anything, because the design follows from them. The sending PSP must reimburse an eligible consumer within five business days of the claim being made. It can stop the clock to gather evidence — for example from the receiving firm — but a final decision has to be reached within a longstop of 35 business days. Consumers have up to 13 months from the last relevant payment to bring a claim. The maximum reimbursement was set at £85,000 per claim (the PSR reduced this from an earlier proposed £415,000 before go-live). The cost is shared 50/50 between the sending and receiving PSP. A firm may apply an optional excess of up to £100 per claim, but not to vulnerable customers, and there is a consumer standard of caution that a firm can only decline against on a high bar of gross negligence. The regime runs over Faster Payments, with an equivalent set of rules for CHAPS.

Free · 4 minutes

Is your engineering team shipping safely, or quietly accumulating risk?

Fourteen questions on how work gets from idea to production — cadence, testing, rollback, and the key-person risk in your delivery. Banded finding on screen, full sheet by email.

Read that as an engineer, not a lawyer. You have a hard deadline, a longstop, a two-sided liability split, a set of eligibility carve-outs, and a decision you have to be able to evidence months later. That is a specification, and most firms never wrote it down as one.

Intake is a data-capture problem, not a form

The claim arrives however the customer chooses to raise it — app, phone, branch, a complaint that only later reveals itself to be a scam. The first failure mode is intake that captures a narrative instead of data. A free-text note saying “customer tricked into paying a fake investment” is not something a decision engine can act on and not something you can reconcile with the receiving firm inside the longstop.

What intake has to produce, from the first contact, is a structured case record: the disputed payment or payments with their scheme references and timestamps, the counterparty account, the scam typology, the channel through which the payment was authorised, whether any warning or intervention was shown at the point of payment, when the customer first became aware, and the vulnerability signals that change both the excess and the standard-of-caution test. If your agents are typing this into a comments box, you are converting a machine-readable event into prose and then paying someone to convert it back. The structured-data discipline here is the same one that makes any regulated reporting workable — capture the fields at source, in a defined schema, or reconstruct them expensively later. It is the same argument I have made about structured data and metadata at the point of submission in an entirely different regime, and it holds here for the same reason.

The decision engine you can defend

The liability decision is where a manual process quietly breaks. A claims handler can reason their way to a sound outcome on a single case. They cannot do it consistently across the volume the regime generates, to the clock, and leave behind a record that shows the same test was applied to the customer you paid and the customer you declined.

What the regime actually needs is a repeatable decision path over the case record. Is the payment in scope — the right rail, within the claim window, an authorised push payment rather than an unauthorised one? Is the consumer eligible? Does the standard-of-caution assessment reach the gross-negligence bar, and if a firm asserts it did, what specific facts support that on this case? Does a vulnerability signal switch off the excess and raise the bar further? Each of those is a rule, not a mood. Encoding them as explicit, versioned logic does two things a spreadsheet and a rota cannot: it lets you actually hit the five-day deadline at volume, and it produces the audit trail — which rule fired, on which evidence, under which version — that turns “we thought it looked like gross negligence” into a decision you can stand behind if the customer escalates or a supervisor asks. This is the same discipline as building any data pipeline behind a regulated signal: the output is only as defensible as the inputs and the logic you can show.

The two-sided part nobody scopes for

The 50/50 split means every claim is also a conversation with another firm. Pay.UK operates a Reimbursement Claims Management System (RCMS) to route claims, evidence and settlement between sending and receiving PSPs, and connecting to it is not the same as being able to feed it well. You are both a sending firm chasing a receiving firm for evidence inside the longstop, and a receiving firm being chased, expected to respond in structured form on someone else’s clock. A firm that has automated its own intake but has to assemble every inbound evidence response by hand has solved half the system and will still miss deadlines on the half it did not. The claims and data-sharing workflow the regime assumes — the round-trips, the evidence formats, the settlement reconciliation — is worth designing deliberately rather than discovering in production, and I have set out what that workflow actually looks like separately.

Where the governance is heading

One caveat on the regulator itself: in March 2025 the government announced that the PSR’s functions would be consolidated into the Financial Conduct Authority, a transition still working through legislation. That changes who supervises the regime, not the obligation. The reimbursement rules, the deadlines and the liability split continue to bind in-scope firms regardless of which nameplate is over the door.

The temptation, with a regime that beds in and stops making headlines, is to let the manual workaround calcify into the permanent process because it is limping along. It will hold until volume spikes — a single large scam campaign, a seasonal surge — and then the five-day clock exposes exactly which parts of your intake and decisioning were people quietly absorbing the load. Build it as a system now, while it is boring, or rebuild it under a backlog later, while it is not.

Most technology problems are not technology problems. They are control problems.

The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.