Agentic Payments: When an AI Agent Initiates the Transaction

Agentic Payments: Who Is Responsible When an AI Sends Money to the Wrong Place?

Agentic payments are coming to banks, payment networks and fraud teams faster than most of the industry has priced in. This post works through what they are, where the operational and regulatory fault lines sit, and what practitioners need to watch.

What Are Agentic Payments?

An agentic payment is a transaction initiated by an AI agent acting on behalf of a human principal, within a set of permissions that human has granted, without the human reviewing and approving that specific transaction at the moment it occurs.

The agent interprets an objective. It decides what to buy, from whom, for how much, and when. It then calls the payment rails to execute.

That is meaningfully different from a payment a human authorised in advance with fixed parameters.

We Already Automate Payments. What Is Actually Different?

The instinct is to say "we already do this with direct debits and standing orders." We do not. Here is what distinguishes agentic payments from existing automation:

Direct debits operate on a mandate with a fixed creditor. The amount may vary but the counterparty is predetermined and the mandate is explicit. The human signed a specific instruction.

Standing orders are fully predetermined. Amount, counterparty and frequency are fixed at setup. There is no interpretation.

Rule based automation in treasury or accounts payable follows conditional logic written by humans: if invoice matches purchase order and amount is below threshold, pay. The logic is explicit, auditable and deterministic.

An AI agent receives an objective: "manage my travel spend this month and keep it under £800." It then decides which hotel to book, which comparison to make, whether to pay now or wait, and which merchant to transact with. The counterparty, amount and timing emerge from the agent's reasoning at runtime, not from a human instruction at that moment.

The crucial shift is from following a predetermined instruction to interpreting an objective. That shifts where discretion lives, and discretion is where accountability begins.

Why Agentic Payments Are Emerging Now

Three things have converged.

First, large language models are now capable enough to plan multi-step tasks and call external tools, including payment APIs, without human intervention at each step.

Second, Open Banking and Open Finance infrastructure gives agents programmatic access to account data and, increasingly, payment initiation. The pipes exist.

Third, consumer AI assistants (voice agents, personal finance agents, autonomous shopping agents) are moving from demo to product. The commercial pressure to give these agents payment capability is significant.

None of this means agentic payments are mainstream today. But the architecture is being built now, which is exactly when practitioners should be forming views.

How an Agent Could Actually Make a Payment

To make this concrete, here is a plausible operational model.

A customer sets up an agent through their bank or a third party provider. They define:

• A spending envelope (say, £500 per month on grocery and household categories)
• Permitted merchant categories (grocery, pharmacy, household goods)
• A per transaction limit (no single transaction above £150 without escalation)
• An escalation rule (anything above the per transaction limit requires explicit human approval before execution)

The agent is issued a tokenised credential that represents both the customer's identity and the scope of authority granted. When the agent initiates a transaction, it presents this credential to the acquiring bank or payment network. The network verifies the credential is valid and that the transaction falls within the delegated scope before routing it.

If the agent tries to buy something outside the permitted categories, or above the per transaction limit, the transaction is declined or held for human review.

This is the permission boundary model. It is analogous to a corporate payment card with merchant category code restrictions and spend limits, except the entity carrying the card is software.

Who Is the Customer: The Human or the Agent?

From a financial crime and KYC perspective, the customer remains the human. The agent is acting as an instrument of that customer's will, within granted permissions.

But operationally, the entity initiating the transaction is the agent. Banks and payment networks need to verify two things simultaneously:

1. That the underlying customer is who they say they are (the existing KYC/AML problem)
2. That the agent is genuinely authorised by that customer and is operating within the granted scope (a new verification problem)

These are separate concerns and current frameworks do not cleanly separate them.

Strong Customer Authentication in the UK is governed by the UK Payment Services Regulations 2017 as amended, and the FCA's SCA requirements sit on top of those. Both were designed around a human in the payment journey. The human authenticates using something they know, have or are. Delegating initiation to an agent does not remove the SCA requirement; it raises the question of when and how it is satisfied.

One workable model is that the human performs SCA at the point of granting authority to the agent, and that act of authentication is cryptographically bound to the permission set the agent carries. Every subsequent transaction initiated by the agent within scope is treated as falling under that original authenticated delegation. This is SCA on the mandate rather than on each transaction.

This is architecturally coherent but it requires payment networks, issuing banks and regulators to agree on the credential format and the liability model. That agreement does not yet exist at scale.

Where the Fault Lines Sit: Fraud and Accountability

New Attack Surfaces

Agentic payments open new attack surfaces that fraud teams need to think through now.

Prompt injection. An agent browsing the web to compare prices could encounter a malicious webpage containing hidden instructions designed to redirect the agent's behaviour, for example to change the payee or amount. Prompt injection attacks against large language models are well documented.

Agent impersonation. A fraudster creates a fake agent claiming to hold valid delegation credentials from a customer. If the verification infrastructure is immature, a payment network may process the transaction before the impersonation is detected.

Fraudulent delegation. A social engineering attack convinces a customer to grant an agent wide authority, and the agent (controlled by the attacker) then drains the permitted spend envelope. This is phishing adapted for the agentic layer. Note that authorised push payment fraud risk is not eliminated here; it shifts to the mandate-granting stage, where the human can still be manipulated into setting up a rogue agent with broad permissions.

Automated fraud at scale. A compromised or malicious agent can initiate thousands of small transactions in the time a human fraudster could attempt dozens. The velocity problem is qualitatively different.

Where Authorised Push Payment Risk Reduces

Programmatic controls applied at the permission boundary are more consistent than human judgment. An agent technically constrained to a merchant category and a per transaction limit cannot be socially engineered into a large irregular payment in the way a human can. This reduces, but does not eliminate, the conventional authorised push payment attack surface.

The net effect on fraud exposure will depend heavily on implementation quality, particularly on how well permission boundaries are defined and how robust credential verification is.

The Accountability Gap

Say the agent misinterprets the customer's objective and books a hotel for the wrong dates. Or it pays a merchant the customer did not intend. Or it exceeds the intended spend because its categorisation logic classed a purchase in the wrong merchant category.

In each case, the customer will expect a remedy. Under current UK payment regulations, the right to a refund for an unauthorised transaction sits with the payment service provider. But a transaction initiated by the agent within a granted permission set may be technically authorised even if the outcome was not what the customer wanted. The transaction was inside the delegated scope. The agent just made a poor decision within that scope.

The liability chain runs across the customer (who granted the authority), the AI provider (who built and operates the agent), the bank (who holds the account and processed the payment), the payment network, and the merchant. Where a dispute lands in that chain is not settled law in any major jurisdiction as of now. Practitioners should treat existing frameworks as incomplete rather than assuming they cover this cleanly.

The Programmable Bank Account

What agentic payments point toward is the programmable bank account: an account that can be given conditional, scoped, revocable authority to act, rather than simply holding funds for a human to deploy manually.

This already exists in embryonic form in corporate treasury through virtual account structures, payment factories and ERP systems connected via API. What is new in the consumer context is that the reasoning layer (the agent) is general purpose and sits outside the bank's infrastructure.

The technical model that makes this work cleanly is tokenised credentials representing scoped authority. Visa and Mastercard have both published exploratory frameworks and announced pilot-stage work on agent credentialling, moving in the direction of tokens that carry machine readable permissions rather than exposing full card numbers or account details. The acquiring bank or payment network checks the token, verifies it is in scope, and either approves or declines before the transaction routes.

This is structurally similar to how OAuth scopes work in API access management, applied to payment initiation.

What This Means for Banks

Banks face a strategic challenge that goes beyond fraud and operations. If a customer's AI assistant becomes the primary interface for managing money, the bank's own app becomes a configuration screen for the agent rather than the place where financial decisions happen.

Product discovery, account switching, savings recommendations, credit offers: all of these currently depend on the customer engaging directly with the bank's interface. An agent intermediary changes that dynamic. The agent will compare products programmatically. It will switch to a higher-rate savings account without the customer needing to notice. It will apply for credit on the customer's behalf based on a financial objective, not brand loyalty.

Banks invest heavily in app experience because engagement correlates with selling across products, retention and data. An agent abstracts that engagement away. The parallel is what happened to travel agents when comparison engines became the default interface. The underlying products still existed. The margin and the relationship moved to whoever owned the customer's decision-making moment.

The strategic response options include: building or partnering on agent capability so the bank's agent is the one the customer uses; positioning as a trusted execution layer (the agent routes through us because we offer superior controls, transparency and dispute resolution); or deepening the relationship at the mandate and permissions layer, where the human is still making meaningful choices. None of these is obviously correct. This is a genuine judgement call about where the industry settles.

From Open Banking to Agentic Banking

Open Banking gave third parties read access to account data and, under payment initiation services, the ability to push payments with explicit user consent at the moment of each transaction. Agentic banking extends this by separating the consent event (granting the agent permission) from the transaction event (the agent executing a payment).

Open Finance extends the data access model to savings, investments, pensions and insurance, providing the information layer an agent needs to make meaningful financial decisions on a customer's behalf. The combination of Open Finance data access and agentic payment initiation is what makes a genuinely capable personal finance agent possible.

The regulatory infrastructure for this is not complete. Powers to mandate data sharing beyond Open Banking sit across both the Financial Services and Markets Act 2023 and the Data (Use and Access) Act 2025, with the smart data provisions enabling Open Finance data portability primarily in the latter. The FCA's work on Open Finance and the FSB's attention to AI in financial services are both relevant, but neither has yet produced a framework that cleanly addresses delegated agent authority in payment initiation.

Practitioners building or evaluating agentic payment products now are operating ahead of the regulatory guidance. That is not unusual in fintech, but it does mean liability positions are genuinely uncertain and should be treated as such in risk assessments.

For more on how retrieval and knowledge graph approaches are being applied to AI systems in financial contexts, the post on GraphRAG and knowledge graph retrieval: how it works and when it is worth the complexity gives useful technical grounding on the underlying AI architecture.

What Banking Professionals Should Watch Through 2027

Visa and Mastercard Agent Credentialling Frameworks

Both networks are developing specifications for how agents are identified and how their authority is verified at the point of transaction. When these go live at scale, they will set the de facto standard that banks and merchants have to implement. Watch for technical specifications and pilot programmes.

Agent Identity Standards from FIDO Alliance and OpenID Foundation

The likely technical substrate for agent identity is an extension of existing digital identity standards. The FIDO Alliance and OpenID Foundation are both working in this area. The output will affect how banks implement the verification layer.

FCA Regulatory Attention

The FCA has signalled interest in AI in financial services, including questions about accountability and consumer protection. Watch for consultation papers that address the liability gap in transactions initiated by AI agents. Any guidance on who bears responsibility for agent errors will have direct operational implications.

FSB Systemic Risk Assessments

The Financial Stability Board is paying attention to AI in financial services at the macro level. If agentic payment volumes grow rapidly, systemic risk questions (concentration in a small number of agent providers, correlated behaviour, automated feedback loops) become material. FSB papers in this area will influence how national regulators frame their approaches.

Open Finance Legislative Progress in the UK

How and when the FCA exercises its data-sharing mandate powers will determine how much data an agent can access to make genuinely useful decisions. The richer the data access, the more capable agents become.

Tokenised Credential Pilots

Watch for live pilots of payment credentials that carry machine readable permission scopes. These are the technical building block the whole model depends on. Early pilots from banks or payment networks will reveal where the implementation challenges actually sit.

Liability Case Law and Regulatory Decisions on Disputes

The first significant dispute about a transaction initiated by an AI agent that goes to a regulator or court will produce guidance the industry uses as a reference point. This may arrive earlier than expected as pilots become live products.

The Bigger Question: What Happens When Machines Become Economic Actors?

The payment system was built around the assumption that the entity initiating a transaction is a legal person: an individual or a company, with rights and obligations that the law recognises. An AI agent is neither. It is an instrument of a legal person. But when agents initiate millions of transactions autonomously, interpreting objectives rather than following instructions, the gap between "instrument" and "actor" starts to matter.

Who can be held accountable for a systematic error? Who carries the regulatory obligation to prevent financial crime at the agent layer? How does sanctions screening work when the agent is choosing the counterparty in real time? These are not questions with settled answers. They are the questions that practitioners in payments, compliance, legal and risk should be thinking through now.

The broader question of how AI changes professional roles in finance is worth considering alongside this. The post on whether AI will replace finance jobs: an honest assessment and a practical plan takes an honest look at where human judgment remains essential in an increasingly automated environment.

Where to Start

Agentic payments are not a future state you can defer thinking about until the standards are finalised. The architecture is being built now, the commercial pressure is real, and the liability gaps are genuine.

Banks, payment networks and fraud teams that form clear positions now will be better placed than those that wait for a complete regulatory framework that may take years to arrive. Start with the permission boundary model. Define what your institution will and will not accept as a valid delegation credential. Build the fraud controls around the agent layer, not just around the transaction. Get your legal and compliance teams into the same conversation as your technology teams, because the questions do not separate cleanly into technical and regulatory buckets.

If you want to go deeper on AI systems and their architecture in financial contexts, the Academy catalogue covers both the technical and the finance dimensions, and membership gives you access to member-only content and the Discord where these conversations are ongoing.