ALM IRRBB System Design for Interest Rate Risk in the Banking Book
Building an ALM Platform That Survives a Rate Shock and an Audit
Asset liability management systems fail their owners in a particular way. The engine calculates correctly, the reports produce plausible numbers, and then a supervisor asks why the economic value of equity moved fourteen percent between two quarters, and nobody can decompose the answer into portfolio change, assumption change, and model change.
That question is the real design requirement. An ALM IRRBB system is not primarily a calculation platform, because the mathematics has been settled for decades. It is a data lineage and reproducibility platform that happens to compute interest rate sensitivities, and teams that scope it the other way around build something that works until it is questioned.
What does an ALM and IRRBB system have to produce?
Economic value of equity and net interest income sensitivities under standardised shocks, with disclosure and an outlier test.
The Basel Committee's standards for interest rate risk in the banking book, issued in April 2016, set out both measurement approaches: economic value of equity, which assesses the impact of rate changes on the value of the bank, and net interest income, which measures earnings sensitivity over defined horizons. Banks apply standardised interest rate shocks so exposures are comparable, quantitative disclosures are based on those common scenarios, and the outlier identification threshold was tightened to fifteen percent of Tier 1 capital.
Why do two measures need two different pipelines?
Because one values the whole balance sheet in run-off and the other projects earnings on a going-concern basis.
Economic value of equity discounts all future cashflows and is sensitive to long-dated positions and to the discount curve. Net interest income projects income over a shorter horizon and is sensitive to repricing behaviour, new business assumptions, and margin decisions. They can move in opposite directions from the same shock, which is not an error and is one of the more useful things the pair tells you. Architecturally that means a shared cashflow model with two distinct downstream calculations and two distinct sets of assumptions, rather than one pipeline with a flag.
Why does disclosure shape the architecture?
Because anything disclosed must be reproducible from stored inputs long after the run.
A number that appears in a public disclosure or a board pack has to be reconstructable a year later, with the model version, assumption set, and portfolio snapshot that produced it. That single requirement drives immutability, versioning, and lineage throughout the platform, and it is far cheaper to build in from the start than to retrofit under audit pressure. The regulatory expectations behind that trail are set out in this guide to data lineage and audit trails.
Can you decompose a quarter-on-quarter move into portfolio, assumption, and model change?
Where does the data come from, and why is that the hard part?
From every product system in the bank, most of which were never designed to expose repricing attributes.
The calculation needs contractual detail that product systems hold implicitly, in fields designed for servicing rather than risk. Assembling it is where ALM programmes spend most of their time and where their credibility is decided.
| Data domain | What ALM needs | Common problem |
|---|---|---|
| Loans and mortgages | Repricing dates, rate basis, caps, floors, prepayment terms | Optionality held in free text or product codes |
| Deposits | Contractual maturity where it exists, rate basis, notice terms | No contractual maturity for the largest balances |
| Wholesale funding | Cashflows, embedded options, call dates | Held in treasury systems with a different product model |
| Derivatives and hedges | Full cashflow legs, hedge designation | Hedge accounting relationships not machine-readable |
| Off-balance-sheet commitments | Drawdown behaviour | Frequently omitted entirely |
| Market data | Curves, volatilities, historical rates | Multiple sources with no single authority |
Which contractual attributes matter most?
Repricing date, rate basis, and every embedded option, because those three drive the answer.
If you capture nothing else accurately, capture when each position reprices, what it reprices against, and what optionality exists on either side. Caps, floors, prepayment rights, and early withdrawal terms change the shape of a shock response materially, and a portfolio where they are approximated produces sensitivities that look precise and are not. Where a product system genuinely cannot supply an attribute, record the substitution explicitly as an assumption rather than defaulting silently, so its impact can be measured and challenged.
How do you handle products with no contractual maturity?
With explicit behavioural assumptions, held as versioned data and backtested against actual behaviour.
Non-maturity deposits are the largest modelling judgment on most banking books, and the assumption about what share is stable and how it reprices moves economic value of equity more than most portfolio decisions. Prepayment behaviour on fixed-rate lending is the second. Both must be modelled as declared assumptions with an owner, an effective date, supporting analysis, and a backtest against realised behaviour. The pressure this creates in a rising rate environment is exactly what this analysis of pricing in a rising interest rate world describes on the liability side of a different balance sheet.
How should behavioural assumptions be governed?
As first-class versioned artefacts with owners, effective dates, evidence, and an approval trail.
Assumptions embedded in calculation code are the single most common reason an ALM platform cannot answer a supervisor's question. Hold them in a store where each assumption has an identifier, a value or curve, an effective date range, a named owner, the analysis supporting it, and the committee approval that adopted it. Then every run records which assumption set it used. That structure makes assumption change a measurable component of any movement, which is what turns an unexplainable variance into a three-line decomposition. The governance discipline mirrors what this look at operationalising a new scenario framework without model-change chaos describes, where the controls around change matter more than the model itself.
How should the calculation engine be architected?
As a deterministic, reproducible pipeline with scheduled official runs and isolated on-demand analysis.
Official runs for regulatory and board reporting must be reproducible from immutable inputs: portfolio snapshot, market data snapshot, model version, assumption set version. On-demand what-if runs for the business need to be fast and freely available, and must never be able to overwrite or be mistaken for an official result. Separate them by design, tag every result with its run type, and make the provenance visible in whatever tool consumes it.
Batch, on demand, or both?
Both, with different guarantees rather than different code.
Use the same engine for both so results are comparable, and differentiate by input handling and retention. Official runs freeze inputs and retain results indefinitely. Analytical runs may use the latest available data, are retained for a shorter period, and are always labelled. Where users need speed, invest in incremental recalculation and caching of the expensive cashflow generation step rather than maintaining a second simplified engine, because two engines guarantee two answers and a standing argument about which is right.
What makes a run reproducible a year later?
Immutable input snapshots, versioned model and assumptions, and stored results with full lineage.
Reproducibility is an engineering property, not a policy. Snapshot inputs rather than querying live systems at run time, version the model as an artefact rather than as whatever was deployed that day, record the assumption set identifier, and store the result together with intermediate cashflows if storage allows. Then provide a decomposition capability that attributes any change between two runs to portfolio movement, market data, assumption change, or model change. That single feature is what earns the platform its credibility.
Rebuilding last quarter's ALM numbers by hand when questions arrive?
Talk to Digiqt about reproducible risk calculation pipelines
How do you handle scenario volume without the platform becoming unusable?
By treating scenarios as data and planning for hundreds of runs rather than a handful.
| Scenario set | Purpose | Typical count |
|---|---|---|
| Standardised interest rate shocks | Regulatory measurement and disclosure | Six common scenarios |
| Internal management scenarios | Business planning and risk appetite | Ten to thirty |
| Assumption sensitivities | Showing dependence on judgment | One per key assumption, often dozens |
| Stress and reverse stress | Severe but plausible, and breaking-point analysis | Five to fifteen |
| Ad hoc analysis | Answering a specific question this week | Unbounded |
The regulatory set is small and the total is not, because sensitivity analysis multiplies. Design the engine for parallel execution across scenarios, make scenario definition a configuration artefact rather than a code change, and report the standardised set alongside the internal view so the board sees both the comparable number and the one that reflects your actual balance sheet. Cross-border balance sheets add another dimension, since currency and jurisdictional segmentation interact with rate risk in the way described in asset-liability mismatch under geoeconomic fragmentation.
How should ALM connect to funds transfer pricing and treasury?
Through shared curves, a shared cashflow model, and a shared assumption set, with one owner for each.
When the ALM system and the funds transfer pricing engine use different curves or different behavioural assumptions, the bank prices business against one reality and reports risk against another. Business units then optimise against pricing signals that do not correspond to the risk being reported, and nobody can reconcile the two without a project. Share the inputs, keep one owner per curve and per assumption, and treat any divergence as a defect. The design consequences on the pricing side are covered in funds transfer pricing engine design, and the intraday and positioning side connects to the real-time treasury platform that supplies actual cash behaviour for backtesting.
What governance must the platform support?
Model risk controls, assumption approval, change management, and independent validation.
The platform has to make governance cheap or governance will be performed on spreadsheets alongside it. That means model inventory registration, an approval workflow for assumption changes with evidence attached, change control that ties a model version to an approval, and the ability for independent validation to rerun a result without help from the team that built it. Access control matters too: the people who set assumptions, run official reports, and approve changes should be distinguishable in the audit trail. None of this is exotic engineering, and all of it is far cheaper to build before the first validation review than after.
How should delivery be phased?
Data foundation first, then a single measure end to end, then the second measure, then scenario scale.
| Phase | Duration | Deliverable |
|---|---|---|
| Data foundation | 4 to 6 months | Contractual attribute capture, product coverage map, market data authority |
| First measure end to end | 3 to 4 months | Cashflow model plus one measure, reproducible official run |
| Assumption framework | 2 to 3 months | Versioned assumption store, ownership, backtesting |
| Second measure and disclosure | 2 to 3 months | Both measures, standardised shocks, disclosure outputs |
| Scenario scale and decomposition | 2 to 4 months | Parallel scenario execution, movement attribution |
| Integration with pricing and treasury | Ongoing | Shared curves and assumptions, feedback from realised behaviour |
Do not start with the engine. A well-implemented calculation over incomplete contractual data produces confident wrong answers faster, and the data phase is the one that determines whether anything downstream is defensible.
Which metrics show the platform is healthy?
Data coverage and attribute completeness, run reproducibility, time to produce an official run, decomposition capability, and backtest accuracy.
Track the share of balance sheet value covered by directly sourced contractual attributes rather than approximations, because that number is your credibility ceiling. Measure attribute completeness per product and drive the gaps down deliberately. Test reproducibility by rerunning a prior official run and confirming identical output, and treat any failure as a serious defect. Watch the elapsed time to produce an official run, since a process that takes three weeks cannot support decisions. And backtest behavioural assumptions against realised behaviour on a regular cycle, reporting the error so assumption quality is visible rather than assumed.
An ALM platform earns its keep on the day someone senior asks a hard question about a number. The institutions that answer in an afternoon are not the ones with the most sophisticated models. They are the ones that stored their inputs, versioned their assumptions, and can show exactly where a number came from.
Frequently Asked Questions
What must an IRRBB system actually produce?
Economic value of equity and net interest income sensitivities under standardised interest rate shock scenarios, with disclosures and an outlier test against Tier 1 capital.
Why is data capture harder than the calculation?
Because the maths is well defined while the contractual attributes it needs, repricing dates, caps, floors, optionality, and prepayment terms, are scattered across product systems that never had to expose them.
How do you model products with no contractual maturity?
With explicit behavioural assumptions such as core deposit stability and prepayment rates, documented, versioned, and backtested rather than embedded in calculation code.
Why do behavioural assumptions need version control?
Because a supervisor will ask what you assumed on a specific date and why. Assumptions held as data with an owner, effective dates, and evidence answer that in minutes.
Should the engine run in batch or on demand?
Both. Regulatory and board reporting run as scheduled reproducible batches, while business teams need on-demand what-if runs that never overwrite an official result.
How many scenarios does the platform need to handle?
Standardised shocks plus internal scenarios, plus sensitivities per assumption, which multiplies quickly. Design for hundreds of runs rather than a handful.
How does ALM connect to funds transfer pricing?
They should share the same curves, cashflow model, and assumption set. When FTP and ALM disagree, business decisions get priced against a different reality than the one being reported.
What makes a run defensible months later?
Immutable inputs, a recorded model and assumption version, a stored result, and lineage from any reported figure back to the contracts that produced it.
