A trading desk's 99% one-day VaR breached eight times last year on 250 trading days. The model claimed 2.5 expected breaches. The supervisor wants to know whether the model is broken or you got unlucky. Kupiec gives one answer, Christoffersen gives another, and Basel's traffic light tells you what your capital surcharge will be. Three frameworks; the exam tests all three.
A VaR model that nobody checks is a number with no meaning. Regulators require backtesting because risk models can drift away from reality silently: vol regimes shift, correlations move, fat tails appear. The exception-counting framework is the simplest possible check: a 99% one-day VaR should be exceeded 1% of the time. Count the exceptions; compare to expectation.
KEY: Backtesting gives you statistical evidence about whether a VaR model deserves to be trusted with capital decisions. Without it, the VaR number is hope, not measurement.
Kupiec's proportion-of-failures (POF) test is the standard exception-count check. The null hypothesis: the breach rate equals the model's stated p (e.g., 1% for a 99% VaR).
Common mistakes
- Confusing the 99% breach rule of thumb with the 95% rule. At 95% VaR over 250 days, the expected breaches are 12.5, and 20+ would be the rejection zone. At 99% VaR, expected is 2.5 and 10+ rejects.
- Treating Kupiec as sufficient. Kupiec catches wrong total counts but misses clustering. A model that has 2.5 breaches all bunched in a single week passes Kupiec but fails Christoffersen. Trap: a question describes "5 breaches in 5 consecutive days": Kupiec passes (5 in 250) but Christoffersen rejects (clustering).
- Adding Basel's three multiplier components incorrectly. The capital multiplier under Basel = 3.0 + traffic-light add-on + plus-factor for backtesting failures. Some students drop the base 3.0 and report just the add-on. Trap: 7 breaches gives a multiplier of about 3.65, not 0.65.
Bottom line
- Backtesting compares realized exceptions (breaches) to a VaR model's stated breach rate. Kupiec POF tests count; Christoffersen tests independence and conditional coverage.
- Type I error rejects a good model; Type II error accepts a bad model. Both depend on sample size, and small samples have low power.
- Basel traffic light: green ≤4 / yellow 5-9 / red ≥10 breaches per 250 days at 99%. Multiplier rises through yellow and to 4.0 in red, with supervisor intervention.
- VaR mapping decomposes positions into primitive risk factors so a portfolio VaR is computed from a manageable factor covariance matrix.
Exam shortcut
When a question gives a breach count and asks for action, the Basel traffic light decides: ≤4 green, 5-9 yellow, 10+ red. If the question asks whether a model is rejected, run Kupiec and compare LR to 3.84 (1 df). When mapping a bond, the cash-flow approach is the most defensible answer; principal mapping is an exam trap that ignores key-rate risk.
The full lesson (about 3,100 words, 21 min read) adds 2 worked examples, all 6 common mistakes, a self-check, free in the app.
Learning objectives
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
Browse all free FRM Part II lessons or jump into free FRM Part II practice questions.