Vanna vs volga and vega

So the bloomberg article that I'm referring to (Bloomberg. Variations on the Vanna-Volga Adjustment. Travis Fisher. Quantitative Research and Development, FX Team. January 26, Version 1) states that volga and vega are considered to be fungible whereas vanna isn't. I can understand why vanna isn't considered to be so , but isn't volga also something that is dependent upon the specific option and its underlying so in a sense it shouldn't be considered fungible?

• Where in the paper does it talk about ‘fungible’ pls?
– dm63
Jul 24 at 10:41
• In the "market price of greeks" section , section 1.5 , page number 4. Jul 24 at 16:27
• Thanks. I’m not even sure I buy the argument about non fungibility of vanna. It seems to me that all Greeks are fungible based on linearity of differentiation. Some options such as barriers may have rapidly changing Greeks, but they’re still strictly fungible, I would have thought.
– dm63
Jul 24 at 19:04

I am not sure I agree with @dm63 - this is way too long for a comment, not necessarily a definitive answer though to be honest. I think the fungibility argument is mainly applied / applicable for pricing with the VV method.

This fungibility argument is used by Fabio Mercurio, in Antonio Castagna's book FX Options and Smile Risk on P.180 and indirectly in a Mathfinance Newsletter where it is shown that VV pricing can result in barrier options being more valuable than Vanilla options (which should never be the case).

the difference between the VV and BS prices can be interpreted as the sum of the option’s Vega, $$\frac{∂Vega}{∂Vol}$$ (Volga) and $$\frac{∂Vega}{∂Spot}$$ (Vanna), weighted by their respective hedging cost y.

This is akin to formula (10) in the BBG paper. However, there is the problem with barrier options with this logic.

See for example Vanna, Vega and Volga on BBG for a barrier option that has an OTM barrier.

a barrier that is very close to spot (meaning the option is essentially worthless)

and in the vanilla case (far OTM to make the option practically worthless)

Fungible things are items that can be easily replaced with another item that is practically the same. Now in terms of Vanna, it was just shown that it behaves differently depending on the type of option. If you want to price options consistently with VV you need to take this into account.

That is why the aforementioned MathFinance Newsletter explains that either no-touch probabilities of the barrier or at least strict caps of the barrier option value at the vanilla option price are imposed to ensure consistency. On the downside, this comes at the cost of causing spikes and jumps in Greeks according to the article.

In any case, Antonio Castagna writes on P.181

Vanna has non-fungible features, ..., in contrast to the other two Greeks (Vega and Volga). This means that a different weighting should be applied and, namely, equal to one for Vega and Volga, ..., whereas the weight for Vanna should depend on the type of barrier and thus tend to zero for knock-out options (i.e., the adjustment should tend to zero as the FX spot rate approaches the barrier, so as to ensure that the zero-value condition is warranted). The weight for Vanna can be the survival probability, for example.

This is exactly what Bloomberg does, where $$p_{vanna}$$ is set to go to zero (using the probability of survival to expiry - the reason the author uses p_sym is that BBG uses an average of the probabilities of hitting the barrier in FOR ccy numeraire and DOM ccy numeraire in order to be symmetric) for options likely to KO whereas the weights $$p_{vega}$$ and $$p_{volga}$$ are set equal to 1 irrespective of the type of option.

While Fabio Mercurio works at Bloomberg, he started some years after that BBG paper was written and is highly regarded in the industry (e.g. Risk.net Quant of the Year 2020). Antonio Castagna published with Fabio Mercurio which means they may both rely on the same faulty argument but I do not see a problem in the argument put forward by them and in the BBG paper.

Last but not least, the MathFinance newsletter points out that VV is fast and provides (rough) indicative prices for first gen exotics (and touch contracts) in FX markets but has some serious difficulties with computing Greeks. Overall, Bloomberg has not changed this VV model for about 20 years and switched to the Stochastic Local Vol (SLV) model for essentially all exotics (with PDE and Monte Carlo versions, depending on the tool - OVML vs DLIB - and type of option - barrier vs TARF for example). If you load a barrier in OVML you will likely default to VV, but I think this is simply due to the fact that it is fast (cheap on resources) and still OKish in pricing. If you try to switch MARS (the risk tool) to SLV, you will notice that this is behind a paywall. Most likely a combination of being a lot more resource intensive, and significantly better, so that users actually are willing to pay extra for this feature.