Hello all,I am currently working on equity derivatives pricing. The biggest issue I encountered up to date is cleaning and parametrizing volatility surfaces. I imply volatilities from exchange traded equity options. Then local volatility model I base on this implied volatility surface blows up from time to time (once in two-three days). Usual reasons for that to happen are:- There is arbitrage opportunity in the market prices- There is calendar arbitrage that occurs after parametrizing volatility surface slice by slice (arbitrage usually occurs on parts of volatility surface that are extrapolated)- There are extrapolated negative volatilitiesApproaches I've used so far:a. Using implied volatility surface "directly" with cubic spline interpolation and flat extrapolationb. Polynomial parametrization done slice by slice (with 2nd degree polynomial) [one slice per maturity]c. SABR parametrization done slice by slice [one slice per maturity]d. Practitioners Black Scholes wchich amounted to using polynomial to fit entire volatility surfacevol(K,T)=a0+a1*K+a2*K*K+a3*T+a4*T*T+a5*K*Twhere:vol(K,T) - implied volatility for strike K and time to maturity TK- option strikeT- time to maturity in yearsa0-a4 - are polynomial parameters,solutions a. and c. resulted mostly in calendar arbitrage for out of sample volatilitiessolution b. and d. resulted in either calendar arbitrage opportunities and occasionally in negative volatilitiesI would be greatful for recommendations on:1. Efficient algorithm for removing non-arbitrage free volatilities from raw implied volatilities set,2. Surface parametrization/interpolation procedure that would be arbitrage free.3. Can I ammend any of the approaches I used so far?I am currently considering trying out SVI but as far as I know it is not free of arbitrage either.Jakub

Hi Jakub,here is a nice overview paper: http://papers.ssrn.com/sol3/papers.cfm? ... 82567There are many different approaches presented. It depends on your application and taste, which one you should use...Darou

A good approach is to perform SVI interpolation per maturity to compute call prices on a cartesian grid (on strikes or log strikes), then use Andreasen, Huge, Volatility Interpolation to fill the gaps between maturities. It will leads to a complete and arbitrage free implied (or local) volatility surface.However, note that the resulting local volatility surface won't be continuous in time.

Thanks Vivien and Darou for your comments.I've went through the paper suggested by Darou and some of the papers referenced in it. 1. I invested time in algorithms thoroughly cleaning raw implied volatility surface 2. I wanted to stick to SABR for a while as I've already had some stuff implemented.I used the approach similar to presented by Artur Sepp:http://kodu.ut.ee/~spartak/papers/sabr.pdfMy valuations are now in line with the market, however I am infrequently encountering negative local vol squared (say once every 2 million simulation steps). Currently I just use some ad hoc replacement for those negative local vol squared. However I was able to spot the reason for negative local vol squared:When the price approaches at the money, due to rounding errors volatility starts to oscillate. Did anyone encounter same issue? If so how would you approach it? Maybe rewriting SABR implied vol formula would make a difference?Jakub

Not that I will most likely have an answer, but I am somewhat confused by your question. My understanding is, you go through the process specified in the paper to build a complete volatility surface. Known expirations are fit to SABR and then an interpolation of some form is performed for parameters in between expirations. I presume you are trying to determine the value of some exotic option and to do so you perform monte-carlo using the local volatility derived from Dupire's formula? i.e. you simulate a one dimensional process dF = F\sigma_loc(K, t)dW_t. That strikes me as inconsistent - I'd probably prefer modeling using SABR with the time varying parameters you found. (Although I think they may represent average parameters form 0 to expiration and need to be translated to instantaneous parameter values). Why use local volatility to do monte carlo?I could see issues in general with computing SABR implied volatility around m = 0 since the formula amounts to being 0/0. The original SABR paper "Managing Smile Risk" determines a quadratic approximation around that money that you may wish to switch to for small m. Ok, I concede modeling using one sde is computationally faster than modeling two. I'm just not convinced they have the same joint densities between time. Marginal densities at a specific time yes. Actually, you may want to use the local volatility formula derived from the identity (steepest descent) [$]\sigma_{loc}(y) = (d/dy\left(y/\sigma_{imp}(y)\right)^{-1} [$] used in the article Reconstructing VolatilityIt leads to a very simple formula for [$]\sigma_{loc}[$] in the case of SABR.

@muaddibThanks for the link. I will go through the article.As for why I am using SABR + Local Volatility.I need to price some equity path dependent basket exotics (but nothing with forward volatility sensitivity). Then estimating parameters + reaching required accuracy could be a problem in the purely Stochastic Volatility setup. Additionally, if I were to do simulations with SV I would opt for model with mean reversion in volatility (which SABR is missing).I am using SABR just as an interpolation/extrapolation tool for implied volatility surface.Then my Local Volatility surface have few negative points (near ATM level - due to oscillations I mentioned in my previous post). Currently I replaced direct calculations of LV on every simulation step with calculation of Local Volatility grid (200x200, time x strike) before the simulation. Then I am using smoothed cubic splines to calculate Local Volatility from the grid at each time step. That way I am avoiding calculating LV for prices extremely close to the strike. Additionally it sped up my Monte Carlo simulations by roughly 25-30%. For 200x200 grid differences between direct calculations and using grid are neglegible (i.e. lower than MC error).Jakub