Bank Stress Testing, Explained to a Developer

When I wrote about VaR, I left out its best-known limitation: it describes a normal day, not a crisis day. Bank stress testing answers exactly the question VaR sidesteps: what happens if everything goes wrong at the same time?

The problem, in engineering terms#

A classic load test ramps up traffic until the system breaks, under otherwise normal conditions. A bank stress test does the opposite of a load test in one sense: it doesn't vary a single parameter, it simulates a full scenario where several things fail at once (equities down 40%, rates up 300 basis points, credit spreads widening), all simultaneously rather than one parameter at a time. VaR answers "what's my likely loss on an ordinary day." A stress test answers "what's my loss if the worst plausible scenario actually happens."

Two families of scenarios#

• Historical scenarios: replay a crisis that already happened (2008, March 2020) against the current portfolio. The advantage: the scenario is credible by construction, it already occurred. The limit: it only covers combinations of shocks already seen, never a new combination.
• Hypothetical scenarios: build a shock that never happened but remains plausible (a rate shock combined with a specific sector collapse). The advantage: it covers combinations history hasn't produced yet. The limit: the scenario's plausibility depends entirely on the judgment of whoever built it.

A simplified worked example#

Take a 50M EUR equity portfolio with a sensitivity of 1.2 (a market shock of x% translates to a 1.2 × x% loss on the portfolio, heavily simplifying a reality made of different betas per position):

Historical scenario (March 2020 style): equities -30%
Estimated loss = 50,000,000 x 1.2 x 0.30
              = 18,000,000 EUR

Hypothetical scenario (rate shock +300 bps combined with equities -15%)
Estimated loss (equity component) = 50,000,000 x 1.2 x 0.15
                                  = 9,000,000 EUR
+ loss on the rate component, computed separately on bond positions

The historical scenario produces the more severe loss here, but that's not systematic: a well-built hypothetical scenario can exceed every known historical scenario, that's often the point of building one.

Why Basel III makes this mandatory, not optional#

Basel III doesn't just recommend stress testing, it ties part of the required regulatory capital to the outcome of these scenarios (Pillar 2 of the prudential framework). A bank whose stress tests reveal a concentrated vulnerability to a given scenario has to hold more capital in reserve, even if its daily VaR stays within limits. That's what separates stress testing from a purely academic exercise: the result has a cost in capital held aside, and therefore a direct impact on the bank's profitability.

Why it's good territory for a curious developer#

Technically, a stress testing engine looks like a scenario simulation engine: apply the same scenario to thousands of heterogeneous positions (equities, rates, credit, derivatives), aggregate the losses consistently, and do it fast enough to test dozens of scenarios across the whole portfolio. It's as much a performance problem as a finance one, and it's exactly the kind of computation kotlin-counterparty-risk already illustrates on counterparty risk: once you know how to simulate a future exposure (PFE), replaying that same simulation under a stress scenario instead of a normal market distribution is a natural extension, not a rewrite.