16. Advanced Topics and Emerging Trends

The previous chapters described how treasury works today and how its systems are built. This chapter looks at the areas where requirements are getting harder or changing fastest: supervisory and internal stress testing, the move from overnight batches to real-time treasury, tokenized money and distributed ledgers, and the failures of Northern Rock, Lehman Brothers, Silicon Valley Bank and Credit Suisse. Engineers working on these topics build systems that supervisors examine closely, that run in the minutes that decide whether a bank survives a run, or that connect the bank to new forms of money whose rules are still being written.

<a id="161-stress-testing-and-scenario-analysis"></a>

16.1 Stress Testing and Scenario Analysis

This subchapter covers how banks and supervisors test whether a bank survives severe but plausible conditions: the supervisory exercises in the EU and the US, reverse stress tests that start from failure, the interaction between liquidity and solvency under stress, and how scenarios are designed and calibrated. Chapter 13.3 describes the scenario engine that runs these calculations.

Regulatory Stress Tests (EBA, CCAR)

Why it matters. Capital and liquidity ratios describe a bank on one reporting date. They say little about what happens if a recession, a rate shock and a property crash arrive together. After 2008, supervisors decided to ask that question themselves, in a common format, for all large banks at once. The results feed directly into capital requirements and dividend decisions, so a stress test is not an academic exercise: a weak result can force a bank to hold more capital or cancel a planned distribution to shareholders.

How it works in general. A supervisory stress test has four ingredients:

• Scenarios: a baseline (the expected path of the economy) and an adverse scenario (a severe recession with market shocks), defined as paths for GDP, unemployment, house prices, interest rates, FX rates, equity prices and credit spreads over a multi-year horizon.
• Methodology: rules for how banks translate the scenarios into credit losses, market losses, net interest income, fees and costs, including what they may and may not assume.
• Projection: the bank (or the supervisor, or both) projects the income statement and capital quarter by quarter or year by year.
• Use of results: the projected fall in capital ratios sets or informs a capital buffer, and results are usually published bank by bank.

EU: the EBA EU-wide stress test. The European Banking Authority coordinates a stress test every two years (2018, 2021, 2023, 2025, ...) for the largest EU banks, run in the euro area together with the ECB.

Feature	EBA EU-wide stress test
Who runs the numbers	Banks, using their own models within strict EBA rules ("constrained bottom-up")
Horizon	3 years
Scenarios	Baseline and adverse; the adverse scenario is designed by the ESRB and ECB
Balance sheet	Static: maturing assets and liabilities are replaced with similar ones; no management actions
Quality assurance	Supervisors challenge bank projections against benchmarks over several submission rounds
Outcome	No pass or fail; the capital depletion informs Pillar 2 Guidance (P2G) in the SREP
Publication	Bank-by-bank results in standard templates

The static balance sheet assumption matters for engineers. It means projections cannot be improved by assuming that the bank shrinks, raises capital or reprices its loans. It also means that maturing positions must be rolled into identical replacements in the projection engine, which is a different logic from the dynamic balance sheet used in internal planning.

US: CCAR and DFAST. The US Federal Reserve runs an annual supervisory stress test for banks with USD 100bn or more in assets (Category IV firms every other year).

Feature	Fed supervisory stress test
Who runs the numbers	The Fed, with its own supervisory models applied to bank-submitted data; banks also run company-run tests
Horizon	9 quarters
Scenarios	Baseline and severely adverse; a global market shock and counterparty default component for the largest trading banks
Balance sheet	Projected to remain broadly constant in size, with planned dividends included
Outcome	The stress capital buffer (SCB)
Publication	Firm-level results each June

CCAR (Comprehensive Capital Analysis and Review) is the capital planning exercise around the test; DFAST (Dodd-Frank Act Stress Tests) is the statutory stress test itself. Since 2020 the result sets each firm's stress capital buffer:

  SCB = max( 2.5%,  (starting CET1 ratio - minimum projected CET1 ratio)
                    + 4 quarters of planned common dividends / RWA )

  Example:
    Starting CET1 ratio                12.0%
    Lowest CET1 ratio in the 9 quarters 8.9%
    Peak-to-trough decline              3.1%
    Planned dividends / RWA             0.4%
    SCB                                 3.5%   (above the 2.5% floor)

    Requirement = 4.5% minimum + 3.5% SCB + G-SIB surcharge (if any)

Because the SCB changes every year with the scenario, it can make capital planning volatile. In 2025 the Fed proposed averaging results over two consecutive years and publishing its models and scenarios for public comment.

Comparison.

Aspect	EBA (EU)	Fed (US)
Models	Bank models, constrained	Supervisory models
Frequency	Every 2 years	Annual
Horizon	3 years	9 quarters
Direct link to capital	Through P2G (supervisory judgment)	Mechanical, through the SCB
Main burden for the bank	Running projections, templates, QA rounds	Data submissions (FR Y-14), capital plan, own tests

Other supervisors run similar exercises (the Bank of England's bank capital stress test, the ECB's thematic tests such as the 2022 climate and 2024 cyber resilience exercises). Liquidity stress tests are mainly internal (the ILAAP, Chapter 9.2), although supervisors run occasional liquidity exercises, such as the ECB's 2019 sensitivity analysis of liquidity risk.

Engineering view. A regulatory stress test is a large, deadline-driven data and calculation project.

  Scenario release        Bank projection engine                   Submission
  (macro paths)                                                     and QA
       |            +---------------------------------------+
       v            |  satellite models: macro -> PD, LGD,  |
  +-----------+     |  NII margins, fee income, market      |     +-------------+
  | Scenario  +---->+  losses                               +---->+ EBA / Fed   |
  | loader,   |     |  balance sheet roll-forward (static)  |     | templates   |
  | versioned |     |  P&L and capital per year / quarter   |     +------+------+
  +-----------+     +-------------------+-------------------+            |
                                        ^                                v
                    starting point data | (reconciled to          supervisor challenge
                    from regulatory     |  FINREP / COREP)         -> resubmission
                    reporting           |                          (several rounds)

• The starting point must reconcile with published regulatory reports (Chapter 9.3). Differences are among the first things supervisors query.
• Each submission round must be reproducible: same inputs, same code version, same results. Use the versioning and lineage practices from Chapters 13.2 and 15.4.
• Templates change with each exercise. Generate them from a model of the data, not by hand in spreadsheets.
• Expect overrides and management adjustments. Record each one with its owner, reason and effect, because the supervisor will ask.

Analogy. A supervisory stress test is like a building inspector checking every skyscraper in the city against the same simulated earthquake. Each owner can describe their building's strength, but the inspector fixes the size of the earthquake, the rules of the calculation and how the results are compared.

Key takeaways

• Supervisory stress tests project capital under common baseline and adverse scenarios over several years and translate the result into capital requirements.
• The EBA test uses bank models within strict rules, a 3-year horizon and a static balance sheet; results inform Pillar 2 Guidance.
• The Fed test uses supervisory models over 9 quarters; the peak-to-trough CET1 decline plus planned dividends sets the stress capital buffer (minimum 2.5%).
• For engineers, the hard parts are a reconciled starting point, reproducible projection runs, template generation and audit trails for adjustments.

🧪 Practice

1. Beginner: A bank starts with a CET1 ratio of 13.2%, reaches a minimum of 10.4% in the severely adverse scenario and plans dividends equal to 0.3% of RWA over four quarters. Compute its stress capital buffer.
2. Intermediate: Explain how a static balance sheet assumption changes the projection of net interest income for a bank whose fixed-rate mortgages mature during the horizon. What data does the engine need to roll them forward?
3. Interview: "The supervisor's QA team says your projected credit losses for SME loans are below their benchmark. How would your systems support the response?" Hint: traceability from macro path to PD and LGD per segment, versioned satellite models, a breakdown of the gap by driver, rerunning with alternative parameters quickly, and an audit trail of the final decision.

Reverse Stress Testing

Why it matters. A normal stress test asks: "Given this scenario, how bad is the outcome?" The danger is that the scenarios chosen are the ones the bank already expects to survive. A reverse stress test turns the question around: "What would have to happen for us to fail?" It forces management to look at the combinations of events that would break the business model, including ones nobody had considered plausible. Supervisors require it (for example in the EBA Guidelines on institutions' stress tests and in the PRA rules) as part of the ICAAP, ILAAP and recovery planning.

Defining "failure". The starting point is a precise definition of the outcome to reverse-engineer:

Failure point	Typical definition
Capital	CET1 ratio falls below the total requirement (minimum + Pillar 2), or below the point of non-viability
Liquidity	Counterbalancing capacity is exhausted within the survival horizon (Chapter 5.2)
Business model	The bank is no longer profitable enough to remain viable, or loses access to a key market
Recovery	A recovery indicator breaches its threshold (Chapter 7.3)

Approaches.

Approach	How it works	Strength	Weakness
Narrative	Management workshops build stories that lead to failure, then quantify them	Captures non-financial causes (fraud, IT failure, reputation)	Subjective, limited to what people imagine
Single-factor search	Increase one shock (rates, deposit outflow) until the failure point is reached	Simple, gives "distance to failure" per risk	Ignores combinations
Multi-factor search	Search over combinations of factors, often on a grid	Finds combinations	Many combinations, hard to rank
Most plausible scenario	Find the combination of shocks that reaches failure with the smallest statistical distance from today	Ranks scenarios by plausibility	Depends on a correlation model that may break in a crisis

The most plausible failure scenario. If risk factor changes x are roughly normal with covariance matrix Sigma and the loss is approximately linear, loss = s' x (with s the vector of sensitivities), the most plausible scenario that produces a target loss L minimizes the Mahalanobis distance x' Sigma^-1 x subject to s' x = L. The solution has a closed form:

  x* = L * Sigma s / (s' Sigma s)

  Plausibility: distance d = L / sqrt(s' Sigma s)  (in standard deviations)
  A larger d means the failure scenario is less plausible.

Example. A bank with CET1 capital of EUR 5.0bn fails when losses reach EUR 1.8bn (the headroom above its requirement). It is exposed to three factors: rates (bp), credit spreads (bp) and house prices (%).

import numpy as np

# sensitivities: EUR m loss per unit move (rates +1bp, spreads +1bp, house prices -1%)
s = np.array([4.0, 6.5, 90.0])

# annual standard deviations and correlation of the factor moves
vol = np.array([80.0, 60.0, 8.0])
corr = np.array([[1.0, 0.3, 0.2],
                 [0.3, 1.0, 0.6],
                 [0.2, 0.6, 1.0]])
sigma = np.outer(vol, vol) * corr

L = 1800.0                                  # EUR m loss that breaches the requirement
x_star = L * sigma @ s / (s @ sigma @ s)
distance = L / np.sqrt(s @ sigma @ s)

print(np.round(x_star, 1))   # [65.5 77.6 11.5] -> +66bp rates, +78bp spreads, -11.5% house prices
print(round(distance, 2))    # 1.6 standard deviations

The result says that the most plausible way to lose EUR 1.8bn is a combined rise in rates and spreads with an 11.5% fall in house prices, about 1.6 standard deviations away. That is uncomfortably close, and it would lead to a discussion of hedges, concentration limits or more capital. Real reverse stress tests use non-linear full revaluation (search algorithms rather than the closed form) and stressed correlations, but the idea is the same.

Liquidity example. For liquidity, the question becomes: which run-off rate on corporate deposits exhausts the buffer within 30 days, given the other outflows? If the answer is 18% and SVB-style outflows reached 25% of deposits in a single day, the result is a strong signal that the funding profile needs work.

From result to action. A reverse stress test is useful only if it changes something:

• Identify the factors and concentrations that drive the failure scenario.
• Define early warning indicators that show when the world is moving toward it (Chapter 5.4, Contingency Funding Plans).
• Link to recovery options and their capacity (Chapter 7.3).
• Document the analysis for the board, which must review it.

Analogy. A normal stress test is like checking whether a bridge holds a 40-tonne truck. A reverse stress test asks what load, wind and temperature combination brings the bridge down, and then asks how close tomorrow's weather forecast comes to it.

Key takeaways

• Reverse stress testing starts from a defined failure point and searches for the scenarios that cause it.
• Failure can be defined for capital, liquidity, business model viability or recovery indicators.
• The most plausible failure scenario minimizes statistical distance from today; for linear losses there is a closed-form solution.
• The output should drive early warning indicators, limits and recovery planning, not sit in a report.

🧪 Practice

1. Beginner: A bank has a liquidity buffer of EUR 12bn and contractual net outflows of EUR 3bn over 30 days. Retail deposits are EUR 60bn. Ignoring other flows, which retail run-off rate exhausts the buffer?
2. Intermediate: Using the example above, change the correlation between spreads and house prices from 0.6 to 0.9. Does the failure scenario become more or less plausible? Explain why.
3. Interview: "Our reverse stress test says failure requires a 6-sigma event, so we are safe. What is wrong with this conclusion?" Hint: correlations and volatilities measured in calm periods, non-linear losses, liquidity and solvency feedback, non-financial triggers, and the history of supposedly 6-sigma events in 2008 and 2023.

Combined Liquidity and Solvency Stress

Why it matters. Banks traditionally ran capital stress tests (ICAAP) and liquidity stress tests (ILAAP) in separate teams with separate models. Real crises do not respect that split. A loss reduces capital, which triggers a rating downgrade, which raises funding costs and causes collateral calls and deposit outflows, which forces asset sales at a loss, which reduces capital further. Silicon Valley Bank and Credit Suisse both failed through this loop. A stress test that runs the two sides separately misses the second-round effects that do the most damage.

The feedback loop.

              +------------------------------+
              |  Initial shock               |
              |  (credit losses, rate rise)  |
              +--------------+---------------+
                             |
                             v
   +-------------------> Capital falls ----------------------+
   |                         |                               |
   |                         v                               v
   |                Rating downgrade,                Higher funding cost
   |                market confidence lost           (spread on new funding)
   |                         |                               |
   |                         v                               v
   |            Deposit outflows, repo haircuts,        Lower NII
   |            collateral calls (CSA triggers)              |
   |                         |                               |
   |                         v                               |
   |            Buffer used; assets sold or pledged          |
   |            below book value                             |
   |                         |                               |
   +------ realized losses <-+-------------------------------+

Transmission channels.

Channel	From solvency to liquidity	From liquidity to solvency
Rating	Losses lead to downgrades, which trigger collateral calls and outflows of rating-sensitive investors
Confidence	Reported losses or capital shortfall trigger deposit runs
Funding cost		Higher spreads on new and rolled funding reduce NII
Fire sales		Selling securities below book value realizes losses (especially amortized-cost portfolios)
Encumbrance		Pledging the best assets leaves unsecured creditors with weaker assets, raising spreads further
Accounting	Selling from a held-to-maturity portfolio can taint the whole portfolio and force fair valuation

How to model it. A combined stress test projects capital and liquidity in the same time steps, with explicit links between them:

1. Apply the scenario for the period and compute losses and the new capital ratio.
2. Map the capital ratio (or rating) to behavioural parameters: outflow rates, haircuts, funding spreads.
3. Compute the liquidity position; if the buffer is insufficient, apply the counterbalancing actions in order (Chapter 5.4), including asset sales with their realized losses.
4. Feed the realized losses and higher funding costs back into the capital projection.
5. Repeat within the period until the numbers converge, then move to the next period.

Example. A simplified quarterly loop.

def combined_stress(cet1, rwa, deposits, buffer, quarters, credit_loss, unrealized_loss_rate):
    """Very simplified joint projection; amounts in EUR bn."""
    for q in range(1, quarters + 1):
        cet1 -= credit_loss[q - 1]
        ratio = cet1 / rwa
        # behaviour depends on solvency: weaker capital -> larger run and higher spread
        outflow_rate = 0.03 if ratio > 0.12 else 0.08 if ratio > 0.10 else 0.20
        funding_spread = 0.002 if ratio > 0.12 else 0.006 if ratio > 0.10 else 0.015
        outflow = deposits * outflow_rate
        deposits -= outflow
        shortfall = max(0.0, outflow - buffer)
        buffer = max(0.0, buffer - outflow)
        # cover the shortfall by selling securities held at amortized cost
        realized = shortfall * unrealized_loss_rate
        cet1 -= realized + deposits * funding_spread / 4
        print(f"Q{q}: CET1 {cet1 / rwa:.1%}, outflow {outflow:.1f}, buffer {buffer:.1f}, "
              f"realized loss {realized:.2f}")

combined_stress(cet1=12.6, rwa=100.0, deposits=150.0, buffer=20.0, quarters=4,
                credit_loss=[0.4, 0.6, 0.6, 0.4], unrealized_loss_rate=0.15)
# Q1: CET1 12.1%, outflow 4.5,  buffer 15.5, realized loss 0.00
# Q2: CET1 11.3%, outflow 11.6, buffer 3.9,  realized loss 0.00
# Q3: CET1 9.5%,  outflow 10.7, buffer 0.0,  realized loss 1.03
# Q4: CET1 5.1%,  outflow 24.6, buffer 0.0,  realized loss 3.69

Run separately, the capital stress would show a loss of EUR 2.0bn of credit losses (CET1 from 12.6% to 10.6%) and the liquidity stress, with a fixed 3% outflow, would show a comfortable buffer. Together, the CET1 ratio falls below 10% in the third quarter and to about 5% in the fourth, as each loss makes the next run larger. The thresholds and rates here are illustrative; real models calibrate them from history and expert judgment and use many more segments.

Engineering view.

• Use one scenario definition, one balance sheet projection and one time grid for ICAAP and ILAAP. Separate engines with separate data snapshots cannot be combined reliably afterwards.
• Make behavioural parameters functions of the bank's own state (capital ratio, rating, news), not fixed inputs.
• Keep the order of counterbalancing actions configurable and record which actions were taken in each period.
• Iterative models can fail to converge or oscillate. Limit iterations, detect non-convergence and report it.
• Liquidity runs in days, capital projections in quarters. Combined models often use a daily grid for the first weeks and coarser buckets later.

Analogy. Solvency and liquidity are like a patient's heart and lungs. A doctor who tests each organ separately may find both acceptable, while the patient is in danger because a weak heart reduces oxygen, which weakens the heart further.

Key takeaways

• Liquidity and solvency stress interact through ratings, confidence, funding costs, fire sales and encumbrance.
• Separate ICAAP and ILAAP tests miss second-round effects that drove the failures of 2007-2008 and 2023.
• Combined models project both in the same time steps, with behaviour that depends on the bank's own solvency.
• Engineering requires one scenario, one balance sheet and one time grid, plus convergence controls for iterative loops.

🧪 Practice

1. Beginner: List three ways a two-notch rating downgrade affects a bank's liquidity position within 30 days.
2. Intermediate: In the example, change the unrealized loss rate on securities from 15% to 5%. What changes, and what does this tell you about the role of interest rate risk in the banking book in a liquidity crisis?
3. Interview: "Our ICAAP and ILAAP engines are owned by different teams and run on different data. How would you move toward a combined stress test without a big-bang rewrite?" Hint: a shared scenario library and starting-point data first, an interface that passes capital ratios to the liquidity engine and realized losses back, a reconciled time grid, and running both in a loop orchestrator before merging models.

Scenario Design and Calibration

Why it matters. A stress test is only as good as its scenarios. If the scenario is too mild, it gives false comfort; if it is implausibly extreme, management ignores it; if the variables in it are inconsistent (unemployment soars while house prices rise), the results cannot be interpreted. Scenario design is the work of turning a story ("a sharp recession with persistent inflation") into a complete, coherent and calibrated set of risk factor paths that every model in the bank can consume.

Types of scenario.

Type	Definition	Example	Strength	Weakness
Historical	Replay the risk factor moves of a past period	Lehman weeks 2008, March 2020, 2022 UK gilt crisis	Plausible by construction, internally consistent	Tomorrow's crisis will differ
Hypothetical	A forward-looking story calibrated by experts	Taiwan Strait conflict, cyber attack on a major payment system	Addresses new risks	Calibration is subjective
Hybrid	A historical pattern rescaled or adapted to today's positions	2008 credit spread moves, scaled to today's spread levels	Combines realism and relevance	Rescaling choices need justification
Sensitivity	One factor shocked, others unchanged	+200bp parallel rates (IRRBB, Chapter 6.2)	Simple, comparable	Ignores correlations

Design steps.

  1. Narrative        "Energy price shock, inflation persists, central banks hike,
                       recession in Europe, commercial property falls"
          |
  2. Core variables   GDP, unemployment, policy rate, 10y yield, house prices,
                      EUR/USD, equity index, credit spreads  (paths per quarter)
          |
  3. Expansion        Derive hundreds of secondary factors (full curves, sector
                      spreads, single-name equities, vols) consistently from the core
          |
  4. Calibration      Check severity (percentiles, history) and plausibility
          |
  5. Translation      Satellite models map factors to PD, LGD, run-off, margins
          |
  6. Governance       Approval, version, documentation, back-testing of severity

Calibrating severity. Common approaches:

• Historical percentiles: set the shock to, for example, the 1st percentile of historical 1-year moves, or "a 1-in-25-year event".
• Worst historical episodes: take the largest observed move, possibly with a margin, for each core variable.
• Peer and supervisory benchmarks: compare with the EBA adverse scenario or the Fed's severely adverse scenario.
• Starting point dependence: shocks should depend on where the economy is. A 300bp rise is severe when rates are at 1% and mild when they are at 10%. Supervisors increasingly make severity counter-cyclical: harsher when the economy is booming, to avoid procyclical capital demands in a downturn.

Coherence through conditional expansion. Experts set the core variables; the secondary variables should follow consistently. A standard technique uses the conditional mean of a multivariate normal distribution: given core moves x_c, the expected secondary moves are

  E[x_s | x_c] = mu_s + Sigma_sc Sigma_cc^-1 (x_c - mu_c)

import numpy as np

factors = ["10y_rate_bp", "equity_pct", "ig_spread_bp", "hy_spread_bp", "eurusd_pct"]
core, secondary = [0, 1], [2, 3, 4]       # experts fix rates and equities

# covariance of quarterly moves estimated from history (stressed period preferred)
vol = np.array([35.0, 9.0, 25.0, 110.0, 4.0])
corr = np.array([[ 1.0, -0.2,  0.1,  0.0,  0.2],
                 [-0.2,  1.0, -0.7, -0.8,  0.3],
                 [ 0.1, -0.7,  1.0,  0.8, -0.2],
                 [ 0.0, -0.8,  0.8,  1.0, -0.3],
                 [ 0.2,  0.3, -0.2, -0.3,  1.0]])
sigma = np.outer(vol, vol) * corr

x_core = np.array([120.0, -30.0])         # +120bp rates, equities -30%
s_cc = sigma[np.ix_(core, core)]
s_sc = sigma[np.ix_(secondary, core)]
x_sec = s_sc @ np.linalg.solve(s_cc, x_core)

for name, value in zip([factors[i] for i in secondary], x_sec):
    print(f"{name}: {value:+.1f}")
# ig_spread_bp: +55.5
# hy_spread_bp: +242.7
# eurusd_pct: -1.0

The equity crash implies much wider credit spreads, far more for high yield than for investment grade, as history suggests. The euro barely moves, because its positive correlation with rates offsets the effect of the equity fall. If the narrative calls for a flight into the US dollar, the modeller overrides that value and documents why. Expansion gives a consistent default; it does not replace judgment.

Checking plausibility. The Mahalanobis distance of the full scenario from the historical distribution (the same measure used in reverse stress testing) gives one number for how extreme it is. Comparing the distance of the designed scenario with that of historical crises helps answer "is this severe enough, and is it believable?"

Common pitfalls.

Pitfall	Consequence	Remedy
Correlations from calm periods	Spreads barely move in an equity crash	Estimate covariances on stressed windows, or blend
Missing factors	Positions without a shocked factor show zero loss	Coverage check: every risk factor used in pricing has a scenario value or a mapping rule
Inconsistent horizons	Shocks for a 10-day trading horizon applied to a 3-year banking book	Define the horizon and liquidity horizon per portfolio
Unchanged behaviour	Deposits behave as in normal times	Stress behavioural parameters along with market factors
Scenario never changes	The same scenario every year, positions adapt to it	Review annually against emerging risks

Engineering view.

• Store scenarios as versioned data with their narrative, core variables, expansion method and approvals (the scenario library in Chapter 13.3).
• Run an automated coverage check before each run: list every risk factor in the portfolio without a scenario value.
• Keep the expansion code and its parameters with the scenario, so that the scenario can be regenerated exactly.
• Support fast ad-hoc scenarios. In March 2023 many banks were asked within days to rerun liquidity and rate scenarios inspired by SVB.

Analogy. Designing a scenario is like writing a disaster film script for an entire city. The writer sets the main events, but every street, hospital and power line must react consistently with them, or the audience stops believing the story.

Key takeaways

• Scenarios can be historical, hypothetical, hybrid or single-factor sensitivities; each has strengths and weaknesses.
• Good scenarios start with a narrative, fix a few core variables and expand consistently to all risk factors.
• Severity is calibrated against history, supervisory benchmarks and the current starting point.
• Conditional expansion and plausibility measures keep scenarios coherent; stressed correlations matter.
• Treat scenarios as versioned, approved data with automated coverage checks.

🧪 Practice

1. Beginner: Classify each as historical, hypothetical, hybrid or sensitivity: (a) +200bp parallel shift; (b) March 2020 market moves applied to today's portfolio; (c) a 2008-style spread widening scaled to today's spread levels; (d) a cyber attack that stops a major RTGS for two days.
2. Intermediate: In the expansion example, change the equity shock from -30% to -10% while keeping rates at +120bp. Recompute the secondary factors (by reasoning or code) and explain whether the result is still consistent with a "stagflation" narrative.
3. Interview: "How would you design a scenario library so that a new ad-hoc scenario can be defined in the morning and results reported in the afternoon?" Hint: parameterized templates, automated expansion from core variables, coverage checks, cached base results with incremental revaluation, and a light but recorded approval step.

<a id="162-real-time-treasury"></a>

16.2 Real-Time Treasury

This subchapter covers the move from a treasury that sees the bank once a day, after the overnight batch, to one that sees and acts on positions continuously: real-time liquidity positions, streaming risk analytics, machine learning cash forecasts and automated funding decisions with human oversight.

Real-Time Liquidity Positions

Why it matters. Traditional treasury systems compute the liquidity position after the end-of-day batch: the cash ladder, the LCR and the funding gap are known the next morning. That rhythm no longer matches the world. Instant payments settle 24 hours a day, 7 days a week (SEPA Instant became mandatory for euro area payment service providers to send in October 2025), corporates move cash through APIs in seconds, and SVB lost USD 42bn in a single business day in 2023. Chapter 5.3 covered intraday liquidity for individual settlement accounts. A real-time liquidity position goes further: a continuously updated, bank-wide view of liquidity across accounts, currencies, legal entities and time buckets, including an estimate of the key ratios.

From balances to a position. A real-time position combines three layers:

Layer	Content	Source	Certainty
Actual	Settled balances on central bank, nostro and internal accounts	RTGS and correspondent notifications (camt.054, camt.052), payment hub	High
Projected	Known future flows: scheduled payments, maturing trades, CLS pay-ins, coupon payments	Trade systems, payment queues, cash ladder	Medium (amendments, fails)
Expected	Statistical flows not yet known individually: client payments, deposit movements	Forecast models (next topic)	Low, given as ranges

The end-of-day expected position for an account is:

  expected_EOD = actual balance now
               + projected inflows  - projected outflows   (still to settle today)
               + expected net flows (forecast for the rest of the day, with a range)

Architecture.

  Sources (events)                     Position service                     Consumers
  +---------------------+
  | RTGS / nostro msgs  |--+     +---------------------------------+     +-----------------+
  | Payment hub         |  |     | per account, currency, entity:  |     | Treasury        |
  | Trade booking       |--+---->|  actual, projected, expected    |---->| dashboard       |
  | CLS schedule        |  |     | per time bucket (today, D+1..)  |     +-----------------+
  | Deposit system      |--+     | estimated LCR, buffer, gaps     |     | Alerts, limits  |
  +---------------------+        | source freshness per feed       |     +-----------------+
           ^                     +----------------+----------------+     | Funding engine  |
           |                                      |                      +-----------------+
           |      reconciliation with             v
           +----- EOD official figures      event store + snapshots

Estimating ratios intraday. The official LCR is computed from the end-of-day balance sheet (Chapter 9.2). A real-time estimate starts from the last official LCR and applies the change in each component since then:

  LCR_estimate = (HQLA_official + delta_HQLA) / (net_outflows_official + delta_net_outflows)

  delta_HQLA         = change in central bank cash + securities bought/sold or pledged
  delta_net_outflows = sum over deposit movements x (run-off rate of their category)
                       + new short-term wholesale funding maturing within 30 days, ...

Example. At 11:00 a large corporate client withdraws EUR 600m of non-operational deposits (40% run-off category) and moves it to another bank.

                                      Official (yesterday EOD)   Real-time estimate 11:00
  HQLA (EUR m)                                  18,000                 17,400   (cash left)
  Net outflows over 30 days                     12,000                 11,760   (600 x 40% removed)
  LCR                                            150.0%                 148.0%

The LCR falls only two points, because the deposit had already been counted as a 40% outflow. If 20 such clients leave in a morning, as in a run, the estimate shows the trend hours before the official figure.

Code sketch: an event-driven position.

from collections import defaultdict
from decimal import Decimal

class LiquidityPosition:
    def __init__(self):
        self.actual = defaultdict(Decimal)         # (entity, account, ccy) -> balance
        self.projected = defaultdict(Decimal)      # (entity, account, ccy, date) -> net flow
        self.seen = set()                          # processed event IDs (idempotency)
        self.last_event_at = {}                    # source -> timestamp, for staleness

    def apply(self, event):
        if event.id in self.seen:
            return                                 # duplicate delivery, ignore
        self.seen.add(event.id)
        key = (event.entity, event.account, event.currency)
        if event.kind == "SETTLED":                # money has actually moved
            self.actual[key] += event.signed_amount
            if event.was_scheduled:                # already in the projection: move it to actual
                self.projected[key + (event.value_date,)] -= event.signed_amount
        elif event.kind == "SCHEDULED":            # a known future flow
            self.projected[key + (event.value_date,)] += event.signed_amount
        elif event.kind == "CANCELLED":
            self.projected[key + (event.value_date,)] -= event.signed_amount
        self.last_event_at[event.source] = event.timestamp

    def expected_eod(self, key, today, forecast_net=Decimal("0")):
        return self.actual[key] + self.projected[key + (today,)] + forecast_net

When a scheduled flow settles, it moves from projected to actual, so the expected end-of-day figure does not change. Only surprises move it. In production, seen is a persistent store with expiry, and events carry sequence numbers per source so that gaps can be detected (Chapter 12.4).

Design challenges.

Challenge	Why it is hard	Approach
Incomplete sources	Some correspondents send statements only at end of day	Show per source freshness; mark positions as partial
Double counting	The same payment is reported by the payment hub and by the RTGS	Match on end-to-end ID and UETR before applying; settle once
24/7 operations	Instant payments flow at weekends while batch systems are down	Run the position service continuously; define what "end of day" means at weekends
Reconciliation	The real-time view drifts from the official ledger	Rebase daily on official EOD figures and report the difference
Legal entity and currency granularity	Liquidity in one entity may not be transferable to another	Keep positions per entity and currency; aggregate only where transfer is possible

Analogy. An official end-of-day position is like a bank statement; a real-time position is like the balance in a banking app that also shows pending card payments and the salary you expect on Friday. Both are useful, but only the second helps you decide whether you can afford something right now.

Key takeaways

• Instant payments, APIs and digital runs make once-a-day liquidity positions too slow.
• A real-time position combines actual, projected and expected flows per account, currency, entity and time bucket.
• Ratios such as the LCR can be estimated intraday by applying deltas to the last official figure.
• Idempotent event processing, source freshness and daily rebasing on official figures are essential.

🧪 Practice

1. Beginner: Explain the difference between actual, projected and expected flows, with one example of each for a EUR settlement account.
2. Intermediate: Using the LCR example, compute the real-time LCR estimate if 15 clients each withdraw EUR 600m of non-operational deposits during the morning (assume HQLA falls by the full amount).
3. Interview: "Design a real-time liquidity position for a bank with 12 legal entities, 35 currencies and instant payments 24/7." Hint: event sourcing per account with idempotent consumers, deduplication across sources, per-entity and per-currency positions with transferability rules, freshness indicators, weekend operating model, and daily reconciliation with the official ledger.

Streaming Risk Analytics

Why it matters. Risk numbers such as DV01 by tenor, FX net open positions and limit utilizations used to be computed overnight. Dealers and treasury managers now want them updated as trades are booked and markets move, so that they can hedge before a limit is breached rather than explain the breach the next morning. Stream processing makes this possible by computing aggregates incrementally on a continuous flow of events instead of recomputing everything from a database snapshot.

Batch versus streaming.

Aspect	Batch	Streaming
Input	Complete snapshot of positions and market data	Unbounded sequence of trade, market and lifecycle events
Computation	Full recalculation	Incremental update of aggregates per event or per window
Latency	Hours	Milliseconds to seconds
Correctness	Easy to reason about: one consistent snapshot	Must handle late, duplicate and out-of-order events
Typical tools	Scheduled jobs on a compute grid	Kafka Streams, Apache Flink, Spark Structured Streaming
Typical treasury use	Official VaR, regulatory figures	Intraday sensitivities, NOP, limit utilization, P&L estimates

Key concepts.

• Event time and processing time: event time is when the trade was executed; processing time is when the stream processor sees it. Aggregates for "trades up to 12:00" must use event time.
• Windows: tumbling (fixed, non-overlapping intervals, such as 1-minute buckets), sliding (overlapping) or session windows. Running totals such as a net position need no window at all; they are kept as state.
• Watermarks: a statement of the form "no more events older than T are expected". Results for a window are finalized when the watermark passes its end; later events are handled as corrections.
• State: the running aggregates, stored in a fault-tolerant store and checkpointed so that a restart neither loses nor double-counts events.
• Exactly-once effect: achieved by idempotent updates or transactional processing (Chapter 12.4); "exactly-once delivery" is not something networks provide.

What can be computed incrementally. Linear measures add up, so they are easy to stream. Non-linear measures need approximations.

Measure	Incremental?	Streaming approach
FX net open position	Yes, sum of deltas per currency	Add each trade's amounts
DV01 by tenor bucket	Yes, for small moves	Add each trade's bucketed DV01 computed at booking
P&L estimate	Approximately	Sensitivities x market moves since start of day (Taylor expansion)
VaR	No	Add new trades' scenario P&L vectors to the morning vector, then recompute the quantile (Chapter 8.4)
CVA, exposure profiles	No	Periodic recomputation on a grid, triggered by material changes

Example: streaming DV01 with a limit check.

from collections import defaultdict

class StreamingDv01:
    def __init__(self, limits):
        self.dv01 = defaultdict(float)          # (book, tenor) -> EUR per bp
        self.limits = limits                    # (book, tenor) -> absolute limit
        self.applied = {}                       # trade_id -> (version, bucketed DV01)

    def on_trade_event(self, ev):
        prev = self.applied.get(ev.trade_id)    # (version, bucketed DV01) or None
        if prev and prev[0] >= ev.version:
            return []                           # duplicate or out-of-order old version
        old = prev[1] if prev else {}
        new = {} if ev.cancelled else ev.bucketed_dv01
        alerts = []
        # replace the previous version's contribution with the new one
        for tenor in old.keys() | new.keys():
            key = (ev.book, tenor)
            self.dv01[key] += new.get(tenor, 0.0) - old.get(tenor, 0.0)
            utilization = abs(self.dv01[key]) / self.limits[key]
            if utilization >= 0.8:
                alerts.append((key, round(utilization, 2)))
        self.applied[ev.trade_id] = (ev.version, new)
        return alerts

An amendment replaces the old contribution rather than adding to it, and a cancellation removes it. These lifecycle cases (Chapter 4.3) cause most of the bugs in streaming aggregates.

Keeping streams honest.

  Start of day:  load official EOD positions and risk  -> state = official
  Intraday:      apply trade and market events          -> state = official + deltas
  End of day:    official batch recomputes everything
  Next morning:  compare streaming state at cut-off with the official result
                 -> difference per book and measure, investigated above tolerance

A systematic difference means missing events, a lifecycle bug or a model mismatch between the streaming and batch calculations. Monitoring this difference is the main correctness control of a streaming risk system.

Analogy. Batch risk is like counting all the people in a stadium by stopping everyone at the gate once an hour. Streaming risk is like a turnstile counter that updates with every person: much faster, but only correct if the turnstiles never double-count, never miss anyone and are reconciled with a full count from time to time.

Key takeaways

• Streaming analytics update risk measures incrementally as trades and market data arrive.
• Linear measures (positions, bucketed sensitivities) stream easily; non-linear ones (VaR, CVA) need approximations or periodic recomputation.
• Event time, watermarks, checkpointed state and idempotent updates are the core concepts.
• Amendments and cancellations must replace earlier contributions, not add to them.
• Reconcile the streaming state with the official batch every day.

🧪 Practice

1. Beginner: Explain the difference between event time and processing time, and give a treasury example where using processing time gives a wrong answer.
2. Intermediate: A trade is booked with a 5Y DV01 of EUR 12,000, amended to EUR 18,000 and then cancelled. Show the state of the 5Y bucket after each event in the example class, and what happens if the amendment arrives before the original booking.
3. Interview: "Our intraday DV01 dashboard and the official overnight figure differ by 3% every day. How would you investigate?" Hint: compare at trade level, look for missing event types (lifecycle events, fixings, maturities), market data timing differences, model differences between the incremental and full calculations, and trades booked directly in downstream systems.

Predictive Cash Forecasting with Machine Learning

Why it matters. Chapter 5.2 described cash flow forecasting with contractual flows and behavioural assumptions. A large part of daily cash movements is not contractual: corporate clients' payment habits, retail spending around payday, tax dates, seasonal patterns. Treasuries traditionally forecast these with averages and expert adjustments. Machine learning (ML) models can find patterns in years of transaction history and give more accurate forecasts with uncertainty ranges. Better forecasts mean smaller precautionary buffers, cheaper funding and earlier warning when actual flows deviate from normal.

What is being forecast. Typical targets are net flows per day (or per hour) for an account, client segment, currency or entity, over horizons from intraday to a few weeks. The forecast should be a distribution, not a single number: treasury cares most about the bad tail (an unexpectedly large outflow), so quantiles such as the 5th and 95th percentile matter more than the mean.

Features.

Feature group	Examples
Calendar	Day of week, day of month, month end, quarter end, holidays in each relevant calendar, days since last business day
Known events	Payroll dates, tax payment dates, dividend dates, large scheduled payments
History	Lagged flows (1, 5, 20 days), rolling means and volatilities
Client and product	Segment, product type, number of active clients, balances
Market and macro	Policy rate, money market fund yields (they drive deposit migration), FX rates

Model choices.

Approach	Strengths	Weaknesses	Typical role
Moving averages, seasonal naive	Simple, transparent	Misses interactions	Baseline that every model must beat
Statistical time series (ARIMA, exponential smoothing)	Well understood, gives intervals	One series at a time, limited features	Stable, aggregate series
Gradient boosted trees (LightGBM, XGBoost)	Handles many features and interactions, strong on tabular data	Needs feature engineering, intervals via quantile loss	Main workhorse for segment-level forecasts
Neural networks (LSTM, temporal fusion transformers)	Learn complex patterns across many series	Data hungry, harder to explain and validate	Very large portfolios of similar series

Example: quantile forecasts with gradient boosting.

import pandas as pd
from sklearn.ensemble import GradientBoostingRegressor
from sklearn.model_selection import TimeSeriesSplit

def make_features(df):
    out = pd.DataFrame(index=df.index)
    out["dow"] = df.index.dayofweek
    out["dom"] = df.index.day
    out["month_end"] = df.index.is_month_end.astype(int)
    out["payroll"] = df["payroll_day"].astype(int)
    out["tax_day"] = df["tax_day"].astype(int)
    for lag in (1, 5, 20):
        out[f"lag_{lag}"] = df["net_flow"].shift(lag)       # only past values: no leakage
    out["vol_20"] = df["net_flow"].shift(1).rolling(20).std()
    return out.dropna()

X = make_features(history)
y = history.loc[X.index, "net_flow"]

models = {q: GradientBoostingRegressor(loss="quantile", alpha=q, n_estimators=300, max_depth=3)
          for q in (0.05, 0.5, 0.95)}

# walk-forward validation: always train on the past and test on the following period
for train_idx, test_idx in TimeSeriesSplit(n_splits=5).split(X):
    for q, m in models.items():
        m.fit(X.iloc[train_idx], y.iloc[train_idx])
    # evaluate pinball loss per quantile and the coverage of the 5-95% interval ...

The 5% quantile is the "bad day" outflow that treasury plans against. Coverage tells you whether the interval is honest: about 90% of actual flows should fall between the 5% and 95% forecasts.

Evaluation.

Metric	What it measures
MAE, RMSE	Error of the point forecast
MAPE	Relative error; unstable when flows are close to zero, which net flows often are
Pinball (quantile) loss	Quality of each quantile forecast
Interval coverage	Share of actual values inside the predicted interval
Improvement over baseline	Does the model beat the seasonal naive forecast, consistently and by segment

Pitfalls.

• Data leakage: using information not available at forecast time (a same-day balance, a feature computed with future data). Walk-forward validation and point-in-time feature stores prevent it.
• Regime shifts: models trained in 2015-2021, when rates were near zero, failed to anticipate the deposit migration of 2022-2023. Monitor drift and include rate-sensitive features.
• Stress is out of sample: ML models learn normal behaviour. They are not stress models. Treasury must still use stress scenarios (Chapter 16.1) for buffers.
• Hierarchy consistency: forecasts for segments should add up to the forecast for the entity. Use hierarchical reconciliation methods.

Governance. A forecasting model used for liquidity decisions is a model under model risk management (for example SR 11-7 in the US and the PRA's SS1/23 in the UK): documented, independently validated, monitored, with explainability (such as feature importance or SHAP values) so that treasury understands why the forecast changed. Keep a human override with an audit trail.

Analogy. An ML cash forecast is like a weather forecast. It is very good at predicting tomorrow's normal weather, and it gives a probability of rain rather than a promise. It is not designed to predict a once-in-a-century storm; for that you still build sea walls (buffers and stress tests).

Key takeaways

• ML models forecast non-contractual cash flows from calendar, event, history and market features.
• Forecast distributions (quantiles), not only point values; treasury plans against the bad tail.
• Validate with walk-forward tests against a simple baseline, and check interval coverage.
• Guard against leakage, regime shifts and over-reliance on models in stress.
• Treat the model as a governed model: validation, monitoring, explainability and overrides.

🧪 Practice

1. Beginner: List five features you would use to forecast daily net flows on retail current accounts, and explain why each might help.
2. Intermediate: A model's 5-95% interval contains the actual flow on 72% of days in the test period. What does this tell you, and how would you fix it?
3. Interview: "Our ML forecast was very accurate for two years and then underestimated outflows for six months in a row. What happened and what would you change?" Hint: regime shift (rates, competition, a client event), drift monitoring, features that capture the driver, retraining policy, and the difference between forecasting and stress testing.

Automated Funding Decisions

Why it matters. Once a treasury has real-time positions and reliable forecasts, the next question is whether routine funding decisions can be automated: placing surplus cash overnight, borrowing to cover a forecast shortfall, choosing between repo, central bank facilities and intragroup loans, or rebalancing between currencies. Manual decisions are slow, especially at weekends with instant payments, and depend on the dealer on duty. Automation can be faster, cheaper and more consistent, but a wrong automated decision can move billions in seconds. The engineering challenge is to automate within strict guardrails.

Levels of automation.

Level	Description	Example
0. Information	System shows positions and forecasts; humans decide	Liquidity dashboard
1. Recommendation	System proposes actions; a dealer approves each one	"Borrow EUR 300m O/N in repo against Bund collateral"
2. Automated with limits	System executes within pre-approved limits; humans monitor and can stop it	Automatic overnight placement of surplus up to EUR 500m with approved counterparties
3. Fully automated	System decides and executes without routine human involvement	Intragroup sweeps between accounts of the same entity

Most banks today operate at levels 1 and 2 for market funding and at level 3 only for internal sweeps and cash pooling (Chapter 10.2).

Funding as an optimization problem. Covering a shortfall at minimum cost, subject to constraints, is a linear program.

  Minimize    sum over sources i of  cost_i x amount_i
  Subject to  sum of amount_i                    >= shortfall
              0 <= amount_i                      <= capacity_i     (limits, available collateral)
              amount from one counterparty group <= concentration limit
              LCR after funding                  >= internal target

Example. A forecast shortfall of EUR 900m for tomorrow, with four sources:

Source	Cost (bp over €STR)	Capacity (EUR m)	Notes
Repo against government bonds	2	500	Uses unencumbered collateral
Unsecured interbank	12	600	Counterparty limits apply
Intragroup loan from parent	8	300	Subject to large exposure rules
Central bank marginal lending facility	25	2,000	Signalling concerns; last resort

from scipy.optimize import linprog

cost = [2, 12, 8, 25]                       # bp
capacity = [500, 600, 300, 2000]            # EUR m
shortfall = 900

result = linprog(c=cost,
                 A_ub=[[-1, -1, -1, -1]], b_ub=[-shortfall],     # total >= shortfall
                 bounds=list(zip([0] * 4, capacity)))
print(result.x)          # [500. 100. 300.   0.] -> repo 500, unsecured 100, intragroup 300
print(result.fun / shortfall)  # about 5.1 bp average cost

The optimizer uses the cheapest sources first. Real models add constraints (collateral eligibility per source, maturity profile, the effect of repo on encumbrance, keeping central bank use for emergencies) and multiple currencies with FX swaps as a source.

Guardrails.

Guardrail	Purpose
Hard limits on size, counterparty, tenor and currency	Bound the damage of any single wrong decision
Input validation and freshness checks	Do not act on a stale position or a broken forecast
Plausibility checks on decisions	Reject decisions far outside the historical pattern, route them to a human
Four-eyes approval above thresholds	Human judgment where the stakes are high
Kill switch	Stop all automated actions immediately, by treasury or operations
Explanation per decision	Record inputs, constraints, alternatives and the reason for the chosen action
Stress mode	Switch automatically to recommendation only when early warning indicators fire

If the system places orders on trading venues, it also falls under algorithmic trading rules (in the EU, MiFID II and RTS 6: pre-trade controls, kill functionality, testing and annual self-assessment).

Decision flow.

  real-time position + forecast (with quantiles)
                  |
                  v
       funding need per currency and entity  ---- input stale? ----> hold, alert
                  |
                  v
       optimizer proposes actions
                  |
                  v
       guardrail checks ---- outside limits or unusual ----> dealer approval
                  |
                  v (within limits)
       execute via trading / payment systems  ---> record decision, inputs, outcome
                  |
                  v
       post-trade monitoring: did the position close as expected?

Analogy. Automated funding is like an autopilot. It flies the routine part of the journey more precisely than a tired pilot, but it operates inside a defined envelope, disconnects when conditions are unusual, and the pilot can always take control with one button.

Key takeaways

• Automation of funding ranges from recommendations to fully automated sweeps; market funding is usually automated only within strict limits.
• Funding choices can be framed as a cost minimization with limits, collateral and regulatory constraints.
• Guardrails (limits, freshness checks, approvals, kill switches, explanations) matter more than the optimizer.
• Automated systems should fall back to human decision in stress.
• Trading on venues brings algorithmic trading regulation into scope.

🧪 Practice

1. Beginner: For each action, suggest an appropriate automation level and explain why: (a) intragroup sweep of a subsidiary's surplus to the parent; (b) EUR 2bn overnight borrowing in the unsecured market; (c) investing a USD 50m surplus in an approved money market fund.
2. Intermediate: In the optimization example, add a constraint that at least EUR 200m of repo collateral must remain unencumbered (so repo capacity falls to 300). Solve the problem again and compute the new average cost.
3. Interview: "How would you make sure an automated funding engine does not make things worse during a liquidity crisis?" Hint: stress mode switched by early warning indicators, limits on market signalling actions (central bank facilities), human approval, kill switch, testing with historical crisis replays, and monitoring of decision outcomes.

<a id="163-digital-assets-and-tokenization"></a>

16.3 Digital Assets and Tokenization

This subchapter explains the new forms of money and settlement that treasury must understand: central bank digital currencies, tokenized bank deposits, stablecoins, settlement on distributed ledgers and programmable money. For each, the focus is on what changes for liquidity, funding and treasury systems, not on cryptocurrency speculation.

Central Bank Digital Currencies (CBDCs)

Why it matters. Today the public can hold central bank money only as cash. Everything else people call "money" (bank deposits, e-money balances) is a claim on a private institution. As cash use declines and private digital payment systems grow, central banks worry about losing a public anchor for the monetary system and about dependence on foreign card schemes and big tech platforms. A central bank digital currency (CBDC) is a digital form of central bank money. For banks, a retail CBDC is a potential competitor for deposits; a wholesale CBDC is a potential new settlement asset for interbank and securities transactions.

Retail and wholesale CBDC.

Aspect	Retail CBDC	Wholesale CBDC
Users	Households and businesses	Banks and other financial institutions
Purpose	Digital equivalent of cash for everyday payments	Settlement of interbank, securities and cross-border transactions, often on DLT
Difference from today	New: the public gets direct access to central bank money in digital form	Incremental: banks already hold central bank reserves; the change is the technology and programmability
Main treasury impact	Deposit outflows into CBDC, funding cost	New settlement channels, intraday liquidity management on new platforms
Examples	e-CNY (pilot), Bahamas Sand Dollar (2020), eNaira (2021), digital euro (in preparation)	SNB Project Helvetia (live pilot since December 2023), BIS Project Agora, Eurosystem Pontes

Design choices.

• Two-tier distribution: the central bank issues; banks and payment providers onboard users, run KYC and provide wallets. Almost all designs follow this model, so banks remain the customer interface.
• Account-based or token-based: ownership recorded against a verified identity, or transferred like a digital bearer instrument with offline capability.
• Holding limits: a cap per person (figures around EUR 3,000 have been discussed for the digital euro) to limit deposit outflows from banks.
• Remuneration: most designs pay no interest, so that the CBDC does not compete with deposits as a store of value.
• Waterfall and reverse waterfall: incoming CBDC above the holding limit is automatically swept to the user's linked bank account (waterfall); a payment larger than the CBDC balance is automatically topped up from the bank account (reverse waterfall).

State of play (2026). The ECB completed the preparation phase of the digital euro in October 2025 and moved to the next phase, with possible first issuance around 2029 if the EU legislation is adopted. China's e-CNY is in a large-scale pilot. The United States prohibited federal agencies from establishing a retail CBDC by executive order in January 2025. For wholesale settlement, the Eurosystem plans Pontes, a link between DLT platforms and TARGET services, in 2026, and a longer-term programme (Appia).

Treasury impact of a retail CBDC. Every euro moved into a CBDC wallet leaves a bank deposit and the bank's central bank reserves:

  Customer moves EUR 1,000 from a deposit into a digital euro wallet

  Bank balance sheet                         Central bank balance sheet
  Assets              Liabilities            Assets          Liabilities
  Reserves  -1,000    Deposits  -1,000                       Reserves (bank)  -1,000
                                                             Digital euro     +1,000

Example: deposit migration. A bank has EUR 40bn of retail sight deposits from 4 million customers.

  Scenario                                      Outflow           Share of retail sight deposits
  30% of customers hold EUR 1,000 on average    EUR 1.2bn         3%
  60% of customers fill a EUR 3,000 limit       EUR 7.2bn         18%
  Stress: run into CBDC (no limit)              unbounded         -

With a holding limit and waterfall, the outflow is bounded and predictable. Without one, a CBDC makes a digital run easier, because moving money to the safest possible asset takes one tap. The bank's treasury would need to replace lost deposits with more expensive funding, hold more liquid assets against the new outflow channel and model CBDC-related run-off in its stress tests.

Engineering view.

• Banks would integrate with the CBDC infrastructure as intermediaries: onboarding, wallet management, waterfall and reverse waterfall linked to core banking accounts, in real time.
• Liquidity systems need a new flow category (deposit to CBDC conversions), with intraday monitoring, because conversions drain reserves immediately.
• Privacy rules may restrict what data intermediaries can see or use about CBDC transactions.

Analogy. A retail CBDC is like a public water fountain installed next to a bottled water shop. Most people will still buy bottles for convenience and extras, but the shop must plan for customers who switch, and the city limits how much each person can take from the fountain.

Key takeaways

• A CBDC is digital central bank money; retail CBDCs are for the public, wholesale CBDCs for financial institutions.
• Retail CBDCs can drain deposits and reserves; holding limits, zero remuneration and waterfall mechanisms are designed to limit this.
• Wholesale CBDCs are mainly a new settlement technology for interbank and securities transactions.
• Treasury must model CBDC conversions as a new outflow channel, especially under stress.

🧪 Practice

1. Beginner: Explain the difference between a retail and a wholesale CBDC, and why only the first creates a new deposit outflow risk.
2. Intermediate: A bank's LCR is 140% with net outflows of EUR 20bn. A digital euro is introduced, and the bank expects EUR 3bn of retail deposits (currently assumed at a 5% run-off) to move into CBDC over a year. Estimate the effect on HQLA and the LCR, stating your assumptions.
3. Interview: "How would you implement the reverse waterfall for a digital euro wallet linked to a customer's current account?" Hint: a synchronous funding call within the payment time budget, overdraft and available balance checks, idempotency and compensation if the CBDC payment fails, consistent posting in core banking, and liquidity monitoring of conversions.

Tokenized Deposits

Why it matters. Banks want the benefits of blockchain-style settlement (24/7 availability, atomic exchange with tokenized assets, programmability) without giving up deposits to stablecoins or CBDCs. A tokenized deposit is an ordinary commercial bank deposit recorded as a token on a distributed ledger instead of, or in addition to, an entry in the core banking ledger. Legally it remains a liability of the bank, with the same regulation, capital, liquidity treatment and deposit insurance as any other deposit. It changes how the deposit moves, not what it is.

Tokenized deposit versus other forms of digital money.

Aspect	Bank deposit (today)	Tokenized deposit	Stablecoin	Wholesale CBDC
Issuer	Commercial bank	Commercial bank	Non-bank or bank issuer	Central bank
Claim	On the bank	On the bank	On the issuer, backed by reserve assets	On the central bank
Ledger	Core banking system	DLT (permissioned or public)	Usually public blockchain	DLT or RTGS
Deposit insurance	Yes	Yes (as a deposit)	No	Not applicable
Interest	Possible	Possible	Usually prohibited (MiCA, GENIUS Act)	Usually not
Transfer between institutions	Through interbank settlement	Within one bank's network today; across banks needs a common settlement asset	On-chain, freely	Between participants

How it works. The bank keeps a token ledger alongside its core ledger. Customers' balances move from the core ledger onto the token ledger and back:

  Mint:     customer account (core)  -100m   -->  token wallet (DLT)  +100m
  Transfer: token wallet A  -50m  --> token wallet B  +50m          (24/7, seconds)
  Burn:     token wallet B  -50m  --> customer account B (core) +50m

  Invariant at all times:
    sum of token balances on DLT == balance of the "tokens in circulation" account in core

Examples. JPMorgan's Kinexys (formerly Onyx and JPM Coin) moves tokenized deposits between clients' accounts in different locations around the clock and supports intraday repo against tokenized collateral. Citi Token Services and HSBC's tokenized deposit service offer similar functionality for corporate clients. Most current implementations work within one bank's network. Moving tokenized deposits between banks needs a common settlement layer, which is what projects like the BIS Project Agora (tokenized correspondent banking with wholesale central bank money) are exploring.

Treasury use cases.

Use case	Benefit
24/7 intragroup liquidity	Move cash between group entities at weekends or across time zones without waiting for RTGS opening hours
Intraday repo	Borrow for hours against tokenized securities, repaying automatically at a fixed time
Atomic delivery versus payment	Pay for tokenized bonds or fund units in the same transaction as the delivery
Programmable sweeps	Rules that move balances automatically (next topics)

Example: intraday repo. A bank needs USD 500m from 09:00 to 15:00 to cover a payment peak. It exchanges tokenized Treasury bonds for tokenized deposits with a counterparty on a shared ledger; a smart contract reverses the trade at 15:00 with interest computed for 6 hours. At 5.0% on an ACT/360 basis, the interest is 500m x 5.0% x 6/24 / 360 = about USD 17,400. Without this, the bank would hold more cash idle all day or use central bank intraday credit.

Engineering challenges.

• Two ledgers, one truth: the core banking system remains the book of record for accounting and regulatory reporting. The token ledger must reconcile with it continuously (the invariant above), and every mint and burn must be atomic across both.
• Liquidity classification: tokenized deposits are deposits, so they need the usual LCR classification (operational, non-operational, by counterparty type). Systems must carry these attributes on tokens.
• 24/7 operations: risk limits, sanctions screening and fraud controls must run when token transfers run, including at weekends.
• Key management: wallets are controlled by private keys held in HSMs (Chapter 15.3); losing or leaking keys is equivalent to losing control of the funds.

def reconcile_tokens(core_balance_in_circulation, token_ledger, tolerance=0):
    on_chain = sum(w.balance for w in token_ledger.wallets())
    pending = token_ledger.pending_mints_and_burns()      # in flight between ledgers
    diff = core_balance_in_circulation - (on_chain + pending.net_amount)
    if abs(diff) > tolerance:
        raise ReconciliationBreak(f"token ledger differs from core by {diff}")

Analogy. A tokenized deposit is like a casino chip that the bank itself issues for its own money. Inside the casino (the ledger) chips move instantly between players, and at the cashier each chip is always exchangeable one for one for the money in your account. The bank must make sure the number of chips on the tables always equals the money set aside for them.

Key takeaways

• A tokenized deposit is a regular bank deposit recorded and transferred on a distributed ledger.
• It keeps deposit regulation, liquidity treatment and insurance, unlike stablecoins.
• Treasury uses include 24/7 intragroup liquidity, intraday repo and atomic settlement.
• Interbank use needs a common settlement layer; most current systems operate within one bank.
• The core ledger remains the book of record; continuous reconciliation and key management are critical.

🧪 Practice

1. Beginner: Explain why a tokenized deposit is covered by deposit insurance while a stablecoin is not.
2. Intermediate: Compute the interest on an intraday repo of EUR 250m from 10:00 to 16:30 at 3.2% on ACT/360. Compare it with the cost of holding the same amount idle all day if the alternative use earns 3.0% per year.
3. Interview: "Design the mint and burn process between our core banking system and a tokenized deposit ledger so that money is never created or lost." Hint: an outbox pattern or two-phase process with a pending state, idempotent operations keyed by request ID, a reconciliation invariant, compensation on failure, and clear rules for which ledger is the book of record.

Stablecoins and Treasury Implications

Why it matters. Stablecoins are tokens on public blockchains designed to keep a stable value, usually one US dollar, by holding reserve assets. Their market value is in the hundreds of billions of US dollars, most of it in USDT (Tether) and USDC (Circle), and they are used for crypto trading, cross-border payments and, increasingly, by corporates. For banks, stablecoins matter in three ways: as competitors for deposits and payments, as large and potentially volatile depositors (issuers keep part of their reserves in bank deposits), and as an asset that corporate clients want to hold, pay with or convert.

Types.

Type	Stabilization mechanism	Example	Risk
Fiat-backed	Reserves of cash, deposits, short-term government securities	USDC, USDT, EURC	Reserve quality, run on redemption
Crypto-collateralized	Over-collateralized by other crypto assets	DAI / USDS	Collateral price crashes
Algorithmic	Supply adjusted by an algorithm and a sister token, no full backing	TerraUSD (collapsed in May 2022)	Death spiral; largely discredited

Regulation.

Aspect	EU: MiCA	US: GENIUS Act
In force	Stablecoin rules apply since 30 June 2024	Signed July 2025; applies 18 months after enactment or 120 days after final regulations, whichever is earlier
Categories	E-money tokens (EMTs, one fiat currency) and asset-referenced tokens (ARTs)	Payment stablecoins
Who may issue	EMTs: credit institutions and e-money institutions	Subsidiaries of insured banks, approved non-bank issuers, state-qualified issuers (smaller ones)
Reserves	Segregated; at least 30% in bank deposits (60% for significant EMTs), the rest in high-quality liquid assets	1:1 in cash, insured deposits, Treasury bills up to 93 days, repo, government money market funds
Redemption	At par, at any time, without fees	At par, timely
Interest to holders	Prohibited	Prohibited from the issuer

For prudential capital, the Basel Committee's crypto-asset standard (applicable from January 2026) separates stablecoins that meet strict conditions on reserves and redemption from other crypto assets, which receive a punitive 1250% risk weight.

Treasury implications.

1. Deposit disintermediation. When a customer buys a stablecoin, their bank deposit moves to the issuer, which places part of it back in the banking system (often in a few large banks) and part in Treasury bills. Retail and corporate deposits are replaced by concentrated wholesale deposits from issuers, or leave the banking system altogether.

2. Issuer deposits are flighty. Stablecoin holders can redeem at any time, 24/7, and issuers face their own runs. In March 2023, Circle had about USD 3.3bn of USDC reserves at Silicon Valley Bank. When SVB failed, USDC briefly fell to about USD 0.88 and holders redeemed billions in days. A bank holding issuer deposits must treat them as concentrated, highly runnable wholesale funding and assume very high run-off in stress.

  Stress chain:
  news about issuer or its bank --> holders redeem stablecoins --> issuer withdraws deposits
  from banks and sells T-bills --> outflows at the banks holding reserves --> more news

3. Client services. Corporates may want to receive stablecoin payments and convert them to fiat, or hold stablecoins for cross-border treasury. This requires on-ramps and off-ramps, custody, blockchain analytics for sanctions and AML, and accounting (under IFRS, most stablecoins are not cash equivalents, which matters for corporate treasury reporting).

Example: run-off for issuer deposits. A bank holds EUR 2bn of deposits from an EMT issuer. Under MiCA, the issuer must hold at least 30% of reserves in bank deposits and spread them across institutions.

Assumption	Normal days	Stress
Daily redemptions of the token	0.5%	15% on day 1, 10% on day 2
Share met from bank deposits first	100%	100% (fastest source)
Outflow from this bank (if it holds a quarter of the issuer's deposits and the token supply is EUR 25bn)	about EUR 30m per day	EUR 940m on day 1 (25bn x 15% x 25%), i.e. almost half the balance

The calculation shows why such deposits should be modelled close to 100% run-off within the LCR horizon and covered by matching HQLA.

Engineering view.

• Tag issuer deposits as a separate counterparty category with concentration monitoring and stressed run-off.
• Monitor issuer-level signals in real time (token price deviation from par, redemption volumes, on-chain flows) as early warning indicators.
• Integrate blockchain analytics for screening, and treat wallet addresses as counterparty attributes.

Analogy. A stablecoin is like a gift card issued by a third party and backed by money it keeps in several banks. If people start doubting the card, they all rush to redeem, and the issuer immediately pulls its money from the banks, which in turn feel the run.

Key takeaways

• Stablecoins are tokens backed by reserve assets, aiming at a stable value; fiat-backed coins dominate.
• MiCA and the GENIUS Act require high-quality reserves, redemption at par and no interest to holders.
• Stablecoins can move deposits out of banks or concentrate them in a few banks as issuer reserves.
• Issuer deposits are concentrated, 24/7 runnable wholesale funding; USDC and SVB in March 2023 showed the contagion path.
• Banks need specific classification, real-time monitoring and screening for stablecoin-related flows.

🧪 Practice

1. Beginner: Name the three types of stablecoin and explain why algorithmic stablecoins are considered the most fragile.
2. Intermediate: A bank holds USD 1.5bn of deposits from a stablecoin issuer with USD 40bn in circulation, which places 12.5% of its bank deposit reserves at this bank. Under a stress of 12% redemptions on day 1, all met from bank deposits first, and assuming the issuer holds 30% of reserves in bank deposits, estimate the outflow from this bank. Is the bank deposit share a constraint?
3. Interview: "A large corporate client wants to receive payments in USDC and have them credited in USD to its account the same day. What does the bank need to build?" Hint: custody wallets and key management, on-chain monitoring, sanctions and AML screening of addresses, conversion with the issuer or exchanges, FX and liquidity management of the stablecoin inventory, accounting and reconciliation with core banking.

Distributed Ledger Settlement

Why it matters. Chapter 2.3 described securities settlement through central securities depositories (CSDs) and the delivery-versus-payment (DvP) principle. Today's process involves several intermediaries, each with its own records that must be reconciled, and settlement typically one or two days after trade date. A distributed ledger (DLT) lets participants share one synchronized record of ownership. If both the asset and the cash are on the ledger, the two legs can be exchanged atomically in one transaction, which removes principal risk, reduces reconciliation and allows settlement at any chosen time, including instantly.

Core concepts.

Concept	Meaning
Distributed ledger	A database replicated across participants, updated by a consensus protocol
Permissioned vs public	Only approved participants run nodes and transact (most financial market infrastructure), or anyone can (Ethereum)
Token	A digital representation of an asset or money on the ledger
Smart contract	Code on the ledger that executes transfers according to predefined rules
Atomic settlement	Both legs settle together or neither settles
Finality	The point at which a transfer is irrevocable: legal finality (defined by law, such as the EU Settlement Finality Directive) versus technical finality (probabilistic on some public chains)

Traditional versus DLT settlement.

  Traditional (T+1/T+2)                              DLT atomic DvP (T+0 or chosen time)

  Trade --> confirmation --> instruction             Trade --> smart contract locks both legs
     --> CSD matching --> settlement batch                    |
     --> cash leg in RTGS / securities in CSD                 v
     --> custodian records --> reconciliation        one transaction: bond token to buyer,
         (many separate ledgers)                     cash token to seller, or nothing

The cash leg problem. Atomic DvP needs money on the same ledger as the asset, or a reliable link between ledgers.

Cash leg option	Description	Status
Wholesale CBDC on the DLT	Central bank money issued as tokens	Pilots: SNB Helvetia, Eurosystem exploratory work in 2024
Interoperability with RTGS	DLT platform triggers a payment in the existing RTGS, which confirms back	Bundesbank trigger solution, Banca d'Italia TIPS hash-link; Eurosystem Pontes
Tokenized deposits	Commercial bank money on the ledger	Live within single-bank networks
Stablecoins	Private tokens on public chains	Used in crypto markets; limited use in regulated securities settlement

Regulation. The EU DLT Pilot Regime (applicable since March 2023) allows DLT-based market infrastructures to operate with exemptions from some CSD and trading rules, within size limits. Settlement finality and the legal status of tokenized securities depend on national law; the ledger only records what the law recognizes.

Example: atomic DvP.

class DvPContract:
    """Settles a bond against cash atomically on a single ledger."""
    def __init__(self, ledger, seller, buyer, bond, nominal, cash_token, amount, deadline):
        self.ledger, self.seller, self.buyer = ledger, seller, buyer
        self.bond, self.nominal = bond, nominal
        self.cash_token, self.amount, self.deadline = cash_token, amount, deadline
        self.state = "PENDING"

    def settle(self, now):
        if self.state != "PENDING":
            return self.state                              # idempotent
        if now > self.deadline:
            self.state = "EXPIRED"
            return self.state
        with self.ledger.transaction():                    # all or nothing
            self.ledger.transfer(self.bond, self.seller, self.buyer, self.nominal)
            self.ledger.transfer(self.cash_token, self.buyer, self.seller, self.amount)
        self.state = "SETTLED"
        return self.state

If either transfer fails (insufficient bond or cash balance), the ledger transaction rolls back and neither party is exposed. There is no period in which the seller has delivered and not been paid.

Treasury implications.

• Liquidity timing: atomic and instant settlement removes netting. A batch that nets 100 trades into one payment now needs cash for each trade gross. Intraday liquidity needs can rise considerably unless liquidity-saving mechanisms are built in.
• Fragmentation: cash and collateral spread across several DLT platforms and the traditional RTGS; treasury must see and move liquidity across all of them.
• Collateral mobility: tokenized collateral can be moved in minutes, enabling intraday repo and faster margin calls, but also faster runs.
• Operations: node operation, key management, smart contract risk and reconciliation with internal books of record.

Analogy. Traditional settlement is like a house sale in which the deed and the money pass through several notaries' offices, each keeping its own copy of the file. DLT settlement is like both parties standing at one counter where the deed and the money change hands in a single movement, or not at all.

Key takeaways

• DLT gives participants one shared ledger; atomic DvP exchanges asset and cash together, removing principal risk.
• The cash leg is the main obstacle: options are wholesale CBDC, links to RTGS, tokenized deposits or stablecoins.
• Legal finality and the legal status of tokens come from law, not from the technology.
• Instant gross settlement can increase intraday liquidity needs because netting is lost.
• Treasury must manage liquidity and collateral across fragmented ledgers.

🧪 Practice

1. Beginner: Explain atomic settlement and why it eliminates principal risk in a bond trade.
2. Intermediate: A bank settles 200 bond trades per day with a counterparty. In today's batch they net to a single payment of EUR 40m. The gross purchases are EUR 2.1bn and gross sales EUR 2.06bn. Estimate the peak liquidity need under atomic gross settlement if all purchases settle before sales, and propose two ways to reduce it.
3. Interview: "Our bank joins a DLT securities platform whose cash leg is settled through a trigger to T2. What can go wrong between the DLT and the RTGS, and how do you design for it?" Hint: timeouts and partial completion, locking of the securities while waiting for cash, idempotent trigger messages, RTGS operating hours, reconciliation of both systems, and who bears the risk in each failure case.

Programmable Money

Why it matters. Many treasury processes are "if this, then pay that": release payment when goods arrive, sweep any balance above a threshold to the parent, pay interest every day, return collateral when a loan is repaid. Today these rules live in separate systems that read data, decide and then send a payment instruction, with delays and reconciliation at each step. Programmable money attaches the rules to the transfer itself, so that the payment executes automatically and atomically when conditions are met. Tokenized deposits, stablecoins and wholesale CBDCs on DLT make this possible.

Two concepts that are often confused.

Concept	Where the logic lives	Example	Main concern
Programmable payments	Outside the money, in a contract or system that triggers transfers	A smart contract that pays a supplier when a shipment is confirmed	Correctness of the contract and its data inputs
Programmable money	In the money itself, restricting how it can be used	Tokens that can only be spent on certain goods or expire after a date	Money loses fungibility; "a euro is no longer a euro"

Central banks and most banks support programmable payments but are cautious about programmable money, because money that behaves differently depending on its history breaks the principle that every unit of money is equal (singleness of money).

Treasury use cases.

Use case	Rule	Benefit
Automated sweeps	Every hour, move balance above EUR 10m to the group treasury wallet	Cash pooling 24/7 without batch files
Conditional payment (escrow)	Release payment when a trusted data source (oracle) confirms delivery	Replaces some letters of credit (Chapter 10.3), reduces counterparty risk
Intraday repo unwind	Return cash and collateral at 15:00 with interest	No manual closing of the trade
Streaming interest	Accrue and pay interest every second or hour	Exact interest, no end-of-period settlement
Margin automation	Transfer collateral when exposure exceeds a threshold	Faster, less operational effort

Example: a conditional payment.

class ConditionalPayment:
    def __init__(self, ledger, payer, payee, amount, oracle, shipment_id, expiry):
        self.ledger, self.payer, self.payee = ledger, payer, payee
        self.amount, self.oracle = amount, oracle
        self.shipment_id, self.expiry = shipment_id, expiry
        self.ledger.lock(payer, amount, reference=self)        # funds reserved at creation
        self.state = "LOCKED"

    def on_event(self, now):
        if self.state != "LOCKED":
            return self.state
        if self.oracle.is_delivered(self.shipment_id):         # trusted, signed data source
            self.ledger.release_to(self, self.payee)
            self.state = "PAID"
        elif now >= self.expiry:
            self.ledger.release_to(self, self.payer)           # refund
            self.state = "REFUNDED"
        return self.state

For the payer's treasury, locked funds are still on the balance sheet but not available. The liquidity system must treat them as encumbered until the contract resolves.

Risks and controls.

Risk	Example	Control
Code defects	A bug releases funds twice, or never	Formal verification, audits, extensive testing, limits per contract
Irreversibility	An erroneous transfer cannot be recalled	Pause functions, governance for upgrades, pre-execution checks
Oracle risk	The data source is wrong or manipulated	Signed data from trusted sources, multiple oracles, dispute process
Liquidity visibility	Funds locked in many contracts are hard to see	Treat locked funds as encumbered; aggregate across ledgers
Legal certainty	Is the code the contract, or does a legal agreement prevail?	Legal agreements that reference and govern the code

Analogy. Programmable payments are like a vending machine: insert money, choose, and the machine delivers and takes payment in one step, following fixed rules. The rules are only as good as the machine's mechanics, and if it swallows your coin there is no clerk to ask for it back.

Key takeaways

• Programmable payments attach rules to transfers so that they execute automatically and atomically when conditions are met.
• Programmable money, which restricts how money itself can be used, threatens fungibility and is viewed cautiously.
• Treasury use cases include 24/7 sweeps, conditional payments, intraday repo unwinds, streaming interest and margin automation.
• Locked funds are encumbered liquidity and must be visible to treasury systems.
• Code defects, irreversibility, oracle risk and legal certainty need explicit controls.

🧪 Practice

1. Beginner: Explain the difference between programmable payments and programmable money, with one example of each.
2. Intermediate: A subsidiary has 50 conditional payment contracts locking a total of EUR 120m, with expiry dates over the next 60 days. How should these appear in the subsidiary's liquidity position and its 30-day cash ladder?
3. Interview: "A smart contract for automated sweeps moved EUR 200m to the wrong wallet because of a configuration error. What controls should have prevented it, and how would you recover?" Hint: allow-lists of destination wallets, limits per transfer and per period, four-eyes approval of configuration changes, staged rollout and simulation, pause functionality, legal recovery agreements with the counterparty, and incident handling (Chapter 15.2).

<a id="164-case-studies"></a>

16.4 Case Studies

This subchapter studies four bank failures in more depth than the overview in Chapter 5.1 (Historical Bank Runs and Lessons), from the point of view of treasury: how each bank was funded, how the crisis unfolded, which measures and systems failed, and what changed afterwards. The last topic turns these lessons into requirements for treasury systems.

Northern Rock (2007)

Why study it. Northern Rock was the first run on a British bank in about 150 years, and its images (queues outside branches) became the symbol of the 2007 crisis. It is the classic example of a bank that was solvent, had low credit losses and still failed, because its funding model depended on markets that closed. It shaped the Basel III liquidity rules and UK deposit insurance reform.

Business and funding model. Northern Rock was a former building society that became a bank in 1997. It grew its mortgage book very quickly, by around 20% a year, using an "originate to distribute" model: it granted mortgages, then funded them by selling packages of mortgages to investors through its securitization vehicle (Granite) and by borrowing in the wholesale markets.

  Approximate funding structure before the crisis (share of liabilities)

  Retail deposits          ######                         ~ 25%
  Securitization (Granite) ###########                    ~ 40%+
  Wholesale funding        #######                        ~ 25%
  Covered bonds, other     ##                             ~ 10%

  Assets: mostly UK residential mortgages (long term, illiquid)

The model needed new securitizations every few months and continuous access to short-term wholesale funding. The bank's stress tests assumed that problems in one funding market could be offset by another; they did not consider all markets closing at once.

Timeline.

Date	Event
June 2007	Basel II approval allows lower capital requirements; Northern Rock announces a higher dividend
9 August 2007	BNP Paribas suspends three funds exposed to US subprime; interbank and securitization markets freeze
August 2007	The bank cannot securitize or roll wholesale funding; it seeks a buyer and asks the authorities for help
13-14 September 2007	The news of Bank of England emergency support leaks and is then announced; queues form at branches; customers withdraw billions within days, also online
17 September 2007	The government guarantees all existing deposits; the run stops
September 2007 - February 2008	Bank of England support grows to more than GBP 25bn; private rescue attempts fail
22 February 2008	Northern Rock is nationalized

Why the retail run happened. UK deposit insurance at the time covered 100% of the first GBP 2,000 and 90% of the next GBP 33,000. A depositor with GBP 30,000 stood to lose up to GBP 2,800 and would wait months for a payout. Withdrawing was the rational choice, even for those who believed the bank was solvent. The retail run was the final stage, not the cause: the wholesale run had started a month earlier.

What went wrong, in treasury terms.

Area	Weakness
Funding concentration	Reliance on securitization and wholesale markets, without enough stable funding
Stress testing	Market-wide closure of all funding channels not modelled
Liquidity buffer	Too small for a prolonged closure of markets
Contingency funding	No realistic plan for months without market access
Supervision and deposit insurance	Liquidity supervision was light; insurance design encouraged runs

What changed afterwards.

• The Basel III NSFR (Chapter 9.2) requires long-term assets to be funded by stable sources.
• Liquidity stress tests must include market-wide and combined scenarios.
• UK deposit insurance moved to 100% coverage up to a higher limit with fast payout (the FSCS today aims to pay within 7 days).
• The Bank of England widened its facilities and collateral framework for lending to banks in stress.

Analogy. Northern Rock was like a shop that paid its suppliers with money borrowed every week from the same lender. The shop was profitable, but when the lender stopped lending to everyone at once, it could not pay its suppliers on Friday.

Key takeaways

• A solvent bank can fail because its funding markets close; Northern Rock's losses were small.
• Funding concentration in securitization and wholesale markets was the core weakness.
• Stress tests did not consider all funding markets closing at the same time.
• Partial deposit insurance with slow payouts made a retail run rational.
• The case led to the NSFR, market-wide stress scenarios and deposit insurance reform.

🧪 Practice

1. Beginner: Explain why a depositor who believed Northern Rock was solvent might still have withdrawn their money in September 2007.
2. Intermediate: Using the approximate funding structure above, estimate the share of Northern Rock's funding at risk if securitization stopped and 50% of wholesale funding did not roll over during a three-month period. What does this mean for the size of buffer the bank would have needed?
3. Interview: "Our bank's stress test assumes that if covered bond markets close, we can increase senior unsecured issuance. What would you ask?" Hint: the Northern Rock assumption, correlation of funding markets in a market-wide stress, investor overlap, the effect of the bank's own rating, and how long the buffer lasts if all markets close at once.

Lehman Brothers Liquidity Collapse

Why study it. Lehman Brothers filed for bankruptcy on 15 September 2008 with about USD 639bn of assets, the largest bankruptcy in US history. Its failure turned a credit crisis into a global panic. For treasury, Lehman shows how short-term secured funding can vanish, how a reported liquidity pool can turn out to be largely unusable, and how the legal entity structure decides where liquidity actually is when it is needed.

Business and funding model. Lehman was an investment bank with leverage of around 30 times equity in 2007, large positions in commercial real estate and mortgage-backed securities, and a big prime brokerage and derivatives business. It funded much of its balance sheet overnight in the repo market, a large part through tri-party repo in which a clearing bank (JPMorgan Chase in the US) provided intraday credit between the unwinding of yesterday's repos and the settlement of today's.

  Tri-party repo dependency (simplified)

  Morning:   clearing bank unwinds overnight repos: cash back to lenders,
             securities back to Lehman -> Lehman owes the clearing bank intraday
  Day:       Lehman's positions are financed by the clearing bank's intraday credit
  Evening:   new repos settle: lenders' cash repays the clearing bank

  If lenders do not roll, or the clearing bank demands more collateral,
  the dealer has to find cash the same day.

Repo 105. Lehman used repo transactions accounted for as sales ("Repo 105") to remove around USD 50bn of assets from its balance sheet temporarily at quarter ends in 2008, making reported leverage look lower. The bankruptcy examiner's report (2010) described this as materially misleading. For treasury and reporting systems, the lesson is that quarter-end window dressing hides the true funding need; this is why many liquidity and leverage metrics now use averages, not only period-end figures.

Timeline.

Date	Event
March 2008	Bear Stearns collapses and is sold to JPMorgan; the Fed opens the Primary Dealer Credit Facility
June 2008	Lehman reports a quarterly loss of about USD 2.8bn and raises capital
9 September 2008	Talks with Korea Development Bank fail; the share price falls about 45%
10 September 2008	Lehman pre-announces a loss of about USD 3.9bn and a restructuring plan
9-12 September 2008	Clearing banks and counterparties demand billions of additional collateral; repo lenders and prime brokerage clients withdraw
12-14 September 2008	Rescue talks with Bank of America and Barclays fail without public support
15 September 2008	Lehman Brothers Holdings files for Chapter 11; the UK subsidiary enters administration

The liquidity pool that was not there. Lehman reported a liquidity pool of over USD 40bn in its final days. The examiner found that a large part was pledged to clearing banks as collateral for intraday credit, or invested in assets that could not be sold quickly. The usable pool was a fraction of the reported figure.

Reported pool component	Problem in stress
Cash deposited with clearing banks "as comfort"	Effectively encumbered: the clearing bank would not release it
Securities pledged for intraday credit	Already used as collateral
Less liquid assets (structured securities)	No buyers, or only at heavy discounts
Cash in subsidiaries	Not transferable to the entity that needed it

Legal entities. Lehman's cash was managed centrally by the US parent, with balances swept to the parent daily. When the parent filed on Monday 15 September, the London broker-dealer (LBIE) had no cash of its own and entered administration the same day. Hedge funds with assets in LBIE's prime brokerage lost access to them for months or years. Over 900,000 derivative contracts had to be closed out or resolved.

What went wrong, in treasury terms.

Area	Weakness
Funding	Heavy reliance on overnight repo, including against less liquid collateral
Liquidity pool	Encumbered and illiquid assets counted as liquidity
Intraday	Dependence on intraday credit from clearing banks that could demand collateral at will
Legal entity	Central cash sweeping left subsidiaries without liquidity at the critical moment
Transparency	Repo 105 hid leverage and funding needs at reporting dates

What changed afterwards.

• The LCR's HQLA must be unencumbered, under treasury control and monetizable in stress (Chapter 5.4).
• Tri-party repo reform in the US drastically reduced intraday credit from clearing banks.
• Resolution planning ("living wills") and requirements to hold liquidity at material subsidiaries (Chapter 7.3).
• Client asset rules for prime brokerage and segregation requirements were strengthened.
• Leverage and liquidity reporting increasingly uses averages to reduce window dressing.

Analogy. Lehman's liquidity pool was like a household emergency fund that turns out, on the day of the emergency, to be partly the deposit on the rented flat, partly a car that nobody wants to buy, and partly in a relative's account abroad.

Key takeaways

• Secured funding can disappear when lenders doubt the borrower or the collateral.
• A liquidity pool is only liquidity if it is unencumbered, controlled by treasury and monetizable in the stressed market.
• Liquidity must be measured and held per legal entity; central sweeping can leave subsidiaries without cash at the moment of failure.
• Quarter-end window dressing hides the true funding need; averages and daily monitoring reduce it.

🧪 Practice

1. Beginner: Explain why cash deposited with a clearing bank that also provides intraday credit may not count as available liquidity in a crisis.
2. Intermediate: A dealer reports a liquidity pool of USD 45bn: USD 12bn of cash at the central bank, USD 15bn of government bonds of which USD 6bn are pledged, USD 10bn of cash at a clearing bank held as comfort deposit, and USD 8bn of structured securities. Estimate the usable pool under stress and explain each adjustment.
3. Interview: "How would you design an encumbrance-aware liquidity pool report so that a Lehman-style overstatement is impossible?" Hint: asset-level data with pledge status from collateral and custody systems, legal entity and location, eligibility and haircuts per central bank, operational control by treasury, daily reconciliation, and explicit exclusion rules with audit trail.

Silicon Valley Bank (2023)

Why study it. SVB was the 16th largest bank in the United States, with about USD 209bn of assets, when it failed on 10 March 2023 after the fastest bank run in history. It invested in very safe assets from a credit point of view and had few bad loans. It failed because of interest rate risk in the banking book, a concentrated and uninsured deposit base, and weak risk management. For treasury, SVB connects almost every topic in this guide: IRRBB (Chapter 6), deposit behaviour (Chapter 5.1), accounting classification (Chapter 14), liquidity buffers and central bank access (Chapter 5.4).

The balance sheet. SVB served technology start-ups and venture capital firms. In 2020-2021, as start-ups raised record funding, its deposits roughly tripled to about USD 190bn. Loan demand did not grow as fast, so SVB invested the deposits in securities, mostly long-dated US Treasuries and agency mortgage-backed securities, classified as held to maturity (HTM).

  SVB, end of 2022 (approximate, USD bn)

  Assets                                 Liabilities and equity
  Loans                         74       Deposits                      173
  HTM securities (amortized     91         of which uninsured          ~ 90%
    cost; fair value ~76,
    unrealized loss ~15)                 Other borrowing (FHLB, etc.)   20
  AFS securities                26       Equity                         16
  Cash and other                18

  Unrealized loss on HTM (~15) was close to total equity (~16)

How the problem built up.

Period	Development
2020-2021	Deposits surge; invested in long fixed-rate securities at low yields; duration of the portfolio extended
2022	The Fed raises rates rapidly; bond prices fall; start-ups burn cash and deposits begin to decline; SVB removes most interest rate hedges on its AFS portfolio; internal interest rate and liquidity limits are breached, and some models and assumptions are changed rather than the positions
Early 2023	Deposit outflows continue; HTM unrealized losses become a topic among analysts

The run.

Date	Event
8 March 2023 (evening)	SVB announces the sale of USD 21bn of AFS securities with a USD 1.8bn loss and a plan to raise USD 2.25bn of capital
9 March 2023	Venture capital firms advise portfolio companies to withdraw; messages spread on social media; the share price falls about 60%; USD 42bn of deposits leave in one day
10 March 2023 (morning)	Requests for about USD 100bn more are queued; the bank cannot meet them; regulators close it and appoint the FDIC
12 March 2023	US authorities invoke the systemic risk exception to protect all depositors of SVB and Signature Bank; the Fed creates the Bank Term Funding Program

About a quarter of SVB's deposits were withdrawn in one day, and half were requested within two. This was a run at the speed of mobile banking, coordinated through a tight network of investors and founders.

Why the HTM portfolio did not help. Securities held at amortized cost show no loss in capital until they are sold. They could, in principle, be pledged at the Fed's discount window or the Federal Home Loan Banks to raise cash without selling. SVB had not prepared operationally: collateral was not pre-positioned at the discount window in sufficient size, and moving securities from one lender to another took time that the bank did not have. Selling instead would have realized the unrealized losses, and selling a significant part of an HTM portfolio would have forced the whole portfolio to be reclassified and valued at fair value.

What went wrong, in treasury terms.

Area	Weakness
IRRBB	Long duration, hedges removed, EVE sensitivity very large relative to capital
Deposit modelling	Deposits assumed to be stable, although concentrated, uninsured and rate sensitive
Liquidity stress testing	Internal stress tests showed shortfalls; limits were breached; little effective action
Contingency funding	Collateral not ready at the central bank; facilities not tested
Governance	Chief risk officer position vacant for most of 2022; risk management did not keep up with growth
Regulation	Under the 2019 US tailoring rules, SVB was not subject to the full LCR and had less stringent requirements

What changed afterwards.

• Supervisors emphasize discount window readiness: pre-positioned collateral, tested operations.
• Uninsured and concentrated deposits receive more attention in liquidity stress tests and supervision; run-off assumptions are being reconsidered for digital runs.
• US agencies proposed applying more of the large-bank rules (including unrealized losses on AFS securities in capital) to banks above USD 100bn.
• Banks across the world reviewed HTM portfolios, hedges and deposit betas (Chapter 6.2).

Analogy. SVB was like a person who locked their savings into a 10-year fixed-rate bond because it was safe, while all their regular expenses were paid from that money. When rates rose, the bond was worth less if sold early, and when an unexpected bill arrived, they had to sell it at a loss or not pay.

Key takeaways

• SVB failed through the combination of interest rate risk and a concentrated, uninsured, digitally connected deposit base.
• Amortized cost accounting hid economic losses that became real when liquidity forced sales.
• About 25% of deposits left in one day; run-off assumptions calibrated on older crises are too slow for digital runs.
• Collateral must be pre-positioned and central bank access tested before it is needed.
• Breached limits and changed assumptions were warning signs that governance failed to act on.

🧪 Practice

1. Beginner: Explain why a portfolio of US Treasury securities with no credit risk can create losses for a bank.
2. Intermediate: A bank has a USD 50bn HTM portfolio with a duration of 6 years. Rates rise by 3 percentage points. Estimate the unrealized loss and compare it with an equity of USD 10bn. What happens if the bank must sell 40% of the portfolio?
3. Interview: "If you had been on SVB's treasury technology team in 2022, which reports or alerts would you have built?" Hint: EVE and NII sensitivity against limits with breach escalation, deposit concentration and uninsured share by segment, daily outflows against stress assumptions, unrealized losses relative to capital, collateral pre-positioned versus potential need, and changes to model assumptions with approval history.

Credit Suisse (2023)

Why study it. Credit Suisse was a global systemically important bank, 167 years old, that met its regulatory capital and liquidity requirements until the end, including an LCR well above 100%. It still lost the confidence of clients and counterparties and had to be taken over by UBS in an emergency deal arranged by the Swiss authorities. Credit Suisse shows that confidence lost over years can collapse in days, and that a bank can meet the LCR and still run out of liquidity.

A long loss of confidence.

Year	Events
2016-2020	Mozambique "tuna bonds" case, a spying scandal involving senior management, repeated restructurings
March 2021	Greensill Capital collapses; supply chain finance funds managed by Credit Suisse (about USD 10bn) are frozen
March-April 2021	Archegos Capital defaults; Credit Suisse loses about CHF 4.8bn
2022	Large losses (about CHF 7bn for the year), strategy reset, management changes
October 2022	Rumors on social media about the bank's health; clients withdraw
Q4 2022	Net asset outflows of about CHF 110bn; deposits fall sharply; the bank uses part of its liquidity buffer

The final week.

Date	Event
9 March 2023	Publication of the annual report is postponed after questions from the US SEC
10-13 March 2023	SVB fails; markets question bank balance sheets globally
14 March 2023	The annual report identifies material weaknesses in internal control over financial reporting
15 March 2023	The largest shareholder says it will not provide more capital; the share price falls about 24%; FINMA and the SNB issue a statement of support
16 March 2023	Credit Suisse announces it will borrow up to CHF 50bn from the SNB
19 March 2023	UBS agrees to acquire Credit Suisse for about CHF 3bn; CHF 16bn of AT1 bonds are written down to zero; the federal government provides a loss guarantee and the SNB extensive liquidity assistance

Liquidity assistance from the SNB eventually reached more than CHF 150bn at its peak, partly backed by a federal default guarantee, because the bank's own collateral could not cover the outflows.

Why the LCR was not enough.

LCR assumption	What happened
Outflows over 30 days at prescribed rates	Outflows in some client categories (notably wealth management deposits) were faster and larger than LCR rates assumed
HQLA available at group level	Liquidity was spread across legal entities and countries and was not freely transferable
A one-off stress of 30 days	Outflows came in waves over six months (October 2022 to March 2023), eroding the buffer and the franchise
Central bank as a backstop outside the LCR	Collateral eligible for emergency liquidity assistance (for example Swiss mortgages) required legal and operational preparation that took time

What went wrong, in treasury terms.

• The franchise itself was the main source of funding stability, and it was damaged by repeated scandals and losses.
• Deposit outflow assumptions were calibrated on normal client behaviour and older stress episodes.
• Collateral for central bank lending was not ready in sufficient amounts.
• Liquidity was held in entities and currencies that did not match where outflows occurred.
• Recovery and resolution options existed on paper (Chapter 7.3), but the authorities chose a merger, partly because of concerns about market contagion.

What changed afterwards.

• Swiss authorities proposed stronger liquidity requirements, a public liquidity backstop, and broader collateral pre-positioning at the SNB.
• Supervisors in many jurisdictions are reviewing LCR outflow rates for digital and wealth management deposits and the usability of buffers.
• The AT1 write-down, ahead of equity, led to legal disputes and to statements by the EU and UK authorities on the creditor hierarchy.

Analogy. Credit Suisse was like a restaurant that keeps passing its hygiene inspections while one food scandal after another appears in the news. The kitchen meets the rules, but customers stop coming, and no rule says how many empty tables a restaurant can survive.

Key takeaways

• Meeting regulatory capital and liquidity minimums does not guarantee survival when confidence is lost.
• Outflows came in waves over months, faster in some segments than LCR assumptions.
• Liquidity must be available in the right legal entity and currency, and central bank collateral must be ready.
• Reputation and franchise value are funding risk factors that treasury cannot model away.

🧪 Practice

1. Beginner: Explain how a bank with an LCR above 100% can still face a liquidity crisis.
2. Intermediate: A bank's LCR assumes 10% run-off for a wealth management deposit category of CHF 120bn. Actual outflows in a stressed month reach 25%. Compute the additional outflow and the drop in the LCR if HQLA is CHF 90bn and total net outflows were CHF 60bn before the stress (assume the extra outflow is paid from HQLA).
3. Interview: "Credit Suisse's crisis lasted six months, not 30 days. How should a liquidity stress testing framework capture slow-burn crises?" Hint: multi-wave scenarios, longer horizons, reputational triggers and repeated shocks, behavioural parameters that worsen with each event, franchise erosion, and early warning indicators linked to the contingency funding plan.

Lessons for Treasury System Design

Why it matters. The four cases differ in era, business model and trigger, but treasury in each case lacked one or more of: a timely and complete view of liquidity, realistic assumptions, collateral that was ready to use, and a link between risk measures and action. Most of these are partly technology problems. This topic turns the lessons into requirements for treasury systems, so that engineers can test their own systems against them.

From failures to capabilities.

Lesson	Cases	System capability
Funding concentration kills solvent banks	Northern Rock, SVB	Concentration analytics by counterparty, sector, product, channel and insured status, with limits
Runs happen at digital speed	SVB, Credit Suisse	Real-time deposit flows by segment, with alerts against stress assumptions (Chapter 16.2)
Reported liquidity may not be usable	Lehman, Credit Suisse	Asset-level, encumbrance-aware liquidity pool with eligibility, location and legal entity
Liquidity is trapped in legal entities	Lehman, Credit Suisse	Positions and buffers per entity and currency, with transferability rules
Collateral must be ready before the crisis	SVB, Credit Suisse	Pre-positioning tracking per central bank facility, with tested operational procedures
Solvency and liquidity interact	SVB, Credit Suisse	Combined stress engine (Chapter 16.1)
Assumptions drift and limits are ignored	SVB	Model and assumption versioning with approvals; breach escalation that cannot be silently closed
New scenarios are needed fast	All	Scenario library with ad-hoc runs in hours
Window dressing hides risk	Lehman	Daily and average-based metrics, not only period-end

Crisis-ready data flow.

  Sources                       Treasury data platform                      Uses

  Core banking (deposits)  --+  +-----------------------------------+
  Payment hub, RTGS        --+->| real-time positions per entity,   |--> Liquidity dashboard
  Trade and repo systems   --+  | currency, account                 |
  Collateral, custody      --+  | deposits by segment, insured flag |--> Early warning
  Central bank pledges     --+  | asset-level pool: encumbrance,    |    indicators
  Market data, ratings     --+  |   eligibility, haircut, location  |
  Model and limit config   --+  | versioned assumptions and limits  |--> Stress and reverse
                                +-----------------+-----------------+    stress engine
                                                  |
                                   bitemporal history and lineage    --> CFP actions,
                                   (what we knew, when)                  regulator reporting

Early warning indicators. Indicators turn data into action. Each has thresholds, an owner and a linked action in the contingency funding plan (Chapter 5.4).

from dataclasses import dataclass

@dataclass
class Indicator:
    name: str
    amber: float
    red: float
    higher_is_worse: bool = True

    def status(self, value):
        breach = (lambda t: value >= t) if self.higher_is_worse else (lambda t: value <= t)
        return "RED" if breach(self.red) else "AMBER" if breach(self.amber) else "GREEN"

INDICATORS = [
    Indicator("uninsured_deposit_outflow_1d_pct", amber=2.0, red=5.0),
    Indicator("top20_depositor_share_pct", amber=20.0, red=30.0),
    Indicator("cds_spread_change_5d_bp", amber=50.0, red=150.0),
    Indicator("unencumbered_hqla_vs_stress_outflow_pct", amber=120.0, red=100.0, higher_is_worse=False),
    Indicator("prepositioned_collateral_vs_need_pct", amber=80.0, red=50.0, higher_is_worse=False),
]

today = {"uninsured_deposit_outflow_1d_pct": 6.1, "top20_depositor_share_pct": 24.0,
         "cds_spread_change_5d_bp": 35.0, "unencumbered_hqla_vs_stress_outflow_pct": 135.0,
         "prepositioned_collateral_vs_need_pct": 45.0}

for ind in INDICATORS:
    print(f"{ind.name:42} {today[ind.name]:>7} {ind.status(today[ind.name])}")
# uninsured_deposit_outflow_1d_pct               6.1 RED
# top20_depositor_share_pct                     24.0 AMBER
# cds_spread_change_5d_bp                       35.0 GREEN
# unencumbered_hqla_vs_stress_outflow_pct      135.0 GREEN
# prepositioned_collateral_vs_need_pct          45.0 RED

Two red indicators would escalate to the asset-liability committee (or a crisis team) under the contingency funding plan. In SVB's case, indicators for deposit concentration and collateral readiness would have been amber or red long before March 2023, and the outflow indicator turned red on 9 March, the day it was too late to act without pre-positioned collateral.

The first hour of a run. A useful design test is to ask what treasury needs within one hour of a run starting, and whether the systems can provide it without waiting for a batch.

Question	Data needed	Typical gap
How fast is money leaving, and from whom?	Intraday outflows by segment, channel and large depositor	Deposit data only available after end-of-day batch
How much cash can we raise today?	Unencumbered assets, eligibility, pre-positioned collateral, cut-off times	Pledge status in separate systems; manual spreadsheets
In which entity and currency?	Positions per entity and currency, transfer restrictions	Group-level figures only
How long can we survive?	Survival horizon under current outflow rates (Chapter 5.2)	Static stress scenario, cannot be rerun with today's observed rates
What actions are available and what do they cost?	CFP actions with capacity, timing and signalling effect	CFP as a document, not data

Testing.

• Crisis simulations: run the contingency funding plan as an exercise with real systems at least yearly, including weekend and out-of-hours scenarios.
• Central bank test operations: borrow small amounts at the discount window or marginal lending facility regularly to prove that operations, collateral transfer and legal documents work.
• Historical replays: feed the outflow patterns of SVB or Credit Suisse into the bank's own position and stress systems to see when indicators fire and how long the buffer lasts.
• Data drills: measure how long it takes to produce the first-hour data set from scratch.

Analogy. Designing treasury systems after these failures is like designing a building's fire safety after studying past fires: smoke detectors in every room (real-time indicators), exits that are actually unlocked (usable collateral), floor plans per wing (legal entity views) and regular fire drills (crisis simulations).

Key takeaways

• The four failures map to concrete system capabilities: concentration analytics, real-time deposit monitoring, encumbrance-aware buffers, legal entity views, collateral readiness and combined stress testing.
• Early warning indicators need thresholds, owners and linked actions, not only dashboards.
• Test systems against the first hour of a run: what is needed, how fast it can be produced, and from which sources.
• Crisis simulations, central bank test operations and historical replays prove readiness before it is needed.
• Version and approve assumptions and limits so that weakening them is visible.

🧪 Practice

1. Beginner: For each of the four case studies, name one system capability from the table above that addresses its main weakness.
2. Intermediate: Define five early warning indicators for a bank with a large wealth management business, with amber and red thresholds and the contingency funding action linked to each.
3. Interview: "The CFO asks: could an SVB-style run happen to us, and would we see it coming? How would you answer with data within one week?" Hint: replay SVB's outflow pattern on your deposit base by segment and insured status, compute the survival horizon with current buffers and pre-positioned collateral, check intraday data availability, review IRRBB and unrealized losses relative to capital, and list the gaps with remediation owners.