Options price imputation when Bid/Ask spread is wide

Discussion in 'Options' started by TigerBalm, Apr 30, 2014.

  1. I am trying to backtest using Options EOD data from ivolatility.com and there are some interesting data issues.

    Let's take the particular case where the Bid / Ask is really wide :
    Bid = $0.67, Ask = $2.63. Mean Price calculated = ($0.67 + $2.63) / 2 = $1.65

    In such a case, the Mean Price calculated is wrong (or rather, far away from the realistic execution price one would get, which is better), and so is the IV imputed from this, and hence, the greeks, too.

    But I (as a human trader) know just by looking at the Bid and Ask that they are too wide apart. I can compare the prices and spreads of the adjacent Strikes and I can guesstimate that this Mean Price is wrong!

    So how is tackled in industry / academia?

    What I want to do is use a machine learning model that considers the entire curve / surface and imputes the most-probably execution price for such options rather than just use the Mean Price. However, the rabbit hole seems deep : do I have to model slippage / liquidity, too?!

    Raw data (omitting Date, ExpiryDate, etc; for brevity):

    Strike = 20, Bid = 1.07, Ask = 1.24, Mean Price = 1.155, IV = 0.8221
    Strike = 20.5, Bid = 0.65, Ask = 3.95, Mean Price = 2.30, IV = 0.5432 <-- wrong!
    Strike = 21, Bid = 0.60, Ask = 0.76, Mean Price = 0.68, IV = 0.8156

    Notice how the mean price for the two surrounding strikes is actually OK because the Bid/Ask spread is not that wide.
  2. TskTsk


    What about filtering the data based on out-of-line IV numbers or based on some criteria for max b/a spread? Then look at two nearest correct IV numbers, interpolate and insert it on the strike with wrong numbers, then recalc price and greeks?

    just thinking out loud. I have no idea how they do it in academia.
  3. SIUYA


    One of the massive problems without adequate resources - and even with adequate resources this will all likely be a fudge of some sort. Especially in anything that does not have some deep liquidity.
    It might be worth using a simple IV midpoint fudge and seeing if there is value....if not, allowing for slippage, and liquidity will be unlikely to make it better.
  4. samuel11


    What if you use put-call parity?
  5. Thanks for the thoughts! I was thinking on these lines, too, but the max b/a spread is a good one, I didn't think of that.
  6. Superb idea! Will update this thread with how it goes.
  7. Thanks. That's a very useful perspective; I have a habit of overengineering things and then finding out it was not worth it! :)

    My particular use case is VXX options (for now). Liquidity actually increased, so it is worth it for at least 2 reasons:
    a) it is realistic to assume that we can get better prices in actual trading, hence improving the backtest makes sense
    b) we can potentially use the same model for hypothetical questions, too, such as:

    "What is the OTM strike which we can expect to Buy for a nickel?"

    This is very useful for hedging strategies. For example, on most indices and even stocks, it seems to me that one can buy a far OTM hedging PUT option for a nickel at a strike that is often not more than 25% below the spot price. This would immediately reduce the risk of holding that stock by 4 times. Thus, it is worth backtesting such an Options hedge to figure out how much such safety would cost us...Except, of course, prices / spreads are the worst on OTM strikes. Hence the effort at modeling this...
  8. P/C parity will require use of mid.
  9. newwurldmn


    The question you asked - it might reduce your margin requirements, but it's a bullshit hedge.
  10. Let's say I'm Short VXX, and I want to hedge my ass by being Long an OTM VXX Call. Then?

    Or if I invested 25% of my life savings in some hot stock and am butt-scared that it may turn out to be Enron, and want to put on a monthly Collar...Then?

    Anyway, my main point is about illiquidity being at them OTM strikes and / or bad data. My trading ideas are often not that good. :)
    #10     Apr 30, 2014