Probability measures: P (real-world) and Q (risk-neutral)

Table of Contents

If you have read ORE analysis docs or paper summaries and kept hitting the phrases "real-world measure", "risk-neutral measure", "P-measure", or "Q-measure" without a clear definition, this document is for you. You do not need a quant background — if you understand the difference between a simulation that tests what will happen and a simulation that tests how to price something, you already have the right intuition. Return to Knowledge.

Summary

Measure Short name One-line meaning Used for
P Real-world Probabilities you estimate from historical data Scenario generation, risk, CPPI
Q Risk-neutral Fictional probabilities where every asset earns the risk-free rate Option pricing, trade valuation

The measures are not competing theories. They are two different lenses over the same financial world, each optimised for a different job. QuantLib's pricing engines always operate in Q. ORE's initial-margin and CPPI simulations operate in P. Synthetic market data generated by GMM (Gaussian mixture models from historical data) lives in P and cannot be fed directly into a QuantLib option pricer as-is.

The problem with "real" probabilities for pricing

Imagine you want to price a European call option on EUR/USD. The option pays out if EUR/USD is above the strike at expiry. Naively you might think: simulate EUR/USD paths using the real drift and real volatility you estimated from history, discount the average payoff — done.

The problem: the fair price of the option must be the same for every participant regardless of their view of EUR/USD's expected return. A currency hedge fund might think EUR/USD will rise 5% next year. A risk manager might think it will fall 2%. If they both buy the same option, the option must have one price, not two.

The elegant solution is to notice that in a complete market there is exactly one way to assign "adjusted" probabilities to the paths such that the price of every tradeable asset, discounted at the risk-free rate, is a martingale (i.e. its expected discounted value equals its current price). These adjusted probabilities are the Q-measure, also called the risk-neutral measure. Under Q you do not need to estimate expected returns at all — every asset's drift is replaced by the risk-free rate.

P-measure (real-world)

The P-measure is the probability distribution of market outcomes as they actually occur over time. If you record EUR/USD daily for 10 years and build a histogram of daily returns, you are estimating P.

Key P-measure properties for developers:

  • Drift reflects real macroeconomic forces. Equities trend upward over decades because companies generate earnings. Currencies reflect interest rate differentials and capital flows. These are P-measure drifts.
  • Risk premia are baked in. Equities have historically returned roughly 7% per year above the risk-free rate. That extra 7% is the equity risk premium and it only exists in P.
  • Calibrated from historical data. You estimate P parameters (drift, volatility, correlations) by fitting models to historical time series.
  • Used whenever you want to ask "what scenarios could actually happen?" Portfolio stress testing, initial margin simulation, CPPI (Constant Proportion Portfolio Insurance) strategy simulation, and VaR all operate in P.

A concrete mental model: P is "the probabilities you would assign by watching markets for 10 years and writing down what happened."

Q-measure (risk-neutral)

The Q-measure is a fictional probability distribution constructed specifically to make option pricing tractable. Under Q, every asset — stocks, bonds, FX rates — earns the risk-free rate as its expected return, regardless of what the asset's real expected return is.

Key Q-measure properties for developers:

  • Drift is always the risk-free rate r. The real expected return mu is discarded. This sounds wrong but is exactly what the no-arbitrage argument demands.
  • Calibrated from option prices, not historical data. The implied volatility you extract from a traded option price is a Q-measure parameter. When you back out implied vol from a market option price you are, in effect, reading off the Q-measure distribution the market has agreed upon.
  • Every derivative price is just an expected value under Q. The Black-Scholes formula, QuantLib's Monte Carlo engine, every swap pricer in ORE — they all compute:

    Price = E^Q [ discounted payoff ]
          = E^Q [ payoff * exp(-r * T) ]
    

    This equation only works under Q, not under P. Under P the equation gives the wrong answer unless you also adjust for the risk premium, which is hard to estimate reliably.

  • Used whenever you want to ask "what is the fair price of this contract?" Option pricing, trade valuation, XVA calculations, and AMC (American Monte Carlo) all operate in Q.

A concrete mental model: Q is "a fictional casino where every game has an expected return of zero after you account for the time value of money." It never existed in the real world but it is the only world where you can derive no-arbitrage prices without guessing expected returns.

The key practical difference for developers

Here is the one thing to memorise:

P-measure paths describe what markets might do. Q-measure paths describe what paths are consistent with current market prices.

In P, a stock's drift is its expected return (mu, maybe 7% per year for equities). In Q, a stock's drift is the risk-free rate (r, maybe 4%). They use the same volatility sigma — or more precisely, the vol in both cases is estimated/calibrated to be consistent, though the source differs (historical data for P, option prices for Q).

The mathematical bridge between the two is the Girsanov theorem. It says you can convert a P-measure Brownian motion into a Q-measure Brownian motion by subtracting a drift term proportional to the market price of risk lambda:

dW^Q = dW^P + lambda * dt
lambda = (mu - r) / sigma        (Sharpe ratio)

Developers rarely compute this directly. In practice the bridge works like this: you observe implied volatility from option prices — that implied vol already encodes the Q-measure distribution. You plug it into a risk-neutral pricer. You never need to know the exact value of lambda.

Where QuantLib uses Q

QuantLib is a pricing library. Its Monte Carlo engines always run in Q.

BlackScholesMertonProcess

BlackScholesMertonProcess is the workhorse stochastic process for equity and FX options. The constructor accepts a riskFreeRate handle:

// Q-measure (risk-neutral) — for option pricing
// drift = risk-free rate r
auto qProcess = ext::make_shared<BlackScholesMertonProcess>(
    spotQuote, dividendYield, riskFreeRate,   // <-- r here, not expected return
    blackVolTS);

// P-measure (real-world) — for scenario generation
// drift = historically estimated expected return (e.g. 7% pa for equities)
auto pProcess = ext::make_shared<BlackScholesMertonProcess>(
    spotQuote, dividendYield, expectedReturn, // <-- mu here, not risk-free rate
    historicalVolTS);

The object is structurally identical in both cases — it is the value you pass as the rate handle that determines the measure. QuantLib itself does not know or enforce which measure you are in; that is your responsibility as the caller.

GeneralizedBlackScholesProcess::evolve()

The evolve() method advances the spot from time t to time t+dt:

// Simplified Euler step inside evolve()
Real drift = (r - 0.5 * sigma * sigma) * dt;
Real diffusion = sigma * std::sqrt(dt) * dW;
return spot * std::exp(drift + diffusion);

The r here is whatever was passed as riskFreeRate at construction. If you pass the real expected return mu instead of r, your paths are P-measure paths and you must not use the resulting option prices as no-arbitrage prices.

MonteCarloModel and GaussianMultiPathGenerator

MonteCarloModel with GaussianMultiPathGenerator is QuantLib's standard MC pricing harness. It generates Gaussian random increments and feeds them through the process's evolve() call. Because the process was constructed with r as the drift, all paths are Q-measure paths by construction. The discounted average payoff across those paths is the no-arbitrage price.

There is no built-in "P-measure mode" in QuantLib's MC framework. To generate P-measure paths you pass a different rate handle at construction time, as shown above.

Where ORE uses each measure

Q-measure: trade pricing and CrossAssetModel AMC

ORE's CrossAssetModel drives its simulation-based XVA (CVA/DVA/FVA/MVA) calculations. The model is calibrated to market option prices — swaptions for interest rates, FX options for cross-currency moves — and then simulated forward. Because it is calibrated to option prices (Q-measure inputs) and the drift of each asset factor is the risk-free rate, all CrossAssetModel paths are Q-measure paths.

The AMCCalculator (American Monte Carlo) uses these Q-measure paths to price callable instruments by regression. The Q-measure paths ensure that the conditional expected values computed by the regression correspond to no-arbitrage prices.

If you were to replace the CrossAssetModel calibration with historical parameters, the regression would still run but the resulting prices would not be no-arbitrage prices.

P-measure: initial margin and CPPI simulation

ORE's CPPI strategy simulation and its SA-CCR/SIMM initial margin (IM) schedule simulations operate in P. The reason is conceptual: you are asking "what range of market states could happen over the next 10 days or 1 year, so that we can size the margin buffer correctly?" That is a question about real-world scenarios, not about pricing.

In practice this means the volatility and correlation parameters used in these simulations are estimated from historical data, not backed out from option prices. The drift of equity factors is the expected return mu, not the risk-free rate r.

Mixing the two is a common source of confusion in ORE configurations. A rule of thumb: if the config section says "calibrate to swaptions" or "calibrate to FX options", it is Q. If it says "estimate from historical returns" or "historical covariance", it is P.

What this means for synthetic market data generation

The GMM paper (see Paper summary: Gaussian GenAI — Synthetic Market Data Generation) fits a Gaussian Mixture Model to historical daily yield-curve and vol-surface data. Sampling from that GMM produces synthetic market data snapshots that are statistically consistent with the historical distribution — i.e. they live in P.

The GJR-GARCH neural-network paper (see Paper summary: GJR-GARCH neural-network option pricing) trains a Mixture Density Network to predict the terminal return density implied by the GJR-GARCH model. The trained MDN maps model parameters to risk-neutral option prices — it operates in Q.

This creates a concrete pipeline problem for ORE Studio:

  1. GMM generates a synthetic EUR/USD vol surface. The surface is sampled from the historical distribution of vol surface shapes. It describes what vol surfaces looked like in the past — a P-measure object.
  2. QuantLib's LocalVolSurface (or ORE's vol surface loader) expects a Q-measure vol surface: one that is consistent with no-arbitrage option prices. Implied volatilities extracted from traded option prices are Q-measure parameters.
  3. A P-measure vol surface is not guaranteed to be arbitrage-free. It may imply negative butterfly spreads or other violations that QuantLib's arbitrage checks will reject.

The resolution discussed in sprint 21 (see Intermediate analysis: map paper techniques to ORE asset classes) is a P-to-Q bridge: use the GJR-GARCH risk-premium adjustment to convert the historically-calibrated volatility dynamics into a Q-measure implied vol surface that is arbitrage-free by construction. Concretely, the GMM provides the shape and correlation structure of synthetic vol surfaces; the GJR-GARCH MDN provides the no-arbitrage Q-measure calibration that makes those surfaces usable as QuantLib inputs.

A simplified view of the two-stage pipeline:

Historical data  -->  GMM (P)   -->  synthetic vol surface shape (P-measure)
                                              |
                                  GJR-GARCH MDN bridge (P -> Q)
                                              |
                                   arbitrage-free implied vol surface (Q-measure)
                                              |
                               QuantLib / ORE option pricer (Q)

Until the P-to-Q bridge is in place, GMM-generated surfaces should only be used for P-measure purposes: scenario generation, stress testing, and backtesting of hedging strategies — not for live option pricing.

See also

Emacs 29.3 (Org mode 9.6.15)