AI Agents & Programmable Money

A valve manufacturer has an AI agent reorder consumables: seals, abrasives, test gas. The agent compares offers, builds the shopping cart and pays the dealer with a card token. Alongside, it queries an interface with commodity prices for demand planning, which charges a few cents per request in a stablecoin. The example is invented, but both payment routes already exist. For the CFO, the same question arises twice, namely who approved these payments and where their limit lies.

Payment Law Has No Agent

A payment transaction is effective against the payer only if the payer has consented to it (section 675j(1) of the German Civil Code). How consent is given is agreed between the payer and the payment service provider. The European basis, the Payment Services Directive PSD2, also allows consent to be given via the payee or a payment initiation service (Article 64(2)). None of these provisions knows an agent as a role of its own. The new Payment Services Regulation (PSR), on which Council and Parliament reached political agreement in November 2025, does not regulate it either. Its text mentions artificial intelligence only for fraud detection, and it has not yet been adopted (as of October 2026).

The payer therefore remains the company. Whether a payment that its agent triggers with the company's credentials counts as consented to is not stated explicitly in any provision. It depends on the agreement with the bank and belongs in a legal review before an agent is given a means of payment. What the bank requires, on the other hand, is clear. When the payer initiates an electronic payment, strong customer authentication is needed (Article 97 PSD2). It combines two independent elements of knowledge, possession and inherence. An agent meant to pay without a human therefore needs a route on which this check takes place beforehand or elsewhere.

The Limit Sits in the Payment Instruction

Providers of payment routes for agents solve the approval problem in similar ways. Google's Agent Payments Protocol (AP2) works with a payment mandate signed by the user. It can set the permitted payees, an amount range and a total budget. Under the Agentic Commerce Protocol of OpenAI and Stripe, the agent receives a payment token. It is limited to one merchant and one cart value and can be used only once. Visa and Mastercard presented their own tokens for agents in April 2025. Coinbase offers wallets for agents with caps per session and per payment; according to its documentation, the agent cannot change these limits. Many of these schemes are still being trialled (as of October 2026).

The common pattern is a separation. The agent decides within a frame that a human has set beforehand, and the means of payment itself carries this frame. If the agent exceeds it, the payment is refused not by the agent but by the token or the wallet. What gets checked is thus no longer each individual payment but the setting of the frame. Where such a rule sits and who can still change it afterwards is covered in Programmability of Digital Money.

x402: Paying in the Protocol of the Web

For the second case in the example, the price interface, there is a separate approach. x402 uses the HTTP status code 402 "Payment Required". The server answers a request with this code and states its payment terms. The client sends the request again, with a signed payment in the request header. A service provider, the so-called facilitator, verifies the payment and executes it on the blockchain, for example in USDC. Coinbase contributed the protocol. Since 14 July 2026 it has been held by a foundation under the umbrella of the Linux Foundation.

In the scheme for Ethereum-compatible networks, the network fee is borne by the facilitator, not the payer. How to post a fee that a third party takes over is covered in Posting, Valuation & Tax. More important for the CFO is one sentence in the specification. x402 expressly leaves budgets and spending limits to the implementation. Anyone who lets an agent pay via x402 therefore has to build the limit themselves, in the wallet or in front of it.

A List the Law Already Knows

The idea of approving the frame instead of the individual payment is not new in payment law. The regulatory technical standards on strong customer authentication, Delegated Regulation (EU) 2018/389, provide for a list of trusted beneficiaries. The bank may pay beneficiaries on this list without strong authentication (Article 13). Whoever creates or amends the list, however, must authenticate strongly. For companies there is a second exemption (Article 17). It covers secure payment processes that are open only to non-consumers, where the supervisory authority considers them at least equally secure.

The law thus places the human at the same point as the agent protocols do, at the change to the list and not at the individual payment. Applied to the example, the agent pays only dealers that purchasing has approved. Adding a new dealer remains an act by a human, with strong authentication.

Where the Risk Lies

The first risk is liability. For consumers, the law caps the loss from an unauthorised payment (section 675v of the German Civil Code). For businesses, bank and customer can exclude this rule in whole or in part (section 675e(4)). Whether the company's own contract with its bank contains such an exclusion is something the CFO should know before an agent pays.

The second risk is manipulation. An agent reads websites, offers and files, and this content can steer it. The OWASP list of risks for applications using large language models puts this prompt injection first in its 2025 edition. That includes the indirect form via external content. A doctored offer could lead an agent to pay a different payee. What helps against this is not an instruction to the agent but a limit it cannot change: the payee list in the mandate or in the wallet.

The third risk is identity. A merchant sees a request, but not whose agent is making it. A guest article at a16z crypto called this gap "Know Your Agent" in January 2026, by analogy with customer due diligence (KYC). In October 2025, Visa presented the Trusted Agent Protocol, an approach with which an agent proves its identity cryptographically. Whether one of these approaches will prevail is open.

The Mandate as Proof of Approval

In the accounts, every payment by an agent remains a payment by the company, with a voucher, an account and a cost centre. What is new is what counts as approval. Until now, a human signed off the individual order or the payment run. With an agent, the human signs off the frame: a mandate with payees, amount range and budget, signed and time-limited. The four-eyes principle thus moves from the payment to the mandate.

For audit, the question shifts accordingly. It is no longer who approved a payment, but under which mandate it ran and who signed that mandate. This can only be answered if every payment carries the identifier of its mandate through to the posting. Today the invoice number travels the same way in the remittance information. How a payment carries its reference into reconciliation is covered in Reconciliation & Payment Flows.