Whose intent are you actually investigating when the payer of record is software acting under delegated authority? No settled UK answer exists yet. Here's how to think about it anyway.
⏱ 18 min read🤖 Interactive🎓 Practitioner Level📋 4 Scenarios
Genuinely unsettled, not a technology explainer
0
FCA's own report signals UK payments law may need to change for autonomous AI agents
FCA 2026 Payments Regulatory Priorities Report, 25 March 2026
Reg 0
Requires a payer's specific consent to a transaction. Agentic AI breaks that model outright.
Payment Services Regulations 2017, regulation 67
0
Major card network now committed to covering erroneous purchases by verified AI agents
American Express Agent Purchase Protection, 14 April 2026
Just Enough to Move On
What an AI agent actually is, in a payments context
Scope note, read this first: unlike a guide anchored to a real enforcement action, no UK court case or regulatory action exists yet for this exact pattern, the technology and the regulation are both this new. Every scenario in this guide is composite and illustrative, per this site's own standard for genuine gaps with no citable case. The differentiation here isn't a real incident, it's honest "unsettled, here's how to think about it" framing grounded in real, current, primary sources, the same discipline already applied to contested crypto-mixer designations elsewhere on this site.
An AI agent, in the sense that matters here, is software that can interpret a goal, break it into steps, and act on digital services with limited human input at each step, rather than requiring explicit approval for every action.[1] This is a meaningful shift from existing automation. A standing order or a recurring direct debit executes a fixed instruction a human already approved in full. An agent decides, within boundaries a human set, what to buy, from whom, and often when, and only the boundaries, not the specific transaction, were approved in advance.
The IMF's own framing is worth carrying directly into this guide: modern payment systems are built on deterministic logic, a transaction either matches its authorisation or it doesn't. Agentic AI is probabilistic, the same instruction can produce a different action on a different run.[1] That single sentence is the whole compliance problem in miniature, and it's why this guide exists.
How a transaction actually gets made
The clearest real architecture to explain this is Google's Agent Payments Protocol (AP2), not because it's the only one, but because it's the most complete public specification of the full lifecycle and the one most other schemes interoperate with. AP2 launched 16 September 2025 with over 60 partners including Mastercard, PayPal, Coinbase, and American Express.[6]
Step 1 · Intent Mandate
What the user actually authorised, in general terms
A budget, a category, a set of constraints, e.g. "find and book a flight to Edinburgh under £200, departing after 6pm." Signed as a Verifiable Credential.
↓
Step 2 · Cart Mandate
The exact price and item the agent chose
This is the point an abstract instruction becomes a concrete transaction, e.g. the specific flight, specific price, specific airline.
↓
Step 3 · Payment Mandate
Hands the now-specific transaction to whatever rail settles it
A card network, a real-time bank transfer, or a stablecoin.[6]
Two distinct flow types matter for how a compliance analyst should think about risk. In human-present flows, the user is actively in the loop, the agent finds options and the user picks one before the Cart Mandate is created, lower risk, closer to a traditional guided checkout. In human-not-present flows, the agent completes the entire chain, Intent through Payment, autonomously within the Intent Mandate's original boundaries, with no further human confirmation.[6] This is where the real judgement gap lives, and where the rest of this guide focuses.
Kept Concrete, Not Abstract
What kinds of transactions AI agents actually perform
🛍️
Real-time discretionary purchases
The classic case, "find me white running shoes under £80." Agent searches, compares, selects, buys. Human-present or human-not-present depending on configuration.
🔁
Recurring and subscription management
Agents renewing, upgrading, or downgrading subscriptions within a budget envelope, without a fresh authorisation each time.
🪙
Machine-to-machine micropayments
A materially different category, e.g. an agent paying a few cents in stablecoin for a single API call or a dataset lookup, settled via protocols like x402, Coinbase's HTTP-402-based standard for onchain stablecoin micropayments.[7] No human is meaningfully "present" at any point in this category, by design.
🌐
Cross-border and multi-rail transactions
An agent might route a single logical purchase across different rails depending on geography, e.g. an instant domestic rail in one country, a card network in another.
🔗
Agent-to-agent commerce
The furthest-out category, one organisation's procurement agent negotiating and settling directly with a supplier's sales agent, no human in the loop on either side for the specific transaction. Still early, industry commentary increasingly names it as a coming phase rather than a settled current practice.
The Core Regulatory Tension
Why detection and authorisation frameworks weren't built for this
UK payment consent law assumes a human gave specific consent to a specific transaction. Regulation 67 of the Payment Services Regulations 2017 requires exactly that: a payment transaction is regarded as authorised only if the payer has given consent to its execution.[3] An agent acting on a general Intent Mandate, days or weeks before the specific Cart Mandate exists, doesn't cleanly fit that model, and regulation 76's refund obligations for unauthorised transactions were written with the same human-specific-consent assumption baked in.[4]
The FCA has not resolved this, it has named it. Its 25 March 2026 Payments Regulatory Priorities Report states the regulator will consider whether change or development of regulation is needed to support agentic AI payments, a genuine departure from its usual posture of applying existing rules to new technology rather than writing new ones.[2] The UK's Competition and Markets Authority has separately said existing consumer protection law applies regardless of whether a decision was made by a person or an AI, which answers a different question, does the law apply at all, without answering the harder one, who specifically is liable when an agent gets it wrong.[5]
The honest takeaway
Nobody has settled this. Whose intent are you actually investigating when the payer of record is software acting under delegated authority? That judgement, not the underlying technology, is what the rest of this guide teaches.
📐
Scenario 01 · Technically compliant, still wrong
The Literal-Compliance Purchase
Boundary vs Intent
⚖️
What do you do?Make the call
An agent, acting entirely within its Intent Mandate's stated budget and category, buys a product that technically satisfies every stated constraint but that the user would clearly not have chosen, e.g. the cheapest available flight that happens to route through a sanctioned jurisdiction's airport for a layover, a possibility the user never considered.
🌀
Scenario 02 · The AI black box problem
The Hallucinated Match
Wrong Item Purchased
⚖️
What do you do?Make the call
An agent misreads a merchant's product listing, a documented, real failure pattern, not a hypothetical one, and purchases an item that doesn't actually match what the user asked for.
🔓
Scenario 03 · Familiar pattern, different evidence trail
The Hijacked Agent
Agent Takeover
⚖️
What do you do?Make the call
A legitimate, previously well-behaved shopping agent is compromised and redirected to make purchases the real customer never approved.
Investigating an agent-initiated transaction?Free. No account needed. Run a PEP, sanctions, and adverse media check on the counterparty.
A customer genuinely used their own agent to make a legitimate purchase, then disputes it as unauthorised once they see the charge.
A Real Industry Response, Not a Case Study
What Amex's coverage commitment actually signals
Unlike a guide anchored to a real enforcement action, no real, named UK court case or regulatory action exists yet for this pattern. Rather than force a case that doesn't exist, or reach for a loosely related one, this section covers a real, citable industry response instead.
On 14 April 2026, American Express launched its Agentic Commerce Experiences (ACE) developer kit alongside an industry-first commitment, Agent Purchase Protection, covering eligible erroneous purchases made by registered, verified AI agents on its network.[9] The model is built on a controlled environment, verified agents are issued payment credentials only after cardholder authentication, intended to reduce merchant disputes and chargeback rates.
Worth reading carefully rather than as a resolution: this is liability becoming an explicit design choice by one network, not the industry or UK regulation settling the question. It's framed as a purchase protection commitment, not fraud coverage, a genuinely different posture to how card networks have traditionally talked about erroneous transactions. What happens when a bad actor defeats the authentication control this commitment assumes holds is a question this doesn't answer, worth carrying forward as an open one, not a solved one.
Verification
Sources
Each numbered claim above is checked against the specific source below it. Sources marked "analysis" are legal or industry commentary, not primary regulation or settled law, treat their conclusions as informed views, not fact. Figures without a bracketed number are illustrative examples rather than verified facts.
Five questions. Do you know why nobody has settled this yet?
1. What does an Intent Mandate actually capture, and what does a Cart Mandate add to it?
2. Under regulation 67 of the Payment Services Regulations 2017, what does a payer need to give for a transaction to be authorised, and why does a human-not-present agent flow sit awkwardly against that?
3. In Scenario 2, why might a hallucinated-match purchase be treated as an unauthorised transaction rather than a standard merchant dispute?
4. What's the practical value of a signed mandate chain in a hijacked-agent investigation?
5. As of this guide's publication, has any UK regulator definitively settled who is liable when an AI agent makes an unauthorised purchase?
0/5
Frequently Asked
FAQ
Is an AI agent transaction ever treated as unauthorised under UK law? +
Potentially yes. Current legal analysis suggests a transaction where an agent's decision can't be explained or traced to the user's specific authorisation is likely to be treated this way, though nothing is settled. See Scenario 2.
Whose liability is it when an agent makes a mistake? +
Unresolved as of this guide's publication. Early industry moves (Amex's coverage commitment) and emerging legal analysis both point toward more exposure for the enabling payment service provider than has traditionally been the case, but no UK regulation currently states this definitively, and the question genuinely spans the consumer, the AI developer, the PSP, and the merchant.
Does the mandate chain (Intent, Cart, Payment) actually help in an investigation? +
Yes, meaningfully, where the underlying protocol is used. It provides a cryptographically signed audit trail that traditional card transactions simply don't have. See Scenario 3.
Is this the same as synthetic identity fraud? +
No, materially different. This guide is about a genuine customer's own delegated software acting on their behalf, not a fabricated identity. See Synthetic Identity and Device-Network Fraud for that distinct pattern.
When will UK regulation actually resolve this? +
No fixed date. The FCA's own March 2026 report only commits to considering whether change is needed, and its wider AI review is due to report later in 2026, worth checking for updates close to this guide's own review date rather than assuming resolution.
Quick Reference
At a glance
Four patterns, the risk each one carries, the signal that tells you which one you're looking at, and the response that fits.
📐
The Literal-Compliance Purchase
An agent stays within its stated boundaries but produces an outcome the user didn't actually intend.
Risk
An agent stays within its stated boundaries but produces an outcome the user didn't actually intend.
Signal
The transaction passes every stated constraint yet still needs a human to have caught the outcome.
Response
Standard screening applies, but flag the boundary-versus-intent gap as a genuinely unresolved consent question, not a closed one.
🌀
The Hallucinated Match
The agent misreads listing data and buys the wrong thing.
Risk
The agent misreads listing data and buys the wrong thing.
Signal
The PSP can't clearly explain why the agent made that specific decision.
Response
Treat as a likely unauthorised transaction from the outset, check where liability actually sits.
🔓
The Hijacked Agent
A legitimate agent is compromised and redirected.
Risk
A legitimate agent is compromised and redirected.
Signal
Traditional fraud signals, device fingerprint, browsing behaviour, may not exist.
Response
Pull the signed mandate chain where the protocol provides one, use it as the evidence trail traditional tooling can't offer.
🎭
The Friendly-Fraud Claim
A genuine purchase gets disputed as unauthorised after the fact.
Risk
A genuine purchase gets disputed as unauthorised after the fact.
Signal
No distinguishing feature from a real hijack at first glance.
Response
Check for a signed mandate chain before resolving either way, don't default to automatic refund at scale.
The Judgement, Not the Technology
Nobody has settled this yet. That's the honest answer.
The mandate chain tells you what was authorised. It doesn't tell you who's liable when the boundary and the outcome diverge, that judgement is still being worked out in real time, by regulators, courts, and card networks alike. FinCrimeRadar's Scenario Lab puts similar investigative decisions in front of you under real time pressure and partial information, free, no signup required.
Want to practise the judgement rather than read about it?Free. No account needed. Work real cases under time pressure and partial information.
Synthetic Identity and Device-Network Fraud, a genuine customer's own delegated software acting on their behalf is a materially different problem to a fabricated identity, this guide's FAQ draws that line explicitly.
