← back
Non-Maturity Deposit Modelling
Turning savings and current accounts into a maturity profile
Anindya Kundu · a practical note
What it is
A non-maturity deposit (NMD) — a savings or current account — has money in it but no
agreed end date. The customer can withdraw tomorrow or leave it for years. Every other product
on the balance sheet has a maturity; these do not. An NMD model gives them one, so they can be
placed on the IRRBB maturity ladder honestly rather than dumped into the overnight bucket.
Why a bank needs it
Treating a large, stable savings book as overnight money makes the bank look far more
rate-sensitive than it is and distorts both EVE and NII. RBI and Basel (BCBS 368) expect a
behavioural treatment, documented and defensible.
The method — an eight-step pipeline
- Load balances. Around five years of daily balance data.
- Percentage changes. For each day, the percentage drop versus a fixed number
of business days back — one look-back per IRRBB bucket (1M = 30 rows, 3M = 90, and so on).
The look-back is a row count, not calendar days.
- Non-Stable %. Per bucket, take the 95th-percentile worst drop, then
de-cumulate so each bucket keeps only its own incremental volatility. The sum is the
Non-Stable (flighty) portion; the rest is Stable.
- Load MEVs. Monthly macro variables — GDP, repo, 10-year yields, and others.
- Regression. Predict Non-Stable % from the economy, so it can be forecast and
stressed. A savings book is modelled linear; a current-account book log-linear, which keeps the
forecast positive.
- Pass-through rate (Beta / PTR). How much of a repo move passes to the deposit
rate. That passed-through slice reprices, so it behaves like short money. Current accounts pay no
interest, so their PTR is zero and this step is skipped.
- Core / Non-Core. See the formula below.
- Bucketing. Non-Core goes overnight; Core is spread across the longer buckets,
starting at the bucket where volatility stops rising.
Stable = 1 − Non-Stable
Core = Stable × (1 − PTR) — capped at the BCBS limit of 90%
Non-Core = 1 − Core → overnight bucket
A worked example (illustrative)
Take a savings book with Non-Stable around 2% and a pass-through rate around 3.5%:
| Step | Value |
|---|
| Non-Stable | ~2% |
| Stable | ~98% |
| Core (raw) = Stable × (1 − PTR) | ~95% |
| BCBS cap | 90% — cap binds |
| Core (final) | 90% |
| Non-Core | 10% → overnight |
A current-account book behaves differently: much higher Non-Stable, zero PTR, and a raw core
below the 90% cap — so the cap does not bind and the model's own number is used.
Two enhancements beyond the standard build
- SARIMAX. A simple regression often shows autocorrelation (a low Durbin-Watson).
A SARIMAX version models the time-series structure properly and is shown side by side, so the bank
can defend the model choice.
- Walk-forward backtesting. Hold out recent months, predict them out-of-sample,
and measure the error (MAE / MAPE / RMSE). This is the strongest evidence for a validation reviewer.
How I validate
Every step is tallied to the bank's own validation workbook — the percentage changes, the
percentile, the regression coefficients, the final core — agreeing to several decimals before the
model is accepted. A subtle point that matters in practice: workbook column headers are often stale
or mislabelled, so the formula cells, not the labels, are treated as authoritative.
Implementation
The method is platform-independent. I have built it in SAS (with SAS/STAT and SAS/ETS); the same
logic builds in Python or R. The model is the decision, not the tool.
All figures are illustrative and show methodology only. This note does not reproduce any client's
data, parameters, or code.