Parametrise Implied Volatility Smile

Z

ZeroReturn

Hi,

I am currently to create my own volatility smile for currency options. I am basically reading the bids and offers and calculating the implied volatilities.

I now want to shape and parametrise my own volatility smile. What is a good way to do it?

I tried it by trial-and-error, which did not really work. I tried the Corrado-Su Model, but I was not too happy about the results. Currently I use the following equation: Vol(X) = Vol(ATM) * (F/X)^(1-beta), where X = Strike and F = Underlying Price. However, having only 1 parameter (beta) to calibrate is a bit small.

Are there any other options? I read about CEV or SABR model, but struggle in their implementation.

Bests.
 
Thanks for the input so far. Both methodologies are interesting. I read about both versions before as well. However, it seems that both try to tackle the volatility surface by building a curve out of given volatilities. Which is good, if the underlying is liquid enough. But my underlying (cryptocurrencies) are sometimes not liquid at all.

Ideally I input only few factors, e.g. the ATM volatility and two more factors like skew and kurtosis or alpha and beta. In such case input factors to a potential function could look like:

ATM = 3500
ATM volatility = 50%
alpha = 0.5
beta = 1.2

The output would be the to a strike corresponding volatility. This at least is the most simple process I can imagine. However, I might be wrong, maybe the Uwe Wystup method or ivolatilites method is really that simple. At first glance however, it looks quite complicated to me.
 
ZeroReturn said:
Thanks for the input so far. Both methodologies are interesting. I read about both versions before as well. However, it seems that both try to tackle the volatility surface by building a curve out of given volatilities. Which is good, if the underlying is liquid enough. But my underlying (cryptocurrencies) are sometimes not liquid at all.

Ideally I input only few factors, e.g. the ATM volatility and two more factors like skew and kurtosis or alpha and beta. In such case input factors to a potential function could look like:

ATM = 3500
ATM volatility = 50%
alpha = 0.5
beta = 1.2

The output would be the to a strike corresponding volatility. This at least is the most simple process I can imagine. However, I might be wrong, maybe the Uwe Wystup method or ivolatilites method is really that simple. At first glance however, it looks quite complicated to me.
More...
I have no experience with the underlying's you are focusing on, so my input may be not be that useful. My interest in similar objectives for SPX options necessitated the problem be addressed in two phases, with the Volatility @ T+0 resolved first, before applying the variations on vol change with time/price. For SPX, I have phase 1 completed, but phase 2 approach is less clear, as which implementation is typically a function of the trade characteristics, so one approach is best for some, another is best for others. However the initial phase only needs to be solved once. You should be able to plot your Volatility surface (all strikes, puts and calls, and all expirations) and observe NO odd anomalies. Then, IMHO, addressing the variable vol, CEV, etc., may be viable, as you have a sound baseline. (Divide and conquer seems appropriate here)
 
ZeroReturn said:
Thanks for the input so far. Both methodologies are interesting. I read about both versions before as well. However, it seems that both try to tackle the volatility surface by building a curve out of given volatilities. Which is good, if the underlying is liquid enough. But my underlying (cryptocurrencies) are sometimes not liquid at all.

Ideally I input only few factors, e.g. the ATM volatility and two more factors like skew and kurtosis or alpha and beta. In such case input factors to a potential function could look like:

ATM = 3500
ATM volatility = 50%
alpha = 0.5
beta = 1.2

The output would be the to a strike corresponding volatility. This at least is the most simple process I can imagine. However, I might be wrong, maybe the Uwe Wystup method or ivolatilites method is really that simple. At first glance however, it looks quite complicated to me.
More...
A model, such as SABR or CEV, which, in your context, is to be used primarily for interpolation still needs to be calibrated. In the absence of any OTM option prices/vols, the choice of model is kinda irrelevant, since you have no information that would allow you to determine if a given approach fits. You might as well just pick numbers randomly.
 
You must log in or register to reply here.
Back
Top