OptionVue new ver. 7.71 Modelling Problems

Discussion in 'OptionVue Forum' started by Jay Winger, Oct 30, 2015.

  1. Kevin Lee

    Kevin Lee Well-Known Member

    One way to check is to turn on the Projected Volatility. We can pretty much eye ball the shape of the projected IV curve.

    upload_2015-11-6_0-3-31.png

    From the look of it, the project IV is pretty much linear. The curving up part above the market has been taken out.

    I think why the new model is so inaccurate is because the it assumes the curve-up part will stay static. In reality, when market turns-around and start grinding up, the curve-up part will flatten and crash much faster than IVs below the market (the linear part). Therefore, options above the market will be over-priced by the new model. Especially for butterflies, if the right leg steps onto the curving-up range, for sure it will crush far more than the other legs. As a result, if the model assumes a static skew, it'll be highly inaccurate.

    Not 100% sure though. Just my educated guess from the limited explanation of the new model in the release notes.
     
  2. Capt Hobbes

    Capt Hobbes Well-Known Member

    You can also see the actual model skew curve and the IV data points it's derived from. Go to Model > Volatility tab > Vertical Skew tab. Then click inside the little table to select the curve you are interested in. For example, click the cell in the "Both" row and the "NOV" column for the model curve for the combined put/call skew for November, then click the "Skew Graph" button to see the curve.
    vskew.PNG
    The "Skew Parameters" button will show the numeric values of the curve parameters, whatever they mean. (Curvature, slope, and offset sound like quadratic regression parameters, but the standard quadratic regression fit to today's data looks different, and actually fits the data better).

    If someone could compare these in 7.72 and an earlier trusted version, it would either prove or disprove that 7.72 really was rolled back to the old behavior, at least as far as the skew model goes.
     
  3. Jay Hattler

    Jay Hattler Well-Known Member

    Based on what Capt Hobbes is saying about the now non-mandatory nature of the upgrade, it seems like a resolution of this whole thing could involve making the 7.67 version available to all of us and then letting folks, at their own pace, backtest and upgrade to the newer version. I doubt many of us have access to 7.6x versions, so OV would need to provide a download link.
     
  4. PatrickS

    PatrickS Member

    I found an old VM with 7.66 installed and the upgrade was not mandatory. I assume 7.66 is decent or closer to 7.67 then 7.72 is?
     
  5. Capt Hobbes

    Capt Hobbes Well-Known Member

    From the letter you shared, Len believes that 7.72 has been reverted to exactly the same behavior as 7.6x so he would probably say that's unnecessary. On the other hand, given their somewhat shaky QA record, I could imagine that he truly believes so but the reality is different. In fact, it appears that they couldn't even manage to get that damage control letter out to all customers. I only saw it here on the forum--and I submitted a ticket to report modeling problems so I'd expect to be on some sort of a "concerned customer" list if there was one.

    This is why it would be nice if someone with access to both the current and older versions could do the steps I described above to compare the specifics. Screenshots of the skew graph and skew parameters in both versions would either give more substance to Len's assurances, or give us proof that 7.72 has not been fully reverted.
     
  6. LearPilot

    LearPilot Guest

    I did a comparison, here you are. 7.67 against 7.72:
    767.jpg 772.jpg
    Not exactly the same, it seems...
     
  7. Jay Winger

    Jay Winger Active Member

    The reason you are seeing a 'non-mandatory' upgrade is because 7.72 did not involve server side changes as 7.71 did. Unfortunately this apparent leap-frogging is a mirage and doesn't do much good, as these server side changes appear to have broken previous versions from functioning for most, often giving the error 'Unable to find background data for RUT' when accessing the asset file: http://screencast.com/t/joHVrn7LTx Ken Dole at OV has confirmed that the server side changes have necessitated this whole rebuilding process, and truly going back to 7.67 or prior on their end is now impossible. Don't get me started on how irresponsible this move was from a software development standpoint, but it's where we are at.

    That being said, I think I've been able to get v.7.67 to function by getting the 7.67 install file from Ken, and then overwriting asset files with ones from previous versions (I couldn't get it to work with versions before 7.65). I can tell you from comparing the 7.72 with the 7.67 that I have functioning, at least with my particular position types, that 7.72 is still screwed up, showing many more negative deltas, and flatter gamma to the upside. I will post screenshots next week.

    To say this creates a crisis in confidence for me, is an understatement. I have gone to flat on all of my income positions that would normally be managed by OV, and I am now re-evaluating the options mgt. tools landscape.
     
    Last edited: Nov 8, 2015
  8. LearPilot

    LearPilot Guest

    Hopefully ONE with its new CEV volatility modelling will be a future alternative to OV. The latest modelling issues and the complete denial of bringing the GUI and user experience to an adequate level for modern computer and internet technology at OV since years is not acceptable considering the monthly charges for OV.
     
    Andrei likes this.
  9. will

    will Well-Known Member

  10. tom

    tom Administrator Staff Member

    Excellent video. Thanks Will for posting it!
     
  11. DavidF

    DavidF Well-Known Member

    Very helpful video, clears things up and explains all the anomalies I was seeing (I believe).
    As of now I´ll be checking the curve fit on the vertical skew anytime I´m using variable (until Len has improved the curve fit model) and using EIOIO in positions where there are far OTM positions.
    My amateur interoperation is this:- the crux of the problem is that the variable model (correctly) attempts to take index skews into account by curve fitting, but this creates other problems as (a) you have to set an arbitrary threshold regarding which options are outliers and (b) curve fitting skews the line where there´s no skew, i.e., close to ATM and markedly alters their greeks. This explains why having a lot of strikes threw my greeks way off in positions where all my positions were close to the money. Screen Shot 2015-11-16 at 04.29.29.png
    Attached is pic of this phenomena.
    Was also valuable for me to learn about the "time since updated" function as that of course affects P/L in position where you have thinly traded options.
    My conclusion is that best strategy for M3s is to use the most liquid options (Locke mentioned, iron butterflies). Then use as small a strike selection as possible. This may sacrifice accuracy for large moves but provides much better greeks in moves >1SD. which is more relevant for day-to-day management.

    Caveat is the less strikes you select in order to get a perfect fit, you´re basically going back to an EIOIO model.
     
    Last edited: Nov 16, 2015
    Jay Winger likes this.
  12. Jay Winger

    Jay Winger Active Member

    Honestly, I see the sudden concern for the effect of OTM Calls/ITM Puts on the skew curve fitting, at least as related to the 7.72 problem, as a bit of a red herring. I've been using Large Extent and Combined Put/Call for as long as I've been using OV and it has provided a decent fit, reasonably stable greeks, and fairly reliable projections for all that time. While I believe that improving the skew curve fit is a challenge and always something to strive for, I don't think it explains the recent problems we've seen, (although I think skew curve issues may be symptomatic of the modelling flaw introduced). Even if it might be perceived as a workaround for some, for my particular position types anyway, changing the Strike Extents does very little to change my greeks, and introduces the problem of positions I have being cut out of the matrix.

    To illustrate skew issues as a possible symptom of a larger problem, here is a comparison of vers. 7.64, 7.67 and 7.72 combined vertical skews on a live matrix from Friday (I have all 3 versions working on live data):

    ver. 7.64
    upload_2015-11-16_12-32-17.png

    OV 7.67:
    upload_2015-11-16_12-32-41.png

    OV 7.72
    upload_2015-11-16_12-32-55.png
     
    Last edited: Nov 16, 2015
  13. DavidF

    DavidF Well-Known Member

    HI Jay, you´re surely right, as I mentioned this stuff is way out of my competence zone so not sure what the root cause is. The major issue in the video was faulty CEV values on RUT, not what I discussed.

    The strike selection is the major factor in my trades, here´s a current screen shot of an SPX postion I have on, M3 with iron BFs, the small strike gives a delta of close to zero, the large setting fluctuates between minus 80 and 120.
    Screen Shot 2015-11-16 at 09.54.12.png Screen Shot 2015-11-16 at 09.54.49.png
     
    Jay Winger likes this.
  14. Jay Winger

    Jay Winger Active Member

    Hi David, good illustration. I wasn't directing my analysis at your observation, which I think is very good, just using it as a jumping off point for Len's discussion in the video in relation to recent problems. I was the one working with him on the CEV issue / Assets.txt file fix on Thursday and Friday, and unfortunately it did not result in a conclusive fix to the problem.

    In my latest communications with him, it sounds like he has simply been unable to identify the problem, and is committing to going forward with his NEW model instead, which he thinks will be more accurate in the skew fitting department, which he will send to beta as soon as he can. Fingers crossed - I'm flat positions I'd normally be managing in OV, until I get something stable I can then start the backtesting/strategy building process on anew. :(
     
    Last edited: Nov 17, 2015
    KiwiDon, GreenZone and DavidF like this.
  15. David Stewart

    David Stewart Well-Known Member

    It's just an unbelievable mess. I don't know what to trust anymore. But I tend to agree with Ron today who has gone back to relying more on TOS. I find that I have been doing that as well.
     
    GreenZone likes this.
  16. Scott Slivnik

    Scott Slivnik Well-Known Member

    I have been using both TOS and OptionVue myself. After OptionVue became usable for me, I was not expecting to need to rely on TOS. I have a butterfly on SPX and TOS showed -2.04 delta and OptionVue showed -8 and change as the delta which I knew was not correct.

    I looked at the volatility skew curves in OptionVue. The put skew curve looked good. The OTM calls messed up the call skew curve. I changed the Extends to Small for the OTM calls and the delta changed to -2.64 which I treated as my current delta. The problem is tomorrow may be different and will need to mess with settings again. The software should be able to determine the "garbage" and throw it out most of the time.

    OptionVue needs to clean up their mess!
     
  17. DavidF

    DavidF Well-Known Member

    Regarding what to trust my (possibly erroneous) understanding is that the position delta generated by the OV variable model is the equivalent to the black dot generated for P&L, i.e., the data generated are based on the best-fit parabola that is only as good as the curve fit. OV EIOIO/TOS/ONE take the mkt. price and use a standard formula to generate MIV from which all other greeks are calculated. OV variable use the same starting formula to generate MIV but then take it further with curve fitting in an attempt to accommodate vertical/horizontal skew. This has has pros and cons.

    So if whole purpose of greeks is to assess risk, the question becomes is my risk more accurately assessed by where I am right now (EIOIO) or where the trade is going when price changes?

    They´re both important but my notional exposure as predicted by the current OV variable model is sometimes so far off (hundreds of thousands $$ notional difference on SPX) that it creates far more risk than the improvement in predictive accuracy the variable model may offer. Only position delta solution for my set-up would be to do what Ron explains for P/L, use the actual value (EIOIO) for current and plug that number into the variable (e.g, EIOIO says current position delta is -50, variable predicts it will change by 30 deltas on a 2% move). However if the actual numbers are way off due to the curve not fitting then I also doubt the predictive accuracy.

    If it´s a very good curve fit then variable should do both jobs, no need to check EIOIO. If it´s not a good fit everything falls apart.

    Will be interesting to see if Len can improve the curve fit given it´s worth depends on very accurate (not wildly over or underpriced or out-of-date) market prices. Perhaps if the model is designed to only include data from options whose price has been updated in the last 60 secs or so.
     
    Last edited: Nov 18, 2015
    Venkat likes this.
  18. GreenZone

    GreenZone Well-Known Member

    David, the black dot in OV is generated from EIOIO data.
    The T+X lines are generated (by default) using variable variance and CEV.
    The fact that the P&L of your T+0 doesn't match the "real" P&L (identified by the black dot) is perfectly normal.

    With TOS, your real P&L is identified via "individual implied volatility" and accurate greeks are shown via "volatility smile approximation".

    I tried to cover this topic again in yesterday's TG2 meeting:
     
    Venkat, Jay Winger and Scott Slivnik like this.
  19. DavidF

    DavidF Well-Known Member

    Ron, I understand the black dot is EIOIO, my point is your position deltas are extrapolating the delta values from the same curve fit when you use the variable model. So when the black dot is way off versus actual P&L, your position deltas will also be way off. Is that wrong? (the default model for the T+x lines are also switched to ind. imp. vol if you change to EIOIO)
     
    Last edited: Nov 18, 2015
  20. GreenZone

    GreenZone Well-Known Member

    Correct.
    Bad curve fit = bad projected IV = bad greeks and T+X lines
     
    DavidF likes this.

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice