Year one of mandatory reimbursement worked, but unevenly.
Since 7 October 2024, banks have had to refund most victims of authorized push payment (APP) scams, where customers send the money themselves because someone deceived them. The regulator's first evaluation came out in July 2026. Losses are down and refunds are up, but outcomes depend heavily on which bank you're with. That inconsistency is a process problem, and process is what an agent can make consistent.
The evaluation also found firms applied the vulnerability assessments, the gross-negligence exception and the optional £100 excess inconsistently. One firm applied the exception in more than 25% of cases by value, while others never did. Figures are from the PSR's one-year review and Frontier Economics' July 2026 evaluation (see sources).
What the bank must do, in plain terms
| Rule | What it means for the design |
|---|---|
| Refund up to £85,000 | Covers Faster Payments and CHAPS. Card, international and crypto payments aren't covered, so the agent has to route them elsewhere and say so plainly. |
| Alert the receiving bank within 2 hours | A hard time limit, which makes protection the obvious step to automate. |
| Decide within 5 business days | The count starts the business day after the report. "Stop the clock" pauses it while the bank waits on information, but every claim must close within 35 business days, and that count never pauses. |
| Receiving bank pays 50% | The sending bank refunds the customer, then claims half from the bank that received the money. |
| Two exceptions | First-party fraud, and gross negligence (the "consumer standard of caution"). Claims older than 13 months can be refused. |
| Vulnerable customers | Neither the gross-negligence exception nor the excess can be applied. The vulnerability call decides the outcome. |
From the PSR's consolidated policy statement PS25/5 and Pay.UK's Faster Payments rules. PSR functions are moving to the FCA, and a consultation on changes is due December 2026, so re-check before relying on these.
One conversation in the app, from report to refund
An app-first bank already owns the moment the customer realizes something is wrong. The agent turns that moment into a complete claim, protects the account in minutes, and keeps the customer updated without making them chase.
The story is told once
The agent pre-selects likely payments for the customer to confirm, and checks whether the scammer is still active. A person is one tap away.
Minutes, not hours
The payee is blocked and the other bank alerted well inside the 2-hour rule. The deadline is shown as a date, not a policy.
A person for the sensitive part
The vulnerability check comes from a named person, not the agent, because it decides the outcome.
Four levels of autonomy, set step by step
One global "how autonomous is the AI" setting is too coarse. Freezing a payee and declining a scam victim are different risks, so each step gets its own level, and staff always know which one they're looking at.
Eleven steps from report to recovery
Two questions set each step's level
How hard is it to undo? A payee block reverses in one click. A message can't be unsent. A declined claim can end up at the Financial Ombudsman.
What does a wrong call cost? A wrong log line costs a minute. A wrong "not vulnerable" costs a scam victim their refund.
Cheap, reversible steps run on their own. Costly steps that can be undone need one tap of approval. Steps that can't be taken back are sent as drafts. Costly, permanent calls stay with people. A step only moves up when the rollout data shows it's earned it.
Case SC-24817: the "safe account" call
On Sunday evening, a 71-year-old customer gets a call from someone posing as the bank's fraud team, who talks them into moving £2,400 to a "safe account" in two payments. They report it on Monday morning.
What the specialist sees on Tuesday at 10:05
The handoff screen is where this design succeeds or fails. If a specialist can't check the agent's work in a few minutes, they'll either redo it or rubber-stamp it.
Recommend: refund in full, £2,400, no excess
Vulnerability confirmed by Priya Nair on Monday at 09:41, so the gross-negligence exception and excess don't apply.
- ✓Payments authorized by the customer, not a third partyPAY-LOG 88213
- ✓Confirmation of Payee returned "no match", and the customer continuedCOP 4471-A
- ✓"Safe account" warning shown, dismissed in 3 secondsWARN-EVT 1192
- ✓Receiving account 9 days old, £2,310 moved out within an hourRB-REPLY 0731
- ✓No earlier claims, no first-party fraud signalsCLAIMS-HIST
- !Scam call came from an outside number, so there's no recordingnot checked
What this should change, and how I'd prove it
This is a concept, so nothing here has been measured. Baselines come from the regulator's published data where it exists. Targets are what the design is built to reach, and each one is tied to the part of the workflow that would move it.
| Outcome | Baseline | Target | What moves it |
|---|---|---|---|
| Claims closed within 5 business days | 84% (industry, year one) | 95% | Evidence gathered in minutes, a day 3 alert, and pauses that need a reason |
| Time to alert the receiving bank | Rule: within 2 hrs | Under 5 min | Protection runs on its own because every action is reversible |
| 50% shares collected on time | 67% of firms paid on time | Every late share chased within 1 day | Automated chasing through Pay.UK's claims system |
| Consistency of outcomes | Refund rates 21–94% across firms | Variance between specialists halved in 6 months | One evidence checklist, and two reviewers on every decline |
| Specialist time per claim | ~3 hrs (assumption) | ~25 min | The agent compiles the file, and the specialist reviews it |
| Times the customer tells the story | Not published | 1 | One claim record from the first message |
Change the assumptions and see what they add up to
Every input is an assumption you can change. The point is to show what a pilot would need to prove, not to predict results. The model treats freed time as capacity to redeploy, not as headcount to cut.
A fast yes and a careful no
Full automation would make declines faster too, and declines are exactly where a wrong call hurts a victim. Setting autonomy step by step lets one design serve both the customer and the bank.
- A better chance the money is still therePayee blocked and the other bank alerted in minutes, before the account is emptied.
- Tells the story onceA single claim record carries the story through every step.
- A refund in a day or two, not on day fiveRetrieval and the write-up take minutes, so clear claims don't wait in a queue.
- The same outcome at any bank deskOne evidence checklist, and two people on every decline.
- A clear reasonPlain-English outcomes, with the route to the Ombudsman spelled out.
- Specialists spend their time on judgmentThe agent gathers evidence from five or six systems, so people review instead of compile.
- Lower net cost per claimMore money frozen in time, and the 50% share chased automatically when it's late.
- Deadlines met without stallingThe 5- and 35-day clocks are tracked, with a day 3 alert, and pausing always needs a person.
- Decisions that hold upSourced evidence and two reviewers on declines mean fewer lost Ombudsman cases, and an audit trail is ready if one is challenged.
- Fewer scams next monthConfirmed mule accounts and scam patterns feed back into payment warnings.
The design follows what banks and regulators are already doing
Agents inside the fraud team
Lloyds has rolled out a fraud system where several agents work during customer calls, on identity checks, transaction analysis and scam risk. Staff stay accountable and can override the agents.
Here: the same principle, applied to the claim after the scam, with the override built into the handoff screen.
A framework for AI agents
The review recommends a trusted framework for AI agents in financial services, covering identity, authority, accountability and execution.
Here: authority comes from per-step levels, accountability from a named owner for every decision, and execution from a sourced audit trail.
Regulator-supervised trials
A second cohort of firms, including Barclays and Lloyds Banking Group, is testing AI with the FCA, including agentic payments.
Here: shadow mode and the 500-case replay produce the kind of evidence a supervised trial asks for.
Stopping impersonation in the app
Revolut's call identification shows customers in real time whether a caller is really from Revolut, adding to its 2024 AI scam interventions on card payments.
Here: prevention catches most of these calls. This design covers the ones that still get through.
The rules are being tuned
After the evaluation, a consultation is due in December 2026. It covers claims open past 35 days and guidance on the gross-negligence exception, with revised rules expected in May 2027.
Here: thresholds and checklists are configuration, not code, so rule changes don't mean rebuilding the workflow.
Autonomy is enforced in permissions, not in the prompt
The agent is a language model with a small set of narrow, permissioned tools. It has no tool to clear a vulnerability flag or send a decline, so it can't do either, whatever an instruction says.
| Tool | Connects to | Permission |
|---|---|---|
| Read payments, Confirmation of Payee and warnings | Payment and fraud systems | Read only |
| Block payee | Payment controls | Write, reversible |
| Notify receiving bank, claim the 50% share | Pay.UK's reimbursement claims system | Send, logged |
| Draft case file, messages, clock pauses | Case management | Drafts only |
| Flag vulnerability | Customer record | Can add a flag, can't clear one |
| Pay refund | Payments | Runs only against a decision a person approved |
Agent runs, nobody sees it
Runs on live claims, and its recommendations are compared with what specialists decided.
Agent prepares, people act
Specialists edit case files and messages. Track how much they change.
One-tap approvals
Full refunds with complete evidence move to approve or change.
Reversible steps only
Protection, evidence and recovery run alone. Declines never graduate.
Sign-offs along the way: model risk validation, Consumer Duty outcome monitoring, a data protection impact assessment for vulnerability data, and a named senior manager accountable under SM&CR. Phase lengths are estimates.
What goes wrong, and what the design does about it
| Failure | Design response |
|---|---|
| Agent misses a vulnerable customer | It can raise the flag but never clear it. Only a specialist can record "not vulnerable," with a reason. |
| Scammer-written text tries to steer the agent | Uploads, messages and screenshots are evidence to read, never instructions to follow. Money moves only against a decision a person approved. |
| Case file states something that isn't in the records | Every line needs a source ID, and unsourced lines are blocked. |
| Specialists start rubber-stamping | Approvals under 20 seconds get sampled, and QA seeds known-answer cases into the queue. |
| Deadlines slip, or the clock is paused to hide it | An alert fires at day 3. A pause needs a person and a reason, and the 35-day limit is tracked separately. |
| Scam is outside the rules (card, crypto, international) | The agent says so plainly in the first conversation and routes the case to the right process, instead of letting it fail on day 5. |
| A model update changes behavior | 500 closed claims are replayed and compared with what specialists decided before any change ships. |
Metrics that reward getting it right, not just closing it fast
| Metric | Why it matters |
|---|---|
| Minutes to receiving-bank alert | The rule allows 2 hours, but recovery odds fall by the minute as mule accounts empty. |
| Claims closed within 5 business days | Year-one baseline is 84%. Read it next to the stop-the-clock rate so the target isn't met by pausing. |
| Variance in outcomes between specialists | Consistency is the gap the regulator found, so measure it directly. |
| Agent and specialist disagreement rate | The gate for any step moving up a level. Read it next to the QA catch rate, since near zero can mean rubber-stamping. |
| Ombudsman overturn rate on declines | The real test of the hardest calls, which in this design are always made by people. |
| Times the customer tells their story | Target: once. |
Checked October 2026
- PSR, PS25/5 APP scams reimbursement requirement, consolidated policy statement (May 2025)
- PSR, One year on: delivering fair outcomes through our APP scam reimbursement regime
- Summary of the Frontier Economics evaluation for the PSR (July 2026)
- Pay.UK, Faster Payments rules clarification on business-day counting
- FCA, The Mills Review: AI and the future of retail financial services (July 2026)
- FCA, Second cohort for AI Live Testing (April 2026)
- FStech, Lloyds expands AI fraud defences (2026)
- Revolut, Call identification feature (January 2026)