Agentic Payments: What Fintech Platforms Need to Build Before AI Agents Move Money
Giving an AI agent read access to financial data is a product decision, while letting it initiate a payment is a compliance decision, and the controls in place before that step decide who carries the risk.
When Fortune asked Mastercard in September who would be responsible if an AI agent made an incorrect, fraudulent, or unauthorized purchase, the company pointed to Verifiable Intent, its record of what the cardholder told the agent to do. It did not say who would ultimately carry the loss if an agent bought something outside those instructions (Fortune, 2026).
That gap is the first thing a compliance officer will spot in any agentic payments proposal, and it's a fair place to start. Agentic payments, where an AI agent initiates or completes a payment on a customer's behalf, tend to show up on a roadmap as a single feature. In practice, they're two very different capabilities sharing one name.
Letting an agent read financial data is a fairly contained problem. If your platform already exposes balances and transactions through an API, an agent can sit on top of it through an MCP server with read-only scopes, and the worst case is a data exposure your existing controls were built to handle. (Our guide explains what an MCP server is and how it works if you want the mechanics first.) Letting the same agent act, by drafting a transfer or initiating a card payment, moves the conversation into authorization, consent, fraud liability, and audit evidence, and those questions don't have settled answers yet.
This article is for fintech, banking, and payments leaders deciding where to draw that line. It covers a tiered model for agent permissions, the regulatory constraints that apply once an agent can act, the guardrails that make agent access defensible, and where Visa, Mastercard, and Google are taking the networks.
Reading vs. Acting: A Risk Ladder for AI Agents in Banking and Payments
Most discussion of AI agents in banking treats "agent access" as a single switch. It's more useful to picture a ladder, where each rung adds one capability and one new way for things to go wrong. The five rungs below run from viewing a balance to initiating a payment.
Tier | What the agent can do | Risk level | What can go wrong | Controls at this tier |
|---|---|---|---|---|
1. View balance | Read balances and recent activity | Low | Data exposure through the agent, its logs, or its memory | Read-only scopes, customer consent for account access, data minimization, no card numbers in the agent's context |
2. Categorize transactions | Write labels or tags to transaction metadata | Low | Mislabeled spend that skews budgets or reporting | Writes limited to metadata fields, every change reversible, change history kept |
3. Flag anomalies | Mark transactions as suspicious and explain why | Moderate | Missed fraud, or false alarms that lead to wrongful blocks | The agent can flag but not freeze; flags go to existing fraud rules or a review queue |
4. Draft a payment | Prepare a transfer or payment for someone else to approve | High | A manipulated draft (new payee, changed amount) approved on autopilot | Drafts can't execute, payee verification, approval screen shows exact amount and payee, SCA on approval where required |
5. Initiate a payment | Submit a payment that moves money | Highest | Mistaken or unauthorized transfers, and disputes with no clear owner | Tokenized and scoped credentials, spending limits, step-up authentication, approval thresholds, full transaction logging, a way to switch the agent off |
Graphic placement: risk ladder (five rungs with controls at each)
The Rung Teams Underestimate
Tiers 1 through 3 have one thing in common: if the agent gets something wrong, no money has moved. A wrong label can be corrected, and a bad flag lands in front of a person or a rules engine that already knows how to deal with false positives. Most platforms can open these rungs using the same controls they already apply to third-party data access.
Tier 4 is where the risk profile changes, even though it doesn't look that way on paper. Drafting a payment sounds harmless because a human still approves it, but an agent that reads emails, invoices, or chat messages can be fed instructions hidden inside that content. A prompt injection that swaps a supplier's bank details inside a drafted transfer turns the approval step into a formality, especially for an approver who clears dozens of drafts a day. The PCI Security Standards Council lists protection against malicious input among its principles for AI in payment environments and names attempts to make fraudulent payments as a specific concern (PCI SSC, 2025).
Why Tier 5 Is a Different Kind of Decision
At tier 5, the agent holds a credential that can move money, and every question about liability, consent, and evidence becomes live at once. The rest of this article focuses on that rung, because it's where agentic AI payments either become defensible or stay stuck in a pilot.
The Regulatory Constraints on Agentic AI Payments
None of the rules below were written with AI agents in mind, and few regulators have issued agent-specific guidance so far. What follows describes where each framework puts pressure on an agent that can act. How your platform meets those requirements is a question for your compliance and legal teams.
PCI DSS Scope
An agent that touches card data is in scope, and so are the systems around it. The PCI Security Standards Council's position is that AI should be scoped like any other technology, and its newest guidance, published in September, covers how PCI DSS applies to AI deployments (PCI SSC, 2026). In practical terms, prompts, context windows, conversation logs, and agent memory all become places where card data can end up. Giving agents payment tokens or single-use card numbers instead of full card numbers keeps that footprint much smaller, which is also the approach the Council suggests.
Strong Customer Authentication Under PSD2
In the EU, agent-initiated payments fall under PSD2 and its SCA technical standards, with no separate regime for agents (Osborne Clarke, 2026). The friction point is dynamic linking, which ties the authentication to a specific amount and payee. That's hard to square with an agent that settles those details after the customer has walked away. When Visa ran live agent transactions with more than 30 European issuers this summer, every one was secured with Visa Payment Passkeys to support SCA requirements (Visa, 2026).
The EU's Payment Services Regulation will take over most of PSD2's conduct rules. Its final texts were agreed in April 2026, with formal adoption and publication expected in the second half of the year. Analysis of the agreed text points to broader fraud liability for payment service providers and a new direct liability regime for technical service providers involved in delivering SCA (Freshfields, 2026). [VERIFY: confirm Official Journal publication status before this goes live]
KYC and AML
An agent isn't a customer, and it can't be onboarded like one. Every action an agent takes still has to trace back to a verified person or business so that transaction monitoring and sanctions screening keep working. The industry has started calling this "know your agent," and Mastercard extended a know-your-agent capability from Skyfire into Agent Pay at the end of September (Mastercard, 2026). Monitoring rules deserve a second look as well, since an agent can split payments, retry declines, or approach limits far faster than a person would.
Consent
Consent for an agent has three parts: what the customer approved, the limits on that approval, and how they take it back. In the US, the stakes show up in Regulation E's definition of an unauthorized transfer, which excludes transfers made by someone the consumer gave access to, unless the consumer has told the institution that person is no longer authorized (Regulation E, 12 CFR 1005.2(m)). That definition was written decades before software agents, and how it applies when a customer hands an agent a credential is still an open question. The practical takeaway is that the record of what a customer agreed to, and the ability to withdraw it in one step, carry more weight than they do for ordinary card-on-file payments.
Audit Trails
When a dispute arrives, someone has to reconstruct who asked for what, what the agent did, and who approved it. The PCI SSC principles say AI actions should be logged and monitored so a named person can be held responsible, and where possible the logs should capture the inputs and reasoning behind an output. The networks are moving in the same direction, since Mastercard's Verifiable Intent and Google's AP2 mandates both produce signed records of what the user authorized. Those records describe the customer's instructions, though, so your own logs still have to show what your systems did with them.
Guardrails That Make Agent Access Defensible
"Defensible" is the right bar here. After an incident, regulators, auditors, and card schemes all ask some version of the same question, which is what you had in place before the agent was allowed to act. These five controls cover most of the answer:
- Spending limits: cap each agent by amount per transaction, total per day or month, merchant or category, and payment method. Set limits on your side and at the credential level where the networks support it, so a failure in one place doesn't remove the other.
- Step-up authentication: ask the customer to authenticate again when the agent steps outside its usual pattern, such as a new payee, a higher amount, a new country, or an odd hour. Passkeys keep this fast enough that customers don't abandon the flow.
- Per-tool permission scoping: give each agent tool its own narrow permission. A tool that reads balances shouldn't share credentials with a tool that adds payees, and adding a payee and paying that payee should be separate tools with separate checks.
- Human approval thresholds: set a level above which a person approves before money moves, and show the exact amount, payee, and account on the approval screen. A threshold that fires on every payment teaches people to click through, while one that fires on the risky few gets real attention.
- Transaction logging: for each payment, record the customer instruction, the agent's identity and version, the tool calls, the approval, and the network response, in a form your dispute and compliance teams can read without an engineer.
One more control is easy to forget until it's needed. PCI SSC recommends that AI systems can be switched off easily if something goes wrong, and per-agent credentials make that realistic, because revoking one credential stops one agent without touching the customer's cards or other connected apps.
Put the Controls in the Server, Not the Prompt
Where these guardrails live matters as much as which ones you pick. An instruction in a system prompt asking the model to stay under $500 is a suggestion the model may or may not follow. A check in the server the agent calls, which rejects any payment above $500, is a control. If agents reach your platform through MCP, the limits, scopes, thresholds, and logging all belong in the MCP server and the payment services behind it, where a cleverly worded request can't talk its way past them.
Graphic placement: prompt vs. server control card
Limits enforced outside the user-facing layer aren't new in payments. When Softjourn built a check-cashing and prepaid card service for PayPartners, banks could cap how many checks were cashed per day and the maximum value of any single check, and the flow ran OFAC and Customer Identification Program checks along the way. Agent limits work on the same principle: rules that the requester can't override.
Where Payment Networks Are Taking Agentic Payments
Visa, Mastercard, and Google are each building agent trust into the payment rails themselves. Here's where each stood at the start of October 2026. (For the buyer-facing side, where assistants find products and hand shoppers off to checkout, our article on [agentic commerce in ticketing](LINK: Agentic Commerce in Ticketing article) covers how that works today.)
Graphic placement: network status timeline
Visa Intelligent Commerce
Visa Intelligent Commerce is Visa's platform for agent-initiated transactions, built around its Trusted Agent Protocol for verifying agents, tokenized credentials, and spend controls. In April, Visa launched Intelligent Commerce Connect, a single connection through the Visa Acceptance Platform for payment initiation, tokenization, spend controls, and authentication that accepts payments started through several agent protocols (Visa, 2026). In June, it added an Agentic Directory of agents and merchants it has verified, and in July it announced live agent purchases in Europe at merchants including lastminute.com and Frasers.
Mastercard Agent Pay
Agent Pay launched in April 2025 around agentic tokens that bind a credential to a specific agent. In 2026, Mastercard added Verifiable Intent in March, co-developed with Google (Mastercard, 2026), and Agent Pay for Machines in June for high-frequency payments between software systems. In September came a consumer option that gives an agent a virtual card with spending, merchant, and approval controls, followed on September 30 by trust and intelligence services, starting with a score for how likely it is that an agent initiated a transaction, now in testing in the US.
Google's Agent Payments Protocol (AP2)
AP2 is an open protocol, announced in September 2025, that uses signed mandates as proof of what a user authorized. In April 2026, Google released version 0.2, which added "Human Not Present" payments for purchases an agent completes on pre-approved instructions, and donated the protocol to the FIDO Alliance, where it's being developed as a standard alongside Verifiable Intent (Google, 2026).
What the Networks Haven't Settled
All three are building the same three pieces: verified agent identity, scoped credentials, and a signed record of consent. None of them answers the question this article opened with, which is who absorbs the loss when an agent acts inside its credential but outside what the customer meant. Until that's settled, your own controls and records carry most of the weight.
Customers aren't in a hurry either. A Harris Poll survey conducted for Visa in May found that only 23% of US consumers trust generative AI to handle payment transactions on their behalf (Visa, 2026), which gives platforms room to build the acting tiers properly instead of rushing them.
Case Study Snapshot: A Separate Fraud Control Layer for an International Money Transfer Service iKobo needed fraud protection that could stand apart from its main transaction system. Softjourn's dedicated team built a rules-based fraud control system on its own machine and database that checked every transaction and could block an account until iKobo's staff finished an investigation, alongside P2P transfers and a smoother settlement process with US banks. Read the case study
Agentic Payments Start With What You Let the Agent Do
For most fintech and banking teams, the real decision about agentic payments is which rungs to open, in what order, and with which controls already running when the agent arrives. Viewing and categorizing can ship with the controls you have today. Drafting needs defenses against injected instructions and an approval step people take seriously. Initiating needs spending limits, step-up authentication, scoped tools, approval thresholds, and logs that hold up in a dispute, all enforced in the layer the agent calls rather than in the instructions it reads.
If agents will reach your platform through MCP, our approach to MCP server development for regulated platforms starts with those guardrails. Contact Softjourn to get started on an agent access model your compliance team can sign off on.
Frequently Asked Questions
What Are Agentic Payments?
Agentic payments are payments that an AI agent initiates or completes on behalf of a person or business, using a credential and limits the owner has granted. They range from an agent drafting a payment for someone to approve, to an agent paying on its own within pre-set rules. Visa, Mastercard, and Google are each building network-level support for them, but most live deployments are still pilots or controlled programs.
How Are AI Agents Used in Banking Today?
Most AI agents in banking today read and organize data: answering balance questions, categorizing spend, and surfacing unusual activity. Agentic banking that moves money is earlier, with controlled live transactions run through programs such as Visa's Agentic Ready and Mastercard's Agent Pay, usually with spending limits and customer authentication on each purchase.
Are Agentic Payments Regulated?
There are no agent-specific payment rules yet, but existing frameworks still apply. PCI DSS covers any agent that handles card data, PSD2's strong customer authentication applies to agent-initiated payments in the EU, and KYC, AML, and consumer protection rules such as Regulation E in the US still apply to the transactions agents make. How each one applies to a specific product is a question for your compliance and legal teams.
Who Is Liable When an AI Agent Makes a Payment?
That's still unsettled. Networks are building signed consent records, such as Mastercard's Verifiable Intent and Google's AP2 mandates, to help resolve disputes, but neither assigns the loss when an agent stays within its credential and still does something the customer didn't intend. For platforms offering agentic AI in financial services, that's the main reason to invest in limits, approvals, and logs before letting an agent move money.
