Three VaR Breaches in Twenty Days
A $60m multi-asset book reports a 99% one-day VaR of $2.1m using historical simulation on 250 days of data, with an EWMA volatility overlay at lambda = 0.94. Over the last 20 trading days there have been three breaches: −$2.3m, −$2.6m and −$3.4m. The equity volatility index is up 40% over the same window; credit spreads have widened modestly. Roughly 15% of the book is in high-yield bonds that trade by appointment, marked from a dealer run published weekly. The desk head argues the model is fine and the losses were 'a one-off cluster' and wants to keep limits unchanged, citing that the annual backtest still shows an acceptable breach count.
1. Test the desk head's claim. Is a cluster of three breaches in 20 days consistent with a correct 99% model?
Read the worked answer
No. Under the model's own assumptions this is not a plausible cluster.
For a correctly specified 99% one-day VaR, breach days are independent with probability p = 0.01. Over n = 20 days:
- P(0 breaches) = 0.99^20 ≈ 0.818
- P(1) ≈ 0.165
- P(2) ≈ 0.0157
- P(3 or more) ≈ 0.0011 (about 1 in 900)
So the observed cluster has roughly a 0.1% chance under the null. That is well past a reasonable rejection threshold.
The desk head's defense - 'the annual backtest still looks acceptable' - is the wrong test. A 250-day window averages the current regime with nine calmer months; it is precisely designed to be slow. It cannot acquit the model of failing right now. Note also that the breaches are not marginal: the worst is 62% beyond the VaR estimate.
What the annual count does tell you is that the model's unconditional calibration may be fine and the failure is conditional - i.e. the model is not adapting to a regime shift, which is exactly what lambda = 0.94 with a 250-day historical window would produce. That is a model-design problem, not bad luck.
2. Separate the plausible causes of the failure and specify what you would change. Be explicit about which changes fix estimation error and which address model risk that VaR cannot capture.
Read the worked answer
Causes, in order of likely contribution:
- Volatility clustering / slow adaptation. lambda = 0.94 has a half-life of about 11 days, so it should be responsive - but if the EWMA overlay is applied to a covariance matrix estimated from 250 days of equally weighted history, the overlay is doing little. When the vol index is up 40%, a 250-day window is still roughly 60–70% populated by the low-vol regime.
- Correlation shift. Losses of 2.3–3.4m against a 2.1m VaR are consistent with normally-diversified positions becoming correlated in a selloff. Historical simulation cannot generate a joint scenario that has not happened in the window.
- Stale marks on the illiquid sleeve. 15% of the book marked weekly from a dealer run means reported VaR understates true risk: the marks are smoothed, so measured vol is too low and the loss, when it arrives, is a jump. This is the most dangerous item because it is invisible in the P&L until it isn't.
Changes that address estimation error: shorten the effective window or raise responsiveness (lambda ≈ 0.97 alone, or filter historical simulation by current vol); recalibrate at least quarterly; add a volatility-of-volatility overlay that scales VaR when the vol index moves more than a set threshold.
Changes that address model risk VaR cannot capture: report Expected Shortfall alongside VaR (the tail beyond the breach matters more than the count); stress test to explicit historical and hypothetical scenarios (2008 Q4, March 2020, a 3-sigma correlation-1 equity/credit day); apply a liquidity horizon to the illiquid sleeve - either hold it at a higher confidence or add a liquidation-cost add-on.
On limits: the correct response to a 0.1%-probability cluster is not 'keep limits unchanged and see.' It is to cut risk in the least liquid, least measurable sleeve first, because that is where the model is most wrong, and to keep limits on the liquid sleeve pending recalibration.