Pay.UK's AI payment marker leaves liability unanswered

Pay.UK, the body that operates the UK's Faster Payments and Bacs interbank infrastructure, is exploring two artificial intelligence ideas: using AI to watch continuously for threats to payments infrastructure, and adding data to payment messages that would show whether a transaction was started by a person or by an AI agent. The proposals were set out by Pay.UK's chief strategy and transformation officer, David Crawford, in comments published by The Fintech Times on 6 September 2026 and FF News on 21 September 2026.

Neither idea is a confirmed delivery programme. No Pay.UK announcement, technical specification or timetable establishes that either capability has been approved, funded or scheduled, or how an AI-origin marker would be authenticated. What the proposals do is bring forward a question that existing UK payments law has general rules for but no settled AI-specific answer to: when an AI agent makes a payment that turns out to be wrong, stolen or simply a mistake, who pays for it?

That question matters now because HM Treasury is already asking it. A consultation published on 14 July 2026, open until 6 October 2026, says the Payment Services Regulations 2017 pre-date current AI developments and may not fully facilitate agentic AI. It asks explicitly whether the rules on authentication, consent and liability for unauthorised payments need to change. A written parliamentary answer on 4 September 2026 pointed to that same open consultation when asked about redress for agents acting outside their mandate. In other words, the policy answer does not exist yet.

What Pay.UK has actually proposed

Crawford described two separate capabilities. The first is AI-assisted monitoring: scanning payments infrastructure continuously for signals of stress or attack, and using AI to support scenario planning for what happens if prevention fails. The second is message enrichment: recording, within the payment message itself, whether the payment originated from a human or an AI agent.

Both are framed in the source material as proposals or ambitions raised in interview, not as an implementation with a technical specification or a go-live date. Several practical questions remain open: whether "originated by an AI agent" means the agent created the order, selected the payee or amount, called an API, or gave final approval; who would assert the marker and how it would be authenticated; what a bank should do if the marker is missing, spoofed or wrong; and whether it would be mandatory, limited to Faster Payments, or travel end-to-end to the receiving provider. A formal scheme consultation would be needed to settle any of this.

An origin marker is not a liability rule

Crawford has also said that AI is strengthening fraud detection at the same time as it enables more convincing scams, synthetic identities, mule-account activity and automated attacks. An origin marker could plausibly help with that: it could feed differentiated risk scoring, support audit trails, and route warnings appropriately.

It cannot, by itself, decide who is liable. Under the Payment Services Regulations 2017, which took effect on 13 January 2018, a payment is authorised only where the payer consented to that specific transaction, or to a series including it, in the form and procedure agreed with their provider. That test turns on consent, not on which piece of software or which person transmitted the message. A marker showing that an AI agent sent the payment instruction says nothing, on its own, about whether the payer consented to that transaction, whether the agent stayed inside its mandate, or whether anyone was deceived.

The existing legal baseline

Three rules from the Payment Services Regulations 2017 do most of the work here.

• Consent (regulation 67): a transaction is authorised only if the payer consented to it, or to a series containing it, in the agreed form and procedure. The regulations do not say how a broad instruction to an AI agent — approve purchases up to a limit, book the cheapest flight — maps onto consent to one specific transaction.
• Burden of proof (regulation 75): if a customer denies authorising an executed payment, the burden is on the payment service provider to prove the transaction was authenticated and correctly recorded. The fact that a payment instrument was used is not necessarily enough, by itself, to prove authorisation or payer fraud or gross negligence.
• Refunds for unauthorised payments (regulations 76–77): subject to statutory qualifications, a provider must refund an unauthorised payment and restore the account by the end of the business day after becoming aware of it. Payer liability can still arise where the payer acted fraudulently, or with gross negligence failed to meet their security obligations. Whether handing credentials or broad authority to an AI agent counts as gross negligence is not answered anywhere in the statute.

The regulations also let a payer and provider agree spending limits on a payment instrument, a control that could plausibly be applied to delegated agent spending, though no cited source confirms this is being pursued for agents specifically.

Three ways an agent payment can go wrong

The legal route a customer would need to take depends heavily on the facts, and no cited source provides an AI-specific answer for any of them.

An ordinary mistake. An agent picks the wrong legitimate merchant, or the wrong item, with no deception involved. If the agent acted inside a mandate the payer legally consented to, this may be treated as an authorised mistake or an ordinary civil dispute — outside both the unauthorised-payment refund rules and the mandatory scam reimbursement regime.

An agent that exceeds its mandate. The agent acts beyond what the payer actually authorised. It is not settled whether this produces an unauthorised payment against the bank, a contract claim against the agent provider, or both. The answer may depend on the bank's agreed authorisation procedure and the agent's technical role — exactly the kind of question HM Treasury's consultation has opened up.

A deceived or compromised agent. A fraudster manipulates the agent rather than the human — through a false merchant, poisoned data, or a technique such as prompt injection. Whether this meets the legal definition of an APP scam is unresolved: the regime is framed around a customer deceived into sending money, but whether manipulation of the agent itself satisfies that definition has not been tested.

Where APP scam reimbursement does and doesn't apply

The mandatory Authorised Push Payment (APP) scam reimbursement regime is separate from the unauthorised-payment rules, and it only covers qualifying cases. For qualifying Faster Payments made since 7 October 2024:

Over the 18 months from 7 October 2024 to 31 March 2026, the Payment Systems Regulator recorded 438,300 claims reported, of which 301,500 were in scope for reimbursement; 88% of reimbursable losses, worth £316m, were reimbursed. £249.6m of that £316m was reimbursed in the final 12 months of the period, from 1 April 2025 to 31 March 2026. Separately, UK Finance's Annual Fraud Report 2026 put total UK payment-fraud losses at £1.28bn for calendar year 2025 — a wider industry figure using a different scope and method, not directly comparable to the PSR data.

None of this data isolates AI-agent activity: the cited regulatory and industry datasets do not separately identify the volume or value of payments initiated autonomously by agents, or fraud losses attributable to them specifically.

The practical point for a reader is that an agent-originated payment still has to satisfy the APP scam regime's scope and definition to qualify for this reimbursement route; agent involvement alone neither establishes nor rules out a qualifying claim, and whether manipulation of an agent rather than a human meets that definition remains untested. A mistaken agent payment involving no deception may not qualify, and may instead need to be pursued as a civil dispute with the merchant or the agent's provider.

An unresolved chain of responsibility

Even where a loss is clear, UK rules do not currently specify how liability would divide between the customer, the sending bank, the receiving provider, a regulated payment initiation service provider, and whoever built or operates the AI agent. The Competition and Markets Authority's guidance, published 9 March 2026, says businesses remain responsible for complying with consumer law whether they interact with customers through people or AI, and recommends transparency, monitoring, human oversight and audit logs. That is consumer-law guidance, and it does not settle who bears a loss under the Payment Services Regulations.

The next milestone: 6 October 2026

HM Treasury's consultation on modernising payment services regulation closes on 6 October 2026. Until the government publishes its response, any resulting FCA rule changes, or legislation, the allocation of liability for agent-made payments remains an open policy question rather than a settled rule. A parliamentary answer on 4 September 2026 confirmed the government is treating this consultation, not a prior settled position, as the route to any change.

What to watch next

Three things are worth tracking: whether Pay.UK publishes a formal technical proposal or scheme consultation on the agent-origin marker; HM Treasury's response to the payment services consultation after it closes on 6 October 2026, and any FCA rule changes that follow; and how the Payment Systems Regulator and Financial Ombudsman Service handle the first disputes involving agent-initiated payments, which will show in practice how existing consent and refund rules apply.