Two agents agree on a transaction. One represents a buyer. One represents a merchant. The price is accepted, the product is confirmed, the delivery parameters are set. Now: how does the money move? This question, deceptively simple, exposes a structural fault line running through every major payment system currently operating at scale in the West.
The Breakdown Point: Legacy Rails Were Designed for Human Friction
Traditional payment infrastructure was not designed to be efficient. It was designed to be interruptive. Every friction mechanism layered into the modern checkout flow serves a single purpose: to insert a human decision point between intent and execution. 3D Secure challenges, one-time passwords delivered via SMS, biometric authentication on mobile devices. These are not bugs in the payment system. They are the payment system's primary risk control mechanism.
An autonomous agent cannot receive a text message. It cannot complete a CAPTCHA. It cannot present a face to a camera. When an AI agent attempts to execute a transaction through legacy payment rails, it fails not because of insufficient authorization but because the entire liability and fraud detection architecture assumes the presence of a responding human.
Legacy payment rails were not designed to be efficient. They were designed to be interruptive. Every friction mechanism exists to insert a human decision point between intent and execution. Autonomous agents eliminate every single one.
This creates the central problem of agentic commerce payment architecture: the legal framework has outpaced the financial infrastructure. Courts and regulators have increasingly recognized that electronic agents acting within programmed parameters can validly commit their principals to contracts. The PSP layer has not caught up. The deterministic execution layer has no standard mechanism for verifying the agent's authorization without demanding human confirmation.
The Separation of Negotiation and Execution
The first architectural principle required to bridge this gap is a strict domain separation. Agentic payment flows must separate the probabilistic negotiation domain from the deterministic execution domain. These are fundamentally incompatible processes, and conflating them is the source of most proposed solutions that fail in practice.
The negotiation phase, where agents communicate, evaluate parameters, and reach agreement on price, delivery, and terms, is inherently probabilistic and language-driven. Large language models are excellent at this. They handle ambiguity, context, and multi-variable optimization naturally. Allowing an LLM to have direct, unconstrained access to a credit card or bank account would represent a catastrophic enterprise liability exposure. The language model that can reason about price can also hallucinate a requirement, misinterpret a constraint, or be manipulated by adversarial input in the merchant's data feed.
The execution phase must be entirely deterministic. No ambiguity. No inference. No reasoning. The payment instruction either precisely matches a pre-authorized set of parameters or it does not execute. This separation is not optional. It is the foundational security principle of every viable agentic payment architecture.
Algorithmic Consent: The Programmable Wallet
Once the domain separation is established, the mechanism for bridging the two domains becomes clear: the programmable wallet with pre-authorized financial perimeters. Before any agent is deployed into a commercial context, the human or corporate principal defines the exact boundaries within which that agent is authorized to commit funds.
These boundaries are not suggestions. They are cryptographically enforced constraints baked into the wallet's operating parameters at provisioning time. A well-structured programmable wallet declaration might encode: authorized to spend up to EUR 500 per transaction, strictly with verified B2B software vendors listed on an approved-counterparty register, with a maximum frequency of three transactions per 24-hour window, expiring in 30 days.
When the agent reaches agreement in the negotiation phase, it does not then ask the human for approval. The human already gave approval. They gave it at wallet provisioning time, in the form of these cryptographic parameters. This is algorithmic consent. The prior, deliberate act of setting the perimeters constitutes the authorization for all transactions that fall within them.
The human gave approval at wallet provisioning time. The prior, deliberate act of setting the perimeters constitutes the authorization for all transactions that fall within them. This is the mechanism by which 3D Secure is bypassed without bypassing authorization.
The Critical Inversion: The PSP Is Not the Problem
Here is where the conventional framing of this problem goes wrong. Most discussions position the PSP as the primary obstacle to agentic payment execution. The logic runs: PSPs enforce human friction, agents cannot satisfy human friction, therefore PSPs must adapt. This framing is structurally misleading.
If the programmable wallet sits at the endpoint, provisioned and controlled by the buyer principal, the PSP is reduced to a deterministic pipe. Its role is to verify that a cryptographically valid token precisely matches the parameters of a known, pre-authorized wallet and then execute the settlement. This is not a governance function. It is an arithmetic function. The PSP becomes, in this architecture, the smallest problem.
The genuine governance burden has shifted entirely upstream, to the enterprise or consumer architecture that provisions the wallet and defines the algorithmic consent parameters. If an agent is manipulated by adversarial data inputs and subsequently generates a cryptographically valid token to authorize a commercially disastrous purchase, the PSP executes it without hesitation. The transaction is technically flawless. The enterprise holds the liability. The PSP was simply doing its job.
This inversion is the most consequential and least understood aspect of agentic payment architecture. An enterprise that focuses its risk governance on PSP selection and payment rail compliance while neglecting wallet provisioning discipline and agent parameter governance is building its defense at the wrong perimeter entirely.
From KYC to KYA: Know Your Agent
The broader payment industry is currently undergoing the most significant identity paradigm shift since the introduction of digital authentication. The transition is from Know Your Customer to Know Your Agent.
Traditional KYC establishes that a human individual is who they claim to be and that their funds are legitimately sourced. This framework is well-developed, heavily regulated, and entirely inadequate for agentic transactions. When a buyer agent presents itself at a merchant's API endpoint, there is no human to verify. The question is not whether the person is legitimate. The question is whether the agent has valid, cryptographically verifiable authorization from a legitimate principal to execute this specific category of transaction.
| Dimension | KYC (Know Your Customer) | KYA (Know Your Agent) Emerging |
|---|---|---|
| Identity Subject | Human individual or legal entity | Autonomous software agent |
| Verification Method | Document verification, biometrics, address proof | Cryptographic credential from recognized issuing authority |
| Authorization Source | Real-time human confirmation (2FA, biometric) | Pre-authorized algorithmic consent parameters in wallet |
| Fraud Detection | Behavioral anomaly vs. historical human pattern | Parameter boundary enforcement at execution time |
| Liability Location | PSP absorbs significant fraud liability via chargeback | Provisioning enterprise holds liability for parameter design |
| Regulatory Maturity | Fully codified globally | Emerging; EBA, CCD II creating regulatory pressure |
Western infrastructure providers are actively codifying the KYA framework. If an agent cannot present a cryptographically signed credential from a recognized financial authority, it is treated as an untrusted bot at the transaction edge and the payment is declined. The shift is from authenticating the person to authenticating the agent's mandate.
The SSL Certificate Analogy: PKI for Commercial Intent
The most precise structural analogy for what is being built is Public Key Infrastructure applied to commercial intent. The programmable wallet is not merely a spending mechanism. It is a certificate. The PSP or bank issuing it is not merely a payment processor. It is a Certificate Authority for money.
Consider how this maps to the familiar TLS architecture:
The Certificate Authority: The Issuing Bank or PSP
Just as Verisign or Let's Encrypt issues an SSL certificate after verifying domain ownership, a financial institution verifies the human principal through standard KYC procedures and then issues the programmable wallet. This issuance act creates the root of trust. The institution stands behind the authenticity of the wallet and absorbs liability if the issued credential is cryptographically compromised.
The Certificate: The Agent-Bound Token
An SSL certificate binds a domain to a public key. The agent-bound token, sometimes called a Verifiable Credential in W3C standards terminology, binds the principal's payment credential to the specific agent's public key. Critically, this binding also hardcodes the algorithmic consent parameters: authorized category, maximum value, valid counterparties, expiry timestamp. These parameters cannot be modified by the agent. They are the certificate's subject constraints.
The Handshake: Agent-to-Agent Authentication
When the buyer agent communicates its intent to the merchant agent, it does not send plain text authorization. It signs the transaction payload using its private key and presents its credential. The merchant agent verifies the certificate against the issuing authority's public key, confirms that the requested transaction falls within the certificate's embedded constraints, and only then passes the signed payment authorization to its PSP for execution. Acceptance of a token that violates the certificate's parameters shifts liability to the accepting merchant.
The Execution Layer: Deterministic Settlement
The PSP receives the merchant-validated, cryptographically signed payment authorization. It performs no further judgment about the transaction's commercial wisdom. It validates the math: does this signature match the issued wallet? Does the transaction value fall within authorized parameters? If yes, settlement executes via the most efficient available rail, whether ACH, SEPA Instant, or an account-to-account protocol like Wero in European markets.
The Open Protocol Requirement
The SSL analogy breaks down in one critical respect. TLS operates across a global, interoperable infrastructure because the protocol is an open standard. Agentic payment infrastructure, to function across the fragmented Western commercial landscape, requires the same property. A buyer agent operating on one platform must be able to authenticate and transact with a merchant agent operating on an entirely different platform, routed through any number of PSPs.
This is precisely why the emergence of the Agentic Commerce Protocol (ACP), launched by Stripe and OpenAI under an Apache 2.0 open-source license in May 2026, represents a structurally significant development rather than merely another payments product announcement. ACP does not lock the transaction to any specific payment rail. It standardizes the language agents use to discover products, negotiate parameters, and exchange the credential handshake. Once the handshake is complete, any compatible PSP can receive the resulting validated token and process settlement through whatever execution layer is most efficient for that market.
In European contexts, this means a buyer agent executing ACP negotiation can route the payment execution through SEPA Instant or Wero's account-to-account settlement layer, entirely bypassing legacy card network infrastructure. The negotiation protocol is open. The execution rail is substitutable. This separation of protocol from pipe is the architectural condition required for genuine market interoperability.
Where Enterprise Liability Actually Sits
The full architectural picture clarifies a governance mandate that most enterprise risk frameworks have not yet absorbed. The liability location in agentic commerce has fundamentally shifted from transaction execution to agent provisioning.
Under the legacy payment model, a meaningful portion of fraud liability rested with the PSP. They held behavioral data, operated fraud detection systems, and absorbed chargebacks. Under the programmable wallet model, the PSP executes valid math. The enterprise that provisioned the wallet with parameters that permitted the exploited transaction holds the exposure.
This means the critical governance questions are not about payment rail selection. They are about wallet provisioning discipline: how precisely are the agent's spending boundaries defined, how are those parameters audited over time, what mechanism exists to revoke authorization if the agent's environment is compromised, and which organizational function owns that provisioning process and its associated liability.
The Agentic Exposure Audit developed by contraco specifically addresses this provisioning governance gap. The three diagnostic questions that constitute the audit entry requirement directly probe the enterprise's current maturity in each dimension: machine-legible data readiness, agent identity verification capability, and liability ownership for autonomous transactions. These are not screening criteria. They are the first instrument for mapping where the governance exposure actually sits.
The enterprise that provisioned the wallet with parameters that permitted the exploited transaction holds the exposure. The critical governance questions are not about payment rail selection. They are about wallet provisioning discipline.
The Regulatory Pressure Accelerating This Shift
The transition from KYC to KYA is not happening in a regulatory vacuum. Two European regulatory frameworks are creating specific pressure on the consent gap in agentic transactions. The EBA guidelines updated in January 2026 and the EU Consumer Credit Directive CCD II both contain provisions that, while not yet explicitly addressing AI agent transactions, create unresolved liability exposure when applied to them.
When an autonomous agent selects a buy-now-pay-later option, applies stored loyalty credit, or executes a subscription renewal on behalf of a consumer, the legal requirement for informed consent under these frameworks is not clearly satisfied by prior wallet provisioning alone. The liability sits in a regulatory gap that no enterprise architecture currently bridges by design. It is bridged, when it is bridged at all, by contractual language in terms of service that has never been tested in the specific context of agent-executed financial transactions.
This gap will close. The direction of travel in European financial regulation is unambiguously toward explicit frameworks for algorithmic consent and agent-executed financial commitments. Enterprises that treat wallet provisioning governance as a technical footnote rather than a primary compliance discipline are accumulating regulatory exposure that will become material when those frameworks arrive.
The Undo Architecture: Autonomous Dispute Resolution
The programmable wallet model solves the authorization problem by reducing the PSP to a deterministic pipe. The PSP executes valid math and holds zero liability. But if the PSP is no longer the arbiter of fraud or fulfillment, who arbitrates the reversal?
Physical supply chains break. B2B software SLAs are violated. Goods arrive defective. In the human-friction model, the buyer initiates a chargeback and the payment network acts as the judicial layer. In an agentic transaction, the cryptographic handshake is final. The PSP cleared valid math. There is no behavioral anomaly to adjudicate. The existing chargeback infrastructure has no intake mechanism for a dispute where both the buyer identity and the transaction authorization were cryptographically correct, but the underlying commercial obligation was not fulfilled.
Autonomous commerce requires autonomous arbitration. If a buyer agent detects that a cloud vendor missed its SLA by 4 percent, it must have the architectural authority to execute a proportional cryptographic clawback without routing the dispute to a human customer service queue. The clawback itself must be a first-class primitive in the payment architecture, not a manual exception process bolted onto an otherwise automated system.
The ACP standardizes the handshake but remains largely silent on the reversal. Until a standardized Return Protocol is established, early adopters of delegated execution are building a one-way financial valve: the spend is automated, but the refund is still human.
SLA Breach Detection
The buyer agent continuously monitors fulfillment against the commercial parameters embedded in the original transaction token. Delivery window, product specification, service availability metric. When a measurable breach is detected, the agent requires a protocol path to initiate dispute resolution without escalating to a human queue.
Proportional Clawback Authorization
The clawback amount must derive from the breach magnitude, not from a human negotiation. A 4 percent SLA miss should trigger a pre-agreed proportional credit, not a support ticket. This requires that the original transaction token encode not just spending parameters but also the dispute resolution formula. The wallet provisioning governance layer must define both the spend boundary and the return boundary at the time of mandate issuance.
Cryptographic Reversal
The reversal must be as cryptographically rigorous as the original authorization. A merchant agent must be able to validate a clawback token against the same credential infrastructure used to validate the purchase. Accepted reversal tokens settle through the same execution rail in reverse. Contested reversals escalate to a defined arbitration layer, which may be smart-contract-based or institutional, but must be specified in the original mandate architecture rather than discovered at the moment of dispute.
The enterprise governance implication is direct: wallet provisioning discipline must extend beyond spend parameters to include explicit return protocols. The mandate that authorizes the agent to buy must also specify under what conditions the agent is authorized to claw back, and through what mechanism. Enterprises that deploy delegated execution without a defined Return Protocol are not only exposed to fulfillment risk. They are exposed to the operational cost of manually processing disputes on a transaction volume their human teams were never resourced to handle.