FRM Exam Part II · Backtesting VaR

Causes of VaR Exceptions and Model Improvement

Updated 11 October 2026 · Fact-checked

A VaR exception is a day when the loss is larger than the VaR estimate. Causes are basic model weakness, wrong inputs or volatility, intraday trading that the model misses, and plain bad luck. Banks first diagnose the cause, then fix the model or the data, and do not treat every exception as a model failure.

Understand Causes of Exceptions and Model Improvement

A VaR exception (also called an exceedance or a breach) happens when the actual trading loss for a day is larger than the VaR forecast for that day. At 99% confidence you expect about 1% of days to be exceptions. Over 250 trading days that is about 2.5 exceptions. So a few exceptions are normal and do not prove the model is wrong.

The key skill is separating bad luck from a real problem. If a model is correct, exceptions still occur by chance. If you see far more exceptions than expected, or they cluster together, something is likely wrong. The statistical tests (binomial, Kupiec, Christoffersen) tell you whether the count is too high. This topic tells you what to look for once the count is too high.

GARP groups the causes into a few families:

Basic integrity of the model: the model does not capture the risk of some positions, there are coding errors, or the risk systems do not feed in all trades.
Model accuracy needs improvement: the model is right in structure but is too weak. Examples are risk factors that are mapped poorly, volatility estimates that react too slowly, or correlations and tails that are mis-specified.
Intraday trading: the VaR is computed on the end-of-day portfolio, but traders change positions during the day. The actual P&L then reflects a different portfolio.
Bad luck: the model is fine, but markets moved sharply in a rare way. This is accepted only after the other causes are ruled out.

Backtesting can use actual P&L or hypothetical P&L. Actual P&L includes fees, commissions, intraday trading results and reserve changes. Hypothetical P&L (also called clean P&L) freezes the portfolio at the start of the day and revalues it with the day's market moves. Hypothetical P&L is cleaner for testing the model itself. Actual P&L is closer to what the bank really earns or loses. Comparing both helps you spot intraday trading as a cause: if exceptions appear in actual P&L but not hypothetical P&L, trading or fees are driving them.

The response depends on the cause. Fix coding and data errors at once. Improve the model if it is too slow or mis-specified. Review limits and intraday risk controls if trading is the cause. Under the Basel traffic light approach, more exceptions bring a higher capital multiplier, and the bank may have to explain each exception to its supervisor.

Key formulas to remember

Expected exceptions: Expected number of exceptions = N × (1 − c); N is the number of days, c is the VaR confidence level. At 99% over 250 days, 250 × 0.01 = 2.5.
Exception rate: Observed exception rate = x ÷ N; x is the number of exceptions. Compare with 1 − c. A rate well above 1 − c suggests the model understates risk.
Exception condition: Exception if loss > VaR; Loss is shown as a positive number. Use the same sign convention for loss and VaR.
Hypothetical vs actual P&L: Actual P&L = hypothetical P&L + intraday trading P&L + fees and commissions + reserve changes; Use the gap to see whether exceptions come from the model or from trading and other items.
Basel traffic light zones (250 days, 99% VaR): Green: 0–4 exceptions; Yellow: 5–9; Red: 10 or more; Yellow brings a higher multiplier on the market risk capital charge. Red usually leads to the model being presumed flawed and a heavier penalty.

How to solve Causes of Exceptions and Model Improvement questions

Use this order for any question that asks why exceptions happened or what a bank should do.

1Compute expected exceptions: N × (1 − c). Compare with the observed count.
2Decide if the count is statistically too high. Do not call a small excess a failure. Note any clustering of exceptions in time.
3Read the clues in the question. Look for words like coding error, missing positions, slow volatility update, mapped proxy, intraday trades, fees, or one extreme market day.
4Match the clue to a cause family: model integrity, model accuracy, intraday trading, or bad luck.
5Check which P&L is used. If actual P&L shows exceptions and hypothetical P&L does not, point to intraday trading, fees or reserves.
6Choose the response that fits the cause: fix the code or data, improve volatility or tail modelling, add intraday controls, or accept bad luck only if everything else is ruled out.
7Add the regulatory consequence if asked: traffic light zone and capital multiplier.
8Check that your answer does not blame the model for every exception.

Quickest way: Clue to cause to fix

When to use it: Use for multiple-choice questions that describe a bank, give a clue and ask for the most likely cause or best response.

Underline the clue word in the stem.
Missing trades, bugs, wrong data: model integrity. Fix the system first.
Volatility lagging, poor mapping, thin tails, clustered exceptions: model accuracy. Improve the model.
Exceptions in actual P&L but not hypothetical P&L: intraday trading or fees.
One shock day, otherwise acceptable count: bad luck.
Eliminate options that blame luck before other causes are checked, or that recalibrate blindly.

Common mistakes in Causes of Exceptions and Model Improvement

Treating every exception as proof the model is wrong.
Students forget that a 99% VaR is expected to be breached on about 1% of days.
Fix: Always compute the expected number of exceptions first. Only a count clearly above it points to a problem.
Calling bad luck the first explanation.
It feels like the simplest answer when a market move was large.
Fix: Bad luck is the last explanation. Rule out model integrity, model accuracy and intraday trading before accepting it.
Confusing hypothetical and actual P&L.
Both are called P&L and the difference is easy to skim over.
Fix: Hypothetical P&L freezes the portfolio and tests the model. Actual P&L includes intraday trades, fees and reserves.
Ignoring clustering of exceptions.
Students focus on the count and not on timing.
Fix: Clusters suggest volatility is updated too slowly or exceptions are not independent. This points to model accuracy.
Assuming intraday trading always increases exceptions.
Students think more trading means more risk.
Fix: Intraday trading can raise or lower the actual loss compared with the end-of-day VaR portfolio. It makes the VaR and the P&L describe different portfolios.
Mixing up the traffic light zones.
The cut-offs are numbers that are easy to swap.
Fix: For 250 days at 99%: green 0–4, yellow 5–9, red 10 or more.

Worked examples

Example 1

A bank backtests a one-day 99% VaR over 250 trading days using hypothetical P&L and records 3 exceptions. Using actual P&L it records 8 exceptions. What is the most likely explanation, and in which Basel zone does each count fall?

Show the solution

Expected exceptions = 250 × 0.01 = 2.5.
Hypothetical P&L gives 3 exceptions, close to 2.5. The model itself looks acceptable.
Actual P&L gives 8 exceptions, much higher. The extra exceptions come from items outside the frozen portfolio.
Those items are intraday trading results, fees and commissions, or reserve changes.
Zones: 3 exceptions is green (0–4). 8 exceptions is yellow (5–9).

Answer: The model is broadly sound. The extra exceptions in actual P&L most likely come from intraday trading, fees or reserves. Hypothetical P&L falls in the green zone and actual P&L in the yellow zone. The bank should review intraday risk controls and the P&L components, not rebuild the model.

Example 2

A bank's 99% one-day VaR shows 9 exceptions in 250 days. Review shows that 6 of them fell within a three-week period of rising market volatility, and the model uses an equally weighted 4-year history. What is the most likely cause and the best response?

Show the solution

Expected exceptions = 250 × 0.01 = 2.5. Observed 9 is far above this.
The exceptions cluster in a period of rising volatility.
An equally weighted 4-year window reacts slowly to a rise in volatility. The VaR stays too low while true risk is rising.
This is a model accuracy problem, not bad luck and not a coding error.
Best response: use a faster volatility estimate, such as an exponentially weighted or age-weighted approach, or a shorter window, and test again.
Regulatory note: 9 exceptions is in the yellow zone (5–9), so a higher capital multiplier applies.

Answer: The most likely cause is model accuracy: a slow-reacting, equally weighted history that understates risk when volatility rises. The bank should move to a more responsive volatility measure and rerun the backtest. The count is in the yellow zone.

Exam tips

Compute expected exceptions first. It anchors almost every question in this topic.
Learn the four cause families and the clue words that signal each one.
When a question gives both actual and hypothetical P&L, compare them. The gap usually answers the question.
Do not pick bad luck unless the stem shows other causes are ruled out.
Memorise the traffic light cut-offs for 250 days at 99%: 0–4, 5–9, 10 or more.

Practice questions from Backtesting VaR

Causes of Exceptions and Model Improvement: frequently asked questions

What are the main causes of VaR exceptions?

The main causes are weak model integrity (bugs, missing positions, bad data), poor model accuracy (slow volatility, bad mapping, thin tails), intraday trading that the end-of-day VaR does not capture, and bad luck. Check the first three before accepting bad luck.

How does intraday trading cause backtesting exceptions?

VaR is usually computed on the end-of-day portfolio. Traders change positions during the day, so actual P&L reflects a different portfolio. This can create exceptions even when the model is sound. Comparing actual and hypothetical P&L reveals the effect.

How should a bank respond to VaR backtesting failures?

It should find the cause first. Fix coding and data errors, improve the model if it reacts slowly or misses tail risk, and tighten intraday controls if trading is the driver. It must also handle the capital consequences under the traffic light approach.

Is a VaR exception always a model failure?

No. A 99% VaR is expected to be breached on about 1% of days. A few exceptions are normal. Only a count well above expectation, or clustering of exceptions, points to a real problem.