Monte Carlo Standard Errors and Run Length
A Monte Carlo estimate is itself a random number with its own margin of error, and that error shrinks only with the square root of how many paths you run — so an extra decimal place of precision is far more expensive than it looks.
Prerequisites: Sample Moments and Their Standard Errors
A political poll asking 1,000 people who they'll vote for doesn't perfectly reveal the whole electorate's preference — it has a margin of error. If you wanted to cut that margin of error in half, you might guess you need twice as many respondents. You'd be wrong: you need four times as many, because sampling error shrinks only with the square root of the sample size, not the sample size itself. A Monte Carlo simulation — pricing an option, estimating a portfolio's VaR, projecting expected P&L across thousands of simulated paths — is exactly the same kind of poll, just polling the space of possible future outcomes instead of voters. Every Monte Carlo estimate comes with its own standard error, obeying the identical square-root law, and treating a simulation output as an exact number rather than an estimate with a margin of error is one of the most common quiet mistakes in quantitative finance.
The formula, one symbol at a time
Run independent simulated paths, each producing a payoff (or any quantity of interest) . The Monte Carlo estimate is simply their average, , and its standard error is:
In words: the standard error of a Monte Carlo mean equals the sample standard deviation of the individual simulated payoffs, divided by the square root of the number of paths — this is the exact same formula as the standard error of any ordinary sample mean, because that's precisely what a Monte Carlo estimate is. It follows immediately that halving requires quadrupling : if , then to get down to half its current value you need to go up by a factor of . Getting one more decimal digit of precision (roughly a 10x reduction in ) costs roughly times more simulated paths.
Watch the running average in the explorer above settle inside a shrinking envelope band as more simulated draws accumulate — that shrinking band, narrowing like , is the standard-error-shrinkage law made visible; the point estimate wobbles early on and steadily tightens, but never stops wobbling entirely, it just wobbles less.
Monte Carlo error shrinks with the square root of the number of paths, not the number of paths itself — quadrupling your simulation budget only halves your error, and the standard error is directly computable from your own simulated sample, so there's no excuse for reporting a Monte Carlo number without it.
Worked example 1: sizing a simulation to a target precision
A binary payoff pays $100 with probability 0.5 and $0 otherwise. Its standard deviation is dollars. At simulated paths, the Monte Carlo standard error is , i.e. about $1.58. To bring that down to $0.50, solve . Going from to — a 10x increase in simulated paths — buys a reduction in standard error from $1.58 to $0.50, a factor of about (), not : the payoff to more computation genuinely diminishes, exactly as predicts.
Worked example 2: a fatter-tailed payoff needs far more paths for the same precision
Now consider an option-like payoff: $0 with probability 0.98, and $2{,}000 with probability 0.02 (same mean as before, ... to keep the comparison cleaner, adjust to mean $50: payoff is $0 with probability 0.975 and $2{,}000 with probability 0.025, mean ). Its standard deviation: . At the same paths, this payoff's Monte Carlo standard error is , i.e. about $9.87 — more than 6x the standard error of the first payoff at the identical path count, purely because this payoff's outcomes are far more spread out (a small chance of a huge $2,000 result versus a much more common $0). To reach the same $0.50 target precision as before would require paths — roughly 39x more simulation than the first, well-behaved payoff needed.
What this means in practice
- Always report the achieved standard error, not just the point estimate. A Monte Carlo option price or VaR figure without its standard error is an unverifiable number — the same output could be trustworthy to four decimal places or barely trustworthy to the first digit, and there's no way to tell without computing .
- Variance reduction techniques exist because is expensive but isn't fixed. Control variates, antithetic variates, and importance sampling all work by reducing the effective in the numerator, which is often far cheaper than brute-force increasing to shrink the same standard error.
- Tail-risk and VaR estimation need disproportionately more paths. As worked example 2 shows, payoffs with rare, large outcomes have large sample variance relative to their mean, and a VaR or expected-shortfall calculation that only rarely samples the relevant tail event effectively has a much smaller usable sample size than its raw path count suggests.
The classic confusion: assuming more simulated paths buys precision roughly linearly — doubling paths, roughly halving error. It doesn't. Error shrinks with the square root of , so the return on additional computation drops off sharply well before you might expect. A more dangerous version of the same mistake is trusting a Monte Carlo digit that was never actually converged: for tail or rare-event quantities specifically, the effective number of paths that actually informed the estimate (the ones that landed in or near the tail event) can be far smaller than the total path count, so a simulation that looks like it ran "plenty of paths" can still have a huge, unreported standard error on exactly the number that matters most.
Related concepts
Practice in interviews
Further reading
- Glasserman, Monte Carlo Methods in Financial Engineering, ch. 1
- Efron & Tibshirani, An Introduction to the Bootstrap, ch. 6 (standard errors)