{
"slug": "bankers-guide-agentic-commerce-happens-ai-bots",
"topic_id": "TOPIC-021",
"cluster": "Agentic Commerce & MCP Tool-Call Gating",
"tier": "Tier B",
"title": "A banker's guide to agents holding payment credentials",
"summary": "When software initiates a card transaction on a customer's behalf, three long-settled questions reopen: who authorised it, who bears the loss, and what evidence resolves the dispute.",
"lede": "Card networks spent forty years building rules around a reasonably stable fact: a person initiates a transaction. Agentic commerce changes the initiator without changing the rulebook underneath it, and the gap is where the disputes will land.",
"date": "2024-05-24",
"category": "Future of Work",
"author_id": "margot-reyes",
"tags": [
"agentic commerce",
"card networks",
"chargebacks",
"liability",
"payments",
"banking"
],
"image_title": "Agents Holding Payment Credentials",
"schema": "Article",
"key_takeaways": [
"Existing dispute rules classify transactions by how they were initiated. Agent-initiated transactions do not map cleanly onto those categories.",
"Authentication frameworks were designed around a cardholder present at a device. An agent transacting on the cardholder's behalf satisfies the mechanism without the assurance.",
"The evidence that resolves an agent dispute — what the human authorised, in what scope — is not currently captured by anyone in the chain."
],
"body": [
{
"type": "h2",
"text": "The three reopened questions"
},
{
"type": "diagram",
"kind": "chain",
"alt": "Three positions, and why only one works",
"caption": "The third is correct and requires a record nobody keeps.",
"nodes": [
{
"label": "Cardholder authorised it",
"sub": "by deploying the agent",
"note": "kills confidence",
"bad": true
},
{
"label": "Cardholder did not",
"sub": "the agent did",
"note": "merchants decline",
"bad": true
},
{
"label": "It depends on the scope granted",
"sub": "",
"note": "needs a record",
"good": true
}
]
},
{
"type": "table",
"head": [
"Question",
"Settled answer for human transactions",
"Status for agent transactions"
],
"rows": [
[
"Who authorised it?",
"The cardholder, present or on file",
"The cardholder authorised the agent, at some earlier time, in some scope"
],
[
"Who bears an unauthorised loss?",
"Allocated by initiation type and authentication status",
"Unclear — depends on whether agent action counts as cardholder action"
],
[
"What evidence resolves it?",
"Authentication data, device signals, transaction history",
"No standard artefact exists"
]
]
},
{
"type": "p",
"html": "The third row is the practical problem. Liability allocation rules can be written; they are being written. They will allocate loss based on evidence that nobody is currently generating."
},
{
"type": "h2",
"text": "Why strong authentication does not settle it"
},
{
"type": "p",
"html": "Authentication frameworks confirm that the cardholder authenticated. In an agent flow the cardholder did authenticate — when they set the agent up, days or weeks earlier."
},
{
"type": "p",
"html": "So the check passes and tells you nothing about this transaction. The mechanism is intact; the assurance it was meant to carry has been separated from the moment it mattered."
},
{
"type": "p",
"html": "This is the same scope-versus-instance problem that appears everywhere in agent authorisation, arriving in a payments vocabulary."
},
{
"type": "h2",
"text": "The dispute that has no good resolution"
},
{
"type": "p",
"html": "A cardholder contests a transaction their agent initiated. Three positions are available and none of them is satisfying."
},
{
"type": "ol",
"items": [
"The cardholder authorised it — by deploying the agent. This makes every agent transaction final regardless of whether the cardholder would have wanted it, and destroys consumer confidence in the channel.",
"The cardholder did not authorise it — the agent did. This makes agent transactions uniformly disputable, which merchants will respond to by declining them.",
"It depends on scope — the cardholder authorised transactions of this kind within these bounds. This is correct and requires a record of the scope, which does not exist."
]
},
{
"type": "p",
"html": "Position three is where the industry will end up. The question is how many years of positions one and two happen first."
},
{
"type": "h2",
"text": "What a scope record has to contain"
},
{
"type": "code",
"text": "delegation {\n principal: cardholder, authenticated with user verification\n agent: [agent identity]\n scope: card_purchase\n merchants: [category or explicit list]\n per_txn_max: 250.00 USD\n aggregate_max: 2000.00 USD / calendar month\n not_after: 2026-03-31\n revocable: yes, effective immediately\n}\nsigned by the cardholder's authenticator\n→ each agent transaction references this delegation\n→ issuer or merchant can verify the transaction falls inside it"
},
{
"type": "p",
"html": "Given that, the dispute becomes arithmetic. Inside the scope: authorised, and the cardholder's recourse is against the agent provider rather than the merchant. Outside it: unauthorised, and the loss sits with whoever accepted a transaction that did not verify."
},
{
"type": "h2",
"text": "What each party should be doing now"
},
{
"type": "table",
"head": [
"Party",
"Action"
],
"rows": [
[
"Issuers",
"Decide how agent-initiated transactions are flagged and what evidence you will require in a dispute — before the volume arrives"
],
[
"Acquirers and merchants",
"Establish whether you can distinguish agent-initiated transactions at all; most currently cannot"
],
[
"Agent providers",
"Capture and retain the cardholder's scope grant in a form a third party can verify without calling you"
],
[
"Corporates deploying agents",
"Bound spend at the credential, not in the agent's instructions, and keep the grant"
]
]
},
{
"type": "h2",
"text": "The commercial argument for doing it early"
},
{
"type": "p",
"html": "Not compliance. Acceptance."
},
{
"type": "p",
"html": "A merchant facing a transaction class with elevated dispute risk and no evidentiary defence will decline it or price it punitively. An agent channel that arrives with a verifiable scope record attached gets accepted; one that arrives as an unidentifiable card-not-present transaction gets treated as fraud risk."
},
{
"type": "p",
"html": "The party that solves evidence first makes their agent channel the one merchants accept. That is worth more than avoiding a chargeback."
},
{
"type": "h2",
"text": "A caution on numbers"
},
{
"type": "p",
"html": "Projections of agentic commerce volume vary by an order of magnitude depending on what counts as an agent transaction — whether a saved-card recurring charge or a shopping assistant's recommendation is included. Treat any single figure with suspicion. The structural argument does not depend on the volume being large, only on the disputes being unresolvable."
},
{
"type": "h2",
"text": "What each party should do now"
},
{
"type": "table",
"caption": "Before the volume arrives",
"head": [
"Party",
"Action"
],
"rows": [
[
"Issuers",
"Decide how agent-initiated transactions are flagged and what evidence a dispute requires"
],
[
"Acquirers and merchants",
"Establish whether you can distinguish agent-initiated transactions — most cannot"
],
[
"Agent providers",
"Capture the cardholder's scope grant so a third party can verify it without calling you"
],
[
"Corporates",
"Bound spend at the credential rather than in the agent's instructions"
]
]
},
{
"type": "h2",
"text": "Objections and honest limits"
},
{
"type": "p",
"html": "“Strong customer authentication covers it.” It confirms the cardholder authenticated at setup, weeks before the purchase. The mechanism passes and carries no assurance about this transaction."
},
{
"type": "p",
"html": "“The market is too small to matter yet.” Estimates vary by an order of magnitude depending on what counts as an agent transaction. The dispute problem exists at any volume, and the infrastructure decisions are being made now."
}
],
"faq": [
{
"q": "Do existing card rules cover agent transactions?",
"a": "They classify transactions by initiation type, and agent initiation does not map cleanly onto the existing categories. Network rules are being updated; the evidence needed to apply them is not being generated."
},
{
"q": "Does strong customer authentication help?",
"a": "It confirms the cardholder authenticated at setup, which is weeks before the transaction. The mechanism passes and carries no assurance about the specific purchase."
},
{
"q": "Who should hold the scope record?",
"a": "It should be verifiable by any party in the chain without calling the agent provider. A signed delegation the cardholder can revoke and the issuer can check is the shape that works."
},
{
"q": "How large is this market?",
"a": "Estimates vary by an order of magnitude depending on what counts as an agent transaction. The dispute problem exists at any volume."
},
{
"q": "Why does solving evidence first matter commercially?",
"a": "Merchants will accept an agent channel carrying verifiable delegation and price an unattributable one as fraud risk."
}
],
"sources": [
{
"t": "Visa — security and trust perspectives on agentic commerce",
"u": "https://corporate.visa.com/en/sites/visa-perspectives/security-trust.html"
},
{
"t": "Regulatory technical standards on strong customer authentication and exemptions."
},
{
"t": "CISA — known exploited vulnerabilities and incident reporting",
"u": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog"
},
{
"t": "Industry commentary on agent-initiated payment liability."
}
],
"related": [
{
"slug": "consumer-mandate-receipt",
"title": "Visa made cardholders responsible for their agents",
"category": "Vertical"
},
{
"slug": "mastercard-verifiable-intent-vs-manav-deconstructing-sd-jwt",
"title": "Payment envelopes versus rendered statements",
"category": "Comparison"
},
{
"slug": "my-agent-did-defense-businesses-will-dispute",
"title": "The 'my agent did it' defence",
"category": "Future of Work"
},
{
"slug": "skyfire-catena-labs-agent-payment-stacks-cannot-own",
"title": "An agent payment rail cannot also be the accountability layer",
"category": "Comparison"
}
],
"image": "https://cdn.twc.sh/images/igcache/Agents%20Holding%20Payment%20Credentials/1200_630/blog.jpg",
"wordcount": 939,
"url": "/blog/bankers-guide-agentic-commerce-happens-ai-bots.html",
"reading_time": "4 min read",
"meta_description": "When software initiates a card transaction for a customer, three settled questions reopen: who authorised it, who bears the loss, what proves it.",
"hub": {
"slug": "topics/agent-tool-call-gating",
"title": "Agent tool-call gating"
},
"answer": "Nobody knows yet, and the rules are being written faster than the evidence. Dispute frameworks classify transactions by how they were initiated, and agent initiation maps onto none of the existing categories. The scope the cardholder actually granted is recorded by nobody.",
"answer_q": "Who bears the loss when an AI agent's card transaction is disputed?",
"glossary": [
{
"term": "Initiation type",
"def": "How a transaction was started, which is how dispute rules classify and allocate loss."
},
{
"term": "Scope grant",
"def": "A signed delegation stating what an agent may spend, where, and until when."
},
{
"term": "Acceptance",
"def": "Whether merchants will take the transaction — the real constraint, and it follows evidence."
}
],
"checklist": {
"title": "Preparing for agent disputes",
"id": "prepare",
"desc": "Four steps.",
"steps": [
{
"name": "Flag agent-initiated transactions.",
"text": "Most acquirers cannot distinguish them today."
},
{
"name": "Require a verifiable scope grant.",
"text": "Signed by the cardholder, checkable by issuer and merchant."
},
{
"name": "Define what evidence resolves a dispute.",
"text": "Before the volume arrives."
},
{
"name": "Treat acceptance as the goal.",
"text": "Evidence is what makes merchants take the channel."
}
]
},
"cta": {
"title": "Where this fits in Manav",
"html": "Manav issues the cardholder's scope grant as a signed, revocable delegation with ceilings and expiry, verifiable offline by the issuer, the merchant or a court.",
"href": "../docs.html",
"label": "See delegation chains"
}
}