Interest rate risk management software, in most banks and credit unions, means the ALM model: a program that projects the cash flows of every loan, deposit and investment and computes how net interest income (NII) and the economic value of equity (EVE, or NEV at a credit union) change when rates move. The model does that arithmetic well. What takes the ALM team's weeks is everything around it: pulling and reconciling extracts, back-testing the assumptions, re-running shocks when an assumption breaks, writing the memo, getting it independently checked and taking it to ALCO. Botminds' Interest Rate Risk (IRRBB) Management leaves the ALM model in place and puts agents on that surrounding work, while the ALM manager, a validator and ALCO make every decision.
The examples come from a fictional sample credit union, Norrell Federal Credit Union, as it runs through the solution. Figures about time saved are our estimates or design targets and are labelled as such.
The model computes in minutes; the change around it takes weeks
8
parallel shocks, −300 to +400 bp, re-run by the sample's ALM model in under four minutes
15days
estimated business days today from a quarter's back-test to a cited memo in front of the validator
2days
design target for the same path with the agents doing the mechanical steps
28
key assumptions back-tested every quarter in the sample, not once a year (target)
What does interest rate risk management software do?
Interest rate risk management software measures how a change in rates moves earnings and value. It holds the institution's balances and contract terms, applies behavioural assumptions to products without fixed maturities, and computes two families of results: earnings at risk over one or two years, and economic value under instantaneous shocks. The OCC describes the earnings side simply: "The model multiplies projected average rates by projected average balances." On the value side, "economic value models begin by calculating the net present dollar value of rate-sensitive assets, liabilities, and off-balance-sheet positions" (OCC Comptroller's Handbook, Interest Rate Risk, 2020).
Almost every number the model produces depends on assumptions it cannot derive by itself: how fast non-maturity deposits run off, how much of a rate rise reaches depositors, how fast mortgages prepay. The model applies them; it does not check whether customers still behave that way. That is why the regulators treat the assumptions, not the arithmetic, as the main source of error. The advisory reminds institutions that while they "may rely on third-party IRR models, they are expected to fully understand the underlying analytics, assumptions, and methodologies" (Interagency Advisory on Interest Rate Risk Management, 2010).
So when a bank or credit union shops for interest rate risk software, it is usually choosing between two different things. One is the ALM model itself, the engine that computes EVE and NII; most institutions already have one, built in-house or licensed. The other is the work that feeds the model and governs its assumptions, which is where the hours and the examination findings are.
The ALM model and the agents around it do different jobs
The ALM model: Projects cash flows and computes EVE (or NEV) and NII under each rate scenario.
Agents around the model: Pulls and ties the data, back-tests assumptions, asks the model for what-if runs, drafts and challenges the memo.
The ALM model: Balances, contract terms and an approved assumption set.
Agents around the model: Read-only extracts from the core and loan systems, the general ledger, the policy and prior memos.
The ALM model: The ALM manager, and only by releasing an approved assumption set.
Agents around the model: Nobody, through them: they never change an assumption, a limit or the live model.
The ALM model: A wrong assumption gives a precise, wrong number with no warning.
Agents around the model: A failed run or missing extract is reported and stops that step; it is never estimated.
The ALM model: Validated as a model, with back-testing and independent review.
Agents around the model: Versioned with an owner, a prompt and a confidence threshold; changes approved by Model Validation.
Where an assumption review's days go
An assumption review spends most of its time before and after the model run, not in it. On our estimate for the sample credit union, a quarter's path from back-test to a memo in front of the validator takes about 15 business days by spreadsheet and email: three to pull and reconcile extracts, five to back-test and find causes, two to re-run, three to write and support the memo, two for the independent review. The model's own run is minutes inside the two re-run days.
Where the business days go: today against the design target
Today, by spreadsheet and email: about 15 business days
- Extracts and general ledger tie-out · 20%
- Back-test and causes · 33.3%
- Re-run NEV and NII · 13.3%
- Memo and its support · 20%
- Independent review · 13.3%
With the agents: about 2 business days (target)
- Extracts and general ledger tie-out · 10%
- Back-test and causes · 15%
- Re-run NEV and NII · 10%
- Memo and its support · 25%
- Independent review · 40%
The second bar is the argument. When the mechanical steps shrink, the largest remaining share is the independent review and the memo, which is where human judgement belongs. A tool that speeds up the model run saves minutes; one that shortens the extract, back-test and drafting steps returns the days, and leaves the validator and the ALM manager more of what is left.
What tasks in interest rate risk can be automated?
The tasks that can be automated are the ones with a defined input and a checkable output: pulling extracts, tying them to the general ledger, measuring each assumption against what customers did, re-running the model with a changed value, reading results against limits, and drafting a memo whose every figure is cited. The tasks that should not be automated are the ones that commit the institution: choosing the value to propose, accepting or challenging it, voting, and releasing a new assumption set.
Regulators already accept automation in the first group. The OCC's validation standards ask whether "data extracts and model inputs have been reconciled with transactions and general ledger systems", and add that "it is acceptable for parts of the reconcilement to be automated." The FDIC calls assumption summary reports "an important tool that management and examiners can use to ensure that reasonable assumptions have been entered into the measurement system" (FDIC RMS Manual 7.1). Neither text asks a person to retype a balance; both ask a person to own the conclusion.
Ten tasks around the ALM model: who does each, and what a person still decides
| Task | Done by | What stays with a person |
|---|---|---|
| Pull the quarter's share, certificate and loan extracts | Extract Reconciler agent | Nothing to decide; a missing extract stops the back-test for that assumption |
| Tie every extract to the general ledger | Extract Reconciler agent | Reviewing any break over the 0.10% tolerance |
| Measure each assumption against what customers did | Back-test agent | Any cause attribution below 0.85 confidence goes to the ALM manager |
| Explain the gap with cited causes | Back-test agent | Judging whether the causes will recur |
| Re-run NEV and NII with the observed value | Sensitivity agent asks the ALM model | The model computes; the live set is never touched |
| Read every run against policy limits and the NCUA test | Limits Watch agent | A breach goes to the CFO the same day |
| Draft the change or re-affirmation memo | Governance agent | The ALM manager edits it, picks the value and submits as maker |
| Recompute the number and test other explanations | Challenge agent, for Model Validation | The validator accepts or challenges, with a reason code |
| Build the ALCO item and board packet | ALCO Packet agent | ALCO members vote; the chair notes each vote |
| Release the new assumption set to the model | ALM manager only | The whole step: no agent can release a set |
What stays with the ALM manager, the validator and the CFO
Every decision that changes what the institution reports or does stays with a named person. The ALM manager keeps the proposal and the release; Model Validation keeps the acceptance or challenge; ALCO keeps the vote; the CFO keeps the response to a breach and the report to the board. The agents can say that regular share decay ran 8.6 points faster than assumed and what that does at +300 bp; they cannot decide that 22.6% is the right value for next year.
That split is deliberate, and it is what keeps the arrangement defensible. An agent that drafts a memo and an agent that recomputes the number for the validator are useful because neither can approve its own work. In the sample, the validator's agent reads the raw extract and never sees the first-line memo before its recompute, so when the two numbers agree to 0.02 points the agreement means something. What a validator needs on top of that is set out in ALM model validation under SR 26-2.
Interest Rate Risk (IRRBB) Management: every assumption against what members did
Do you need new ALM software to back-test assumptions?
No. Back-testing an assumption compares what the model assumed with what customers did, using the institution's own core and loan data; it does not need a different ALM model. What it needs is the extracts, a tie-out to the general ledger, a consistent method for each assumption, and a way to re-run the existing model with the observed value without disturbing the live set. Interest Rate Risk (IRRBB) Management does those steps around the model you already run, and asks that model for what-if runs.
That matters for the buying decision. A new ALM model has to be loaded with balances, terms and assumptions and validated before anyone relies on it, while the examiner's questions are mostly about assumptions and their support, which a new engine does not answer. The 2012 interagency FAQ lists what to weigh when choosing a model, including "the extent to which the model uses automated processes compared with manual procedures" and "whether the model has automated interfaces with institution source systems" (Interagency IRR FAQ, January 2012). If the model is sound and the manual work is the problem, the fix belongs around the model.
A what-if re-run in the institution's own ALM model, live set untouched
Is IRR software a model under SR 26-2?
The ALM model almost certainly is; much of the work around it may not be. Since April 17, 2026, model risk guidance for banks is SR 26-2 from the Federal Reserve and OCC Bulletin 2026-13, issued with the FDIC, which replaced SR 11-7 (SR 26-2; OCC Bulletin 2026-13). It narrows "model" to complex quantitative methods built on statistical, economic or financial theory, and leaves out simple spreadsheet arithmetic and deterministic, rule-based software. An ALM model that discounts projected cash flows under behavioural assumptions fits the definition; a reconciliation that sums an extract does not.
Three features of the new guidance shape the answer for interest rate risk. It is aimed at banking organisations above $30 billion in assets; it states that it does not set enforceable standards; and it places generative and agentic AI outside its scope, leaving their governance to the bank's own risk management. How the same definition sorts other bank tools is worked through in whether a customer risk rating model is a "model" after SR 26-2. For a community bank or credit union, the interest-rate-specific expectations (validation, back-testing, independent review) still come from the 2010 advisory, the 2012 FAQ and the examination manuals.
One caution for readers of the OCC's Interest Rate Risk booklet: its model risk section, dated 2020, still quotes the 2011 definition of a model, which also reached methods built largely on expert judgement. That definition no longer applies. The solution's own governance does not depend on the answer: each agent has a version, a prompt, a model, a confidence threshold and an owner, any change to an agent is approved by Model Validation, and every human override is counted with a reason code.
What an examiner asks of your IRR software
An examiner asks less about the software's brand than about what it was fed and how its results were checked. The OCC's request letter for an interest rate risk review asks for "a summary of significant changes to IRR modeling since the last examination", "a narrative describing the process by which the bank's accounting records are input into the model", with a note of "any manual processes necessary to upload assets and liabilities", and "a copy of the most recent model validation and back-testing analysis (e.g., EAR and EVE) performed", with management's responses and "the project plan for corrective action" (OCC booklet, request letter items 21 to 23).
Each item is a test of the work around the model. Manual uploads are a data-integrity question; the change summary is an assumption-governance question; the validation and back-testing analysis is the evidence that the outputs match reality. In the sample, the examiner's package is built from one trail of every action by a person or an agent, so the answer to each item is an export rather than a reconstruction.
A cited change memo, drafted by an agent and submitted by a person
Questions to ask before you buy interest rate risk software
Ask questions that separate the engine from the work around it, and that test whether the tool keeps decisions with people. The list below is the one we would use on any vendor, including us.
Ten questions for any interest rate risk software, including ours
- Does it replace your ALM model or work with it?
A new model must be validated before you rely on it. If yours is sound, look for tools that work with it.
- Can it read your core and loan servicing extracts read-only?
Write access to source systems is a control problem nobody needs.
- Does it tie every extract to the general ledger with a tolerance you set?
The OCC asks whether extracts are reconciled to the general ledger; the tool should show the difference, not just a pass.
- Does every figure open its source?
A number the validator cannot trace back to an extract line or a model run is a number to recompute by hand.
- Can anything in it change the live assumption set?
The right answer is: only a named person, after approval. Proposals should live in what-if sets.
- Does the validator get an independent recompute?
A second line that starts from the first line's memo is checking the prose, not the number.
- What happens when a run fails or an extract is late?
It should be reported and the step stopped, never filled in with an estimate.
- How are automated components governed?
Versions, owners, thresholds, approvals for changes and a count of human overrides.
- How is customer data protected?
Masking of names and account numbers, logged unmasked views, and BSA fields removed before anything reads the extract.
- Can you test it on last year's data before committing?
A pilot on a closed year shows whether its back-tests agree with what you already know.
The last question is the one that settles most decisions. A month spent back-testing last year's assumptions on your own extracts shows both whether the tool works and whether your current deposit study still holds; a 30-day pilot on last year's data lays out the weeks.
Where Interest Rate Risk (IRRBB) Management does not fit
Interest Rate Risk (IRRBB) Management is not an ALM model. It does not project cash flows or compute EVE, NEV or NII itself; it asks your model to. An institution that has no model it can run, because it receives a quarterly interest rate risk report from an outside provider, can still use the back-testing, memo and approval steps, but the what-if re-runs depend on what the provider can turn around. The 2012 FAQ recognises that institutions "that completely outsource the measurement process" need other means to estimate the effect of changes.
It is also not a deposit study, a pricing engine or a hedging tool. It tells you that an assumption from your last study has stopped holding and what that does to your limits; deciding a new deposit rate or a swap is the ALCO's work. And the sample is a credit union: at a bank the measure is EVE rather than NEV and the owner is often the corporate treasurer, but the assumptions, the back-tests and the maker-checker route are the same.
Questions people ask
What is the difference between ALM software and interest rate risk software?
In practice they are usually the same engine: an asset-liability model that computes earnings and economic value under rate scenarios. "ALM software" sometimes also covers liquidity and budgeting modules. Interest rate risk work adds the governance of assumptions, back-testing and limit reporting around that engine.
Can AI change an ALM assumption?
It should not, and in Interest Rate Risk (IRRBB) Management it cannot. The FDIC expects assumption changes to be reviewed and approved before they occur. Agents measure, re-run in what-if sets and draft; the ALM manager proposes, Model Validation reviews and ALCO approves before the model uses a new value.
What are interest rate risk models for banks?
They are earnings-at-risk simulations, which project net interest income over one to two years or longer, and economic value models, which discount all future cash flows to measure the change in EVE. The 2012 FAQ says institutions should use a combination of both. Gap reports remain only for the simplest balance sheets.
How long does it take to set up interest rate risk software?
It depends on which kind. A new ALM model must be loaded with balances, contract terms and assumptions and validated before it is relied on, so it runs in parallel with the old one first. Tools that work around an existing model start from its outputs and your extracts, so the first step can be a back-test of a year that has already closed.
Do examiners accept vendor-built interest rate risk models?
Yes, but the institution remains responsible for them. The 2010 advisory says institutions may rely on third-party models but must fully understand the analytics, assumptions and methods, and the vendor should document that a credible independent party has tested the mechanics.