EMV 3-D Secure defines exactly five message extensions today. Not one of them can say that an agent was involved, and the agentic payments framework EMVCo put out for comment on 1 September 2026 does not add a sixth.
That is the shape of the document, not an oversight. EMVCo has published a coordination layer for consumer intent and said nothing about the two things a payments engineer needs settled: what travels in the authorisation message, and who pays when the agent gets it wrong. Comments close on 30 September.
What Is EMVCo's Agentic Payments Framework?
The document is titled EMV® Agentic Payments – Framework for Specifications v1.0 DRAFT. It sits under Technical Resources on emvco.com, not under Specifications, and EMVCo calls it a foundation for potential specification development. No timeline for a real spec is committed anywhere.
The naming carries more than the press release does. An earlier round went to EMVCo Associates as EMV® Agentic Payments Specification – Technical Framework v1.0 DRAFT, comments closing 5 August 2026, and a Disposition of Comments for it already exists. Between August and September the word "Specification" moved out of the title and the document became a framework for specifications. Whatever came back from Associate review was enough to downgrade the work before it went public.
EMVCo is owned by American Express, Discover, JCB, Mastercard, UnionPay and Visa, and its Board of Advisors votes on whether a specification is ready to publish. That Board next meets on 13 and 14 October 2026, a fortnight after the window shuts. First point where direction becomes visible.
What Are Intent Services in Card-Based Agentic Payments?
Intent Services are the substance of the draft. EMVCo's framing is a shared layer that lets participants "register, reference, retrieve and manage consumer-authorised intent" before, during and after a transaction, with an overview of roles and data fields for doing so.
The scope is narrower than the headlines suggest. EMVCo has aimed at cases where intent has to persist: recurring purchases, cumulative budgets, disputes and reconciliation. Those need a state that outlives a single authorisation and is readable by a participant who was not present when consent was given. EMVCo is explicit that this complements the cryptographic assurance other efforts provide, naming Verifiable Intent directly, rather than replacing it.
One caution on the secondary coverage: the main write-up quoting the draft credits EMVCo with a three-layer credential delegation chain that is actually Mastercard's Verifiable Intent. If you see EMVCo credited with a signing scheme, check the source.
Why There Is No Agentic Indicator in the Authorisation Message
The two capabilities engineers keep asking about, Know Your Agent and Agentic Transaction Indicators, appear in the release with the softest verb available. EMVCo says it may consider including them in future publications. No agent identifier format, no attribute schema, no flag.
The concrete position today: EMV 3DS carries five registered message extensions, being Attribute Verification, Bridging, Device Acknowledgement, Payment Token and Travel Industry. The Message Extension element allows up to 15 extensions and 81,920 characters, so the headroom for an agentic one exists and is quantified. The published specification is still v2.3.1.1, from May 2023, and EMVCo has confirmed only that a next major version is being designed around a more iterative release model. There is no public v2.4.
Nor is there anything in ISO 8583 or ISO 20022. No agentic data element, no reserved field, no bulletin defining one.
So where does agent context travel in 2026? Inside the token. Google's AP2 hands a signed Payment Mandate to a credential provider, which returns a scoped credential, and suggests placing the closed mandate inside it. Nothing new appears on the network message, which is exactly why it works.
EMVCo Intent Services vs AP2, Verifiable Intent and ACP
| What is signed | Who holds the credential | Lifetime | |
|---|---|---|---|
| AP2 v0.2.0 (28 Apr 2026) | Checkout and Payment Mandates as SD-JWT VCs, ES256/P-256 | Credential Provider, or a Trusted Agent Provider backend key | Per transaction |
| Verifiable Intent v0.1.0 (Mastercard) | L1/L2/L3 SD-JWT chain, agent key bound via cnf.jwk | Consumer device holds L2, agent signs L3 | L3 about 5 minutes, L2 up to 30 days |
| ACP Delegate Payment (OpenAI, Stripe) | Nothing, in the cryptographic sense | Merchant's PSP vaults the token | Bounded by allowance.expires_at |
| EMVCo Intent Services | Nothing yet | No credential defined | Designed to persist across transactions |
All three shipping protocols solve the problem the same way: bind consent to one purchase, cryptographically, expire it fast. AP2 v0.2 dropped the Intent Mandate entirely and renamed Cart Mandate to Checkout Mandate, which tells you where its authors landed. ACP does not sign consent in that sense at all; its allowance object carries max_amount, currency, merchant_id, checkout_session_id and expires_at, and Mastercard's documentation makes the sharp point that those constraints are set by the agent, not the buyer.
The trade-off is real. Short-lived mandates are excellent evidence that a specific purchase was authorised, and useless for answering "was this £2,400 inside the budget the customer set six weeks ago", because the artefact proving the budget expired long ago and the issuer never saw it. That is the gap EMVCo is aiming at, and no shipping protocol covers it.
A dependency already runs the other way, which most coverage missed. AP2's credential request asks for vct_values: ["com.emvco.dpc"] and claims card_last_four, card_network_code and credential_id. EMVCo's Digital Payment Credential, still a draft after review rounds in March and July 2026, is a normative dependency of Google's protocol. EMVCo is not late here. It is already load-bearing in someone else's stack.
Who Is Liable When an Agent Buys the Wrong Thing in the UK and EU?
EMVCo's public material contains no liability language at all: not a sentence on scheme rules, chargeback rights or PSD2.
Under the PSD2 RTS there is no special regime for agents, as Osborne Clarke set out in March 2026; disputes turn on whether the payer authorised every element of the transaction and whether that is auditably evidenced. Worldpay's read is that where the agent authenticates and the transaction is tokenised, existing rules apply and the issuer carries fraud risk, while the "my agent misunderstood me" category gets negotiated contractually.
My own view, offered as opinion: the harder problem is classification, not liability. An agent spending against a stored budget looks like a merchant-initiated transaction on the wire, and MITs following an authenticated first payment are SCA-exempt. Semantically it is a delegated cardholder-initiated transaction: a human set the constraint, a machine chose the moment. Nothing in the data model separates the two, so an agentic purchase escapes strong authentication by accident rather than by design. Intent Services would fix that by making the original consent retrievable at authorisation time. My prediction: EMVCo never defines liability here. It defines an evidence store and leaves the schemes to write rules on top, and the agentic indicator lands as a 3DS message extension rather than a new ISO 8583 field, because the extension mechanism already exists and nobody wants to re-certify a network message.
One participant stopped waiting. American Express launched Agent Purchase Protection on 14 April 2026 alongside its ACE Developer Kit, backing purchases made by registered agents. Amex is a three-party network, so it can write that rule alone. Visa and Mastercard cannot, which is the structural reason this ended up at EMVCo.
What This Means for Payments Engineers in 2026
- Do not build against this draft. No wire format, no schema, no committed date. Watch the 13 to 14 October Board of Advisors meeting.
- Comment if you have a position. The Specification Feedback form on emvco.com now carries an "Agentic Payments" topic and closes 30 September 2026. Submissions may be published anonymously in a Disposition of Comments, so this round will be visible.
- Instrument for it now, cheaply. Store a stable intent identifier and a hash of the consent artefact alongside the authorisation record. That costs one column, and it is what a dispute in eighteen months will need. Keep it out of descriptors and addendum records you will later have to migrate, and assume a 3DS extension is coming.
- On ACP, the concrete piece already exists. Its Delegate Authentication RFC, versioned 2026-01-28, is straight 3DS2: it returns
trans_status,electronic_commerce_indicator,three_ds_cryptogramandthree_ds_server_trans_id, and takesacquirer_binandacquirer_merchant_idso the AReq matches the final authorisation. A shipping integration, unlike anything in the EMVCo draft, and the counterpart to the gap in Anthropic's commerce agents.
- Watch the classification question. Whether agentic volume books as MIT or CIT changes your SCA exemption profile and your chargeback rights.
If you are building agent-initiated card flows and want to compare notes, I am Tom Wang.