Who Authorises, and Who Is Liable, When an AI Agent Pays? A UK Guide for Retailers, Platforms and Their Risk Teams
Until recently the question in agentic commerce was whether an AI agent could complete a payment at all. Working products are now appearing, and a harder question has taken its place. When an agent buys the wrong thing, buys it twice or buys it without the customer's real consent, who authorised the payment, and who is left holding the loss? For a retailer, a platform or the risk team that sits behind them, the answer determines what you can safely accept at checkout. This guide sets out how authority can be delegated and proven, where liability sits under the frameworks that already apply in the UK, and what a retailer should put in place first. It is analysis, not legal advice.
Why the question has changed
Our reading of October 2026's market coverage is that the centre of gravity in agentic commerce and payments has moved. Authorisation and liability have been the dominant agentic-commerce theme in our monitoring of press and regulator commentary for three consecutive reviews, with the debate shifting from "can agents pay" to "who is liable and how is authority proven". That is our reading of the coverage rather than a measured statistic, so treat it as a direction of travel.
Two reported developments illustrate it. First, JPMorgan Chase has reportedly blocked outside AI agents from directly accessing customer accounts, and is backing open-banking routes instead, according to coverage by Finextra. The reasoning, as reported, is about sanctioned and authorised access rather than agents using customers' own credentials. Second, the FCA set out its position on AI in a speech on 19 October 2026. As reported, it applies existing frameworks, including Consumer Duty and senior-manager accountability, to AI rather than creating a separate set of rules for agents. It also asked AI providers to add disclaimers to AI financial advice, published examples of good and poor practice, and acknowledged agentic finance.
Those are reported facts. What follows from them is our analysis: if the regulator is applying existing accountability to agents, and large incumbents are restricting who may act on an account, then the burden of proving that an agent was authorised falls on the businesses that accept its transactions. Retailers and platforms cannot wait for a dedicated rulebook to tell them where they stand.
Consumer behaviour points the same way. Consumer surveys reported in October 2026 suggest that people are more willing to use AI to research a purchase than to let it complete one. Willingness to delegate payment, in other words, is lagging willingness to delegate discovery, and the gap is a trust gap. Authority and liability are what close it.
Part one: how authority is delegated and proven
Before liability can be allocated, someone has to establish what the agent was allowed to do. Three ideas recur in the tooling now being developed, and they are worth understanding conceptually even though no single standard has emerged.
Mandates: what the agent is permitted to do
A mandate is the statement of authority that a customer, or a business acting for itself, gives to an agent. A usable mandate is specific. It names the principal, the agent, the kinds of purchase allowed, a spending limit, a time window and any conditions, such as preferred merchants or categories excluded. A vague instruction such as "buy what I need" is not a mandate, and a payment made on the strength of one is the hardest kind to defend later.
The design principle is that a mandate should be narrow by default and machine-readable, so that a merchant or payment provider can check a transaction against it rather than infer intent after the fact.
Tokens and credentials: proving the agent is who it says it is
The second idea is proof of identity and delegation. In practice this means a credential or token that binds an agent to a principal and to a mandate, so that a merchant can verify that this agent, acting for this customer, is entitled to make this purchase. The goal is to avoid the agent simply replaying a customer's card details or login, which is the kind of access the reported JPMorgan restriction appears aimed at.
Agent identity and authorisation tooling expanded quickly in October 2026, with several vendors announcing products within a single week. Search interest in the phrase "know your agent" remains small, at roughly 40 to 50 UK searches a month, so the term is not yet established with buyers. Importantly, no single standard has emerged. Competing approaches and scheme-sponsored tokens coexist, and the wider set of agent-commerce standards continues to multiply without converging. We have written separately about agent identity standards, so we will not repeat that here. The relevant point for a risk team is that committing early to one scheme carries rework risk.
Step-up checks: bringing the human back in
The third idea is that some transactions should not complete on the agent's authority alone. A step-up check asks the customer to confirm, using an authentication method they already trust, when a transaction crosses a defined line. Typical triggers would include an amount above the mandate's limit, a merchant the customer has not used before, an unusual basket, or a change in delivery address.
Step-up is the practical bridge between full delegation and full control. It lets a retailer accept agent-initiated purchases while keeping a human decision at the points where the risk is highest. It also generates evidence: a confirmed step-up is a clear record that the customer authorised this specific payment.
Part two: where liability sits
Liability is where most of the uncertainty lies, and where legal advice is essential. What we can offer is a way of structuring the questions. Under existing frameworks, we would break the problem into three layers.
Was the payment authorised?
In broad terms, UK payment rules turn on whether the customer authorised the transaction, and on the evidence of how that authorisation was given. An agent acting inside a clear, verifiable mandate gives a firm a much stronger position than an agent acting on an ambiguous instruction. An agent acting outside its mandate, or one that has been manipulated, gives a far weaker one. Which party bears the loss in each case depends on the facts and on the specific rules that apply, and that is a question for your legal and compliance teams.
The practical implication is that evidence is your first line of defence. If you cannot show what the agent was authorised to do, who the principal was and what checks were applied, you will struggle to demonstrate authorisation whatever the underlying rules say.
Were customers treated well?
The FCA's reported position is that Consumer Duty applies to AI-driven activity as it does to anything else. For a firm that provides financial products to retail customers, that means thinking about outcomes: whether the customer understood what the agent could do on their behalf, whether the controls were proportionate, and whether a customer who lost money through an agent error was treated fairly. Retailers that are not themselves regulated financial firms still sit in a chain with firms that are, and their payment partners will expect their processes to support those obligations.
Who is accountable inside the business?
Senior-manager accountability means that a named individual is answerable for a firm's controls. As reported, the FCA is not creating a separate accountability regime for agents, which implies that responsibility for agent-initiated payments will land with the same people who are responsible for payments and fraud today. A risk team that cannot say which senior manager owns the agent-acceptance policy has an unassigned risk.
Where card-scheme rules fit
Card schemes have their own rules governing disputes and chargebacks, and those rules allocate responsibility between issuers, acquirers and merchants. How they will treat transactions initiated by an agent is something to confirm directly with your acquirer and the relevant scheme rather than assume. We have deliberately not described scheme rule detail here, because it varies and is changing.
Part three: what a retailer should implement first
The aim of a first phase is not to solve agent commerce. It is to make a small number of decisions that keep you safe while you learn. We would suggest this order.
- Map where agents can reach you. List the checkout, account and payment surfaces an agent could touch today, including through third-party tools your customers already use. You cannot set policy for paths you have not found.
- Set an acceptance policy. For each path, decide whether you will accept agent-initiated payments, accept them only with a step-up check, or decline them. Write it down, and record which senior manager owns it.
- Capture evidence by default. Log the mandate or instruction presented, the identity of the agent and principal as far as it can be established, the checks applied and the time. Evidence is far cheaper to collect at the moment of payment than to reconstruct afterwards.
- Design step-up deliberately. Define the triggers, test the experience and make sure it works for customers who are not technical. A step-up that confuses people will be abandoned or bypassed.
- Prepare a dispute playbook. Decide in advance how you will handle a customer who says an agent bought something they did not want: what you will ask for, who decides and how quickly.
- Stay flexible on standards. Because no scheme or standard has won, keep your integration layer thin enough to support more than one approach. We have also written about checkout security and prompt injection, which is a separate risk worth addressing alongside authority, since an agent that has been manipulated can act within its mandate and still cause harm.
- Start where authority is clearest. Industry coverage this month points to production agent payments appearing first in accounts payable and business-to-business invoicing, where authorisation and audit trails already exist. Reported pilots by major card networks and payments providers are examples, though much of what is announced is vendor-authored and should be read that way. Consumer checkout by agent should not be treated as mainstream in production. A retailer can sensibly begin with the use cases where the principal, the limit and the approver are already well defined.
A first agent use case also makes a good candidate for a contained proof of concept, tested with real users, before any wider rollout. That is the model behind Innovify's AI Labs, where enterprise teams run several proofs of concept in parallel, test with real users and finish with a business case ready for funding.
What we would not do yet
It is as useful to know what to avoid as what to build.
- Do not assume your existing fraud rules cover agent behaviour. They were written for people and for conventional bots, and agent traffic may look like either or neither.
- Do not treat a vendor announcement as an industry standard. Several approaches are live and none has displaced the others.
- Do not allow open-ended mandates. A broad instruction is the weakest foundation for any later dispute.
- Do not leave accountability with "the digital team". If a named senior manager cannot explain the acceptance policy, it is not yet a policy.
- Do not rely on this article, or any commentary, for a legal conclusion. Liability depends on facts, contracts and the specific rules in play.
Where Innovify fits
Innovify is a technology partner with deep expertise in banking, financial services, fintech and insurance. We help mid to large businesses build AI-native products, modernise their technology stack and launch fintech products, and we design compliance in from day one. For agentic payments, that means treating authority, evidence and accountability as design requirements from the start of a build rather than as a review at the end.
If you are deciding what to accept at checkout, or planning a first agent use case, our work on agentic commerce and payments is a good place to start, and the AI Labs team can help you test an approach with real users before you commit.
FAQ
Who is liable when an AI agent makes a payment?
There is no single answer, because liability depends on the facts, the contracts and the specific rules that apply. The useful starting questions are whether the payment was authorised within a clear mandate, whether customers were treated fairly, and which senior manager is accountable for the controls. Take legal advice for your own circumstances.
How is an AI agent's authority to pay proven?
An agent's authority is proven by connecting it to a principal and a specific mandate through a verifiable credential or token, then checking each transaction against the mandate's limits. Step-up checks add a human confirmation where risk is higher. No single standard has emerged yet, so approaches vary between schemes and vendors.
What has the FCA said about AI agents and payments?
As reported after its speech on 19 October 2026, the FCA is applying existing frameworks, including Consumer Duty and senior-manager accountability, to AI rather than creating new rules for agents. It also asked AI providers to add disclaimers to AI financial advice and published examples of good and poor practice. Read the speech directly before relying on the detail.
What is "know your agent"?
"Know your agent" describes checking who or what an AI agent is, and on whose behalf it is acting, before accepting its transactions. It is an extension of the know-your-customer idea to software that acts for a customer. The term is new and search interest remains small, but identity and authorisation tooling for agents is developing quickly.
What should a retailer do first about agent-initiated payments?
A retailer should first map where agents can reach its checkout and payment surfaces, then set a written acceptance policy owned by a named senior manager. After that, capture evidence of each agent payment, design step-up checks for higher-risk transactions and prepare a dispute playbook before volumes grow.
Are AI agents already making payments in production?
Some are, but mainly in business settings. October 2026 coverage points to agent payments appearing first in accounts payable and business-to-business invoicing, where authorisation and audit trails already exist, and much of that coverage is vendor-authored. Consumer surveys suggest shoppers are less willing to let an agent complete a purchase than to let it research one.
Conclusion
The question that matters in agentic commerce is shifting from whether an agent can pay to whether you can show who authorised it and who answers for it. Existing UK frameworks already point to accountability, so the work for retailers and platforms is to make authority specific, evidence routine and ownership clear. Start with a written policy, a narrow mandate and a use case where authorisation is easy to establish, and let the standards settle before you commit to one.
