The reimbursement rules
Authorised push payment fraud is a payment the customer authorised, having been deceived into it. The Payment Systems Regulator’s figures, citing the UK Finance Annual Fraud Report 2024, put losses at £459.7 million in 2023.
Since 7 October 2024 the PSR’s mandatory reimbursement requirement has applied to payments made on or after that date between UK accounts over Faster Payments or CHAPS. The main parameters, as the PSR states them:
- victims are reimbursed by their payment firm, normally within five business days of making a claim
- the maximum reimbursement is £85,000 per claim, confirmed in PS24/7, a level the PSR says fully reimburses 99.8 percent of Faster Payments APP scams by volume and 90 percent by value
- the cost is split 50:50 between the sending and receiving firm
- firms may apply an optional excess of up to £100, which cannot be applied to vulnerable consumers
- where a firm needs more time to gather information it can stop the clock, but must reach an outcome within 35 business days
- claims must be made within 13 months of the payment
- a consumer is not reimbursed if found complicit in the fraud or grossly negligent; the PSR describes gross negligence as a high bar and the exception does not apply to vulnerable consumers
The effect is that the cost of an authorised payment that turns out to be fraud sits with the payment firms, not the customer.
What an agent changes
APP fraud has always been a social-engineering problem: a person is talked into authorising a payment. Agents change three things about that problem.
The thing being talked into it is software. An agent reads text and treats it as instruction. Hide a command in a web page, a document or an email, and the agent may follow it. Tool descriptions are text too, and a hidden instruction in one is obeyed without the user ever seeing it. Prompt injection and tool poisoning are the agent-era forms of the phone call that persuades a customer to move their savings.
It happens at machine speed and scale. A person pauses, gets suspicious, calls the bank. An agent that has been instructed to make a payment makes it, then makes the next one. An agent that is invoked by another agent may make it on behalf of a request that started three hops away.
The authorisation is ambiguous. When an agent acting for a customer initiates a payment, the customer’s instruction and the manipulation that shaped it are tangled together. A claim will turn on what the customer actually authorised, and on whether the firm can show it.
The FCA’s payments regulatory priorities report of March 2026 says it will consider whether rules need to change to support agentic AI payments. Neither the FCA nor the PSR has said how the reimbursement rules treat a payment an agent initiates on a customer’s instruction.
This page does not offer a view on how the reimbursement rules apply to a specific agent-initiated payment. That is a question for your legal and compliance teams. What follows is the set of controls that reduce the exposure whichever way that question is answered.
Human approval on money movement
The control that does most of the work is a person in the path of the payment: a hold on this payment, now, until a named person approves it, rather than a design-time sign-off or a review of yesterday’s transactions.
The threshold is a policy choice. A firm can require approval for every agent-initiated payment above an amount, for every payment to a new payee, or for every payment from a high-risk agent. What matters is that the hold is applied on the call, that the agent cannot proceed without it, and that the approval and the payment land in the same record.
A budget enforced on the call belongs alongside it. If an agent’s spend limit for the day, or for the originating request, is enforced when the payment is attempted rather than reported afterwards, the size of any single manipulation is bounded.
Stopping the chain
A payment agent is rarely the agent a customer talks to. An assistant takes the request and calls the payments agent. If the assistant is found to be compromised and is revoked, the payment it already initiated still goes out unless the payments agent is stopped too.
Containment has to cover the whole chain: stop the assistant and everything it set in motion, remove the credentials the chain relied on, and be able to show afterwards that nothing in the chain was authorised after the stop.
Evidence
When a claim arrives, the questions are concrete. Which agent initiated the payment. On whose instruction. Was a person asked to approve it, and did they. Was the record altered.
Application logs answer some of these badly. A record that ties every agent action to the agent, the principal it acted for, the approval, the decision and the outcome, tamper-evident so an alteration is detectable, and verifiable by someone outside the firm, answers them directly. A log you control is not evidence.
Where KPATH sits
KPATH is the inline enforcement layer for enterprise AI agents. Every governed call passes through it before the payload reaches the target. For money movement, that means: the payments agent’s identity is verified and, where policy requires, the customer it acts for is verified too; budget is enforced on the call and attributed to the originating request; a high-risk payment waits, inline, for a named approver; any agent or the whole chain can be stopped and loses the credentials it relied on; and the call, the approval and the outcome go into a signed, tamper-evident record streamed to your SIEM.
It governs the request envelope, identity, target, action, size, delegation chain, and reads only the payload values you declare for a rule, such as the amount. Keys stay in your own vault or key service.
KPATH enforces human control; it is not autonomous decisioning. The control layer, never the trigger.
Start in monitor mode: observe only, enforce no policy, rewrite no agents. See which agents can reach a payment rail, then set the approval threshold and flip to enforce by repointing egress.