Blog · AI and agents · 20 October 2026

AI agents that pay: why proof of intent is becoming a payment control

Amex, Mastercard and AWS are converging on one idea for AI agent payments: record what the person approved, then check every payment against it. What it means.

On 13 October 2026 American Express published its Intent Intelligence framework, its recommended way to capture and authenticate what a customer wants to buy before an artificial intelligence (AI) agent completes the purchase, and then to keep that approved intent attached to the transaction as a control. Amex says it is making the framework public to help the industry settle on a common approach.

The announcement is about consumer card purchases, but the design problem it tackles is the one every institution faces once software starts initiating payments: how do you prove that a payment matches what a person with authority actually approved, and stop it when it does not?

What Amex's Intent Intelligence framework does

The Amex release describes four steps:

Create and confirm intent. A Create Intent application programming interface (API) records the customer's instructions and constraints, such as the merchant and a maximum budget. The customer authenticates and signs off on what the agent captured.
Establish proof of intent. The system issues an Intent ID and a Proof of Intent Token that represents the high-level constraints.
Scope the credential. The token is used to obtain a digital payment credential that the agent uses at checkout instead of the real card number, and the approved intent limits what that credential can do.
Apply intent throughout. The Intent ID and token can be checked at later steps, supporting fraud prevention, authorisation decisions and dispute resolution.

What Amex says is different is timing: the approved intent reaches the card issuer before the agent executes the purchase, not after. In an interview with TechCrunch, Amex's Hannah Bozian gave the example of a customer who asks for white Nike trainers in size 9 while the agent tries to buy Adidas shoes; Amex could stop that transaction because it does not match the approved request. The same TechCrunch report says Amex has not yet seen an increase in disputes from agent purchases and is building the control ahead of growth.

The volumes are still small but real. Bozian told Digital Transactions that Amex is seeing "thousands" of agent-initiated transactions a week, and the same report notes that Amex chairs the EMVCo agentic commerce working group, the card industry's standards body for this area.

The rest of the industry is building the same pattern

Amex is not alone. In the past week, two other announcements described closely related controls:

Mastercard. On 7 October, IBS Intelligence reported that Alchemy had integrated Mastercard Agent Pay into its AgentCard platform, giving agents one-time-use tokenised card credentials with user- and issuer-defined spending limits, approved merchant categories and transaction permissions. It also supports Mastercard's Verifiable Intent framework, which aims to show what actions were approved, under which conditions and by whom.
Amazon Web Services (AWS). An AWS post on 13 October describes Amazon Bedrock AgentCore payments, which enforces configurable spending limits at the infrastructure layer rather than in the agent, and gives visibility of payment attempts, approvals, denials and settlements.

The common thread is a separation of duties. The agent decides what it would like to do. Something outside the agent, holding a record of what a human approved, decides whether the payment may happen. In the card designs, the agent never sees the real card number.

Why this matters beyond consumer shopping

Federal Reserve Governor Christopher Waller made the business case at Sibos on 29 September. In his speech, published by the Bank for International Settlements (BIS), he said business-to-business (B2B) purchases may be especially well suited to agents because they are recurring and follow rules such as approved suppliers and budget limits, but that higher B2B values amplify the exposure from agent errors or unauthorised actions, so "robust controls and monitoring systems will be essential."

He also framed the authentication problem precisely. According to the same speech, the question shifts from proving that a buyer is an authorised payer to proving that an agent has the authority to pay on the buyer's behalf, and fraud models calibrated to human behaviour will need to be recalibrated for agent payment patterns. He noted that businesses pay over automated clearing house (ACH), wire, instant payments and cards, so agents in B2B would need to work across many rails.

That last point is the gap for institutions. Card networks can attach intent to a card credential. A bank transfer, an instant payment or a stablecoin transfer has no issuer-side intent check built in. If an agent is allowed to prepare supplier payments or treasury moves on those rails, the institution has to supply the equivalent control itself.

What it means for treasury and payment operations

Even if no agent touches your payments today, the questions are worth answering before one does:

Where is approved intent recorded? For each payment an agent prepares, can you point to the instruction a person approved, with its limits: payee, amount ceiling, currency, rail and validity period?
Is the check outside the agent? The control that compares a payment with the approved instruction should run in a system the agent cannot change, as in the AWS and Amex designs.
Does the agent ever hold a reusable credential? The card schemes are moving to one-time or narrowly scoped credentials. The equivalent for bank rails is a release that is valid for one specific payment and nothing else.
What happens on a mismatch? Decide in advance whether a payment that drifts from its approved intent is stopped, sent back to a person, or both, and record the reason.
Can you reconstruct a dispute? Six months later, can you show what was approved, by whom, what the agent proposed and why the payment was released?
Do your fraud rules know about agents? Waller's point about recalibration applies inside the institution too: an agent paying at machine speed and at odd hours looks different from a human approver.

Nothing here is legal advice. Liability for agent-initiated payments is still being worked out, and each institution must check its own obligations with its advisers, its scheme rules and its supervisors.

Where IXFXN fits

IXFXN is a control plane for money movement built on the same separation the card schemes are now adopting. Its AI proposes and explains payments but never sends money. The payment engine only acts with a permit for one exact payment, which works once and expires within 60 seconds. Rules limit the asset, provider, recipient, jurisdictions and maximum amount; a payment outside them is stopped with a reason code, larger amounts need more approvers, and every decision can be replayed against the rule version in force at the time.

To be clear about where it stands: bank transfers, tokenized deposits and USD Coin (USDC) run against a built-in simulation only, and outside AI tools can connect through a read-only Model Context Protocol (MCP) server. No customers or pilots exist yet.

Sources

IXFXN's weekly briefing on payments, treasury and AI. Not legal or investment advice. Get new posts in a feed reader (RSS).