The year is 2025. Your AI assistant has just negotiated a better rate on your insurance, automatically transferred funds between your accounts to optimise interest and purchased supplies for your business; all while you were sleeping.
But behind these seemingly simple tasks lies a fundamental problem: our financial infrastructure was never designed for non-human actors. Every transaction, every authentication flow, every compliance check assumes a human is present, making decisions in real time.
This disconnect may become the biggest bottleneck stopping AI becoming AGI.
This post was meant to be the last in the Banking Evolution series, but with the accelerating innovation in AI I couldn’t justify cramming 9000 years of banking history in beforehand. We’re jumping straight to the future.
The Case for Agentic Banking
Over the last year, AI agents have gone from scripted task runners to semi-autonomous decision-makers. They’re buying coffee, booking travel, managing calendars, writing code, querying APIs and even joining the gig economy as workers in their own right.
But while their reasoning and action capabilities continue to improve, their financial capabilities are nowhere near human level. Today’s financial infrastructure assumes a human is behind every transaction. Consent is assumed to be explicit, real-time and human-initiated. Interfaces are designed for human eyes and hands. Authentication flows require human input.
As agents manage more complex tasks for users, organisations, and even other agents, they’re colliding with the limitations of our human-centred financial systems.
Look at what’s already happening:
-
Agent Frameworks & Development Tools
- LangChain - The orchestration framework for controllable agentic workflows.
- Crew AI - AI agent teams that work together to tackle complex tasks
- Vercel’s AI SDK - Toolkit for building AI-powered applications with agents.
- OpenAI’s Response API and Agent SDK - The building blocks to build useful reliable agents.
-
UI/UX Generation
- Lovable - AI-powered frontend generation in minutes
-
Financial & Payment Agents
- Payman - Autonomous payments on ACH & crypto rails.
- PayOS - Agentic card payments.
- Skyfire - Financial stack built to unlock autonomous Agentic AI commerce.
- Stripe Agent SDK - Virtual card and issuance and payment links. for agents
-
Business Process Agents
Each of these innovations represents a different aspect of the evolving agent ecosystem, with capabilities ranging from development frameworks to specialized business functions. The financial capabilities vary widely, with crypto-based solutions achieving more autonomy while traditional financial rails remain more constrained.
The agent needs some degree of financial agency. The ability to act with money, within constraints, on behalf of someone else. To make that possible, we need to design a new kind of financial infrastructure. One built not for users with agents but for agents as users themselves. One that blends autonomy with compliance, flexibility with safety, programmability with accountability.
We call this concept Agentic Banking.
A Bank for Agents is a platform that treats agents as first-class actors:
- They can hold and route funds under delegation.
- They can act on real-time events (e.g. incoming payments).
- They can operate under rules, limits and comprehensive audit trails.
- And critically, they act on behalf of a fully identified, consent-granting humans or organisations.
This post introduces the foundational concept: agents need their own financial infrastructure and it’s possible to build it on traditional rails in a compliant, responsible way.
In the rest of this series, we’ll explore:
- 📜 Regulation: PSD2, BSA, EMI/PI and how they apply to agents
- 🧠 Consent Models: Structuring delegation and accountability
- ⚙️ Infrastructure: APIs and SDKs for agent-native finance
- 🌍 Ecosystem: What’s already happening and who’s building
- 🚀 Possibilities: What we unlock with full financial autonomy
Regulatory Tension: Autonomy vs. Compliance
Why this sounds impossible, but isn’t
Financial regulations worldwide assume human-centred decision-making. From a regulator’s perspective, this makes perfect sense: humans can be held accountable, can demonstrate intent, and can be prosecuted for violations.
When we introduce autonomous agents into this equation, we immediately encounter what appears to be an irreconcilable conflict. How can an agent authorize a transaction without the human present? How can consent be proven? Who is liable if something goes wrong?
To resolve these questions, we must distinguish between regulatory intent and implementation mechanisms.
Regulations exist to prevent fraud, money laundering, terrorist financing, and market abuse. They aim to ensure accountability, traceability, customer protection, and system stability. These goals do not change in an agent-based financial system, but the way we meet them can.
We can preserve regulatory intent while reinterpreting implementation for agent-based systems.
Regulatory Frameworks Across Key Markets
Europe (PSD2, RTS on SCA & CSC) Overview
The Payment Services Directive 2 (PSD2) and its associated Regulatory Technical Standards (RTS) form one of the most comprehensive regulatory frameworks for payments globally. Several provisions are directly relevant to delegated agent autonomy. I’ll take you through the key articles.
PSD2 Article 97(1) Authentication:
Member States shall ensure that a payment service provider applies strong customer authentication where the payer:
- (a) accesses its payment account online;
- (b) initiates an electronic payment transaction;
- (c) carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.
Strong Customer Authentication is defined in PSD2 Article 4 as:
PSD2 Article 4(30) Definitions:
an authentication based on the use of two or more elements categorised as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) that are independent, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data;
In practise, this is implemented as follows:
- Knowledge: A password or pin;
- Possession: mobile phone, card reader, or device with a one-time passcode;
- Inherence: fingerprint or other biometric data.
This authentication framework creates the first major challenge for Agentic Banking. An agent can’t easily provide biometric data, possess a physical device or “know” a password in the conventional sense. However, the RTS provides some limited flexibility in Article 16.
RTS on SCA/CSC Article 16 Low-value transactions:
Payment service providers shall be allowed not to apply strong customer authentication, where the payer initiates a remote electronic payment transaction provided that the following conditions are met:
- (a) the amount of the remote electronic payment transaction does not exceed EUR 30; and
- (b) the cumulative amount of previous remote electronic payment transactions initiated by the payer since the last application of strong customer authentication does not exceed EUR 100; or
- (c) the number of previous remote electronic payment transactions initiated by the payer since the last application of strong customer authentication does not exceed five consecutive individual remote electronic payment transactions.
This is a good start, but we’re nowhere near full autonomy. Our delegated agent could make up to 5 consecutive transactions under €30 without requiring the human to re-authenticate, as long as the total doesn’t exceed €100. Pretty limited scope. Some more flexibility comes in RTS Article 14.
RTS Article 14 Recurring transactions:
- Payment service providers shall apply strong customer authentication when a payer creates, amends, or initiates for the first time, a series of recurring transactions with the same amount and with the same payee.
- Payment service providers shall be allowed not to apply strong customer authentication, subject to compliance with the general authentication requirements, for the initiation of all subsequent payment transactions included in the series of payment transactions referred to in paragraph 1.
As soon as the amount changes, we lose autonomy again. We can regain some autonomy by using trusted beneficiaries under RTS Article 13.
RTS Article 13 Trusted beneficiaries:
- Payment service providers shall apply strong customer authentication where a payer creates or amends a list of trusted beneficiaries through the payer’s account servicing payment service provider.
- Payment service providers shall be allowed not to apply strong customer authentication, subject to compliance with the general authentication requirements, where the payer initiates a payment transaction and the payee is included in a list of trusted beneficiaries previously created by the payer.
This is great, provided we’ve complied with SCA when the human created the trusted beneficiaries, our agent can autonomously send any amount to these payees without SCA. However, creating the beneficiaries in the first place doesn’t scream full autonomy to me either.
There are some more exemptions that allow non-consumers (i.e. corporates) to initiate payments in Article 17, 1as well as where the payer and payee are the same natural legal person in Article 15.
The juiciest exemption comes in Article 18 on Transaction Risk Analysis. If the PSP deems that the transaction poses a low level of risk we can be exempt from SCA, but what does this mean in practise?
Assuming no fraud, we have a new cap of €500, provided the following conditions are met.
RTS Article 18 Transaction Risk Analysis:
- An electronic payment transaction referred to in paragraph 1 shall be considered as posing a low level of risk where all the following conditions are met:
[…]
(c) payment service providers as a result of performing a real time risk analysis have not identified any of the following:
- (i) abnormal spending or behavioural pattern of the payer;
- (ii) unusual information about the payer’s device/software access;
- (iii) malware infection in any session of the authentication procedure;
- (iv) known fraud scenario in the provision of payment services;
- (v) abnormal location of the payer;
- (vi) high-risk location of the payee.
All of this is manageable, and some not even relevant as the agent has no physical location.
Europe Recap
PSD2’s Strong Customer Authentication requirements present specific challenges for agent autonomy, but several pathways exist when operating as a regulated financial institution:
- Low-value transactions: Agents can make up to 5 consecutive transactions under €30 without re-authentication (total under €100).
- Trusted beneficiaries: Once a human authenticates to establish trusted payees, agents can send any amount to these recipients without further SCA.
- Recurring payments: Fixed-amount, same-payee recurring transactions only require authentication on the first payment.
- Transaction Risk Analysis: For institutions with low fraud rates, transactions up to €500 can be exempted from SCA if risk analysis deems them safe.
- Corporate payments: Business accounts offer additional exemption opportunities with higher transaction thresholds.
As a regulated E-Money Institution, we can directly apply these exemptions at the infrastructure level rather than relying on third-party banks to approve them. This gives us significantly more control over the authentication flows, allowing us to design agent-friendly pathways while remaining fully compliant with regulatory requirements.
The key advantage is our ability to implement sophisticated risk monitoring systems specifically calibrated for agent behavior patterns, maximizing the effectiveness of exemptions while maintaining the security standards required by regulation.
For official PSD2 and RTS references:
Licensing Pathways: EMI vs. PI
- Payment Institutions (PIs) can offer payment services but face limitations around holding funds and account structure flexibility.
- E-Money Institutions (EMIs) can issue e-money, maintain client accounts, and design programmable sub-account infrastructure - a key enabler for agent-native financial logic.
UK (FCA’s approach)
Coming soon…
US (Money Transmission, BSA)
Coming soon…
Asia (Singapore / MAS as example)
Coming soon…
Compliant Agent Bank Architecture
What to build and how to build it
Coming soon…