4
$\begingroup$

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?

$\endgroup$
2
  • $\begingroup$ "but we don't factor in the fact that the price keeps changing". Do you mean that the hedging you get is not perfect? $\endgroup$ Feb 8, 2013 at 21:06
  • $\begingroup$ @AlexeyKalmykov yep, exactly. I know it shouldn't be, but it seems the rehedging is affected mainly by the fact that every time we use the underlying it's got a different price. (in other words, we suffer from exposure to an underlying position even though in theory the option should counterbalance it) $\endgroup$ Feb 9, 2013 at 9:01

2 Answers 2

9
$\begingroup$

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?

$\endgroup$
4
  • $\begingroup$ Nice find in the code. I overlooked that. I am willing to bet that is where most all of his hedge error originates from. $\endgroup$
    – Matt Wolf
    Feb 9, 2013 at 0:43
  • $\begingroup$ In addition a big effect comes from the difference in volatitly. The geometric brownian motion with vol 100% (which is by the way quite large) in your BS delta assumption has approx. 100 time the vol of S(t) (since S is normal and S(0) is 100. Another thing which I found strange is that S(t) is evolved backward in time, but I did not dig deeper into your code. $\endgroup$ Feb 9, 2013 at 8:12
  • $\begingroup$ @ChristianFries couldn't find this demo in the source code (searched for 'delta'), would welcome a pointer $\endgroup$ Dec 2, 2013 at 6:03
  • $\begingroup$ The link to the applet above works. The source code of the delta hedge is here: svn.finmath.net/finmath%20lib/trunk/src/main/java/net/finmath/… (there is also a delta-gamma hedge version in the same package/folder) $\endgroup$ Dec 2, 2013 at 8:42
2
$\begingroup$

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.

$\endgroup$
2
  • $\begingroup$ Wait, that doesn't sound correct - if I long some and then short some, I don't end up with separate long and short position, my long position is reduced by short amount and vice versa. $\endgroup$ Feb 8, 2013 at 20:42
  • $\begingroup$ What is not correct about that? At any time you can query the net exposure which represents your open position by differencing the total longs and total shorts. The amount by which the total longs and total shorts are balanced is your closed/realized exposure on which you calculate realized PnL. $\endgroup$
    – Matt Wolf
    Feb 9, 2013 at 0:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.