Why Delta Hedge Simulations Retain Error
Summary
The discussion explains why a simulated delta hedge may retain tracking error and how to account for changing positions. In the Black–Scholes framework, hedge error should shrink as rehedging intervals become smaller when the simulated underlying follows the same dynamics used to calculate the option delta. A mismatch, such as simulating Brownian motion while calculating deltas under geometric Brownian motion, can prevent convergence.
For portfolio bookkeeping, one answer recommends tracking long and short positions and their average prices separately, updating the relevant side with each trade to distinguish realized profit and loss, unrealized profit and loss, and exposure. The replies provide conceptual guidance rather than a full implementation or empirical study. They also emphasize that real-world assumptions and frictions mean hedging error generally remains nonzero in practice.
Key ideas
- Delta hedge error should converge toward zero as rebalancing intervals shrink when the underlying follows the model used to calculate delta.
- A mismatch between simulated price dynamics and the hedge model can prevent convergence.
- Track long and short holdings and their average prices separately when recording trades.
- Separate realized profit and loss from unrealized profit and loss when measuring portfolio performance.
- Practical assumptions mean real hedges can retain tracking error.
Tags
Full text
# Why doesn't a simulated delta hedging process go to zero?
# Why doesn't a simulated delta hedging process go to zero?
I put together a simple simulation of delta hedging a set of options with an underlying and it seems that the fluctuations of the price still seem to affect the final outcome. The reason, I understand it, is because when we rehedge, we assume that $\Delta_{S}=1$ but we don't factor in the fact that the price keeps changing. Is this a normal consequence of delta hedging practices?
Incidentally, my approach to keeping track of the amount of underlying bought or sold is to keep information related to total underlying position and the recalculated price which is
- If position is increased, we recalculate the price based on the increased position, i.e. average out the prices.
- If position is decreased, we keep the entry price the same, reduce the number of underlyings and calculate the p/l of the underlyings we bought/sold as cash.
So, another question - is this the right way to recalculate the portfolio position?
## Answer by Christian Fries (score 9, accepted)
https://quant.stackexchange.com/a/7257
I assume you mean that the hedge error should go to zero when the time-step size goes to zero. This is the case! I have a BS delta hedge simulator here: http://www.christian-fries.de/finmath/applets/HedgeSimulator.html and the source code here: http://www.finmath.net/java/ which shows that the delta hedge converges.
However, in order to have that result, the underlying stock must follow the model which is assumed in the calculation of the hedge.
In your MatLab code it looks like you are simulating stocks as Brownian motion but are calculating delta from Black-Scholes (which assumes Geometric Brownian motion). Is this intentional or a bug?
## Answer by Matt Wolf (score 2)
https://quant.stackexchange.com/a/7255
I think you incorrectly calculate portfolio values. For me the easiest way to keep track of portfolio positions and avg price is to separately calculate the sum of volume traded on the long and short side and to also calculate an average price separately for buys and sells.
You obviously must update the avg price and size of the particular side (long/short) at which you traded each time in order to in exchange have the ability to query pnl and exposure (unrealized and realized) at any time.
Edit: About your hedge error, I think Christian got it right, you can't get to zero tracking error by running different dynamics in the evolution of the underlying vs the hedge origination. Also I hope we all agree this only works in theory. In reality the simplifying assumptions made will cause the tracking error to always be non zero.Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.