Agentic AI in Banking: What Treasury and Risk Teams Need to Know
This post explains what agentic AI is, how it differs from chatbots and copilots, and what it means for treasury, liquidity, ALM, and risk workflows in banking. It covers practical use cases, real risks, and the skills worth building now.
Imagine arriving at your desk at 7:30am to find that the overnight liquidity commentary is already drafted, the LCR movement has been attributed to three specific cash flows, and the two positions that breached internal early warning thresholds have already been flagged with supporting context pulled from three systems. Nobody worked through the night. No offshore team produced it at 3am. A piece of software made a series of decisions, accessed several live systems, and assembled something coherent enough to review rather than build from scratch.
The technology enabling it is called agentic AI, and it is meaningfully different from the chatbots and copilots most finance teams have encountered so far. That is not speculative in 2025. It is not yet standard practice either. But there is a reasonable case that by 2027, for banks that move with purpose, it will be recognisable. That is a judgement, not a guarantee.
From Chatbots to Copilots to AI Agents
How Each Generation Differs
Most banking professionals have now seen at least one internal pilot of a large language model, usually wrapped in a chat interface and pointed at a policy document or data dictionary. You type a question, it answers. That is a chatbot. It is reactive, stateless between sessions, and entirely passive. It does nothing until prompted and it executes nothing at all.
Copilots are a step forward. They sit inside a tool (a spreadsheet, a reporting platform, a coding environment) and they take instructions from you to help with the task in front of you. GitHub Copilot suggests code. Microsoft Copilot drafts a slide. They are still reactive, still single step, and still wholly dependent on your instruction at each moment. They are very useful. They are not agents.
An AI agent is different in kind, not just degree. An agent can receive a high level goal, decompose it into steps, decide which tools to use, execute those steps in sequence, evaluate the output of each step, adjust its approach based on what it finds, and produce a final output, all without a human directing each move. It acts. It has access to tools. It can call APIs, run code, query databases, write files, and trigger downstream processes. And crucially, it can reason across multiple steps while retaining context about what it has already done.
Chatbot vs Copilot vs AI Agent: A Comparison
The table below compares the three generations across the dimensions that matter most for banking workflows. If your CMS renders this as an image, the alt text should read: Comparison of chatbot, copilot, and AI agent capabilities for banking use cases.
| Dimension | Chatbot | Copilot | AI Agent |
|---|---|---|---|
| Trigger | Human sends a message | Human issues a command inside a tool | Goal set by human or by schedule or by event |
| Autonomy | None | Low, one instruction at a time | High, multi step without constant supervision |
| Tool access | None or read only retrieval | Limited to the host tool | APIs, databases, code execution, file systems, external services |
| Multi step reasoning | No | No | Yes, plans and replans across steps |
| Memory | Session only or none | Session only | Can persist memory across sessions and tasks |
| Actions taken | Returns text | Modifies content inside one tool | Can read, write, trigger, escalate and communicate across systems |
| Human involvement | Required at every step | Required at every step | Required at key decision points and for final sign off |
| Banking example | Answering "what is the LCR definition" | Drafting a commentary paragraph in Excel | Pulling overnight repo positions, attributing LCR movement, flagging breaches, and producing a draft report for analyst review |
The last column is the one that changes what treasury and risk teams actually do on a Tuesday morning.
Why Agentic AI Is Viable Now
The concept of autonomous software agents is not new. What is new is that the underlying models are now good enough to make them practical.
A few specific technical shifts have converged. First, reasoning capability. The latest generation of foundation models can sustain coherent multi step logic across complex tasks without losing the thread. This was not reliably true even eighteen months ago.
Second, tool use and API access. Models can now call external functions in a structured and reliable way. You can give an agent a set of tools (a function to query a database, a function to call a REST API, a function to execute Python) and it will choose which tool to use, pass the right parameters, and interpret the result. This is what connects language models to the actual systems inside a bank.
Third, context windows have grown substantially across leading models. An agent working on a liquidity investigation might need to hold a spreadsheet, a set of trade confirmations, and a policy document in view simultaneously. Many current models can do that, though context window limits vary significantly by model and a very large spreadsheet can still exceed them. Treat this as an architectural consideration, not an assumption.
Fourth, structured outputs mean agents can produce JSON or other machine readable formats consistently, which allows their outputs to feed directly into downstream systems rather than requiring a human to transcribe them.
Fifth, orchestration frameworks like LangChain, LangGraph, AutoGen and CrewAI have matured to the point where engineers can build reliable multi agent workflows without building everything from first principles.
The key shift is not that AI got better at generating text. It is that AI can now interact with surrounding systems. That is what makes the step from copilot to agent possible.
The combination of these five developments means that a workflow which previously required a human to move between systems, interpret results, and make sequential decisions can now be partially or substantially automated at the reasoning layer, not just the data extraction layer.
What an AI Agent Inside a Bank Could Actually Look Like
Before walking through specific workflows, it helps to have a picture of the architecture. A basic agentic setup inside a bank might involve an orchestrating model (the "brain"), a set of tools it can call (think Python functions wrapped around internal APIs or database connections), a memory store (so it can recall context from previous runs), and a set of guardrails (rules about what actions require human approval before proceeding).
The agent does not have unrestricted access to everything. It has access to what it has been explicitly granted, scoped to its function. This matters enormously for controls, and we will come back to it.
A treasury liquidity agent, for example, might be granted read access to the liquidity position system, read access to the trade repository for overnight activity, read access to the LCR calculation engine, and write access only to a staging area where its draft output sits until a human reviews it. It can read, reason, and propose. It cannot approve, submit, or execute a trade.
That boundary between autonomous reasoning and human authorised action is where the design of these systems lives, and getting it right is a genuine risk management challenge.
Seven Banking Workflows AI Agents Could Transform
Liquidity and Treasury
The daily liquidity process in most banks involves a morning run: pull overnight positions, compare to the prior day, attribute movements to funding activity, check LCR and internal metrics against thresholds, investigate anything unusual, and produce commentary for the ALCO pack or internal report.
An agent could own the data collection, comparison, and initial attribution layer. It would query the position system, identify the drivers of movement, cross reference against the trade blotter and known cash flow schedule, and flag anything that does not fit the expected pattern. The human reviews the output, challenges the attribution where it does not look right, and adds the contextual judgement that the agent cannot have (a known counterparty issue, a market event that morning, a management decision taken yesterday).
What stays with the human: final sign off, any escalation decision, and the contextual interpretation that requires knowledge outside the systems the agent can see.
ALM and IRRBB
Interest rate risk in the banking book involves running sensitivities, comparing to limits, understanding what has driven changes in NII or EVE metrics, and reporting to risk committees. Much of the data gathering and delta analysis is mechanical and time consuming.
A weekly note on treasury, liquidity and practical Python. No spam, unsubscribe any time.
An agent could be set up to run scheduled sensitivity comparisons, identify the portfolios or products driving the largest movements, pull the relevant behavioural assumption inputs, and produce an initial narrative. The ALM analyst then focuses on whether the model assumptions remain valid and what the business implications are, rather than on assembling the data.
For more on the ILAAP and what adequate liquidity assessment involves in practice, the ILAAP Explained post on this blog is worth reading alongside this one.
Regulatory Reporting
PRA110, LCR reporting, NSFR submissions. These involve pulling data from multiple source systems, applying regulatory definitions and run off rates, reconciling to prior submissions, explaining movements, and packaging for submission. The reconciliation and movement analysis layer is highly structured and rule bound.
An agent could handle the data assembly, the application of regulatory run off rates, the comparison to prior period, and the generation of a draft variance commentary. Human review before submission is mandatory, and regulatory accountability sits with the firm not with a model. But the hours spent pulling and checking data could reduce substantially.
Finance and P&L Analysis
Month end P&L review involves pulling actuals, comparing to budget and forecast, attributing variances by product line or cost centre, and preparing commentary for finance leadership. A carefully scoped agent could own the variance attribution step and produce a first draft commentary, flagging the largest variances and offering a factual description of what drove them based on the data it can see.
What stays with the human: the narrative that connects the numbers to business decisions, the conversation with the business line, and the forward looking view that requires context beyond the data.
Risk Monitoring
Credit risk, market risk, and operational risk teams run regular monitoring processes: checking exposures against limits, reviewing counterparty concentrations, monitoring early warning indicators. A monitoring agent could run these checks continuously or on schedule, compare against thresholds, pull supporting data for any breach, and route a structured alert to the relevant risk manager with the context already assembled.
The risk manager receives a package rather than a trigger, and their job becomes evaluating whether the agent's assessment is correct and deciding on the response.
Operations and Reconciliation
Breaks and reconciliation items require an analyst to identify the break, investigate the likely cause (timing, data feed, booking difference), and either resolve it or escalate. An agent with access to the relevant systems could investigate a break autonomously, check the obvious causes in sequence, and either resolve the low complexity items automatically (where it has been granted the authority to do so and the resolution is unambiguous) or produce a structured investigation summary for the analyst to act on.
Data and Analytics
Finance and risk teams spend a large proportion of their time answering one off data questions. "Can you pull the repo exposure to this counterparty for the last six months?" "What is the average daily variance in our HQLA buffer over the last quarter?" An agent with access to the relevant data and the ability to write and execute SQL or Python can answer these questions directly, showing its working so the analyst can validate the output.
This connects to a broader point about whether dedicated visualisation tools remain worth their licence cost as AI becomes capable of producing analytical output on demand. There is a thoughtful treatment of that question in this piece on Tableau in an AI world.
The Treasury Analyst of 2027
Consider a treasury analyst at mid level in 2025. A significant part of their day is executing steps: pulling data, running calculations, building comparisons, writing commentary. The intellectual content of the role is real but it is often embedded inside a large volume of procedural work.
In 2027, in an environment where agents handle the procedural layer, the same analyst's morning looks different. They arrive to find a set of outputs already produced: the LCR movement attributed, the threshold breaches flagged with context, the draft commentary written. Their job is now to read critically, not to build. They ask: does this attribution make sense given what I know about yesterday's activity? Is the agent missing a context that changes the interpretation? Does this breach require escalation or is there a known explanation?
The cognitive demand shifts from execution to evaluation. That is a different skill set. It also requires a deeper understanding of the underlying processes than you need when you are simply running them, because you can no longer rely on the act of building the output to catch errors.
The value of completing each step manually falls. The value of knowing whether the result is right rises. Those two things are not the same skill and many practitioners will need to consciously develop the second.
Does This Mean AI Will Replace Banking Jobs?
Honestly: some roles will change substantially. Some tasks that currently require a junior analyst will be automatable. But "tasks" and "jobs" are not the same thing.
The tasks most susceptible to automation are the ones that are rule bound, data intensive, repetitive, and well defined. Running a daily data pull, producing a standard variance table, formatting a regulatory return, checking a reconciliation against a list of expected items. These are the tasks that junior roles often spend the majority of their time on.
The tasks least susceptible are those requiring regulatory accountability (someone must sign), human judgement in ambiguous situations, relationship and communication (explaining a risk position to a board, negotiating a funding agreement, managing a stressed liquidity event), and governance (designing the controls, deciding the thresholds, challenging the model outputs).
The honest concern is about the shape of career pathways. If the traditional entry point for a treasury or risk analyst involves building competence through executing the manual process, and that process becomes automated, then the entry level job changes. New entrants may need to develop technical and critical evaluation skills earlier than their predecessors did, while the volume of rote analytical work available for skill building may fall.
This is worth taking seriously as a profession rather than dismissing. There is a longer treatment of the job replacement question in this honest assessment on the blog.
The Risks Banks Cannot Ignore
Agentic AI introduces risks that deserve serious attention. None of them are reasons not to proceed, but all of them require active management.
Hallucinations and model errors. Language models can produce confident, plausible looking outputs that are factually wrong. In a regulatory reporting context, a wrong number that passes review is worse than a missing number. Controls must ensure outputs are validated against source data before being treated as authoritative.
Model risk. Banks have existing model risk management frameworks. In the UK, the PRA published SS1/23 (Model Risk Management) in 2023, which sets out expectations for how firms should identify, manage, and govern models. An AI agent that makes consequential decisions or produces outputs that inform consequential decisions is a model, and it should be treated as one: documented, validated, monitored, and subject to ongoing performance review.
Access permissions and least privilege. An agent that has been granted broad system access poses a significant risk if it behaves unexpectedly or if it is compromised. The principle of least privilege applies directly: each agent should have access only to what it needs for its specific function and no more.
Segregation of duties. A single agent that can both calculate a position and submit a regulatory return has collapsed a control that exists for good reason. Agent design must preserve the segregation that human workflows enforce.
Auditability and explainability. Regulators and internal audit will want to understand why a particular output was produced. Agentic systems must log their reasoning steps and tool calls in a way that can be reviewed. A black box that produced the right answer is not acceptable if you cannot explain how.
Cyber security. An agent that can authenticate to internal systems and take actions is an attractive target. Prompt injection is a genuine and serious attack vector. This covers not only direct user inputs that attempt to manipulate the agent, but also malicious content the agent retrieves from external sources during its normal operation, such as a document or web page that contains embedded instructions intended to redirect the agent's behaviour.
Third party dependency. Most agentic AI relies on a foundation model provided by a third party. That introduces concentration risk, data privacy questions, and operational dependency on a vendor whose model may change or whose service may be interrupted.
Regulatory accountability. The firm is accountable for its regulatory submissions and risk management outputs regardless of how they were produced. Regulators have been clear on this. An agent cannot be the responsible party.
Building a Control Framework for Agentic AI
Banks do not need to invent control frameworks for agentic AI from scratch. The principles already exist in model risk management, IT risk, operational risk, and third party risk management. What is needed is a deliberate extension of those frameworks to cover the specific characteristics of agents: their autonomy, their multi step action capability, and their ability to access and affect multiple systems.
A framework covering agentic AI would address: how agents are approved and scoped, what access they are granted and how that is reviewed, what actions require human confirmation before execution, how outputs are validated, how agent behaviour is monitored, how incidents are detected and responded to, and how the agent is retired or updated when the underlying model changes.
This is an area where practitioners with both banking domain knowledge and technical understanding are genuinely valuable, because they can design controls that work in practice, not just on paper.
What Happens When Agents Work Together?
A single agent working on a defined task is complex enough. Multi agent systems, where several specialised agents hand off tasks between each other, compound the complexity. One agent might gather data, pass it to a second agent that performs the analysis, which triggers a third that drafts the output, while a supervisory agent monitors the process and intervenes if something looks wrong.
The potential efficiency gain is real. So is the potential for errors to propagate across the chain before a human sees the output. The design of handoff points, validation steps, and checkpoints where a human must approve before the process continues is a genuine engineering and risk management challenge in multi agent workflows.
For those interested in how retrieval and knowledge graph architectures support these systems, how GraphRAG retrieval works in agentic AI systems explains one of the key underlying techniques that allows agents to retrieve structured, accurate context rather than relying on model memory alone.
The Skills to Start Building Now
If you are a banking practitioner thinking about where to invest your development time, here is a concrete and honest answer.
AI literacy. Understand what these systems actually do, how they fail, and what their limitations are. You do not need to be a machine learning researcher but you should be able to distinguish a retrieval augmented generation system from a fine tuned model from a pure reasoning agent. That vocabulary matters in conversations with technology teams and vendors.
Python. Not at a software engineering level, but at a level where you can read, write, and debug analytical scripts, understand what a function call does, and work with data using pandas or similar. This is the practical interface between domain knowledge and technical systems for most banking practitioners. The Academy at The Industry Portal has structured courses on Python for finance professionals if you want a starting point: browse the catalogue here.
SQL. Agents query databases. Understanding what those queries do, and whether the output makes sense given the query, is a basic quality control skill for anyone supervising agentic outputs.
API familiarity. Agents connect to systems via APIs. You do not need to build APIs but you should understand what they are, what authentication means, and why the scope of access matters. This connects directly to the control framework conversation.
Workflow design thinking. The ability to map a process, identify decision points, and specify what a machine can handle versus what requires human judgement is a skill that does not require any technical background but is central to designing agent workflows that are actually useful.
Model validation awareness. Understanding what it means to validate a model, what the key risks are, and how ongoing monitoring works. This connects to existing model risk frameworks, including SS1/23, and becomes essential as agent outputs feed into regulated processes.
AI governance. Data privacy, regulatory expectations, accountability structures. This is emerging territory but regulators are forming views. Practitioners who understand both the technology and the regulatory context are in a strong position.
From Using Software to Managing Digital Workers
The mental model shift required here is not trivial. For most of their careers, finance practitioners have used software as a tool that does exactly what they tell it. Agentic AI is different: it makes decisions. The skill of managing it is less like operating a spreadsheet and more like managing a capable but fallible junior analyst who works at volume, makes no complaints about repetition, and sometimes confidently produces something wrong.
Deep domain knowledge combined with technical capability is the most defensible position as adoption grows. An agent that knows nothing about how LCR run off rates work, what constitutes HQLA, or why a particular FTP methodology was chosen cannot be supervised effectively by someone who does not know those things either. The practitioners who will shape how these tools are deployed and controlled are the ones who understand the domain well enough to know when the agent is wrong.
That is not a reason to be anxious. It is a reason to build.

Liquidity Management
The core building blocks of treasury: cash, liquidity, funding and the ratios regulators care about.
Take the courseGet the next one in your inbox
A weekly note across Finance & Treasury, Innovation & Automation and Career Development. No spam, unsubscribe any time.
Notes across finance and treasury, innovation and automation, and career development, written by practitioners who do the work.
