APP fraud reimbursement best practice, in one sentence: decide every UK APP scam claim within five business days on evidence the bank can show, give the customer written reasons, refuse only where you can prove gross negligence against a bespoke warning, let a trained person judge vulnerability, and reach the same answer for the same facts whoever handles the claim. The PSR's rules set the first four. The fifth is where firms fall short: the independent evaluation published in July 2026 found that outcomes can still depend on who a customer banks with. Any way of running claims, whether by hand, with a rules engine, or with AI agents gathering evidence for people to decide, should be judged against those yardsticks. Botminds' APP Fraud Reimbursement is the third kind, and this guide is honest about where it fits and where a bank needs something else.
The guide is written for the operations and transformation leads choosing how to run claims for the next few years. It starts with the yardsticks, compares the three approaches against them, and ends with the questions to put to any supplier, including us.
Three ways to run APP claims, judged against what the rules require
| What the rules require | Manual case handling | Rules engine or workflow tool | Agents gathering evidence, people deciding |
|---|---|---|---|
| Notice to the receiving firm within two hours | Depends on when a person reaches the claim; late on busy days | Reliable once the claim is logged with the payment details | Sent at intake by an agent, with the payments the receiving firm needs |
| A decision within five business days, stops only for permitted purposes | Tracked in a spreadsheet or the case tool; stops often undocumented | Strong on counting and alerts; cannot judge whether a request is proportionate | Counted against UK bank holidays; each stop drafted with its purpose and approved by a person |
| Refusals proven, interventions quoted | As good as the handler’s search of warnings and call recordings | Sees that a warning flag fired, not what it said, so generic warnings can pass as interventions | Quotes each warning and call, classes it bespoke or boilerplate, and proposes; a person decides |
| Vulnerability judged case by case | Found when a handler happens to read the right note | Matches flags and keywords; misses signals in free text and calls | Quotes signals from notes and transcripts with confidence; a specialist decides |
| The same facts get the same answer | Varies by handler; visible only in a month-end sample | Consistent where the rule is coded, silent where judgment is needed | Each proposal compared with similar decided claims; the spread between handlers reported |
| The receiving firm’s half claimed and chased | Manual; easy to forget the excess rule | Calculates and schedules well if the claim is complete | Claimed once the refund posts, with the excess rule, and chased in bulk |
| A file the Ombudsman can read | Notes in free text across several systems | Structured fields, but the reasoning lives elsewhere | Every answer cites the payment, warning, note or call it rests on |
What is best practice for APP fraud reimbursement?
It is a short list of habits, each tied to a rule or a finding the PSR has published. None of them requires particular software. All of them are harder to keep at volume than they look on paper.
Ten practices for APP fraud reimbursement, and the rule or finding behind each
- Notify each receiving firm at intake, not at assessment
The rules require notice within two hours of the claim (PS25/5 para 3.14).
- Gather the whole file before the handler opens it
Payments, Confirmation of Payee results, every warning as shown, notes and calls. Five days leave no time for searching.
- Stop the clock only with a named purpose and an outstanding request
Five purposes, and no others (SR1 para 5.4); close by the 35th business day.
- Assess vulnerability before drafting any refusal
A material impact removes both the excess and the caution exception.
- Judge each payment in a claim separately
A bespoke warning before payment three does not reach payments one and two.
- Quote the intervention; never cite a warning type
Only bespoke, actively shown interventions can support gross negligence (guidance para 1.10).
- Put a second reader on every refusal and every release
The burden of proof is the bank’s alone, and money should not move on one person’s word.
- Write the reasons in plain words, with the Ombudsman route
Written reasons are required before the claim can close (SR1 para 5.9).
- Claim the receiving firm’s share the day the refund posts
Only 67% of receiving firms paid within five days in the first nine months.
- Measure consistency between handlers every month
The PSR’s evaluation found outcomes still vary by bank; it will consult on consistency in December 2026.
The yardsticks every approach is judged by
The published numbers set the floor a bank's own performance will be compared with. Over the regime's first 18 months, the PSR's dashboard shows 82% of claims closed within five business days and 98% within 35, with 3% rejected for lack of customer care. In the first three months, 86% of claims reached the receiving firm within two business hours.
The industry's numbers, the floor for any operating model
82%
of claims closed within five business days
to 31 Mar 2026
98%
closed within 35 business days
same period
86%
passed to the receiving firm within two business hours
first three months
95%
of firms submit accurate data on time
first year
Speed alone is not the test. A bank that closes every claim on day 3 but refuses on boilerplate warnings is fast and non-compliant, and the cost arrives later as complaints the Financial Ombudsman upholds. The yardsticks have to be met together, which is why the comparison above runs row by row rather than giving each approach a single score.
Three ways banks run APP claims
Most banks started with manual case handling in October 2024, many have added workflow rules since, and some are now testing agents. Each solves a different part of the problem.
Manual case handling puts an experienced handler on each claim with access to every system. Judgment is its strength, and it is the right starting point for a small firm with few claims. Its weakness is the reading: payments in one system, warnings in another, notes in the core banking system, calls in a recording archive. With five-day clocks, the reading crowds out the judgment, and two handlers reading different subsets of the evidence reach different answers.
A rules engine or workflow tool adds clocks, queues, routing and arithmetic. It is excellent at what can be written as a rule: the two-hour notice, the business-day count, the 50:50 calculation, the second-review threshold. It is weak where the evidence is free text. A rule can see that a warning fired before a payment; it cannot tell whether that warning was specific to this customer, this scam and this payment. Coded naively, it counts a generic warning as an intervention, which is exactly what the PSR's guidance forbids.
Agents with people deciding do the reading. They pull the evidence, quote it, answer each question the rules ask with a confidence and the passage it rests on, and propose. People decide, check and sign. The approach is newer, and its risks are different: an agent can misread, so the design has to make every answer checkable, ask a person when confidence is low, and never let an agent refuse, stop a clock or move money.
Can APP claims be automated?
The gathering, counting, drafting and chasing can be; the decisions should not be. The rules place judgment squarely on the sending bank. "We expect sending PSPs to gather and take into account all relevant evidence when processing a claim." Vulnerability is to be assessed case by case, and a refusal needs proof the bank can stand behind. None of that forbids software; all of it argues for a named person on each outcome.
The useful line runs between work that produces evidence and work that produces outcomes. Notifying receiving firms, building the payment trail, quoting warnings, counting business days, computing contributions, drafting letters and assembling monthly data are evidence and administration. Deciding scope in a borderline case, finding gross negligence, confirming vulnerability, approving a stop, releasing money and sending a refusal are outcomes. Automating the first group is what frees people for the second.
How one claim moves when agents gather and people decide
Agent
Intake agentBuilds the claim from the report, starts the clock and notifies each receiving firm within two hours.
Never: Decides scope or contacts the customer
Agent
Assessment and Vulnerability agentsAnswer scope and the caution requirements with quoted evidence; find vulnerability signals in notes and calls.
Never: Refuse, or label a customer vulnerable
A person decides
Vulnerable customer specialistConfirms or declines material impact, with a note, after speaking to the customer where needed.
Agent
Consistency agentCompares the proposal with similar decided claims and flags an outlier before anyone signs.
Never: Changes a decision
A person decides
Handler, then a second personThe handler decides; a reviewer checks every release and re-reads every refusal for gross negligence.
Agent
Letter and Recovery agentsDraft the outcome letter for the checked release, then claim the receiving firm’s share once the refund posts.
Never: Send a letter or pay another firm without a person
How do you keep handlers consistent?
Measure the spread, find its cause, and put comparable decided claims in front of the handler before they sign. A monthly sample read by a quality team finds inconsistency after the letters have gone. A comparison at the point of decision prevents it.
The measure is simple: each handler's reimbursement rate by value on comparable claims, and the gap between the highest and lowest. The cause is usually a pattern, not a person. In Botminds' solution the Consistency agent compares each proposal with similar decided claims before anyone signs and reports the spread to the head of fraud operations. In the solution's fictional sample month, the spread was 6.1 points against a design target of 5, traced to one habit: an excess taken on claims where a vulnerability was confirmed later. The fix there was a calibration session and refunds of the excess, each needing a release check. The pattern, not the handler, was what needed changing.
A vulnerability finding, and what it changes for the decision
What did the PSR evaluation say about firms?
That the scheme works, and that firms apply it unevenly. The evaluation by Frontier Economics, summarised by the PSR on 1 July 2026, found losses down by an estimated £73 million a year and in-scope claims reimbursed at 97%. On consistency it was direct:
"Inconsistent implementation has meant outcomes can still vary to some degree depending on who consumers bank with."
PSR news release on the independent evaluation, 1 July 2026
The PSR's response is a consultation planned for December 2026. Its roadmap says the consultation will consider where the policy needs more clarity, naming guidance on the consumer standard of caution, on civil disputes and on payments between a customer's own accounts. Firms that can already show consistent decisions in those areas will have the least to change. The guidance on caution as it stands is set out in the consumer standard of caution exception.
Questions to ask before you buy
Ask any supplier to run your own past claims, and judge the answers against the yardsticks, not against a demonstration. The questions below are the ones we would ask of ourselves.
Questions for any APP claims software, ours included
- Show me the warning, not the warning flag
For a refused claim, can it display the exact text or call the customer received before each payment, and say why it was bespoke?
- Who can refuse, stop a clock or move money?
If the answer includes the software, ask how that squares with the bank carrying the burden of proof.
- How does it count business days?
The rules exclude bank holidays in any part of the UK, including Scotland’s and Northern Ireland’s.
- What happens below its confidence threshold?
It should ask a named person, not guess.
- How does it calculate the receiving firm’s share?
Including the excess rule, several receiving firms, and money recovered later.
- Can it show consistency between handlers, with the cause?
A spread without a reason is a number nobody can act on.
- What evidence will the Ombudsman see?
Every answer should trace to the payment, warning, note or call it rests on.
- Will you run it on our closed claims first?
Comparing its proposals with the decisions your handlers made is the fairest test before go-live.
How quickly can a new process go live?
The timetable depends less on software than on what the bank brings: a written reimbursement policy, reason codes, letter templates, and access to the systems a claim touches. A bank that has to write its policy first will take longer than one that is changing tools. The rules allow no pause while a new process beds in, so the safe route is to run the new process alongside the old on a slice of claims, then switch.
For Botminds' solution, the inputs are the bank's reimbursement policy, reason codes, letter templates and the systems claims already run on: core banking, the Faster Payments gateway, the industry claims exchange, case management with call transcripts, the general ledger and print. It goes live after its quality checks pass. We offer to run it on a sample of a bank's own past APP scam claims first, so the comparison is with the bank's own decisions rather than with our sample data. The bank-to-bank side of that integration is covered in the reimbursement claims management system guide.
Where Botminds' APP Fraud Reimbursement fits, and where it does not
It fits a bank that already receives a steady flow of APP claims and wants the reading, counting, drafting and chasing done before its people decide. It is built around the yardsticks above: seven agents, each with stated limits, a handler deciding every claim, and a second person on every release, every refusal for gross negligence and every claim over £30,000. Its design targets are every claim decided within five business days, or by the 35th where a stop is permitted, and no more than five points between handlers' reimbursement rates. These are targets, not results measured at a customer.
It does not prevent scams; warnings, payment holds and Confirmation of Payee belong to Botminds' APP fraud detection solution. It does not replace the industry claims exchange or Pay.UK's reporting; it works with them. And it does not make decisions a bank must make itself, including its policy on the excess, its second-review thresholds and its approach to borderline scope. A small firm with a handful of claims a month may be well served by careful manual handling and a good checklist.
The outcome letter, written plainly and checked before it goes
Questions people ask
Is there an official APP fraud reimbursement best practice guide?
There is no single official guide. The binding texts are the PSR's Specific Requirement 1, the Faster Payments and CHAPS reimbursement rules, and the PSR's consumer standard of caution guidance; PS25/5 consolidates them with answers to common questions. The Financial Ombudsman also publishes how it approaches APP complaints.
Should a bank use AI to decide APP scam claims?
Decisions should stay with named people: the sending bank alone decides each claim and carries the burden of proof on refusals. AI can gather and quote evidence, count deadlines and draft letters, provided every answer is checkable and a person signs each outcome.
How should banks organise APP claims teams?
Around separate seats for intake, decision, vulnerability, second review and recoveries, with a head of fraud operations accountable for timeliness, outcomes and consistency. The seat-by-seat view is in our guide to PSR mandatory reimbursement.
What do auditors and the Ombudsman look for in an APP claim file?
The evidence behind each finding, the timing of each step and the reasons given. The Ombudsman says it will assess the nature and quality of any intervention a refusal relies on and why the customer moved past it, and it asks sending firms to complete a business response form for scam cases.
Does best practice include reimbursing more than the rules require?
That is a policy choice. A bank may pay above £85,000 or beyond 13 months, but those payments are voluntary and the receiving firm owes no share of them.