A large-scale autonomous billing ecosystem for an international fintech organization operating in the B2B payments sector.
The card networks are building the infrastructure, and the first production deployments are here. The harder question is who controls what an AI agent is allowed to do with money.
A year and a half ago, "an AI agent paid for it" was a demo. Today Visa, Mastercard, Google, and Stripe have introduced protocols and infrastructure for agentic payments. In August 2026, Coupa reported that a payment agent had assembled 2,395 supplier payments worth $20.1 million in five weeks.
What has not moved as fast is the answer to the question every payments team eventually asks: if the agent does something the customer did not mean, who stops it, and who pays?
Traditional payment authorization assumes that a person stands behind a transaction. An agent introduces a probabilistic decision-maker between the person and the payment. The customer authorizes a goal; the agent chooses the actions to achieve it.
The industry is converging on one principle: the agent may decide, but it must not be the system that checks its own authority.
Identity, spending mandates, payment credentials, and transaction controls must remain outside the agent's ability to change them. Working components now exist. Liability, disputes, and the limits of delegated consent remain much less settled.
Fintech teams need to define which payment tasks agents can handle automatically, which require human approval, and which actions the system must block.
Why agentic payments change authorization
An IMF note published in April 2026 describes agentic payments through three layers:
| Layer | Function | Nature |
| Intent and orchestration | The agent interprets the user's goal, compares options, and proposes actions | Probabilistic |
| Control and authorization | Rules determine whether a proposed action is permitted | Deterministic |
| Payment execution and settlement | Authorized transactions move through payment infrastructure | Rule-governed |
The distinction matters because the first layer can make mistakes the other two cannot afford to treat as authorization.
A customer might tell an agent to keep office supplies stocked under $500 a month. The agent decides which products to purchase, from whom, and when. Even if it stays within the spending limit, it might select an unsuitable product or a fraudulent merchant.
A technically valid transaction is not necessarily one the customer intended.
That ambiguity reaches into payment regulation. In July 2026, HM Treasury's consultation on modernizing payment services regulation explicitly asked whether existing rules on authentication, consent, and liability for unauthorized transactions need to change for agentic payments. The consultation closed on 6 October; the underlying questions remain.
The architectural response is to separate what the agent wants to do from what the payment system will allow it to do.
The four controls behind agentic payments
Across the competing protocols, four building blocks recur. Each answers a different question.
| Control | Question | Industry examples |
| Agent identity | Is this a known agent, and who is responsible for it? | Visa Trusted Agent Protocol; Mastercard Agent Pay |
| Mandate | What did the customer actually authorize? | Google's AP2; Mastercard and Google's Verifiable Intent |
| Scoped credential | Which payment capabilities can this agent use? | Mastercard Agentic Tokens; Stripe Shared Payment Tokens; agent cards |
| Runtime control | Is this particular action permitted right now? | MAS Safeguards for Agentic Finance at Runtime (SAFR) |
These are different controls, not interchangeable solutions.
An identified agent may still lack permission to purchase something. A valid mandate does not make an unrestricted payment credential safe. And a transaction that was permitted yesterday may require additional approval today.
The most important control is the last one: checking each proposed action immediately before execution.
The Monetary Authority of Singapore's SAFR framework, developed with industry participants, proposes a runtime governance architecture that establishes agent identity, checks actions against the user's mandate, and records the resulting decisions.
The framework describes four possible outcomes: deny, escalate to a human, execute, or execute and flag for monitoring.
On 9 October 2026, MAS confirmed that SAFR Version 1.1 and an open-source reference implementation were available for industry experimentation. SAFR is a reference framework, not binding regulatory guidance, but it provides one of the clearest published models for controlling agent autonomy.
Its significance is not the number of components. It is where control resides.
An agent can request a transaction and receive the result of an authorization check. It cannot rewrite the policy that rejected its request.
What Visa, Mastercard, Google, and Stripe have actually built
The industry's protocols approach agentic commerce from different directions.
Visa: identifying agents and connecting protocols. The Trusted Agent Protocol, developed with Cloudflare, helps merchants distinguish recognized agents from ordinary bots using cryptographic verification. Visa's Intelligent Commerce Connect, announced in April 2026, aims to let merchants accept payments initiated through different agentic commerce protocols using a single integration. It was introduced in pilot rather than as a universally deployed standard.
Mastercard: limiting credentials and recording intent. Mastercard Agent Pay uses Agentic Tokens to support agent-mediated payments with controlled payment credentials. Its Verifiable Intent initiative, co-developed with Google, is designed to create tamper-resistant evidence connecting the customer's authorization to the agent's resulting purchase.
Google: proving what the customer authorized. The Agent Payments Protocol (AP2) uses digitally signed mandates to make delegated authorization verifiable. Google's Universal Commerce Protocol (UCP) addresses the broader interaction between shopping agents and merchants. In April 2026, Google contributed AP2 to the FIDO Alliance, an important step toward interoperability rather than dependence on one platform.
Stripe: completing checkout with restricted payment access. The Agentic Commerce Protocol, developed with OpenAI, supports purchases initiated through AI interfaces. Stripe's Shared Payment Token is designed to let an authorized agent complete a purchase without exposing a reusable, unrestricted payment credential.
These initiatives solve different parts of the same problem. None, by itself, settles who is liable when the agent makes an unwanted purchase.
For a fintech team, the implication is practical: build around enforceable permissions and payment controls, not around whichever agentic commerce protocol appears likely to win.
The external standards may change. The platform's responsibility to verify authority, protect credentials, and record transactions will remain.
What production examples tell us about autonomy
The clearest evidence of how companies are managing agentic payments comes from the boundaries they place around their own agents.
Coupa: $20.1 million in payments, but who released the funds?
On 20 August 2026, Coupa reported that its Payment Batch Creation Agent had processed 14 payment batches containing 2,395 payments worth $20.1 million in its first five weeks in production.
That is a meaningful operational workload. But the crucial question is what "processed" means.
Contemporaneous reporting explained that a human or separate system still approves the release of funds. Coupa's own announcement described autonomous batch creation without fully specifying that final approval boundary.
Both statements can be true. Preparing a payment batch and authorizing money to leave an account are different actions.
For anyone evaluating an agentic payment product, that distinction matters more than the headline transaction volume.
Mercury: spending power without administrative power
Mercury's agent cards provide an unusually clear example of separation of privileges.
A human creates a virtual card, assigns it to an agent, and sets spending limits. The agent can retrieve the assigned card's credentials and make purchases.
But Mercury's documentation states that the agent cannot create agent cards, increase their limits, unfreeze them, or retrieve credentials for cards it has not been assigned.
The agent has spending authority, but no authority to expand that spending power.
Mercury also makes an important commercial boundary explicit: businesses remain responsible for their agents' transactions, including purchases that fall outside what the business intended the agent to do.
Technical restrictions reduce the exposure. They do not eliminate the liability question.
Ramp: narrowing what an agent can spend
Ramp's agent card approach follows a similar pattern. Its April 2026 early-access offering described transaction caps, merchant restrictions, and limited-use credentials, with funding and approvals established through company-controlled settings.
The common design across Mercury and Ramp is more important than their implementation differences.
The agent receives a defined financial capability. Administrative control over that capability remains elsewhere.
This is ordinary access management, applied to an actor that can execute financial tasks without waiting for a human instruction at every step.
What this looks like inside a business banking app
Consider an SMB neobank building an AI assistant to manage recurring supplier payments.
The customer wants the agent to pay approved invoices automatically, but not to change spending limits or send money to an unfamiliar beneficiary.
A workable architecture separates the workflow into five steps.
1. The customer defines the mandate. An authorized administrator permits payments to approved suppliers, with a $500 per-transaction limit and a $2,000 monthly ceiling. These are illustrative limits, not industry requirements.
2. The platform provisions limited access. The agent can prepare payments and invoke an approved payment workflow. It cannot create beneficiaries, change limits, or modify approval rules.
3. The agent proposes a transaction. An invoice for $180 arrives from an existing supplier. The agent extracts the details and submits the proposed payment.
4. An independent service authorizes the action. The service verifies the supplier, bank details, amount, available balance, and applicable mandate. If the checks pass, the payment proceeds through existing infrastructure.
5. An exception remains an exception. When the supplier changes its receiving account or sends an $850 invoice, the agent cannot authorize its own exception. The payment is blocked or routed to an authorized human reviewer.
Every decision, including rejected actions, is recorded with the applicable policy and authorization evidence.
The AI handles the work. The financial system retains control.
The difficult engineering is not connecting an LLM to a payment API. It is ensuring that the agent cannot cross the authorization boundary by persuading itself that an exception is reasonable.
What the industry still hasn't solved
Working payment controls do not resolve every risk created by delegated decisions.
The mandate gap. An agent may stay within its formal permissions while making a purchase the customer did not mean to authorize. Mastercard's Verifiable Intent work recognizes the need for reliable authorization evidence, but evidence of a mandate is not the same as proof that every decision reflected the customer's expectations. Whether the loss falls on the customer, issuer, merchant, or platform remains dependent on the facts, contracts, and applicable law.
Mandate drift. Standing instructions make agents useful, but their meaning can become less clear over long-running tasks. "Renew our subscriptions" may not authorize a higher-priced plan, a new supplier, or an annual commitment. Systems need rules for mandate expiry, changes, and reauthorization rather than relying on the agent's interpretation.
Fraud through manipulated instructions. A malicious invoice, merchant page, or email can try to persuade an agent to change a beneficiary or ignore a restriction. Payment credentials are only part of the attack surface. The mandate itself becomes a target.
Disputes at machine speed. Existing payment systems have chargeback procedures and evidence requirements, but agent-mediated purchases can involve several parties holding different parts of the authorization record. High-frequency, low-value transactions make investigation economics harder still.
Human oversight that becomes nominal. A required approval does little if reviewers cannot understand the transaction, lack authority to reject it, or face more escalations than they can process. Runtime controls need queue capacity, clear ownership, timeouts, and safe failure behavior.
None of these problems makes agentic payments unusable. They determine which workflows can be automated responsibly and which should continue to require explicit human decisions.
What fintech teams should build now
The emerging architecture suggests five priorities.
1. Keep financial controls outside the agent. Store mandates, spending limits, beneficiary permissions, and approval policies in services the agent cannot modify. Treat attempts to change them as separate, privileged operations.
2. Make delegated authority explicit. Translate customer instructions into enforceable policies covering permitted actions, amounts, counterparties, validity periods, and exceptions. A natural-language instruction alone is not a sufficient authorization mechanism.
3. Separate preparation from execution. An agent that can assemble payment instructions does not automatically need permission to release funds. Grant execution authority only where the product's risk model supports it.
4. Design for exceptions before scaling. Decide which actions are denied, which require approval, and what happens when a reviewer does not respond. Reconciliation, duplicate-payment protection, beneficiary changes, and audit trails belong in the initial design, not a later compliance phase.
5. Define liability before launch. Customer agreements and partner contracts should explain delegated authority, responsibility for permitted transactions, and dispute procedures. Contractual allocation must still comply with applicable payment regulation and consumer protection requirements.
The common principle is straightforward: agents can propose and initiate financial actions, but the authority to permit those actions must remain independently enforceable.
That is the design choice most likely to survive changes in models, protocols, and payment networks.
Building agentic payments without giving up control
Agentic payments are moving into production, but completing a transaction is only the visible part of the problem.
The harder work is deciding what an agent can authorize, connecting those decisions to existing payment infrastructure, and making sure the system can stop an action that violates the customer's mandate.
For fintech companies, this is an architecture and operational-control problem before it is an AI feature.
At Itexus, our work on digital banking, payment integrations, and financial transaction workflows is directly relevant to those requirements. We approach agentic payment design through authorization boundaries, reliable integrations, exception handling, and auditable execution – the controls that matter when software is allowed to act with real money.
Planning to introduce AI agents into your payment workflows? Contact the Itexus team to discuss the architecture, integration requirements, and controls your product will need.