American Express has published the thing EMVCo only described. On 13 October 2026 it released Intent Intelligence, a framework that turns a shopper's instructions to an AI agent into a record with its own identifier, a signed token and a lifecycle the issuer can check at authorisation and again in a dispute.
The timing is pointed. EMVCo's Board of Advisors met in Hanoi on 13 and 14 October to decide what happens to its draft agentic payments framework, and as of today no readout has been published. Amex, one of EMVCo's six owners, shipped its own answer on the first morning of the meeting.
What Is Amex Intent Intelligence?
Amex calls it "a suite of services to create, update, and cancel a user's authenticated intent". It is delivered through the Agentic Commerce Experiences (ACE) Developer Kit, the SDK Amex launched in April alongside Agent Purchase Protection, and the press release describes it as a core ACE service.
The flow has four steps:
- The agent collects what the customer wants and submits it through the Create Intent API.
- The customer authenticates and signs off, by passkey or through a sign-off the issuer has delegated to the agent or a wallet.
- Two artefacts come back: an Intent ID, which Amex describes as the primary key for every later request against that intent, and a Proof of Intent Token, which is a JSON Web Token carrying the high-level constraints.
- The token is exchanged for a scoped payment credential. The agent pays with that credential at checkout and never sees the card number.
Issuers can run risk checks and step-up after sign-off, before anything is bought. The intent then feeds authorisation and fraud decisions, and Amex says issuers can evaluate disputes against the cardholder-confirmed version.
Hannah Bozian, Amex's VP of agentic partnerships, told Digital Transactions the network already sees "thousands" of agentic transactions a week across the integrations it supports. That is a small number for Amex, and an honest one.
What Fields Does an Amex Intent Contain?
The technical post by Inderpreet Hundal and Gianna Rotondo lists eight fields. This is the part a press release would never print, and it is where the design decisions show.
| Field | What it holds |
|---|---|
| Purchase Summary | What was agreed, with personal details irrelevant to the purchase removed |
| Max Amount | The most the customer will pay |
| Intent Expiry | Last date the intent can be actioned; the token expires then too |
| Merchant Data | Only if the customer named a merchant |
| Item-Level Conditions | Dependencies between items; absent means each item is fulfilled independently |
| Maximum Number of Transactions | Expected number of purchases, mapped to the number of credentials that can be issued |
| Order Context | Typed Intent (preferences) or Cart (approved products), each item and merchant with a reference ID |
| Purchase Criteria | Conditions that must hold before the agent buys, such as a restock or a date |
Read the full article on tomcn.uk →
About the Author
I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.
Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.
Top comments (1)
The lifecycle detail that matters most is that the Intent ID anchors every later request, including the dispute path. Agentic commerce has been missing exactly that: a durable, issuer-checkable record of what the customer actually authorized, instead of reconstructing intent from prompts and screenshots after something goes wrong. Mapping maximum transactions to the number of credentials that can be issued is also the right containment, since it caps the blast radius of a leaked token rather than trusting the merchant to self-police. Curious whether the intent expiry will hold up for replenishment-style purchases, where the condition pattern argues for long-lived intents.