AI shopping agents can spend your money. Six banks say the trust layer still needs work

What the six banks actually published

On 23 September 2026, Commonwealth Bank of Australia, ASB Bank, Bank of America, Capital One, ING Group and NatWest Group published a joint paper on agentic commerce. Their definition is practical: an AI agent helps make or facilitate a payment between a customer and a merchant. At one end, a person reviews the final basket. At the other, an agent identifies a need and purchases on its own.

The paper is not a law, a payment-network rule or a finished technical standard. Its five principles—transparency, safety, privacy and data, choice, and interoperability—are voluntary and non-binding. The banks say a later paper will address implementation. That distinction matters: the document identifies the trust gap, but it does not close it.

• Read the banks’ original principles paper

A recommendation becomes a financial action

A shopping assistant that compares shoes is a familiar search tool. An AI shopping agent that selects the shop, inserts card details and confirms the order is something else. A mistaken answer is no longer only text on a screen. It can become a charge, a shipment and a dispute before the customer notices.

The banks describe both human-in-the-loop and autonomous purchases. Risk grows with the authority delegated to the agent: which products it may buy, how much it may spend, which payment rail it may use and whether a person must approve the final transaction. A vague instruction such as ‘keep the office stocked’ is not the same mandate as ‘buy these cartridges from this approved seller for no more than £120’.

The Agentic Commerce Protocol developed by Stripe and OpenAI shows why this is already operational rather than speculative. It provides building blocks for product discovery, checkout and secure payment handling by agents. A protocol can move purchase data safely; it does not decide whether the seller, product, instruction or underlying claim is trustworthy.

• See the Agentic Commerce Protocol

The fraud problem has more than one attacker

The obvious scenario is a fake merchant built for AI traffic: convincing catalogue data, synthetic product photographs, a short-lived domain and a checkout that looks machine-readable. But the banks point to a wider set of failures. An unsafe agent may type card details directly into a website, favour a payment method with weaker protection or exceed the authority its user intended to grant.

The agent itself can also be impersonated or compromised. A criminal can pose as a trusted shopping service, alter a merchant record, inject instructions into a page or use social engineering to persuade the customer to extend a spending limit. A genuine agent can still make a bad purchase after reading false product claims. Conversely, a legitimate merchant may receive an order with too little information to distinguish a customer’s real intent from an agent error.

That is why ‘AI shopping bot scam’ is too narrow a label for the entire problem. Agentic commerce fraud can involve merchant impersonation, agent impersonation, stolen credentials, manipulated media, prompt injection, unauthorised delegation and ordinary payment fraud. Each leaves different evidence and may put responsibility on a different participant.

• Check batches of suspicious product images

The missing record is often the customer’s intent

When a normal card payment is challenged, investigators can inspect the merchant, amount, authentication and payment route. An agentic purchase adds another layer: what the customer asked for, what authority the agent had, which options it considered, what it changed and which warning—if any—the customer saw.

The banks call for auditable records of instructions, authentication, intent, transaction decisions and outcomes. That does not mean retaining every private conversation forever. It means designing a minimal, access-controlled record before the first dispute arrives. The record should let an authorised reviewer reconstruct why this agent bought this item from this merchant at this price.

• See evidence-linked reporting

• Identity of the customer, agent provider and merchant of record.
• The instruction or mandate, including limits, expiry and prohibited actions.
• Authentication and approval events, with time and method.
• Product, price, delivery terms and payment method presented at approval.
• Agent decision, material alternatives, warnings and human overrides.
• Transaction, refund, chargeback and complaint identifiers.
• Versioned logs or hashes that expose later changes without storing unnecessary data.

A practical control set for banks, marketplaces and merchants

Start by making the agent visible. The merchant and payment provider should know that software is acting, for whom it acts and what authority it carries. The customer should know when a result is sponsored, when a payment option benefits the agent provider and which party will handle a dispute.

Use narrow, revocable mandates rather than permanent access. Put hard limits around merchant categories, amount, frequency, geography and payment method. Require fresh authentication when the transaction crosses those limits, changes the delivery address or selects a weaker payment route. A person should be able to see active delegations and cancel them without negotiating with the agent.

Treat merchant content as untrusted input. Product text, photographs, invoices and support messages can be false even when the checkout is technically valid. Separate media verification from payment authorization, and separate both from identity or legal review. Finally, test the ugly cases: duplicated merchants, a changed price after approval, an unavailable product, a poisoned page, a compromised agent and a customer who denies the instruction.

• Disclose agent participation and the party it represents.
• Bind every purchase to a specific, revocable customer mandate.
• Require step-up authentication for material changes and high-risk payments.
• Keep merchant-of-record, intent and authorization data available for disputes.
• Detect duplicate, substituted and newly created merchants before payment.
• Preserve warnings and failed attempts, not only successful orders.
• Give customers and merchants a clear human escalation route.

Where synthetic-media checks help—and where they do not

Synthetic product photographs, cloned support voices, fake founder videos and altered invoices can all sit inside an agentic-commerce fraud. Checking those files can help a fraud team prioritise a case, connect repeated creatives and preserve a reproducible report. Cross-checking supplied invoices, order records and messages can also expose contradictions that a polished summary hides.

DeepfakePolicy does not decide whether an AI shopping agent is trustworthy, authenticate the merchant, authorise a payment or determine liability. Its detector reports probabilistic media signals; Cross-check compares the material a business supplies and cites the relevant passages. Those outputs belong inside a wider payment, identity and investigation process—not in place of one.

• Compare supplied evidence with Cross-check
• Review sample evidence reports

What the banks’ paper changes today

The paper does not create a new consumer right on 23 September. It does something more immediate for product and fraud teams: it makes it difficult to pretend that ordinary checkout logging is enough. The banks explicitly identify agent identity, customer intent, purchase decisions, warnings, data use and responsibility for errors as parts of the payment record.

Any company preparing autonomous purchasing should therefore run a dispute backwards before launch. Ask which evidence the issuer, merchant, agent provider and customer would each need. If the answer depends on a conversational log nobody can access, a model trace that changes on every run or a merchant identity that was never recorded, the product is not ready to spend real money unattended.