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:
1. The agent collects what the customer wants and submits it through the Create Intent API. 2. The customer authenticates and signs off, by passkey or through a sign-off the issuer has delegated to the agent or a wallet. 3. 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. 4. 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 |
Two details matter more than the rest.
Maximum Number of Transactions caps credentials, not authorisations. If a customer approves "buy these three things when they come back in stock", the issuer can mint at most three scoped credentials against that intent. The budget is enforced where the credential is minted, which is the one place an issuer fully controls. That is a better enforcement point than asking every merchant to respect a limit in a JWT. The reference IDs in Order Context are scoped to the request body. Amex says plainly they are not stable identifiers across the ecosystem. So the Intent ID is the only durable key, and a merchant cannot use an item reference to reconcile anything after the fact. If you are planning to join intent data to your order system, you join on the Intent ID or not at all.The post also defines two intent shapes, Broad Intent and Specified Intent, and two cart shapes: an Order-Ready Cart the customer signs before checkout, and a Proposed Cart the agent presents for confirmation before filling it.
Amex Intent Intelligence vs EMVCo Intent Services, AP2 and Verifiable Intent
When I wrote about EMVCo's draft framework last month, the gap was clear. Every shipping protocol bound consent to one purchase and expired it fast. Nothing covered intent that had to persist: a budget set six weeks ago, a restock order, a recurring purchase. EMVCo's Intent Services aimed at that gap but defined no credential and no schema.
| Durable record | Signed artefact | Who enforces limits | Status | |
|---|---|---|---|---|
| Amex Intent Intelligence | Intent ID, held by issuer | Proof of Intent Token (JWT) | Issuer, at credential minting | Live in ACE Kit |
| EMVCo Intent Services | Described, not specified | None defined | Not defined | Draft framework |
| AP2 v0.2.0 | None; Intent Mandate dropped | Checkout and Payment Mandates (SD-JWT VC) | Credential Provider | Published spec |
| Mastercard Verifiable Intent | L2 credential, up to 30 days | L1/L2/L3 SD-JWT chain | Verifier of the chain | v0.1.0 |
| ACP Delegate Payment | None | Nothing signed | Agent sets allowance | Shipping |
The trade-off is between a record and a proof. AP2 and Verifiable Intent put the evidence in the artefact: anyone holding the signed chain can verify it without calling home. Amex keeps the evidence at the issuer and hands out a token that points to it. The record approach answers "was this purchase inside what the customer agreed in August?" because the issuer still has August. The proof approach answers "did the customer sign this exact cart?" without a network round trip.
Amex can choose the record because it is a three-party network. It is usually the issuer, the acquirer and the network at once, so a lookup against the Intent ID never leaves the building. Amex says other participants would plug in their own network and tokenisation services, but a four-party Visa or Mastercard transaction would need the issuer, the token service provider and probably the acquirer to agree on where the intent lives. That is exactly the coordination problem EMVCo exists for.
Will Amex Intent Intelligence Become the EMVCo Standard?
My view, offered as opinion: the Intent ID survives and the JWT does not.
An issuer-held intent record keyed by a single identifier is the minimum EMVCo needs, and Amex has now shown it works with real traffic. Digital Transactions reports Amex chairs EMVCo's agentic commerce work (EMVCo's own material calls the group a task force), so the shape will travel. What will not travel is a plain JWT with unpublished claims. AP2 and Mastercard both settled on SD-JWT verifiable credentials with selective disclosure, and AP2 already depends on EMVCo's Digital Payment Credential. A four-party standard will want selective disclosure so the merchant can see Max Amount without seeing Purchase Summary.
My prediction is that any EMVCo specification which follows, if one is approved, defines an intent identifier and a retrieval interface and lets the proof format be either a JWT or an SD-JWT VC. The Intent ID ends up in the network token cryptogram data or a 3DS message extension, not a new ISO 8583 field, because nobody wants to re-certify the authorisation message for this.
What Amex Has Not Published Yet
Be careful about how much of this you can build today. The public material does not include:
- endpoint paths or request and response schemas for create, update or cancel
- the JWT's claims, signing algorithm or key distribution
- how the token is exchanged for a credential, or whether that credential is a network token or a virtual card number
- the sample payloads, which appear only as images in the blog post
- any dispute data; the release says the framework reduces "the chance of costly disputes" and gives no figure
What This Means for Payments Engineers Building Agents
- Make the intent a first-class row. Store an intent identifier, its expiry, its max amount and its remaining credential count in your own schema now. When Amex's Intent ID, an EMVCo identifier or your own UUID fills that column, the joins are the same. I suggested one column last month; this release says you need four.
- Enforce budgets where credentials are minted. If you run an agent platform, count credentials issued against each intent rather than trusting the agent to stop. Amex's Maximum Number of Transactions field is the pattern to copy.
- Do not treat a stored intent as a stored credential. An agent spending against an intent set weeks ago looks like a merchant-initiated transaction on the wire. Until a scheme says otherwise, keep the original authentication evidence linked to every later payment so you can prove the customer was in control.
- Map your ACP or AP2 flows to this table. If you already ship on AP2, ACP or x402, the missing piece is almost always the durable record. Add it on your side before a network makes you.
- Watch for the Hanoi readout. If EMVCo moves Intent Services from framework to specification, the Intent ID question gets settled for Visa and Mastercard too.