Asset Liability Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why do instrument cash flows keep getting scoped as buckets?

Because the core extract is thin and nobody argues with it. The core will happily give you balance, rate and maturity. It is far less willing to give you the rate floor written into the note, the reset index and lookback convention, the amortisation type on a balloon, the ceiling that binds on three hundred commercial loans at plus 200 basis points, or the prepayment penalty schedule that steps down over five years.

So the project scopes around what is available. Loans get grouped by rate band and repricing bucket and modelled as one synthetic instrument, and every embedded option in the portfolio disappears at that moment. The result looks reasonable, produces a tidy sensitivity table, and is wrong in a specific direction: a portfolio with binding caps looks materially more asset sensitive than it is. The shortfall then shows up in exactly the scenario the model existed to warn you about.

The fix is to treat the extract as the project rather than as an input. 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 behavioural assumption is applied. Some cores will not expose those fields without a custom report, and finding that out in week two is a schedule problem. Finding it out in week fourteen is a different project.

Ask a developer 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, your cash flows will be approximations wearing a better interface.

What goes wrong when the investment portfolio and prior assumptions get migrated?

Three things, and all of them are quiet. The investment portfolio frequently arrives from a safekeeping agent as a document somebody keys, which means position level detail is transcribed rather than imported and structured securities carry whatever cash flow assumption the last person applied. Prepayment vectors get carried across as hard coded numbers with no provenance, because the person who set them has left and the model has been inherited twice.

The most damaging item is the assumption set itself. Deposit betas and decay factors are usually inherited from a consultant study or an industry reference, and when they move into a new system they arrive without their estimation window, their method or their approval date. The new model then looks more rigorous than the old one while resting on exactly the same unexamined numbers, which is a worse position because it invites confidence.

Handle it by refusing to migrate an assumption without provenance. Every behavioural assumption enters the registry with its estimation window, method, owner and approval date, even if the honest entry says inherited, source unknown, review scheduled. That record is uncomfortable to write and it is precisely what a validator wants to see, because it shows you know which numbers are evidenced and which are placeholders. Then schedule the re-estimation work rather than leaving it as an intention.

Why do core and general ledger integrations break after launch?

Because they are batch extracts, and batch extracts fail in ways that look like nothing happened. The core upgrades and a field changes type. A new loan product is added and lands in a category the extract filter never included, so an entire product line is silently missing from the model. Month end timing shifts and the snapshot is taken a day early. Nothing errors. The run completes. The numbers move slightly and everyone assumes it is the market.

The general ledger side breaks differently. Back testing requires comparing projected net interest income to what the ledger actually recorded, and that comparison depends on account mappings that get reorganised during a chart of accounts change or an acquisition. Once the mapping drifts, your variance analysis becomes noise and people stop looking at it, which is exactly when it would have been most useful.

The controls are simple and they belong in the first release. Reconcile the instrument extract to the core trial balance on every run, by category and by count, and refuse to publish a run where the difference exceeds a tolerance you set. Alert on new product codes that no rule recognises. Version the ledger mapping with effective dates so a historical back test still uses the mapping that applied at the time. None of this is sophisticated, and all of it is the difference between a model people trust and one they quietly stop using.

What happens when validation evidence and back testing are not covered?

You get a working model and a failing examination. Supervisory expectations under the interagency guidance on interest rate risk management, reinforced by model risk guidance in SR 11-7, are that you can document assumptions, demonstrate they were tested against your own history and show independent review. A model that produces excellent numbers and no evidence satisfies none of those three.

The specific gap is that validation support gets treated as documentation to write at the end. It cannot be. Back testing requires that every run was stored as an immutable artefact at the time it was produced, capturing the instrument snapshot, the assumption set version, the scenario definitions, the code version and the outputs. If runs were not stored that way from day one, there is nothing to back test and no amount of writing fixes it.

Build the artefact first and the reporting second. Then back testing becomes a query: take the run from four quarters ago, compare projected net interest income against the ledger, decompose the variance into volume, rate and behaviour. Doing that consistently gives you the one thing that makes a model credible, which is evidence that when it was wrong you found out and adjusted. Ask any development partner what they will hand a validator. A serious answer includes a technical specification of every calculation, estimation evidence for behavioural assumptions, back test results and a written limitations statement.

Should you build custom or configure what you already own?

If you are under roughly 700 million dollars in assets with a conventional balance sheet, no derivatives, a simple deposit book and no acquisitions pending, buy. Abrigo or ZM Financial Systems will produce a defensible package for a fraction of a build and an examiner will be satisfied. Buying is also right when your constraint is people rather than software, because a model you cannot staff is worse than a service you can.

Empyrean Solutions, Quantitative Risk Management and Moody's Analytics all build genuinely capable engines, and the engine is rarely the reason anyone builds. The reason 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. You can buy a capable cash flow engine and a field to type a beta into. You cannot buy a defensible answer to where that beta came from.

Build when two or more apply. Your loan book has embedded options that the 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 the absence of back testing. Or the treasurer needs the model to answer funding and pricing questions rather than to fill a monthly compliance table.

How do hidden costs get into the quote?

Core extract quality is the largest and it is occasionally the whole project. Some cores do not expose rate floors or reset conventions without custom reporting work that the core provider schedules on their timeline, not yours. Get a sample extract examined before a fixed price is agreed, and ask specifically which fields were confirmed present.

Structured securities are the second. They need external cash flow projections rather than internal ones, which means another data source, another vendor relationship and another reconciliation.

Derivatives are the third. A swap portfolio brings hedge accounting and collateral into scope and is not a small addition to an interest rate risk model.

Multiple charters or a recent acquisition is the fourth: two cores means two extraction pipelines and a reconciliation between them, and the reconciliation is usually harder than either pipeline.

The item most often left out entirely is parallel running. Two full committee cycles with both models producing packages is real treasurer time, and it is where you discover that the old model was quietly excluding a loan category or applying a stale prepayment vector. Budget it, and do not schedule the cutover in the same quarter as an examination.

What separates a build that works from one that fails here?

The ones that work do loans and non maturity deposits properly in phase one and take vendor supplied cash flows for the investment portfolio until phase two. That covers the balance sheet where the risk actually lives and gets a usable model in front of the committee while attention still exists.

They version the assumption instrument, not just the assumptions. When you revise a methodology, historical assessments must not silently change meaning, or your three year trend becomes an artefact of your own improvements.

They estimate deposit behaviour by segment rather than in aggregate. A single blended beta across all money market accounts hides that your largest relationships behave completely differently from the retail tail, and in a stress those relationships move first and largest. Segmentation matters more than mathematical sophistication here.

And they settle ownership before kickoff. You should own the repository, the model specification, the assumption estimation code and the cloud accounts, in writing. At Digital Heroes the client owns all of it from the first commit. In this category it is not a commercial preference. A model you cannot open, explain line by line and modify is not defensible in a validation review, regardless of how good the underlying mathematics happens to be.