Independent research and analysis

To advance fairer, faster, and more transparent payment dispute resolution.

Public Research

EMVCo's Agentic Payments Framework Fixes How AI Agents Pay. It Doesn't Touch What They Buy.

September 30, 2026

A critical read of EMVCo's Agentic Payments Framework for Specifications (Version 1.0 DRAFT), and what it leaves for disputes practice to work out on its own at this stage.


Payments has always been a HOW discipline. Which data element sat where in the message. How the cardholder was authenticated. Which party held liability once a chargeback flag went up. Four decades of EMV, EMVCo and the wider scheme architecture answer questions of mechanism: how value moves, how trust is established between issuer and acquirer, how a transaction is proven to have been authorised.
Disputes practice sits in both worlds, but unevenly. A meaningful share of chargebacks — claimed fraud, unauthorised transactions — are HOW questions at heart: the investigation turns on authentication data, authorisation flags, and whether the transaction was placed by the cardholder at all. Unrecognised-transaction disputes muddy that split: they're routinely filed under the same "unauthorised" umbrella, but often the consumer isn't disputing how the transaction was authenticated at all — they're disputing what it was for, unable to match a cryptic merchant descriptor to a purchase they may well have made themselves. That's arguably a WHAT question wearing a HOW label. The goods-and-services chargeback — not as described, not received, not as expected — is the clearer case: it's unambiguously a WHAT question, what was meant to be delivered, what quality or condition was implied, what information a consumer was actually given before they agreed to pay. That second category is where agentic commerce concentrates its risk, because forming a view of the WHAT before a human ever sees it is the agent's entire function. The industry has built extraordinary infrastructure for the first question and comparatively little for the second, leaving it to bilateral resolution, reason codes, and whatever evidence a merchant happens to keep.
Underneath both questions sits a harder one: trust. Trust — not technical readiness, not agent capability, not payment-rail interoperability — is arguably the single biggest constraint on whether consumers and merchants actually adopt agentic commerce at scale. Every HOW question EMVCo answers well — authentication, delegation, cryptographic binding — matters because it's a precondition for that trust. None of it is sufficient for it.
EMVCo's Agentic Payments Framework for Specifications — circulated as a Version 1.0 draft in August 2026 — was the moment to test that. When a consumer delegates product evaluation entirely to an agent, the WHAT question stops being a dispute-time afterthought and becomes central to the transaction itself.
It hasn't been answered. The framework is careful, well-scoped work on delegation, authorisation and cryptographic trust — genuinely useful groundwork for agent-initiated payment. But it is another HOW layer. What the agent was told, what it was shown, what it decided and why: none of that is captured. That gap is where trust will actually be won or lost.

THE INTENT OPPORTUNITY

Intent, properly captured, is arguably the biggest opportunity the payment ecosystem has ever had to better understand shopping behaviour, to detect and combat fraud, and to reduce — in theory even circumvent — buying-and-selling scams before they reach a completed transaction. ISO 8583 was never built to carry that kind of information; it moves authorisation data, not context. An Intent layer can, in theory, carry the richer, more context-specific data that fraud and scam management actually depends on: what a consumer asked for, what an agent was shown, why it chose what it chose. Agentic commerce hands the industry a structural opportunity to manage fraud, scams and chargebacks more effectively than card-present or card-not-present commerce has ever allowed — and, done well, to give consumers and merchants a genuine reason to trust it.
That is the standard this framework should be measured against. Not whether it moves a payment safely from an agent to a merchant — it does. Whether it captures enough of the WHAT to make Intent a trust-building asset, rather than just another payment record.

THE HOW/WHAT SPLIT IN EMVCO'S FRAMEWORK

EMVCo defines two operating modes — Immediate Mode, where the consumer is present and approves a purchase in real time, and Autonomous Mode, where a consumer authorises an agent to act within pre-agreed bounds and is absent at the moment of execution (§4.1). Authorisation flows through a three-layer delegation chain of Verifiable Credentials: a Trust Anchor binding the consumer to a payment credential, an Authorised Intent layer capturing consent and delegated authority, and an Autonomous Fulfilment layer carrying the agent's final, executed values (§4.2, §6.4). Consent itself is expressed through what the framework calls a Mandate Pair (§6.2.3): a Checkout Mandate, disclosed to the merchant, and a Payment Mandate, disclosed to the payment system — cryptographically bound to each other so that what was authorised for payment matches what was authorised for purchase. It is a genuinely careful answer to a real problem: how does a payment system trust that an agent acting without the consumer present is still acting within the bounds the consumer actually set. On that question, EMVCo has done the job well.
But a closer look reveals a Checkout Mandate carries three things: purchased items with quantities and prices, a stable merchant identifier (name, web domain, logo), and a merchant-signed record of the cart contents (§6.2.1). The framework's own definition of Checkout Context — the representation of "what is being purchased" — is scoped to "items, quantities, and merchant identity, and other information established during the checkout process" (Table 1.2). That is more than the bare "product plus quantity" the term Intent might suggest — price and a signed merchant record are in there too. But it is still a payment-adjacent record, not an evidentiary one, and nowhere close to the richer Intent data the opportunity above describes. Nowhere in that Mandate Pair is there a field for what the merchant presented about the product before the agent decided to recommend it. Nowhere is there a record of the consumer's original instructions or constraints — the actual brief the agent was working from. Nowhere is there any trace of how the agent got from a stated intent to a specific recommendation.
The framework captures what was bought. It has nothing to say about what the buyer — human or agent — was told, or why the agent believed it was the right answer.
It's a boundary by design: Section 1.2.2 excludes, in EMVCo's own words, "checkout schemas (item-level cart details) and merchant checkout validation logic" from this framework's scope entirely. The granular content of what a merchant actually presents — and whether it matches what's on the human-facing site — is left for someone else to define, at some later date, possibly never.
That gap has a direct cost, and it shows up in two places at once: in how disputes get investigated after the fact, and in how much trust an agent-mediated purchase can earn before a transaction ever happens. EMVCo does gesture toward dispute resolution as a benefit of its model, noting that "when a dispute is raised, the visibility of the Intent can be used by the Consumer, card issuer, merchant, acquirer, payment system to resolve the dispute" (§4.2). But the Intent available to do that is the same thin Mandate Pair described above — item, quantity, price, merchant identifier. It tells an investigator what was agreed to be purchased. It says nothing about whether what arrived matched what was presented, or whether the agent's recommendation was reasonable given the information available to it. Two examples make the cost concrete.

THE GATEKEPT LISTING PROBLEM

Consider a consumer asking an agent to source premium nut-free chocolates for a Christmas hamper. The agent queries a merchant's machine-readable product feed — the API or structured data source it actually reads, as distinct from the merchant's human-facing website — and that feed states "nut-free." The agent recommends the product; the consumer authorises the Checkout Mandate; the product arrives with "may contain traces of nuts — processed in a facility that also handles nuts" printed on the packaging. The merchant's human-facing website, as it happens, carries the identical disclaimer. No misrepresentation occurred there.
Under the current architecture, that discrepancy — between what the machine-readable listing said and what the human-readable listing (correctly) disclosed — sits entirely outside the transaction record EMVCo defines. The Checkout Mandate captures "nut-free chocolates, quantity one, from Merchant X, at $Y." It does not capture the claim the agent actually relied on to form its recommendation. And under current industry practice, the machine-readable feed used for agent discovery is typically not the same asset that a human reviewer or a chargeback investigator would be shown — it's gatekept for approved machine consumption only, not data that consumers, dispute teams, or anyone else can simply query or view. If a chargeback were investigated, the evidence available would be the human-facing site, which discloses correctly. The consumer would very likely lose the dispute.
Nobody involved — not the issuer, not the scheme, not the consumer — would actually know whether the agent misread the feed, the feed itself was wrong, or the agent's recommendation logic simply didn't weight an allergen disclosure the way a human shopper would have.
That last point matters beyond the value of one hamper. Agents do not currently disclose a confidence level in what they recommend — they act on the facts they were given, and the framework has nothing to say about capturing that reasoning trail. For a mispriced item, that's a friction cost. For an allergen, a safety claim, or a medical compatibility statement insufficiently disclosed in a machine-readable feed, the exposure moves well past the transaction amount.

THE IMPERSONATION PROBLEM

The framework is also silent — completely, not just thinly — on scams and merchant impersonation. There is no reference anywhere in its 56 pages to a fraudulent or impersonating merchant, and the Know Your Agent section explicitly rules "agent qualification processes, accreditation, or trust frameworks" out of scope (§3). That silence becomes more consequential once you look at how agents are actually observed to weight information when choosing between merchants.
Paul Accornero's working paper on agentic commerce theory — offered here as a data point, not a settled finding; it's a self-published, non-peer-reviewed SSRN paper built on the author's own computational simulation rather than live-market observation — models AI shopping agents as weighing purchase decisions across layers: hard constraints, then "inferred knowledge" (brand reputation, reviews, third-party endorsements), then real-time operational data (price, stock, delivery, API accessibility). Across a simulation of 600 synthetic purchase decisions, agents configured to weight reputation and operational signals equally still ended up dominated by the operational layer — averaging 0.970 on operational signals against 0.206 on reputation signals, a roughly 4.7-times gap (the effect was smaller but still present, at 1.8 times, across all agent configurations tested).
The finding wasn't framed by its author as a fraud story — it's offered as a theory of competitive dynamics between legitimate brands. But the mechanism generalises uncomfortably. If agents structurally favour whichever merchant presents the most machine-ingestible, real-time-verifiable data — regardless of how that merchant weights its actual reputation — then the barrier to competing for agent attention is largely a technical one: structure your data well, expose a clean API, keep it current. That barrier is unrelated to whether a merchant is who it claims to be. It is, if anything, an easier barrier for a fast-moving, purpose-built impersonator to clear than for an established brand with legacy systems and a slower integration timeline.
Accornero (2026), computational simulation, n = 600 synthetic purchase decisions.
Set this against the anti-scam tooling actually in market. Mastercard's relevant products — its Merchant Scam & Risk Indicator, and the Scam Merchant Monitoring Program taking effect from July 2026 — are built substantially on transaction-outcome signals: drops in authorisation approval rates, spikes in refunds and chargebacks, and issuer-reported scam classifications. MSRI is marketed as predictive, flagging risk patterns before an individual issuer formally escalates — but the pattern it's trained on is still built from historical authorisation and escalation behaviour, not from what a merchant claims about its products at the point an agent discovers it. Both mechanisms operate after money has started moving, or after enough transactions have accumulated to form a pattern. Neither reaches into the discovery layer where an agent decides, in milliseconds, which merchant to trust based on how well-structured its data feed is. EMVCo's Know Your Agent section acknowledges that agents "may produce inaccurate or unintended outputs" (§2.2) — but having named the risk, the framework does nothing to build a mechanism that would catch it before the point of payment.

THE SCOPE PROBLEM, STATED PLAINLY

None of this is a criticism of EMVCo's engineering — it's a deliberate scope boundary, stated at three separate points in the document: liability allocation, dispute handling, rulebook obligations, agent accreditation and trust scoring, and enforcement obligations are all explicitly excluded (§1.2.2, §3, §5.8). The framework itself is framed as a foundation for future specification work, not a complete answer (§1.1).
The risk is what happens in that gap while nobody else picks up the WHAT question. Card schemes, issuers, and dispute rulebooks already treat the payment record as a proxy for what was agreed to — an assumption that strains under ordinary "not as described" disputes, and won't survive an agent layer deciding and transacting on information nobody downstream can see.
The framework is a credible first draft for facilitating agentic payments. Facilitating agentic commerce — commerce consumers and merchants actually trust — needs far more attention to effective, accessible Intent management than this draft gives it. A cryptographically verifiable record of price, quantity and merchant identity proves the payment was authorised. It says nothing about whether the purchase should have been.

OPEN QUESTIONS
Who is expected to define the WHAT layer, if not EMVCo — the merchant checkout schemas, the item-level representations, the record of what an agent was actually shown before it formed a recommendation?
Should Know Your Agent extend to verifying what a machine-readable listing claims against what a human-facing listing discloses, as a condition of agent-facilitated discovery — and if so, whose responsibility is that verification?
If agents don't currently disclose a confidence level in their recommendations, should payment-layer or checkout-layer specifications require one, and what would a dispute process do with that information if it existed?
Does a merchant risk signal built on authorisation drops and chargeback history — arriving after transactions have already occurred — meaningfully protect consumers and issuers against an impersonator whose only advantage is a better-structured product feed?
If trust, not technical capability, is the real constraint on agentic commerce adoption, should effective and accessible Intent management become its own named workstream — alongside Know Your Agent and Agentic Transaction Indicators — rather than an implicit by-product of the payment layer?
And if liability, dispute handling and enforcement are consistently out of scope for the standards bodies building the payment rails, which body — regulatory, industry or otherwise — is actually accountable for answering them before agentic commerce scales past the point where retrofitting is possible?

Methodology and sources
This article draws on a direct review of EMVCo's EMV® Agentic Payments — Framework for Specifications, Version 1.0 DRAFT (August 2026), circulated for industry consultation; all section references (§) are to that document. The document is marked as a confidential draft under EMVCo's standard review terms — this piece paraphrases and cites specific defined terms and section numbers rather than reproducing its text at length, and does not represent EMVCo's final published position, which may change materially before formal release.
The Accornero figures are drawn from Paul F. Accornero, Agentic Commerce: A Theory of Markets When the Shopper Is No Longer Human (SSRN Working Paper, 2 January 2026) — a self-published, non-peer-reviewed working paper. The cited statistics come from the author's own computational simulation of 600 synthetic purchase decisions across simulated products, not from observation of live agent behaviour in market; they are presented here as an illustrative, hedged data point on agent decision-weighting, not as an established empirical finding.
Mastercard product detail (Merchant Scam & Risk Indicator; Scam Merchant Monitoring Program, effective 24 July 2026) is drawn from Mastercard's own published materials and industry reporting current as of publication.
The nut-free chocolate scenario is an illustrative hypothetical constructed for this piece; it does not describe an actual dispute or an actual merchant.

Sources

  1. Accornero: AGENTIC COMMERCE: A Theory of Markets When the Shopper Is No Longer Human
  2. EMV® Agentic Payments - Framework for Specifications v1.0 DRAFT: Comment period ends 30-Sept 2026 | EMVCo

See all sources in the reference library →