# Finite Differences Vega calculation - confirmation on proper approach

I have a MC simulation that uses finite differences to calculate the Greeks. It's for baskets and calendar spreads mostly.

Now the logical (to me anyway) approach to calculate Vega is to increase the input volatility by 1% (annual vol) for each leg (leg1 Vega: leg1 vol + 1%, leg2 Vega: leg2 vol + 1%, etc.), reprice, then subtract the initial price, leg by leg. Result = $change from a 1% volatility increase on each leg of the option. Today, my boss told me I should be using a much smaller number than 1% (as a FD shock). I responded: but isn't Vega supposed to show you the change in option value with a 1% increase in volatility (annualized)? Did I miss something here? Please if there are other methods, or I am completely wrong in my approach, I really need to know. And if my method is satisfactory, please confirm as well. Note on my background: I came from a market risk role, and transfered into derivatives pricing. Not the other way around, so my understanding of the meaning of Vega is the way it is understood in market risk. It may very well be looked at differently from a financial engineering perspective, but that is news to me. Thanks for your time. ## 2 Answers Did you try using your tool for vanilla options (a single underlying)? Technically, Black Scholes Greeks are for infinitesimally small changes (not 1%). That said, making shifts too small is dangerous - especially with numerical methods because you can get into an area where your standard error will be bigger than the change in shift in vol. This answer shows the two main ways to compute greeks with bump and reprice: • $$[P(v+d/2) - P(v-d/2)]/d$$ central difference -> bump up and down • $$[P(v+d) - P(v)]/d$$ forward difference -> only shifting up The former is the most frequently used for Delta and Gamma. The latter is what most systems (I came across) use for calculating vega; mostly done with an absolute one-sided shift of 0.0050 = 0.5% = 50 bps. In complex models, you can compute Greeks in many other ways: • market greeks: bump market (vol surface) and reprice (you can either recalibrate or not) • model greeks: bump model parameters (e.g. LV surface) and reprice If you use (probably the most sensible approach) a “bump market, recalibrate and reprice technique, you should ideally get close to closed-form expressions. Depending on your access to other prices, you could compare your model to existing tools (e.g. Bloomberg DLIB), where you can actually manually decide what the shift in your Greeks should be (with default sizes of 1% for delta and 0.5% for vega in equities). • Thanks for your reply. So I tried using 0.5% bump vs the 1% bump across a whole range of strikes, and the difference was never more than a 1/10 of a cent (option values from 5-11$), ITM through OTM. Compared to a simple bump of 1% up the values are in line (on just 1 option pricing example to note). I'll have to compare it on more scenarios, and try vs. Black Scholes (thanks for the suggestion). Also, thanks for the reference for the delta bump (+/-) BTW as I was trying to get my coworker to do that and that link shows why it's better, he wasn't interested...
– Matt
Feb 4, 2022 at 21:20
• Very good points, +1. I would want to add that - well at least in a perfect world - your team should have a consistent policy or set of definitions across models and greeks. How would you properly hedge / manage your book otherwise? Of course, for simple products the error is small (as your suggested, @Matt ), but it can become a mess pretty soon. Feb 4, 2022 at 22:24
• Hmm..., I went from a Calendar Spread (Asian) to a 6 leg Basket (Asian) and varied the time to expiry, the strike, and tried around 30 scenarios and the worst error I found fully ITM through OTM was 0.0025 using 0.5% vs 1% shocks. Translated into trading terms: \$25K on a 10M bbl position. Rounding error, although certainly not definitive. I'm sure someone can find a case where the error increases that I haven't tested yet. So... I'll just leave that field open in the spreadsheet so the trader can change to their liking. Yeah we should have standards but don't unfortunately.
– Matt
Feb 4, 2022 at 23:34

When using numerical differentiation based on a Monte-Carlo estimator you encounter two sources of error.

1. Monte-Carlo Error which is of order $$\mathcal{O}(1/\sqrt{N})$$ for a simulation of size $$N$$,
2. Numerical difference error. The forward difference has error of order $$\mathcal{O}(h)$$. The central difference is better with order $$\mathcal{O}(h^2)$$ for bump size $$h>0$$.

You should check which bump size $$h>0$$ gives you the best trade-off between those two error sources. Depending on the method you are using and the number of simulated scenarios 1% can be just right, two small or to big.

Additional i would recommend checking it would be beneficial to compute directional derivatives based on identifiable principle components. In your case that could be for example as follows:

1. Parallel shift: increase volatility of leg1 and leg2 the same amount up.
2. Spread shift: increase volatility of leg1 and decrease vola of leg2 the same amount.
• Central differences sounds better, thanks for the commentary. I prefer that approach as well over a single shock up, just because, it's better in theory. Although error estimates I've found in practice to be oversimplified proxies to reality. We already reduced #1 through RQMC w/ Sobol (Joe/Kuo 2010) and Owen Scrambling so 8192 sims -> 1-5M antithetic ones in accuracy, so the only place we can reduce error is your point #2. Thanks!
– Matt
Feb 4, 2022 at 23:37