Wednesday, American Express published its Intent Intelligence framework, a new core service of the Agentic Commerce Experiences (ACE) Developer Kit. I covered the ACE launch in April in American Express Breaks the Agentic Commerce Deadlock: Why Today Matters. In April, Amex said it would stand behind agent errors. This week it published how it will know what the agent was supposed to do.

I have written five posts on the problem of intent in machine to machine (M2M) transactions:

• Agentic Intent and the New Data Games,
• Carts and Mandates: Decoupling Discovery,
• Authentication, and Liability,
• Agentic Data Battle: Intent,
• Agentic Apocalypse: How to Stop It and
• EMVCo Enters the Intent Wars.

One principle runs through all of them: intent data must flow to the party taking the risk. Amex has now published a framework built around the issuer, the party that authorizes the payment, answers the phone and absorbs the dispute (and COULD take on liability).

Executive Summary

• Agents get complex purchases wrong. Delta Network data shows a 28.8% false positive rate (wrong purchase released) wiself-attestationion alone, rising to 71.4% on intents with five or more constraints.
• AP2 and Google/Mastercard Verifiable Intent are technically elegant, but the orchestrator interprets the intent, controls disclosure, manages the credentials, and attests that the cart matches. The party verifying the purchase is the party that profits from it, and it takes no risk. I call this grading your own homework.
• Amex Intent Intelligence moves intent to the issuer before the agent transacts. The consumer signs off through the issuer (passkey, or a delegate the issuer approves), the issuer scopes the payment credential to that intent, and the same record governs authorization and disputes.
• Banks have three roles here: authorization, taking risk (liability shift) and confirming intent with the consumer, as they already do in step up authentication. Networks set the standards and governance.
• Yes, this adds friction. My view is that this friction is acceptable while consumer behavior and agent performance are modeled. I expect a version of Amex Intent to make its way through EMVCo.
• Longer term, issuers will provision credentials to platforms for signing. Apple could make this work today across every card in Apple Pay. The fourth model is the walled garden (Amazon), where intent never leaves the platform.

The Problem: Agents Get It Wrong, and the Party That Pays Cannot See It

In Agentic Apocalypse I published the first hard data I had seen on intent failure. Delta Network ran 100 single product purchase intents through two agents, both using Shopify’s UCP CLI for discovery. The control agent relied on its own judgment. The second used Delta Mandate to check the proposed purchase against the consumer’s constraints before release.

Constraints in the intent	Control agent error rate
Easy (1 to 2)	22.2%
Medium (3 to 4)	25.0%
Hard (5 or more)	71.4%
All purchases released	28.8% wrong

Every failure had the same shape: the agent claimed a constraint was satisfied without evidence. Fleece joggers were called cotton. A product was passed as “dishwasher safe” when the catalog said nothing about it. With pre release verification, the false positive rate was zero.

This is not fraud. It is subtle wrongness, and it lands on the issuer’s phone line. Federal Reserve Governor Christopher Waller framed it the same way at Sibos last month: the authentication question shifts from proving the buyer is an authorized payer to “proving that an agent has the authority to pay on the buyer’s behalf,” and liability “comes down to a pretty simple question: Who is on the hook if an agent makes the wrong purchase?” (Waller, “Payments in the Age of AI Agents,” Sep 28, 2026).

Why Existing Protocols Do Not Solve It

AP2 is technically elegant. The Google and Mastercard Verifiable Intent specification adds a layered credential chain with eight constraint types. The problem is not the cryptography. It is who builds, holds, verifies and benefits.

Who signs, and who benefits

The orchestrator (the agentic platform) constructs the mandate from its own reading of the conversation, holds it in its own wallet, and its agent signs the fulfillment layer asserting that the purchase met the consumer’s constraints. Google’s model is “I signed it, trust me.” (but I take no risk at all if I’m wrong). The signer and the beneficiary of the transaction are the same party.

To be precise, as I noted in the technical addendum to Agentic Data Battle: Intent: the self attestation is not in the math. A Verifiable Intent chain proves the amount, the payee and that the chain was not tampered with. It cannot prove the joggers are cotton. That claim rests on the agent’s signature alone.

The test for an issuer is simple: “Google, if you are wrong, are you taking risk?” The answer is no. An immutable audit trail does not change that. An immutable record of a mistake is cold comfort when the fraud losses land on your balance sheet.

What credential, and how it is disclosed

Verifiable Intent builds on verifiable credentials with selective disclosure, so intent data is revealed “only to the right party at the right time.” The catch is that the orchestrator controls disclosure. The payment network receives the payment disclosures; the merchant receives the checkout disclosures. What the consumer said stays opaque to networks and issuers unless the orchestrator chooses to reveal it. That is the design, not a bug. It protects Google’s data governance stance: data goes in, it never comes out (Agentic Intent and the New Data Games).

Compare EMVCo’s September draft, which I called the fix in EMVCo Enters the Intent Wars. It uses a three layer signing chain. Layer 1 is a trust anchor issued by the payment credential provider (candidate: the Card DPC). Layer 2 is signed by the consumer on their own device. Layer 3 is the agent’s fulfillment. Signing moves to the consumer. The consumer’s key, not the platform’s, roots the chain. Device binding (a DPAN in the Secure Enclave or Titan M2) is allowed but not yet required. That is the open gap.

How the customer is involved

Banks have spent more than a decade on ID&V and DPAN credential provisioning that binds a consumer’s biometrics to a device and a credential (Tokens and Binding 101, EMVCo and DPCs). Apple does not publish the figure, but my estimate is that more than 80% of US iPhones carry a provisioned DPAN. That binding AND the bank control in provisioning (with standards in HOW the credential is stored) is what makes a signature meaningful: it proves the human authorized this specific scope, not just that a platform says they did. Verifiable Intent’s Layer 1 can be issued by a network or issuer. But the consumer confirms the scope inside the orchestrator’s wallet, under the orchestrator’s process, and nothing yet requires the signing key to be bound to a device the bank verified. The bank has no say in how the consumer was involved.

Governance: who owns the risk

From Agentic Data Battle: Intent: “Intent data must flow to the entity taking the risk… There should be no self attestation from ‘new’ parties in a transaction that do not bear risk.” An orchestrator that wants to attest an agent acted within scope has two legitimate paths:

1. Share the actual intent data with the party assuming liability, or
2. Assume liability for its own attestation.

Verifiable Intent takes neither.

A Worked Example: An $800 Carry On Bag

A consumer tells an agent: “Buy me a carry on bag, up to $800. Black. Ballistic nylon or hard shell. Four caster wheels. It has to fit in the overhead bin on a plane.”

That is five constraints. In Delta’s data, this is the hard bucket, where the control agent was wrong 71.4% of the time.

How it works in AP2 with Verifiable Intent

1. The platform writes the intent. Gemini turns the conversation into an Intent Mandate. Per the AP2 specification, it includes “the natural language description of the user’s intent as understood by the AI Agent.” The consumer signs it with a biometric inside Google’s wallet. The words are the agent’s; the consumer approves the agent’s summary.
2. The merchant signs the cart. Days later the agent finds a bag. The merchant builds and signs a Cart Mandate: SKU, price ($649), merchant identity. The merchant’s signature is a price and item lock. It guarantees what the merchant will sell. It says nothing about whether the bag is ballistic nylon or fits an overhead bin, because the merchant never sees those constraints unless the platform discloses them.
3. The platform checks its own work. Under Verifiable Intent, the agent compares the signed cart with the consumer’s mandate, decides it fits, and signs the Layer 3 checkout and payment credentials. That Layer 3 signature is the “verifiable” part of verifiable intent. The party doing the verification is the party that interpreted the intent, selected the product and earns from completion.
4. The issuer gets a payment mandate. with the amount, the merchant, an agent flag and the “human not present” modality. It does not see “black,” “ballistic nylon,” “four wheels” or “overhead bin.”

Now suppose the bag is polyester, has two wheels, and is 24 inches tall: a checked bag, not a carry on. Every signature in the chain is valid. The consumer calls the bank.

How can a bank act on an intent it can’t see, signed with a credential it didn’t issue or control, with no say in how the consumer was involved in confirming the transaction, and no consequences if Gemini (and the merchant) were wrong?

Banks can’t operate like this. The issuer handles the dispute under Regulation Z (Regulation E for debit) and network rules whether or not it saw the intent.

How it works in Amex ACE

Intent Intelligence treats consumer intent the way issuers already treat a step up.

1. Capture. The agent collects the constraints and calls the Create Intent API: a purchase summary, a maximum amount of $800, an expiry date, a maximum of one transaction, optional merchant data, and an order context of type “Intent” describing the item.
2. Confirm with the issuer. The consumer authenticates and signs off on the intent, by passkey or through a third party (the agent or a wallet) only if the issuer chooses to delegate, and issuers “may require incremental data” to do so.
3. Assess and issue. The issuer runs risk assessment, can “complete an additional step up as needed,” and then issues an Intent ID and a Proof of Intent Token, a JSON Web Token carrying the intent’s high level constraints.
4. Scope the credential. The token is used to obtain a payment credential scoped to the intent: $800 cap, expiry date, single use, merchant restrictions if the consumer set them.
5. Enforce at authorization. The Intent ID and token “serve as controls” to validate that the purchase request maps to what the consumer authorized. Amex’s Hannah Bozian gave the example of a consumer asking for white Nike sneakers in size 9 and the agent submitting Adidas: Amex can stop that before money moves (TechCrunch, Oct 13, 2026).
6. Resolve disputes against the record. The issuer can “evaluate subsequent disputes against the intent confirmed by the cardholder.”

One honest caveat. The scoped credential enforces the quantitative constraints at authorization: amount, time, merchant, number of transactions. Whether the bag is ballistic nylon still depends on the cart detail the agent shares in the order context. The difference from AP2 is that the issuer sees the claim, set the rules for how the consumer confirmed it, and decides whether to approve, decline or step up. Pre release verification services like Delta Mandate fit into this model as tools the risk bearer can call, rather than assurances from the seller of the transaction.

	AP2 / Verifiable Intent	Amex Intent Intelligence (ACE)	EMVCo Draft Framework
Who captures intent	Agent platform	Agent (any platform)	Any authorized party
Who confirms with the consumer	Platform wallet	Issuer (passkey) or issuer approved delegate	Consumer signs Layer 2 on device
Who holds the record	Platform	Issuer	Intent Service Provider (payment system or card issuer named as examples)
What the issuer sees	Payment disclosures	Constraints, purchase summary, order context	Retrievable intent state
Who checks cart against intent	Platform’s agent	Issuer, at credential request and authorization	Merchant, issuer and network can retrieve and check
Who bears the error	Undefined	Issuer, backed by Agent Purchase Protection	Not yet defined

Why the Issuer Is the Right Home for Intent

Banks have a role in three things, and agentic commerce needs all three:

• Authorization. The issuer already decides yes or no on every transaction. Intent is one more input to that decision, and Amex puts it there before the agent acts.
• Taking risk. The issuer handles disputes and owns the liability shift. Amex has already put its balance sheet behind registered agents with Agent Purchase Protection (American Express Breaks the Agentic Commerce Deadlock).
• Confirming intent with the consumer. Step up is a bank job today: 3DS challenges, OTPs and now passkeys (Adios 3DS “Step Up”… Hello FIDO2).

The ACE model solves several issuer problems at once. It works across platforms and agents: Gemini, ChatGPT, Muse or a retailer’s agent all present the same kind of token against the same issuer record. It gives the issuer a single point of authorization for every agent acting on a card. The consumer can restrict amount, time and merchant name, and the issuer can add a second step up before the agent acts. Bozian says customers can edit or cancel an intent “via Amex or via their agent” (Digital Transactions, Oct 13, 2026).

It also answers part of the platforms’ data objection. The purchase summary strips personal detail: “I want to buy a flight for my mom’s birthday on July 12th” becomes “Flight on July 12th.” The issuer gets what it needs to manage risk, not the conversation.

Networks still hold the central role in standards and governance. Amex can move first because, as I wrote in April, it is the issuer, the network and the acquirer; it controls the credential, the message and the participant rules. VGS made the same point at a UBS investor event this month: Amex may find it easier to approve and provision an agentic token because it is the issuer, while Visa and Mastercard must drive adoption across a wide pool of issuers (Terry Angelos, VGS, at UBS Payments Innovation Event Series, hosted by Timothy Chiodo, Oct 5, 2026). Visa is moving in a similar direction with passkey authenticated Payment Instructions in Visa Intelligent Commerce. Amex is the first to publish an intent framework built around the issuer and offer it to the industry. It is a framework, not yet a deployed standard: Amex reports “thousands” of weekly agentic transactions across its integrations (Digital Transactions) and says it is in talks with partners to implement ACE.

Will This Add Too Much Friction?

Yes, some. My view is that this level of friction is acceptable in the early days of agentic commerce, until consumer behavior and agent actions can be modeled.

The evidence supports a gradual path. Forrester finds only 24% of US online adults trust AI to make routine purchases. Checkout.com’s June 2026 survey found 3% of transactions involve agents, and 75% of merchants say real time ability to revoke permissions is critical to adoption (both via Forkast, Sep 28, 2026). Goldman Sachs describes the likely early model as spending limit rules where “transactions exceeding a predefined amount” require consumer authentication (Eric Sheridan et al., Goldman Sachs, “Entering the Agentic AI Era for the Commerce Landscape,” Sep 24, 2026). Waller closed his speech by asking “what is the right balance between user convenience and purposeful friction in agent authorization?”

Step up is scaffolding, not the end state. 3DS followed the same path: challenges first, then risk based exemptions as data accumulated. Issuers that hold the intent record will build the models that let them stop asking. Platforms that hide intent will keep getting declines and challenges, because the issuer has nothing else to go on.

My firm view is that a version of this will make its way through EMVCo. Amex chairs EMVCo’s agentic commerce working group (Digital Transactions). EMVCo’s draft already lists the card issuer as an example Intent Service Provider and describes issuers using intent “to ensure that requests for payment credentials conform to the Payment Mandate and/or Intent Constraints,” then setting controls applied at authorization (EMVCo, “Agentic Payments: Framework for Specifications 1.0,” Draft, Aug 2026). That is the Amex model in standards language.

Longer Term: Issuer Credentials and the Apple Option

Over time, I expect issuers to have credentials they can provision to platforms for signing, as BankID does in the Nordics (BankID Norway: Evolution and Success). EMVCo’s Layer 1 is built for exactly this. The question is the container. DPCs in an authorization UC could also.

The DPAN is the proxy for identity today, and Apple holds most of it. Apple could make all of this work today across every card in Apple Pay: the key is in the Secure Enclave, the issuer ID&V is already done, and Apple Wallet already sits between the consumer and the issuer. In that model Apple sees the intent and brokers it with the issuer. That would also improve Siri’s ability, running locally, to make recommendations and manage complex agent actions across platforms and localized specialist agents. I made a version of this argument in 2025: wallets will not become the agents, but they will be the interface to all agents, brokering identity, permissions and data on the handset (Scenario: Agentic Wallets and Federated Data). Siri AI entered public beta in September. Google’s DPC push is, in part, an effort to neutralize this hardware advantage (EMVCo and DPCs).

The Fourth Model: The Walled Garden

In the fourth model, one company manages all of this inside its own walls. Amazon owns the account, the stored card, the checkout, the returns policy and the customer service. Intent never needs to leave because Amazon is the merchant, the agent and the risk bearer. Its agents act primarily within its platform, and it defends that boundary: Amazon blocked Meta’s Muse from browsing and buying on Amazon.com on September 20 (GeekWire, Sep 22, 2026). Buy for Me reaches other retailers’ sites, but on Amazon’s terms with Amazon holding the card. This model works. It just does not scale beyond the garden (Amazon vs Walmart: Two Very Different Bets on Agentic Commerce, Card VAS Tailwind: Agentic).

Model	Who holds intent	Who confirms with consumer	Who bears risk	Reach
Platform (AP2 / Verifiable Intent)	Orchestrator	Orchestrator’s wallet	Undefined	Open web, low issuer trust
Issuer (Amex ACE)	Issuer	Issuer, or its delegate	Issuer	Any agent, per card
Wallet broker (Apple)	Wallet, shared with issuer	Device bound credential	Issuer	All cards in the wallet
Walled garden (Amazon)	Merchant platform	Merchant platform	Merchant platform	Inside the garden

Where I Could Be Wrong

• Evidence is not allocation. Forkast argues that Amex’s framework “moves the evidence issuers hold, not the merchant of record loss default” (Forkast, Oct 14, 2026). If issuers outside Amex use intent data to win chargebacks rather than to take risk, the issuer’s data improves but the consumer and merchant see little change.
• Verifiable Intent may converge. Mastercard describes Verifiable Intent as “cryptographic proof of authorization that consumers, merchants, and issuers can rely on,” and its Layer 1 is signed by the credential issuer (Mastercard, Mar 2026). If EMVCo binds Layer 1 to an issuer bound credential and gives issuers access to the intent, the gap between VI and ACE narrows to who hosts the record.
• Merchants want the agent to pay. PYMNTS Intelligence found 93% of merchants believe the AI or agent provider should bear the loss when an agent makes an incorrect purchase (Forkast, Oct 9, 2026). That is my second legitimate path for the orchestrator: assume liability for its own attestation. If platforms accept it, they could keep intent and still be trusted. None has offered.
• Four party issuers may not build it. Amex moved first because it is issuer, network and acquirer. A typical bank issuer can decline low confidence agent transactions at no new cost. Building intent infrastructure and taking agent error risk needs a price, as I argued in Retail, Roles and Know Your Agent, and debit issuers face Regulation E timelines that differ from credit.
• 3DS is an imperfect precedent. European SCA was mandated by regulation. Issuer intent confirmation in the US is voluntary, and issuers that add friction can lose share to those that do not.
• Friction could stall adoption before the models exist. Apple Pay took more than a decade to reach roughly 25% of US online adults (Forkast, Sep 28, 2026). OpenAI shut down Instant Checkout in March (Explaining the Death of OpenAI’s Instant Checkout). If consumers do not tolerate a passkey per intent, platforms will route around issuers with stored credentials.
• Platforms may not send intent. Amex says it is “in talks” with partners. Google and OpenAI have little incentive to share intent with any issuer, and the walled garden may win by default.

What to Watch

1. Which agent platforms integrate the Create Intent API, and whether Google wires it into AP2.
2. Whether EMVCo’s next draft names issuers as Intent Service Providers and requires device bound Layer 1 credentials.
3. Whether Visa and Mastercard issuers adopt issuer side intent confirmation, or leave it to the network.
4. Whether Apple brings Apple Pay credentials into Siri AI agent actions.
5. Amex’s dispute data. Amex says it has not yet seen a rise in agentic disputes; the first numbers will show whether pre transaction intent works.

Bottom Line

Agents are a new party to the transaction. The rules for who carries risk are not new. The party that authorizes, takes the risk and confirms with the consumer should hold the intent. Today that is the issuer. Amex has published the first model that gives the issuer that role and lets intent flow from the issuer to any agent. Expect EMVCo to follow, and expect Apple to be the platform that can make it work at scale.