Asset Liability Management Software: How Do You Build an Interest Rate Risk Model an Examiner Will Actually Accept?

Why the ALCO package is the most fragile document in the bank

The treasurer opens the monthly file at 7am on the day before the committee meets. Loan cash flows came out of the core on the 3rd. The investment portfolio came from the safekeeping agent as a PDF that somebody keyed. The deposit decay assumptions came from a study run in 2023 by a consultant who is no longer engaged. The prepayment speeds are a hard coded vector in row 214 that has never been changed because nobody now working here knows where it came from. The output is a net economic value sensitivity table that the board will look at for four minutes and that the examiner will spend two days on.

That gap is the whole problem. Interest rate risk modelling is one of the few places in a bank where a number with enormous consequence is produced by a process with no reproducibility. And the exposure is real in both directions. Deposit runoff and rate shocks are what actually damage balance sheets, and the supervisory expectation, set out in the interagency guidance on interest rate risk management and reinforced by model risk guidance in SR 11-7, is that you can document assumptions, demonstrate they were tested against your own history, and show independent review. A spreadsheet whose author has left cannot do any of those three.

Empyrean Solutions, ZM Financial Systems, Quantitative Risk Management, Abrigo and Moody's Analytics all build genuinely capable ALM engines, and for many institutions one of them is the correct purchase. Where they get uncomfortable is that the engine is only as good as the instrument data you feed it and the assumptions you attach, and both of those are yours. Vendors give you a robust cash flow engine and a place to type a beta. They do not give you a defensible answer to where that beta came from, and that is precisely the question a model validator opens with.

Problem 1: instrument cash flows are approximated because the extract is thin

Your core will happily give you balance, rate and maturity. It is far less willing to give you the things that actually shape a cash flow: the rate floor written into the note, the reset index and lookback convention, the amortisation type on a balloon, the fact that 300 commercial loans have a rate ceiling that binds at plus 200 basis points, the prepayment penalty schedule that steps down over five years. So the model aggregates. Loans get bucketed by rate band and repricing bucket and modelled as one synthetic instrument, and every embedded option in the portfolio disappears at that moment.

The consequence is not academic. A portfolio with binding caps looks far more asset sensitive than it is, and the shortfall shows up in the exact scenario you built the model to warn you about. A custom build starts by fixing the input, not the engine: pull loan level attributes including floors, caps, indices, reset schedules and penalty terms, hold them as a proper instrument record, and generate contractual cash flows per instrument before any behaviour is applied. Once that exists, aggregation becomes a reporting choice rather than a modelling compromise, and you can answer which specific loans are driving a shock result.

Problem 2: deposit assumptions are the model, and they are usually borrowed

For most community and mid sized institutions the answer to what happens in a rate shock is decided almost entirely by non maturity deposits. Their beta, their decay, and how much of the balance you are willing to treat as core. Those three numbers move economic value more than anything on the asset side, and in a great many models they are industry averages or a consultant's study from a rate environment that no longer exists.

The uncomfortable part is that you have the data to do better. Your core holds years of account level balance and rate history through an actual tightening and easing cycle. A custom build turns that into an assumption you own: estimate beta by product and by segment from your own repricing history, measure decay by cohort with account age and channel as factors, and hold the resulting assumptions in a registry with the estimation window, the method, the owner and the approval date attached. When the validator asks where the money market beta of 0.45 came from, you show the regression on your own accounts, not a citation. That single artefact changes the tone of a validation review more than any other feature we build in this category.

Segmenting matters more than sophistication. A single blended beta across all money market accounts hides that your top 50 relationships behave completely differently from the retail tail, and in a stress those relationships are the ones that move first and largest.

Problem 3: nobody can reproduce last quarter's run

Ask most institutions to reproduce the ALCO package from two quarters ago exactly as it was produced and the honest answer is that they can show you the PDF. The data has been overwritten, the assumption tab has been edited, and the model version is whatever the workbook is today. That is a finding waiting to happen, and it also removes your ability to do the single most persuasive thing in model risk management: back testing.

A build fixes this structurally. Every run is an immutable artefact capturing the instrument snapshot, the assumption set version, the scenario definitions, the code version and the outputs. Then back testing becomes trivial rather than heroic. Take the run from four quarters ago, compare projected net interest income to what the general ledger actually recorded, and decompose the variance into volume, rate and behaviour. Doing that consistently gives you the one thing that makes a model credible: evidence that when it was wrong, you found out and adjusted.

Problem 4: the scenario set is compliance theatre until it includes your own scenario

Standard parallel shocks of plus and minus 100 through 400 basis points are table stakes and every vendor produces them. They are also the scenarios least likely to happen. The ones that hurt are specific to your balance sheet: a flattening or inversion combined with deposit migration from checking into certificates, a funding scenario where your largest twenty depositors move a quarter of their balances in a month, a repricing scenario where competitors move deposit rates faster than loan yields catch up.

What a custom build allows is a scenario as a first class object your treasurer can compose: a rate path, a set of behavioural overrides, a balance sheet growth strategy, and an execution assumption about what management would actually do. That last piece is what makes the output useful to a board rather than to a file. A model that says economic value falls 22 percent in a rising rate scenario prompts nothing. A model that says it falls 22 percent unless you extend funding by 18 months at current spreads, which costs this much in net interest income, is a decision. Getting there requires linking your ALM engine to your actual funding options and pricing, which is exactly the integration a packaged product will not do for you.

What this costs and how long it takes

A focused first release, meaning instrument level extraction and cash flow generation, an assumption registry with versioning and approval, and net interest income plus economic value simulation across the standard shock set with drill down to instruments, runs $95,000 to $210,000 and ships in 16 to 22 weeks. A full platform adding behavioural deposit estimation from your own history, back testing, liquidity and funding concentration scenarios, board and committee reporting, and a validation evidence pack runs $250,000 to $650,000 phased over 9 to 16 months.

What drives cost up specifically in this category: the quality of the core extract, which is the single biggest variable and occasionally the whole project, since some cores simply do not expose rate floors or reset conventions without a custom report; a complex investment portfolio with structured securities, which need external cash flow projections rather than internal ones; derivatives, because a swap portfolio brings hedge accounting and collateral into scope; and multiple charters or a recent acquisition, since two cores means two extraction pipelines and a reconciliation between them.

What holds it down: doing loans and non maturity deposits properly in phase one and modelling the investment portfolio with vendor supplied cash flows until phase two. That covers the balance sheet where your risk actually lives.

Build versus buy, and when a vendor model is right

Buy if you are under roughly $700M with a conventional balance sheet, no derivatives, a simple deposit book and no acquisitions pending. Abrigo, ZM Financial Systems or an outsourced modelling service will produce a defensible package for a fraction of a build, and the examiner will be satisfied. Buying is also right if your constraint is people rather than software: a model you cannot staff is worse than a service you can.

Build when two or more of these are true. Your loan book has embedded options that your current model buckets away. Non maturity deposits are more than half your funding and your betas are borrowed rather than estimated from your own history. You cannot reproduce a prior run from data. Your last validation or examination produced findings on assumption documentation or lack of back testing. Or the treasurer needs the model to answer strategy questions about funding and pricing, not just to produce a compliance table each month.

Our position is that the engine is rarely the reason to build. The reason to build is that the assumptions, the instrument detail and the reproducibility are institution specific, they are what validation actually examines, and every vendor leaves them as your homework.

How to choose a developer for ALM and interest rate risk software

Ask them to describe an instrument record before they describe a screen. If floors, caps, index, reset frequency, lookback and amortisation type do not come up unprompted, they have not built this before and your cash flows will be approximations wearing a nice interface.

Ask how a run is stored. The answer must be an immutable artefact with the data snapshot, assumption version, scenario set and code version, because without that there is no back testing and no reproducibility, and without those two a validator will not sign off no matter how good the maths is.

Ask what they will hand a model validator. A serious team produces a technical specification of every calculation, the estimation evidence for behavioural assumptions, the back test results and a limitations statement. If validation support is treated as documentation to write later, budget for a second project.

Ask who owns the code, the model specification and the cloud accounts, and get it in writing before kickoff. At Digital Heroes the client owns all of it from the first commit. A model you cannot open, explain and modify is not your model, and in a supervisory conversation that distinction becomes very expensive very quickly.