Agentic AI in Banking: What Happens When AI Can Actually Move Money?

From Asking to Doing: What Agentic AI Actually Means for Banking

Agentic AI lets a system receive an objective, reason through how to achieve it, and take action across multiple steps without a human in the loop at every point. For banking, that distinction between answering a question and completing an objective is what matters.

Most AI tools in banking today are capable research assistants. You ask a question, the model gives you an answer, and a human decides what to do with it. That is useful. It is not a fundamental shift in how financial workflows operate.

Agentic AI is different. The agent receives an objective, reasons through how to achieve it, selects and uses tools, takes actions across multiple steps, and adapts when something changes. That distinction matters enormously in banking, where a wrong action is categorically more serious than a wrong answer.

This post covers what agentic AI actually means, where it could be deployed, what the risks look like when AI has execution authority, and what this means for finance professionals in practical terms.

What Is Agentic AI and How Is It Different from the AI You Already Use

It helps to place agentic AI on a spectrum. Traditional automation executes a fixed sequence of steps. Rules are fixed in the code. Deviation from the expected input breaks the process. Machine learning models score or classify data and surface a recommendation, but they do not act. Generative AI copilots, the chat interfaces now embedded in many platforms, respond to prompts. They are still answering questions, not completing objectives.

An agent adds three things on top of a language model: the ability to plan a sequence of actions to achieve a goal, access to tools (APIs, databases, code execution environments, other systems), and a feedback loop that lets it observe the result of each action and decide what to do next.

The shift is from question and answer to objective, reasoning, tool use, and action, repeated across a workflow that may involve dozens of steps without a human touching each one.

Why Banking Is a Different Environment for AI Action

Banking workflows sit at the intersection of regulated obligations, real money movement, counterparty relationships, and irreversibility. An AI that gives a wrong answer in a customer service context can be corrected. An AI that initiates an incorrect CHAPS payment, files an inaccurate regulatory return, or releases a hold on a transaction under AML review cannot simply be undone without consequence.

Regulatory accountability is also not delegable. Under PRA and FCA frameworks, including the Senior Managers and Certification Regime (SMCR), senior managers and designated individuals remain responsible for decisions within their remit regardless of what tool or process generated the action. An agent cannot be an approved person.

This is the governance and accountability gap that matters, and it is not a technical problem that better AI will eventually solve. It is a structural feature of the regulatory and legal environment that banks operate in.

A Realistic Treasury Example: From Shortfall Detection to Funded Position

This is the scenario that makes agentic AI concrete for treasury practitioners.

A treasury liquidity agent, connected to the bank's intraday position feeds, cash flow forecasting models, and funding systems, is given the objective of maintaining the projected liquidity position within approved limits across a rolling 30 day horizon.

At 09:15 on a Tuesday, the agent detects that a large drawdown on a committed facility is projected to create a shortfall against the bank's internal management buffer above the regulatory LCR minimum in five days. Here is what it does next, step by step.

Step 1: Detect. The agent flags the shortfall against the approved limit, calculates the magnitude (say, £180m equivalent), and confirms the projection is based on current confirmed drawdown notices, not an anomaly in the feed.

Step 2: Investigate. It queries the facility management system to confirm the drawdown notice is valid, checks whether any offsetting inflows are expected in the same window, and reviews the HQLA pool to assess available headroom.

Step 3: Evaluate options. It models three funding alternatives: a repo transaction against available government bond collateral, a term deposit drawdown from the internal funding book, and a bilateral short term borrowing from an approved counterparty. For each option it calculates the cost using current FTP curves, the encumbrance impact, and the resulting LCR and NSFR positions. If you want background on how FTP works in this context, see our post on funds transfer pricing and how banks put a price on internal liquidity.

Step 4: Prepare and route. It prepares a funding recommendation with supporting analysis, drafts the transaction instruction for the preferred option, and routes it to the treasury manager for approval via the bank's workflow system, flagging that approval is needed within a defined window to allow same day settlement.

Step 5: Execute. On approval, the agent initiates the transaction through the appropriate system and confirms settlement.

Step 6: Document. It writes a structured audit entry capturing the trigger, the options considered, the recommendation rationale, who approved, when, and the outcome. This step matters as much as execution. The audit trail is what makes the governance argument credible, and in a regulatory or internal review it is what demonstrates that a human exercised genuine oversight at the decision point.

The human in this scenario exercises genuine judgement at the approval step, with full supporting analysis already prepared. Every other step is handled by the agent. That is a credible near term architecture given the tools already available.

AI Agents in Banking: Use Cases Across Treasury, Payments, and Compliance

Specific use cases matter more than generic claims about efficiency. Here is what agents could actually do across key banking functions.

Cash management. Automated intraday position monitoring, sweeping of zero balance accounts with dynamic rule adjustment, and liquidity optimisation across multiple currencies and entities in real time.

Payments and payment investigations. Routing decisions, SWIFT message repair, correspondent banking chain optimisation, and the bulk of first line investigations on returned or rejected payments. The agent queries the relevant systems, drafts the resolution, and routes exceptions to a human only when the resolution is outside predefined parameters.

Reconciliations. Matching transactions across ledgers, identifying and categorising breaks, and escalating unresolved items above a materiality threshold. This is already partly automated in many banks, but agents can handle the reasoning step for complex breaks rather than just the matching logic.

AML and KYC. Transaction monitoring alert triage, where the agent investigates the alert against transaction history, customer profile, and typology libraries, and produces a structured disposition recommendation. The human investigator reviews the recommendation rather than building the case from scratch.

Regulatory reporting. Compiling and cross checking inputs for liquidity regulatory returns such as the PRA's liquidity data reporting templates, flagging data quality issues, and preparing draft commentary for review. The judgement calls on borderline classification questions stay with the human responsible for the return.

Fraud detection. Real time intervention on suspicious transactions, placing holds and routing to investigation queues, with the agent managing the workflow through resolution within defined parameters.

Agentic AI and Payments: Who Actually Authorised That Transaction

Payments deserve specific attention because the accountability question is sharpest here. When an agent initiates a payment, even with human approval at a workflow step, several things need to be clear before that architecture goes anywhere near production.

Who is the legally authorised initiator of record? What is the scope of the agent's permission to prepare and route instructions? What happens if the approval step is bypassed due to a system fault? How is the approval captured in a way that satisfies the bank's payment authorisation framework and audit requirements?

These are not edge cases. They are the core governance questions that have to be resolved in policy before the agent touches live transaction flows.

What Could Go Wrong When AI Has Execution Authority

The risk profile of an acting AI is not just a scaled up version of a recommending AI. The failure modes are qualitatively different.

Hallucination. A generative model embedded in an agent can produce plausible but incorrect output. In a copilot, the human checks the answer. When the agent uses that output to drive the next action, the error propagates.

Stale or incorrect inputs. An agent is only as good as the data it can access. If a feed is delayed, a system is down, or an integration returns a cached value, the agent may act on a position that does not reflect reality.

Poorly scoped objectives. Agents optimise for their objective function. If that objective is not precisely specified, the agent may achieve it in ways that breach limits, create unwanted side effects, or satisfy the letter of the instruction but not the intent.

Prompt injection. In systems where agents process external data, including payment messages, customer communications, or vendor documents, a malicious actor can embed instructions in that data designed to redirect the agent's behaviour. This is a live attack vector, not a theoretical one.

Multi agent interactions. When multiple agents run concurrently across shared systems, their actions can interact in ways that neither individually would have produced. A liquidity agent and a collateral management agent making independent decisions against the same asset pool simultaneously is one straightforward example of how this gets complicated fast.

How to Control an AI That Can Take Action: Bounded Autonomy in Practice

The right response to these risks is to design a control architecture that matches the autonomy level to the risk level of the task. A useful way to think about this is a five level framework. This is an illustrative structure, not a regulatory standard or established industry taxonomy.

Level 1: Observe only. The agent monitors, detects, and logs. No output leaves the system without human retrieval. Risk: negligible. Suitable for: position monitoring, anomaly flagging.

Level 2: Advise. The agent produces a recommendation and presents it for human decision. The human acts manually. Risk: low. Suitable for: funding options analysis, alert triage drafts.

Level 3: Prepare and route. The agent prepares a complete action package (transaction instruction, filing, communication) and routes it for human approval before any external action is taken. Risk: moderate. Suitable for: most treasury execution workflows, regulatory draft submissions.

Level 4: Execute with notification. The agent executes within predefined parameters and notifies the relevant human immediately. The human can reverse within a defined window. Risk: elevated. Suitable for: low value automated payments within agreed limits, standard reconciliation resolutions.

Level 5: Execute within predefined limits. Full autonomous execution within a clearly bounded permission set, with full audit trail and automatic escalation on limit breach. Risk: high if parameters are wrong. Suitable for: specific, narrow, well tested use cases only.

Every deployment needs bounded permissions (the agent can only access and act on specific systems and within specific limits), role based access aligned to the bank's existing authorisation framework, approval workflows that are captured and auditable, a full audit trail of every decision and action, a reliable kill switch, and a documented human escalation path for anything outside parameters.

The bank's ILAAP and ICAAP processes, and broader operational risk frameworks, will need to account for agentic AI as a new category of operational risk.

LCR, Treasury Automation, and What Happens to Finance Roles

The honest answer is that it depends on the task, not the job title.

Tasks likely to be automated. Routine data gathering, first pass matching, standard report compilation, alert triage where the outcome follows a clear decision tree, and templated communications. These tasks are rule following or pattern matching at scale. Agents will do them faster and more consistently.

Tasks likely to be augmented. Analysis of complex positions, investigation of unusual situations, preparation of judgement based submissions, counterparty relationship management, and governance decisions. Agents will surface the relevant information and do the legwork. The practitioner exercises the judgement and bears the accountability.

Tasks where human accountability cannot be delegated. Signing off on regulatory returns. Approving material funding decisions. Making judgement calls on SAR filings. Deciding whether to escalate a risk concern to the board. Regulatory frameworks and legal liability mean these stay with named individuals.

The practitioners who will be most valuable are not those who can be replaced by an agent, and not those who refuse to engage with the technology. They are the ones who understand both the financial process in detail and how agents operate well enough to design, oversee, and challenge them. That combination is currently rare.

If you want to build the technical side of that combination, the Academy has structured courses and learning paths covering Python for finance and automation. You can browse at industryportalacademy.vercel.app/catalogue or explore guided learning paths at industryportalacademy.vercel.app/paths.

AI Governance in Banking: What Banks Should Be Doing Now

Before any agent touches a live workflow, three things need to be in place.

First, a taxonomy of tasks by autonomy level. Not every process needs an agent, and not every agent deployment needs the same level of control. That mapping has to come before the technology procurement decision.

Second, governance policy that explicitly addresses agentic AI as a distinct category. Existing model risk frameworks were built for scoring and classification models. They do not naturally cover multi step reasoning systems with tool use and feedback loops. The gap needs to be closed deliberately.

Third, API and data infrastructure that supports agent integration safely. If you want to understand the infrastructure layer that agent deployments depend on, the post on APIs for finance practitioners covers the foundations in practical terms.

What Finance Professionals Should Be Learning in the Next 12 to 24 Months

You do not need to become an AI engineer. You do need to be able to read an agent's decision log and understand what it did and why. You need to know what a well scoped objective looks like and how a poorly scoped one produces bad outcomes. You need to understand what a permission boundary is and why it matters.

Practically, that means getting comfortable with how agents are structured, what APIs are and how they work, and enough Python to follow what a workflow is actually doing. The career advantage goes to the person who can sit in the room with both the technology team and the risk committee and translate credibly between them.

The Bigger Picture: When Agents Start Talking to Other Agents

This is forward looking and should be clearly labelled as such. The current deployment conversation is about bank internal agents operating within a single institution's systems. The next layer, which is already being explored in research and early pilots outside banking, involves agents operated by different parties communicating with each other.

A corporate treasury agent acting on behalf of a corporate client and negotiating terms with a bank's liquidity management agent. A consumer personal finance agent instructing a payment agent. Multiple correspondent bank agents resolving payment investigations across borders autonomously.

If that architecture becomes real, the questions about accountability, authorisation, and audit trail become significantly more complex. Which agent is the originator of record? How does a human regulator or auditor reconstruct a decision chain that involves four autonomous systems operated by four different organisations? How are disputes between agents resolved?

These are not problems that need solving today. They are problems that the people designing today's governance frameworks should at minimum be aware of, because the groundwork for answers will need to be laid before the architecture arrives.

The Authority Question

The agent cannot answer that question. The human who scoped the agent's permissions, approved its deployment, and signed off its control framework can. That is the accountability that practitioners need to understand, and it is the accountability that makes the people who design, oversee, and challenge these systems genuinely irreplaceable.

The technology is arriving whether the governance frameworks are ready or not. The practitioners who engage now and understand the risks clearly will be in the strongest position when it does. Building the skills to work alongside agents without ceding accountability is the practical goal.