The Agent Was Authorized Once. EMVCo Says the Authority Behind That Grant Keeps Changing.

Most of what has been built so far to secure an AI agent's payment authority answers one question: was this specific action authorized. A signed mandate, a cryptographic credential, an approval receipt, each of these proves that at some point a human granted permission for something. EMVCo's new draft asks a different, harder question. If that permission was for a budget that gets drawn down over several purchases, or a purchase that repeats on a schedule, or an authorization that can be revoked after the fact, does proving the original grant still tell anyone what authority remains right now.

What EMVCo actually published, and what it is not

On 1 September 2026, EMVCo, the technical body that creates and manages the EMV specifications governing most of the world's card payments, published the EMV Agentic Payments, Framework for Specifications, version 1.0, as a draft. EMVCo invited all interested stakeholders to provide feedback through Wednesday 30 September 2026. EMVCo's own framing, corroborated consistently across the outlets this record checked, describes the document as a foundation for further industry engagement and potential specification development, language that keeps the draft well short of an adopted standard.

That distinction is publication critical and this record preserves it throughout. This is a draft framework for future specifications. It is not a final EMV specification, not an implemented network protocol, not a production service, and not a rule Visa or Mastercard has adopted. No specification, implementation or production deployment built on it has been identified. It is also a separate, later artifact from EMVCo's 20 November 2025 announcement, which committed only to studying how EMV Specifications, including EMV 3D Secure, EMV Payment Tokenisation and EMV Secure Remote Commerce, could be developed to support card based agentic payments. That earlier announcement named no Intent Services concept and committed to no specific mechanism. The version 1.0 draft is the first point at which EMVCo has put a concrete proposal on paper for public comment.

Intent Services: a coordination layer, not a proof of one grant

The draft's central proposal, in EMVCo's own language as corroborated across this record's search passes, introduces Intent Services, a shared, interoperable layer that lets payment participants register, reference, retrieve and manage consumer authorized intent before, during and after a transaction. EMVCo describes Intent Services as designed to complement the cryptographic assurance already provided by existing industry solutions, naming Mastercard's Verifiable Intent, with a common coordination point that helps participants consistently interpret consumer authorized intent. That is EMVCo's own framing of a coordination function, and this record does not extend it into a claim that Intent Services is a single centralized database. Whether an Intent Service is one logical service, several interoperating providers, or implemented separately by each card scheme or participant is not established by anything available to this session, and this record leaves that architectural question recorded as unknown rather than guessed.

EMVCo's own stated reason for building a coordination layer at all is specific. Following industry input, EMVCo has focused on card based agentic payment scenarios where intent needs to be managed over time, naming three examples directly: recurring purchases, cumulative budgets and post transaction activities. EMVCo's language states these scenarios may require a shared intent state that persists across multiple participants and interactions, not a single point in time record of one signature. The framework also states it provides an overview of ecosystem roles and data fields for registering intent, for maintaining lifecycle and state information, and for enabling the authorized retrieval of intent related data, a description this record could not verify against the draft's own text directly, since this session could not fetch it.

The distinction this record treats as durable

Read past the specific mechanism EMVCo proposes, the thesis underneath it is the one this record treats as the lasting signal, independent of whether Intent Services itself is ever finalized. A payment mandate can be validly authorized and still not describe the authority actually available at the moment a later, related transaction executes. A signed intent is not the same fact as the current state of that intent. A recurring authorization is not a permanent one. Every participant holding a copy of an original mandate is not the same as every participant holding the current state of it. One agent spending part of a shared budget does not mean other agents drawing on the same budget automatically know it. Cryptographic proof that a mandate was signed is not the same fact as lifecycle coordination of what remains of it. A payment succeeding is not the same fact as every participant's view of remaining authority updating automatically. EMVCo's draft is significant less because of what Intent Services specifically defines today, which is thin, and more because it is an independent global card payment standards body formalizing the requirement that authority be treated as stateful and consumable at all, alongside protocol level attempts elsewhere in this corpus.

Moona Intelligence's evidence of authorization record already tracks the closest existing implementation of this same problem: an AWS and Solv Labs architecture that checks a cumulative session spending cap before each payment rather than resetting it per transaction, and a distinction that record coined between transaction authority, whether an agent may submit one payment, and position authority, whether an agent may create a continuing financial exposure that outlives it. EMVCo's draft describes the same underlying requirement, a shared, persistent view of what authority remains, from the standards body side of the industry rather than from one platform's own session architecture, and this record treats the two as independent confirmations of the same durable thesis rather than one restating the other under new terminology.

What the draft names and what it leaves open

EMVCo names cumulative budgets and recurring purchases as motivating scenarios. Nothing available to this session establishes whether the draft actually defines the field level mechanics a cumulative budget would require: a remaining balance, a consumed amount, a transaction counter, a reservation or pending state, a rollback mechanism, or an expiry field. This record does not invent that schema on EMVCo's behalf, and does not assume the draft carries generic policy expressiveness beyond what its own corroborated language states.

Concurrency is the sharper gap. Nothing found by this session states whether the framework defines an atomicity guarantee for two participants simultaneously drawing on the same shared intent or the same cumulative budget, the exact double spending of authority question this record's parent thesis is built around. This record marks that behavior unknown rather than assuming either that a guarantee exists or that the framework ignores the problem. The same is true of revocation and modification. Nothing available to this session states who is authorized to modify or revoke a registered intent, how other participants learn a change occurred, whether a previously retrieved or cached intent reference can remain usable after that change, whether intent records carry a version, or how long intent state is retained once a transaction concludes.

Post transaction scope is named without being defined. EMVCo states Intent Services cover the period after a transaction as well as before and during it, and names post transaction activities as a motivating scenario, but nothing available to this session states whether that scope specifically covers a refund, a reversal, a chargeback, a cancellation, a failed authorization, a partial capture or an incremental authorization, or whether a consumed cumulative budget is restored after any of those outcomes. This record does not assume any of them are covered simply because the general category was named.

Verifiable Intent, and what complement does not mean

EMVCo's own language states Intent Services are intended to complement, not replace, the cryptographic assurance already provided by existing industry solutions, naming Mastercard's Verifiable Intent specifically. Mastercard's own published material about Verifiable Intent, corroborated through this session's search passes, describes it as built on specifications from the FIDO Alliance, EMVCo itself, the IETF and the W3C, producing a cryptographic proof of consumer authorization tied to one transaction. Read together, the two are complementary but distinct layers, not one absorbing the other. Verifiable Intent, on the material available to this session, is a proof mechanism for one authorization event. Intent Services, on EMVCo's own framing, is a coordination and lifecycle layer for what happens to that authorization afterward. This record does not claim EMVCo has adopted Verifiable Intent as its canonical evidence format, and does not claim Mastercard's own specification independently provides the shared lifecycle state Intent Services describes, because nothing found by this session establishes either claim. Moona Intelligence's record on the Agentic Payments Alliance already tracks the venue, FIDO's own conference, where Mastercard's Verifiable Intent and Google's AP2 sit alongside each other as a separate, unresolved interoperability question; EMVCo's draft is a distinct, standards body level development running in parallel to that venue, not a product of it.

Named future work, kept separate from what the draft requires today

EMVCo's own material, corroborated across this session's search passes, states EMVCo may consider capabilities related to Know Your Agent, KYA, and Agentic Transaction Indicators for future publications, part of a broader effort toward consistently identifying agentic transactions across the payments ecosystem. This record treats both as named future direction EMVCo has flagged, not as requirements the current version 1.0 draft itself establishes, and found no description of either capability's actual mechanics beyond that they are being considered. EMVCo separately states it is working on how EMV 3D Secure, EMV Payment Tokenisation and EMV Secure Remote Commerce can be developed and enhanced to support card based agentic payments, and that the Agentic Payments Framework helps identify potential future enhancements to EMV Digital Payment Credential. This session did not directly read draft text defining exactly how Intent Services would interoperate with any of these existing specifications, so this record states EMVCo's own direction without asserting a specified integration.

Where this sits against what Moona Intelligence has already verified

The evidence of authorization record already owns proving, after a payment settles, that it was authorized under a specific policy before it moved, and it already owns the sharpest existing implementation of a cumulative, consumable spending cap and the transaction authority versus position authority distinction. The Agentic Payments Alliance record already owns the admission, from a card network coalition rather than a standards body, that agent payment authority interoperability across organizations remains unsolved. The authorization propagation record already owns how one human's authorization survives being routed through a chain of agents and organizations that never saw the original delegation, including a Chinese payments industry convention's own four stage trusted evidence chain, the closest existing analogue in this corpus to a registry style coordination layer, though built by a different body with different mechanics. Robinhood's record already owns what a single platform does when it authorizes its own software to move a user's money, with simple ceilings rather than a consumable, cross participant budget. None of them, on the material this record could verify, does what EMVCo's draft does: propose, from an independent global card payment standards body rather than one vendor or one national industry association, a shared coordination layer explicitly built around the idea that authority is a state that changes after the original grant, not a signature that stays valid until it expires. That is why this record treats the draft as its own canonical rather than folding it into any of the above.

It is also why this record refuses to let that distinct contribution round up into more than a draft framework actually claims. EMVCo has named the problem precisely: recurring purchases, cumulative budgets and post transaction activities each require someone to know what authority remains, not only what was originally granted. It has proposed a coordination layer for that problem and opened it for public comment through 30 September 2026. It has not yet published, on anything this record could verify, the field level mechanics a cumulative budget requires, a concurrency guarantee against two participants consuming the same authority at once, or a defined revocation propagation mechanism. The agent was authorized once. Whether anyone across the payment chain can currently see what that authorization has become still depends on specification work EMVCo has only just begun.