Euler Discretization Can Distort SABR Swaption Volatility Smiles

# Asymmetric Choppiness in Swaption Vol Smile with SABR Model


# Asymmetric Choppiness in Swaption Vol Smile with SABR Model












I was modelling the swaption volatility smile with SABR using the following steps:

- Using a pre-determined set of SABR parameters, I priced a set of swaptions across a range of strikes [0.020, 0.090], with an initial forward rate of 0.045. These pricings are done Monte Carlo style by letting the forward rate and volatility evolve stochastically. A strike that is <= 0.045 I price it as a put, else I price it as a call.

- Each implied volatility across its strike is deduced using Brent from their corresponding swaption prices.

There is no discounting done in the Monte Carlo simulations i.e. discounting the average of the terminal payoffs.

I noticed that the swaption volatility smile I produced exhibited greater "choppiness" on the right side as compared to the left side i.e. on the OTM call side as compared to the OTM put side.

Question: Can anyone tell me if this is an expected feature of the swaption volatility smile?

Additional information on parameters and varying experimentations -

My SABR parameters are [F0, sigma0, alpha, beta, rho, T, K] = [0.045, 0.058, 0.60, 0.5, 0.00, 1, 0.045]

where sigma0 is the initial volatility and alpha is the vol-of-vol to avoid confusion.

(1) A normal vol smile with 252 steps per year with 10,000 paths per Monte Carlo simulation, (2) Increase the number of steps per year to 1000 from setup (1), and (3) Increase the number of paths per Monte Carlo simulation to 100,000 from setup (1).

(1) Number of Steps Each Year = 252, Number of Paths in Monte Carlo Simulation per Option = 10,000

(2) Number of Steps Each Year = 1000, Number of Paths in Monte Carlo Simulation per Option = 10,000

(3) Number of Steps Each Year = 252, Number of Paths in Monte Carlo Simulation per Option = 100,000

## Answer by Russlan Ramdowar (score 1, accepted)

https://quant.stackexchange.com/a/85788

not a bug, you just found a classic Euler-discretization artifact near a boundary. happens to basically everyone who simulates CEV/SABR (beta<1) the naive way. good news: easy fix exists.

why it happens: your beta=0.5 makes the forward rate process behave like CEV — the diffusion (vol) term shrinks as the rate gets close to zero. think of it like a ball that loses bounce-energy the closer it gets to the floor. Problem is, plain Euler has literally no idea that floor exists: $F_{t+\Delta t} = F_t + \sigma_t F_t^{\beta} \sqrt{\Delta t}\, Z$

nothing here stops 𝐹 from going negative if Z rolls a bad draw while F is already small. Euler just blows straight through the boundary like it's not there.

why calls get hit worse than puts, specifically: your OTM puts (low strikes) are priced off paths that stayed low — near that floor, sure, but low forward rate = low diffusion too, so those paths are actually pretty chill once away from the blow-up zone. put payoffs near the money are smooth, numerically well-behaved, nothing weird.

your OTM calls (high strikes) need paths where the rate ran way up. to get there under bad-near-zero-discretization, some of those paths pick up extra noise near the boundary early on, THEN have to travel far to hit a high terminal value. High-strike payoffs are tail events already — few paths land there, so your MC estimate for them is naturally noisier (classic far-OTM = high variance in any MC sim). Boundary noise + tail noise stack on the same side. that's your asymmetry, right there.

your own experiments basically prove this:

- more steps/year (252→1000) shrinks the discretization error — smaller time jumps = less chance of Euler violently overshooting past zero. if call-side choppiness visibly calmed down here, that's discretization bias confirmed, not "real" model behavior.

- more paths (10k→100k) only kills pure sampling noise, does nothing for the discretization bias itself. if it helped a little but not as much as more steps did — yeah that's exactly what you'd expect. some noise is sampling, some is a structural bias more paths can't touch.

the fix, ranked by bang for buck:

- absorb or reflect at zero — cheapest patch. step goes below 0? clamp to 0 (absorb) or flip sign (reflect, |F|). kills the worst blowups instantly.

- Milstein scheme instead of Euler — adds a correction term for the changing diffusion coefficient, meaningfully cuts the bias for beta<1 processes without a full rewrite.

- Andersen's QE scheme — built for Heston originally but works great on CEV-ish square-root-type dynamics. this is basically the industry standard fix for exactly your problem. cleanest smile, no need to brute-force with more paths.

Do any of these and rerun setup (1) — the right side should smooth out to match the left. that'll confirm it was discretization bias the whole time, not some real quirk of the SABR smile itself.