AI in asset liability management is most useful today around the ALM model rather than inside it. The model's job, projecting net interest income and economic value under rate scenarios, is a quantitative model in the regulators' sense and is validated as one; the work around it, proving the model's inputs to the general ledger, explaining what moved, comparing every measure with the board's limits, logging assumption changes, answering committee members and drafting minutes, is where the hours go and where AI agents can take the mechanical part without touching a single model figure. That design also follows the 2026 model risk guidance, which keeps traditional models in scope and leaves generative and agentic AI to each bank's own risk management. Botminds' ALCO Reporting is built that way: its agents read the model's run and the systems around it, draft and check, and hold; people approve every page, exception and assumption change.
Examples come from a fictional sample bank, Tessaly Community Bank, as it runs through the solution; its people and figures are sample data. Regulatory and research text is quoted from the source, linked where it appears.
Where AI agents sit in asset liability management: between the systems and the people
Systems that hold the numbers stay as they are · read only
Agents read, check, draft, hold
People decide
How is AI used in asset liability management?
AI is used in asset liability management in two quite different places, and they carry different risks. The first is inside the measurement: statistical and machine-learning estimates of prepayment speeds, deposit betas or decay rates that feed the model. Those are models in the full sense and are validated as such. The second is around the measurement: the reporting, reconciliation and governance work that turns a model run into an ALCO package. That is where generative and agentic AI fit, because the work is reading, comparing, drafting and tracking, and every output can be checked against a source.
In the second place, six jobs recur every month. Proving the model's inputs to the general ledger and the core before anything is drafted. Explaining each moved measure by its drivers. Comparing every measure with its board limit and drafting exceptions. Showing a proposed assumption change with its effect and evidence. Answering members' questions from the package's sources. And drafting the minutes and tracking the actions. The FDIC already expects some of this to be automated: input reconciliation "is often done using automated software that can identify and report exception items" (FDIC RMS Manual §7.1). Agents extend the same idea to the rest of the package.
Can AI replace an ALM model?
No, and a bank should not want it to. The ALM model's projections are the numbers the board's limits are written against; they need documented methods, validated assumptions and back-testing, which the 2010 interagency advisory expects of interest rate risk models and the 2026 model risk guidance expects of quantitative models generally. A generative model producing NII and EVE figures would be an unvalidated replacement for a validated one, with no gain in accuracy.
Replacing the model would also throw away what works. A model run is only as good as its inputs and assumptions; the advisory's model validation section is about inputs, assumptions and back-testing, and the 2023 reviews of Silicon Valley Bank and Signature Bank point to the same places: assumptions, data inputs and reporting. The productive question is not whether AI can calculate EVE, but whether it can make sure the inputs that EVE is calculated from are complete, and that every change to an assumption is visible to the committee.
Replacing the ALM model against working beside it
Replace the model with AI: New, unvalidated projections of NII and EVE
Agents around the model: The validated model's projections, unchanged; agents never change a model figure
Replace the model with AI: A new model to document, validate and back-test before use
Agents around the model: The model's validation stands; the agents' outputs are drafts checked against sources
Replace the model with AI: Embedded in a system the committee cannot read
Agents around the model: Proposed by the analyst, shown with their effect, decided by the Treasurer
Replace the model with AI: Parallel runs, conversion and revalidation
Agents around the model: One month of the bank's own data alongside the existing process
Replace the model with AI: The limits are measured on wrong numbers
Agents around the model: A draft is held: notes that do not sum, or inputs that do not tie, stop the page
Is an AI agent working on the ALM model a model under SR 26-2?
Generally not under the guidance itself. SR 26-2, issued with the OCC and FDIC on April 17, 2026, replaced SR 11-7 as the agencies' model risk management guidance. It defines a model as a complex quantitative method that applies statistical, economic or financial theory to produce quantitative estimates, excludes simple spreadsheet arithmetic and deterministic rule-based software, applies its principles to traditional quantitative models and to non-generative, non-agentic AI models, and places generative and agentic AI outside its scope. It is aimed mainly at banks with more than $30 billion in assets, and the OCC's version says it does not set enforceable standards (Federal Reserve SR 26-2; what SR 26-2 counts as a model, in detail).
Outside the guidance is not outside governance. The guidance itself says a bank's own risk management and governance practices should decide the controls for tools it does not cover, and the Vice Chair for Supervision has explained the intent: the Fed, the OCC and the FDIC amended the guidance so that it does not reach generative or agentic AI (her words are quoted in AI treasury management software). She added: "Going forward, we expect other risk-management and governance practices to support adoption of generative and agentic AI in ways that will encourage ongoing innovation" (Bowman, May 1, 2026).
For a community bank, the practical reading has two parts. The ALM model stays under the controls the interest rate risk guidance already expects: independent review, back-testing, and documentation of assumption changes. The agents around it need controls of their own: what they may read, what they may never do, who approves their output, and a trail of every step. The agencies said they plan a request for information on model risk and AI; as of late October 2026 none had appeared in the Federal Register.
What do regulators say about generative AI in banks?
US supervisors in 2026 describe generative AI as permitted, governed by the bank's own controls, and best used with people in the loop. In testimony in March 2026, a Federal Reserve official told Congress that "While our supervised institutions typically have controls such as sound development practices, effective testing regimes, and human-in-the-loop systems in place to manage AI risks, financial institutions should proactively implement governance, risk management, and oversight policies as AI usage becomes more widespread" (Federal Reserve testimony, March 26, 2026).
Internationally, the Financial Stability Board's final report on sound practices, published on October 15, 2026, sets out the risks particular to agents. It warns of unauthorised actions, where agents "may act autonomously in pursuit of pre-defined goals" and take steps "inconsistent with organisational policies, legal requirements, delegated authority, or other intended constraints"; of erroneous actions, noting that "An AI agent can take hundreds of intermediate steps in pursuit of its goals and make errors in any of those steps"; and of oversight, because no one can watch every agent decision in real time once agents are used widely (FSB, Sound Practices for Responsible Adoption of AI, final report; the sentence is quoted in questions to ask of liquidity monitoring tools).
Each of those risks has a design answer in ALM reporting. Unauthorised action is answered by agents that cannot approve, release, change a limit or change the model. Erroneous action is answered by checks that stop a draft: inputs that do not tie hold the pages they touch, and notes that do not sum are not published. Oversight at scale is answered by showing the agent's steps on the page, with sources, and putting a person's approval between every draft and every reader.
Can AI write ALCO commentary?
AI can draft ALCO commentary, if the draft is held to a standard a person can check in a minute. In ALCO Reporting that standard is three rules: every amount in a note opens the source passage it came from; the amounts must add up to the move, and a remainder holds the page; and a note below the bank's confidence threshold, 85% in the sample, goes to the ALM Analyst before the page is drafted. On the sample bank's margin page, three notes explained a 9 basis point fall with 0.0 bp left over, and the lowest confidence was 93%. How the margin note is built is worked through in net interest margin analysis by driver.
The analyst accepts or edits each note with a reason, and the Treasurer approves the page. The agent's steps are listed under its notes: what it read, what moved, where each amount came from, and the check that they sum. That list is the answer to the FSB's concern about the hundreds of steps an agent may take: the steps are not hidden, and the result is checked by a person before anyone reads it.
What must a person approve in ALM?
A person must approve anything that changes what the committee or the board relies on: every page before members read it, the release of the package, every fix to an input, every exception plan, every assumption change, the minutes, and every answer to a member. Limits and policy changes belong to the board. In ALCO Reporting, agents prepare all of those and approve none of them.
Data in, drafts out, and a person between every draft and every reader
Agent
Read the run and the sourcesThe model run and ten other sources, read only.
Never: Never writes to the model or the general ledger
Agent
Check the inputsFourteen checks against the general ledger and the core; a break holds the pages it touches.
Never: Never drafts on an input that does not tie
A person decides
Fix and approve the fixThe ALM Analyst fixes the input; the Treasurer approves the fix with a reason code.
Agent
Draft and explainDrafts the pages, the margin notes, the limit comparisons and any exception or watch note.
Never: Never publishes notes that do not sum
A person decides
DecideThe Treasurer approves each page, each exception plan and any assumption change, or sends it back with a reason.
A person decides
ReleaseThe Treasurer releases the package to members; the CFO, as chair, later approves the minutes.
The Treasurer approves the page; only then can members read it

What data does AI need for ALM?
AI needs the same data the ALM analyst uses, and nothing more: the model's run, the general ledger trial balance, loan and deposit balances, rates and migration from the core banking system, securities holdings, any partner or brokered balances and their agreements, borrowing capacity statements, the board's policy and limits, the deposit study, and last month's package and minutes. In the sample, that is eleven sources, read only.
What matters as much is what it must not see or show. In the sample bank's settings, members see released pages only; depositor concentration shows ranks and amounts, never names; and investigation and suspicious activity report flags are excluded from every source, so they cannot appear on any page or in any answer. The FSB names data exposure among agents' risks: agents "may expose or manipulate sensitive data such as customer details", which is why the exclusions are set at the source rather than left to the agent's judgement.
How do you go live with AI in treasury?
Go live with AI in treasury by running it beside the existing process on one month of the bank's own data, without replacing anything, and comparing the result with the package the bank produced by hand. Because the model, the general ledger and the board portal stay as they are, there is no conversion and no revalidation of the model; the integration is read access to the run and the sources, and a copy of the bank's package template, policy and limits.
The comparison month answers four questions. Do the agents' tie-outs find the breaks the bank found, and any it missed? Do the margin and NII notes sum, and do they agree with the analyst's own explanation? Are all the board's limits compared, with the same exceptions? And does the trail show who approved what? A bank that can answer yes to all four on its own month has its go-live evidence, and its internal audit has something concrete to review.
An assumption change shown with its evidence and its effect, before anyone decides

Questions to ask before you integrate AI with an ALM model
The questions that matter before integrating AI with an ALM model are about boundaries and evidence, not features. A vendor, including Botminds, should be able to answer each from a working demonstration on the bank's own data.
Integration questions for AI in asset liability management
- Does it write to the model, the general ledger or the core?
The answer should be no: read access only.
- What stops a draft built on inputs that do not tie?
Ask to see a break hold the pages it touches.
- What stops an explanation that does not add up?
A remainder should hold the page, not appear as "other".
- What can an agent never do?
Approve, release, change a limit, change an assumption in the model.
- Who approves each kind of output, and where is that kept?
Maker and checker, with reason codes, on a trail that cannot be edited.
- Which data is excluded at the source?
Customer-level detail for members; investigation and SAR flags everywhere.
- Can internal audit see every agent step?
Steps, sources and confidence, exportable for examiners.
- What happens to the model's validation?
It should stand unchanged, because the model is unchanged.
The costs on the other side of the decision are set out in pricing the ALCO package before the software, and the model-validation expectations that stay with the model are in the 2010 advisory's section on independent review (Interagency Advisory on Interest Rate Risk Management).
Questions people ask
Can machine learning be used for deposit betas or prepayments?
Yes, but then it is part of the model. SR 26-2 applies its principles to non-generative, non-agentic AI models as well as traditional ones, so a machine-learning beta or prepayment estimate needs the same documentation, validation and back-testing as any other assumption that feeds the board's limits.
Which guidance covers a community bank's ALM model?
Mainly the interest rate risk guidance. SR 26-2 says it is expected to be most relevant to banking organizations with more than $30 billion in assets, and that smaller banks' models are typically subject to internal practices suited to their size. A community bank's ALM model remains subject to the interest rate risk guidance, including independent review of inputs, assumptions and back-testing, as ALM model validation under SR 26-2 sets out.
Will examiners accept AI-drafted ALCO commentary?
Examiners judge the commentary, not who typed it: whether it explains the moves, whether assumption changes and limit exceptions are documented, and whether management acted. Commentary whose amounts open their sources and add up to the move, approved by a named person, gives an examiner more to test than commentary written from memory.
What is the risk of AI hallucination in ALCO reporting?
The risk is a fluent explanation with a wrong number or an invented cause. The controls are mechanical: every amount must cite a source passage, the amounts must sum to the move, and a person approves the page. An explanation that cannot be traced is not published.
Does AI in ALM need board approval?
No federal rule requires board approval of a reporting tool, but the board approves the policies it serves, and the Federal Reserve has urged institutions to put governance, risk management and oversight policies for AI in place as use spreads. A bank may well choose to take a tool that drafts board-facing material to the board's risk committee before go-live.