Asset liability management software measures a bank's or credit union's interest rate and liquidity risk: it projects net interest income and economic value of equity under rate scenarios, produces repricing gaps and liquidity forecasts, and holds the assumptions those projections depend on. That is the model. The monthly ALCO package around it, pulling the inputs, proving them to the general ledger, building the pages, explaining what changed, checking every limit and writing the minutes, is often still done by hand in spreadsheets and slides, and it is where the hours and most of the reporting risk sit. So before comparing ALM software prices, price the package. Botminds' ALCO Reporting is built for that part: it leaves the model in place and puts agents on the work around it, with every approval kept by a person.
The arithmetic below uses Botminds' own estimate of the days a monthly community-bank package takes by hand, labelled as an estimate, and federal wage data. Where a product example is needed it comes from a fictional sample bank, Tessaly Community Bank, in the solution; its figures are sample data.
Where the wage cost of one ALCO package goes, by hand
$3,894 a package
- Pull data · 11.6%
- Prove to the general ledger · 11.6%
- Build pages · 23.2%
- Explain what changed · 17.4%
- Limits · 11.6%
- Review · 24.6%
What does asset liability management software do?
Asset liability management software turns the bank's balances, rates and contractual terms, plus behavioural assumptions, into projections of earnings and economic value under different rate paths. The interagency advisory describes the range a modern system covers: "many simulation models have the capability of forecasting the impacts on both earnings and capital by generating pro-forma income statements and balance sheets", most can assess "the impact of changing rates on the market value of the balance sheet", and "Institutions are encouraged to use the full complement of analytical capabilities of their IRR simulation models" (Interagency Advisory on Interest Rate Risk Management, 2010).
It comes in two forms. In-house software is licensed and run by the bank's own staff. An outsourced service runs the model for the bank, usually monthly or quarterly, from data the bank sends, and returns a report. Either way, the model's run is the part of the month that software does well. What the FDIC expects of the bank before any model runs, inputs proved accurate and complete against its own books, is the part that remains the bank's.
What does it cost to produce an ALCO package?
By our arithmetic, a monthly ALCO package at a community bank costs about $3,900 in wages and about $5,600 once benefits are added, or roughly $67,000 a year, before the model's own cost. That is not a large number, and it is the first thing a buyer should know: at community-bank scale, the hours alone rarely justify new software. The case, if there is one, rests on what the hours buy and what goes wrong when they run short.
The inputs are worth stating one by one, because each can be replaced with a bank's own figure.
The ALCO package cost formula, with every input labelled
| Input | Value used | Where it comes from |
|---|---|---|
| Analyst days per package | 6.5 (pull 1, prove 1, build 2, explain 1.5, limits 1) | Botminds' estimate for a monthly community-bank package, kept modest |
| Review days per package | 1.5 (Treasurer and CFO) | Botminds' estimate |
| Hours per day | 8 | Our assumption |
| Analyst wage | $56.41 an hour | BLS May 2025 median, financial risk specialists (SOC 13-2054), released May 15, 2026 |
| Reviewer wage | $80.08 an hour | BLS May 2025 median, treasurers and controllers (SOC 11-3031.01) |
| Wages as a share of total compensation | 70.0% | BLS Employer Costs for Employee Compensation, private industry, June 2026 (released September 9, 2026) |
| Packages a year | 12 | Monthly; four for a quarterly committee |
| Result | $3,894 in wages, $5,563 loaded, $66,759 a year | (52 h × $56.41 + 12 h × $80.08) ÷ 0.70 × 12 |
How many hours does an ALCO package take?
No published study measures it. Botminds' estimate for a monthly community-bank package is eight business days of analyst, Treasurer and CFO time by hand, about 64 hours, not counting the model run; its design target for ALCO Reporting is three days, about 24 hours. Those are estimates and a target, not measurements, and the honest way to use them is to replace them with a count of the bank's own last three packages, by step.
The steps that vary most are the ones that depend on things going right. Proving the inputs can take an hour when everything ties and days when a segment is missing. Building the pages can take a morning when nothing has changed and a day when a new product, a renamed account or a new limit breaks the template. A count of the average month understates the cost of the bad month, and the bad month is the one the committee remembers.
Which inputs move the answer
The annual figure is most sensitive to how often the committee meets and how many days the analyst spends, and much less to anything else. Shown on a yearly, loaded basis:
What one year of ALCO packages costs in loaded wages, under different assumptions
The gap between the base case and the target, about $40,000 a year by this arithmetic, is the most a community bank should expect to save in staff cost by automating its package, and the saving only arrives if the freed time is used for something else. A vendor proposal that promises more than that from hours alone is pricing something other than wages.
What are the hidden costs of ALM software?
The hidden costs of ALM software are the costs of everything it leaves undone, and they are larger than its price. Four recur. Lateness: when the package takes eight days after the general ledger closes, members get it with little time to read, and questions are asked in the meeting instead of answered before it. Coverage: under time pressure the limits nearest their edge get checked carefully and the rest get a glance. Explanation: the page that says what changed is written last and comes out as a description. And evidence: who approved an assumption change, and on what basis, lives in email.
Each of those has a supervisory cost when it goes wrong. The OCC's examination questions for interest rate risk include "Has management established controls that restrict access for making changes to the model, data inputs, or assumptions to only those personnel who need such access?" and "Is there an assumption logging report that shows the history of assumption revisions?" (OCC, Interest Rate Risk booklet). A bank that cannot answer either from its own systems pays for it in examination time and, possibly, a finding. Those costs do not appear on any software invoice.
Hidden costs to put a number on before buying ALM software
- Days from general ledger close to release
Every day here is a day members do not have to read.
- Breaks found after pages were built
Count the rebuilds in the last year, and what each cost.
- Limits not compared every cycle
Any limit checked only when close is a gap in the trend.
- Unexplained remainders
Basis points of margin or points of NII change nobody traced.
- Assumption changes without a log
Old value, new value, evidence, effect, approver: can you show all five?
- Minutes and actions
Days to finished minutes; actions overdue at the next meeting.
- Examination findings on data or reporting
Open findings on model inputs, assumptions or management information.
How much does asset liability management software cost?
No independent source we found publishes prices for asset liability management software, and they vary with the form (licensed or outsourced), the frequency of runs, the size and complexity of the balance sheet, and what is bundled. The useful comparison is not between quotes but between each quote and the package cost above: what does the bank still have to do by hand after buying it, and what does that cost.
Three questions make quotes comparable. What exactly is delivered each cycle: model results only, or a package, and if a package, who proves its inputs to the general ledger? What does a change cost: a new product, a new scenario, a new limit, an assumption change mid-year? And what evidence does the bank get: an assumption log, an input reconciliation, an independent validation of the model? On the last, the 2026 model risk guidance, SR 26-2, addresses vendor and third-party products and their validation, while leaving generative and agentic AI outside its scope; the guide on what SR 26-2 counts as a model sets out its terms.
Does ALM software include ALCO reporting?
Usually it includes reports of the model's results, which is not the same as the ALCO package. A model's report shows NII and EVE under each scenario, gaps and perhaps liquidity projections. The package also needs the inputs proved, every board limit compared with last month beside it, each move explained by driver, exceptions with cause, plan and owner, the assumption log, members' questions and the minutes. Those are the parts that let the board do what the FDIC expects of its reports: see where the risk comes from, judge the assumptions, and check compliance with every limit (FDIC RMS Manual §7.1).
Every board limit, every month, with the share used: a page ALM software rarely builds
What to look for in asset liability management software
Look for software that makes the bank's own obligations easier to evidence, not only the model run faster. Each line below traces to something an examiner or the interagency guidance asks of the bank, whoever runs the model, and each can be tested in a demonstration on one month of the bank's own data.
Asset liability management software: what to ask for, and why
| Ask for | Why it matters | Test it by |
|---|---|---|
| Input reconciliation to the general ledger, by segment | Inputs should be accurate and complete before results are used (FDIC §7.1) | Removing one loan segment from the extract and seeing whether it is caught |
| An assumption log with old value, new value, evidence, effect and approver | The OCC asks whether one exists; the advisory wants changes and their effects identified | Asking for last year's changes to deposit betas, with who approved them |
| Change access restricted to named people | An OCC examination question on model, data and assumption changes | Asking who can change a decay rate, and where that change shows |
| Scenarios beyond ±200 bp, and non-parallel ones the profile needs | The advisory names ±300 and ±400 bp and yield-curve and basis scenarios | Running a twist and a basis scenario on the bank's own balance sheet |
| Back-testing of projections and betas | The advisory includes back-testing in the scope of model review | Comparing last year's NII projection with actual, and modeled betas with realized |
| Every board limit compared each cycle | Boards review exceptions and management's proposed actions (FDIC §7.1) | Counting the limits the report compares against the policy |
| Independent validation documentation for a vendor model | Vendors are expected to show a credible independent party tested the mechanics (advisory) | Asking for the latest validation report and its date |
| The package, not only the results | Explanations, exceptions, questions and minutes are the bank's work either way | Asking what the bank still builds by hand after go-live |
How do you measure the ROI of ALM automation?
Measure the return of ALM automation on the four things the hidden-cost list names, before and after, from the bank's own packages: days from general ledger close to release; the share of limits compared every cycle; breaks caught before drafting rather than after; and remainders on the explanation pages. Add a fifth if the bank has had a finding: whether the evidence an examiner asks for now exists without being rebuilt.
ALCO Reporting's own design targets give a reference point, stated as targets: an approved package three days from month-end data, and every board limit, 23 of 23 in the sample, compared every month with exceptions drafted with cause, plan and owner. A pilot should measure the bank's own numbers against those, on its own month, rather than take them on trust.
Where ALCO Reporting fits, and where it does not
ALCO Reporting is not ALM software in the modelling sense: it does not calculate NII, EVE, gap or liquidity, and it never changes a model figure or an assumption in the model. It reads the model's run, whether in-house or from an outside provider, and does the work around it: proving the inputs to the general ledger and the core, drafting the pages, explaining moves by driver, comparing every limit, showing each proposed assumption change with its effect, answering members from the package's sources and drafting the minutes. The ALM Analyst prepares, the Treasurer approves every page and the release, and the CFO approves the minutes.
An assumption change with its evidence and effect, decided by the Treasurer
It fits best where the package is monthly, draws on many sources and is built by one or two people under a fixed deadline. It adds least where an outside provider already delivers a complete package, the committee meets quarterly, and the limits are few: there, the quarterly row in the chart above is the honest comparison. Where it fits beside the model, and why that matters for model risk, is set out in AI in asset liability management; for credit unions weighing an outside provider, credit union ALM providers compared covers the choice. The days themselves are followed in what an ALM analyst does.
Questions people ask
Should we outsource ALM or run it in-house?
It depends on the balance sheet and the staff, but outsourcing the model does not outsource the responsibility. The interagency advisory expects institutions that rely on third-party models to understand how those models work and what they assume, and the bank still owes the input reconciliation, the assumptions it supplies and the committee's decisions.
Is a spreadsheet ALM model acceptable?
For a small, simple balance sheet it can be, if it captures the bank's risks and is controlled. The 2026 model risk guidance excludes simple spreadsheet arithmetic from its definition of a model, but an interest rate risk simulation built in a spreadsheet is still a measurement system that examiners will test for accurate inputs, reasonable assumptions and independent review.
What does an ALM software implementation involve?
Mapping the general ledger and the core banking system to the model's instruments, loading the assumptions, running parallel months against the old process, and reconciling the two until they agree. The reconciliation is the part to plan for: the FDIC expects inputs to be proved to the general ledger by experienced staff before results are used.
What is the cheapest way to improve an ALCO package?
Change the order of the work before changing the tools: prove the model's inputs to the general ledger before building any page, compare every limit every month, and require each explanation to add up to the move. Those three habits cost little and close the input, coverage and explanation gaps described above.
How long does it take to go live with ALCO Reporting?
It is built on the bank's own package template, board policy and limits, model output and general ledger extracts, and it runs beside the existing process rather than replacing the model, so the usual approach is to run one month of the bank's own data through it and compare the result with the package the bank produced by hand.