Home > Option Trading Software and Tools > OptionVue Forum > OptionVue new ver. 7.71 Modelling Problems

OptionVue new ver. 7.71 Modelling Problems

  1. On 10/29/15, OptionVue came out with a new Mandatory Upgrade ver. 7.71, which among other changes (changes to OTM call skew modelling, expanded CEV time period reporting) appears to have tweaked the CEV model, reminiscent of ver. 7.65, which was pulled for having some issues. Well the issues are back, and then some. After going back through two years of backtested trades in Backtrader, I found instance after instance of T+0 line wonkiness, and thus greeks instability, effectively rendering my backtested adjustments worthless, and bringing into question the modelling in general, for me.

    In today's live trading I saw the same issues on live data, and numerous other traders in our groups reported and showed the same erroneous modelling behavior. I would have positions go from -60 delta with a convex T+0 'crick' near current price (collapsing gamma) to a convex crick below the money, sending delta to +30. These mutations would hold for some time.

    Below is a quick example of the type of T+0s seen on two expirations of backtrader data:

    http://www.evernote.com/l/AAKojlFYdqFK2JtmjmfTMYwg0coFGUsRAIs/

    If you haven't yet seen a clear manifestation of these issues yet, I urge you to go back through several months of backtrader data and see if it crops up - beyond the T+0 shape, look to see if there is unusual instability in greeks.

    Consider reporting this to OptionVue support at support@optionvue.com . Part of the problem is this is a Mandatory Upgrade, meaning we can't opt out of it, can't compare previous modelling to the new one, and can't complete due diligence on the core modelling changes they've made. I have emailed OV pleading with them to at least take off the mandatory feature of this upgrade.

    Jay
     
  2. Indeed. Here is a very simple position (Rhino "simple" trade example entry from Brian's presentation), just a BWB.
    upload_2015-10-30_23-8-39.png
     
  3. I noticed a significant change in the T+0 line of my live M3 where it slopes down on the right.
     
  4. I got a response from Ken and sent over screenshots. No word as to what the solution is yet, but he did say they had a "hectic" day over there on Friday.

    Kind of reminds me of the Seinfeld episode in which the building super comes around and installs "low-flow" shower heads in all the apartments and there's a bit of an uproar.
     
  5. 2015-10-31_16-38-07.png Yes, sometihng has gone seriously wrong. Here is an old iron condor, modeled in Backtrader using version 7.71
     
  6. Send it in if you haven't already.
     
  7. No kidding. They really ought to have some sort of a release process instead of just throwing some bits over the wall every once in a while.
     
  8. Hi everyone, my name is Jeff Plimpton, and I'm a Product Consultant for OptionVue. Len is working out the modeling
    bugs and will have a new release at the end of today. Please keep in mind that when there are issues with a release,
    we have to recreate the problem in order to come up with a solution. If any of you would like to send over an asset
    file to help with the process, we would appreciate the support. A picture from the Graphic Analysis won't solve the
    problem if the same trade looks fine when we enter the position on our software. Thanks...
     
  9. Thanks Jeff. Where should people send the asset files to with a description of the problem they are having?
     
  10. Off topic:
    Every time OV is talking about software development (be it new features or bugs), it is always Len who is working on it. Is your founder your only software developer?
     
  11. I updated to 7.72 - seems to be even worse:
    screenshot.png
    A bearish butterfly with that many DTE never has the T+0 peak right below its center. In the past (before 7.71) this was better.

    I deleted my asset file and started fresh - no change.
     
  12. You can send asset files to jim@optionvue.com...We really appreciate everyone's patience and help with this release...

    Jeff
     
  13. Here is the exact same screen shot of my IC as above, but this time with version 7.72. Certainly looks much more like it used to before 7.71. (I don't have a screenshot of the IC prior to 7.71.) I have sent the current SPX.INX flile to OptionVue as requested.
    2015-11-02_19-16-01.png
     
  14. Hi Jeff,
    I appreciate you taking the time to respond on here and making the customer outreach, I must say it has been sorely lacking on the individual level on this issue (I started emailing Ken, James and the general support site with specific examples and screenshots starting Thursday evening with nary a substantive response).

    I am not entirely happy to hear that this doesn't sound like a true rollback to the previous model as much as an educated guess to unwind a problem introduced. Back on the ver 7.65 release, when there were also modelling issues (subsequently rolled back), I stressed with Ken the importance of allowing us access to previous versions whenever modelling changes are made, in order to allow us time to investigate what impact the changes will have on the strategies we have developed, sometimes after hundreds of hours of backtesting. Modelling changes attached to a Mandatory Upgrade effectively handcuff us to the new modelling, flawed or not, and cut us off from all our past research.....and it sounds like they've handcuffed Len/Jim as well, from being able to simply roll back to the prior long-standing model.

    I was pretty much trading blind today managing my many positions, and now there is a seed of doubt that the model may not be the same. I don't feel we should have to play detective to find out where the cracks are, when a working model is out there that we have built everything upon, and we should have an avenue to simply go back to it. This is our livelihood, and we depend on some consistency and reliability in our main trading tool while these tweaks are done to the core of the tool.
     
  15. Based on a few backtests, it's not the same model. My T+0 line isn't predicting P&L at all. My black dot spent 85% of the trades under the T+0 by a large margin (not the case prior to the update) and only caught up to the line on large vol days. EIOIO is more accurate than whatever they have going on now. I seem to be profitable even using EIOIO numbers, so I guess I shouldn't mind all that much, but there is definitely a sense of "trading blind". I'd like to trust whichever model I'm using. On my three lot live trade, OV is giving me -15 delta, IB is giving my -7 and ONE is giving me 0. Who to trust?:(
     
  16. Matt, it's perfectly normal for the black dot to not match up with the variable variance T+0 line.
    Yes, when using EIOIO, the black dot will match up, but that T+0 won't give you accurate projections of your greeks compared to variable variance.
     
  17. One thing I've noticed is that the variable model is over-predicting upside on a down move. For example in a butterfly/M3 set-up, I'm short 100 SPX deltas and a 2% pullback predicts a profit of around $4k. However, I'm also short >1000 vega and the prediction would only be correct if I was short /ES futures, not options. The EIOIO model is flat and seems more accurate, i.e., that the vega would offset the deltas. Hoping it's just a temporary blip as I understand the variable model should be more accurate (and is relied on by many who know their stuff).
     
  18. Jeff, there are many advance OV users in this community. Our trades are highly sensitive to IV modeling. Why not suggest to Len to use this community to test out any changes to IV modeling before rolling it out ? I'm sure there'll be many who will be willing to sign up as beta testers.
     
  19. Yeah, I'm seeing the over-prediction of profit as well. When I initiate a trade, the T+0 line is telling me I should already be about a quarter of the way toward my profit target, which is absurd of course. There's also way more gamma/curvature than I would usually see with as many DTE and IV as I'm working with. It's as if the T+0 line has become a T+20 line without being labeled as such.
     
  20. OK, I was forced to play detective and go back to screenshots I happened to still have of positions from ver 7.64 to find out if there truly were differences, because things just didn't look right after the 7.72 update, and sure enough there is still something horribly wrong:

    http://www.evernote.com/l/AAKcymLojiRGY4q5j_GCavHzqtkv6f0UsG4/

    Another trader I'm in contact with found that the 'G/L to include previously realized G/L's' function was not working properly for him, and Len was able to reproduce it (it works for me so far), and Len is currently trying to play detective to fix THAT part of the code as well.

    Jeff, it's time to truly roll back to ver 7.67 or earlier, enough is enough. I have tens of thousands of dollars in positions that I simply can't manage now.
     
  21. We talked about this in our trading group meeting today. Try going to the quotes display, right clicking on the symbol and click the DA button. This will delete the asset file, but it leaves your trades untouched. Then double click on the symbol and OptionVue will rebuild the asset file. This seemed to do the trick for one our members and the Greeks seemed to be what he expected after doing this procedure.

    HTH
     
  22. Thanks Tom,
    It does get your delta closer, but I just want to make it clear that we are still not back to the old model - the T+0 shape and projections (and thus the gamma in some of my positions) are pretty far off, especially on the upside.
     
  23. Jay, not sure what positions you have on but (as I mentioned in another thread on variable vs EIOIO) my deltas are completely thrown off unless I have "small" on the calls as strike preference (on variable model). My current SPX position has +17 on small and minus 58 on moderate/large.
     
  24. I have started deleting my asset files on a regular basis (every day or two) and letting OV rebuild them. I also consistently use temporary files when using Backtrader. My subjective experience is that I have had fewer problems, fewer of the Access Violations, etc. in working this way.
     
  25. Jay, what do you mean by using temporary files when using Backtrader?
     
  26. I found that using the shortcut key to reload prices, Ctrl-T, will often vastly improve the T+0 line, but it will often flip back to a mutant T+0 when I move a time interval in Backtrader, requiring me to reload prices to get it back to proper.

    Before hitting Ctrl-T:
    http://screencast.com/t/tTri8OHqa

    After hitting Ctrl-T, much closer to previous models:
    http://screencast.com/t/vXmKYYTlz
     
  27. My goodness.... how many little tricks we have to learn to get OV to work ? :( Thanx Jay.
     
  28. When you have a backup from an old version. You can restore that version and don't upgrade as long as problems are not resolved.
    I don't know there could be another modelling problem when using an older version. Every day when start OV the first time, it download the daily files.
    Possible in these daily files OV download CEV data and is based on the modelling version 7.72 and not modelled on an older version 7.67.
    Perhaps Jef can give the right answer how this works out?
     
  29. About Implied volatility calculation in the Matrix when using back trader and go back in time.
    See, View, System Models, Interest Rates.
    When going back in time with backtrader Interest Rates remain the same values as today.
    To have the right Implied Volatilities in the matrix,
    adjust these values manually to the interest rates for the dates you test in back trader.

    Example for the month that you test, enter the values of this period.

    It would be great backtrader doing this automatically in a next upgrade.
     
  30. When you start Backtrader, you are given the option to store the historical data in a temporary asset file. See the attached screenshot.

    2015-11-04_10-27-32.png
     
  31. Here are the screen shots from the earlier and current versions.
     
  32. Did you run the older version and it just worked? I found two backups of 7.64, but in both of them after I delete the asset file for RUT, OV fails trying to recreate it, giving a message "Unable to find background data for RUT".
     
  33. I still have 7.66 on an old backup laptop and I just recreated the T Log for the M3. Quite a difference in Greeks and T+0 line for a couple of minutes apart.
     
  34. I have just received an email from OptionVue with a discussion of what has happened over the last few days. (It looks like the email has gone out to all current OV customers.) I found it very helpful in explaining what has happened, as well as containing easily understandable info about how the Vertical Skew works. The tone was also quite good and customer-focused. I would be interested to hear how the more advanced members of this forum perceive the explanations given, especially in light of the claims being made in this thread about differences between 7.72 and the 7.6x versions.

    Jay Hattler
     
  35. Attached is a PDF of the email mentioned above. (I hope I got all the content into the PDF.) I tried to copy and paste the email directly into this forum, but the images don't show up and they are important to understanding the emaill, at least for me. I hope this is helpful to everyone.

    Jay Hattler
     
  36. Thank you for sharing this, Jay. The explanation is good, but I wish someone from OV was more active here on the forum and looked into the reports about the differences between 7.72 and 7.66, like the ones posted by ACS. I wasn't able to get an older version running, but today in 7.72 my November M3 was wobbling between -59 and -100 delta without any appreciable price movement within just a few minutes. At the same time TOS with volatility smile approximation was showing a pretty stable -11 delta.

    What concerns me in Len's letter, and I'm going to send the following to OV, is it appears that he doesn't realize the real significance of the skew model to someone trading a trading plan in which precise values of the greeks (a 10-20 change in delta for a $50K PC position is pretty precise) trigger specific adjustments. If a model is changed so that in the same situation it produces different greeks, the adjustments will be triggered at different times, and possibly the adjustments too will be different. The plan will produce different results, and the results may be better or worse, up to potentially turning the plan into a negative expectancy game. The only way to know for sure is to backtest with the new model, comparing the results with the old backtests.

    An improved model is nice--presumably it would produce the t+0 line even more predictive of the reality--but it doesn't mean it will necessarily improve the performance of a specific trading plan built for the old model. It's as if a stock charting package suddenly replaced the formula for, say, the RSI indicator with something that's supposedly better, but completely replaces the original RSI.

    Which all means, the core issue here is not more extensive beta testing to ensure the software is "stable and bug free". It's that the current model behavior--albeit not perfect--is depended upon and must not be changed freely and without notice. It doesn't matter that the change is an improvement. Ideally, the older model(s) should still be available as an option. If not, the main purpose of beta testing with customers it to let them verify that the new model doesn't break their strategies and give a green light for setting the changes in stone.
     
  37. Thanx Jay. I wonder why I did not receive this email from Optionvue. I seriously think they should be much more proactive in making use of community like this one to gather feedback as well as address issues. Nowadays companies spend millions of marketing dollars just to get access to community of customers and opinion leaders. Access to this community is free. Not sure why OV is not more proactive in leveraging this channel. Someone should send this message to Len.
     
  38. Kevin, I never recieved the mail either, have written to OV about this so I assume they'll be updating their mailing list.
    The mail confirms what I'd observed, the call settings on autostrike "small" vs "moderate/large" are a major issue in the large delta variations. My all-put positions are ok (rhino) and only display marked position delta variations in 2 settings:- EIOIO vs variable model (e.g., minus 50 vs minus 100 repsecitvley). Where there are calls (M3, Kevlar) the large variations in positon delta are dependent upon one additional setting, the autostrike input.

    Am new to OV and still not sure if the advantage of the variable model vs. EIOIO is more in relation to dynamic greeks, i.e., where they'll go with underlying price changes, or if it's also more accurate with static greeks, i.e, where they are currently.
     
  39. OV IS NOT FIXED
    Contrary to the letter from Len, OV is NOT fixed. Jim and Len appear to have an entrenched position they are defending for some reason instead of deferring to users, who are the ones on the front lines and are the ones who have intimate knowledge of the previous model in relation to their strategies (sometimes built from hundreds of hours of backtesting and live trading).

    Capt Hobbes is right, it's not about adding refinements on top of the model to make it 'better'. As I told Ken Dole on the phone after the ver 7.65 modelling problem a few months ago, if any new model is introduced, we NEED time verify the changes to the model and analyze how they affect our finely tuned strategies. At the very least this means allowing us to run previous versions with the previous model, so we can run them side-by-side for awhile. So what did they do? They attached a change to the core modeling function to a Mandatory Upgrade (because of a server side change due to another change they made in the release) - NOT the time to do that.

    Getting back to the continuing modelling differences, I won't run on in this post, I'll just share an Evernote note:

    http://www.evernote.com/l/AAJDRbVuZzREp4cFfk-lq9WQl6tRptn_lZc/
     
  40. Looks like the first public beta for CEV modeling in the ONE software has been made available in the last couple of days. Perhaps this will eventually offer more alternatives and also prompt a healthy competition and attention to customer concerns across vendors. I believe some of the more advanced users in this forum have been involved in this (Kevin? Ron? Sorry, can't remember who). Perhaps Tom could have Andy come on a session to discuss.
    2015-11-05_10-00-05.png
     
  41. 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.
     
  42. 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.
     
  43. 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.
     
  44. 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?
     
  45. 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.
     
  46. I did a comparison, here you are. 7.67 against 7.72:
    767.jpg 772.jpg
    Not exactly the same, it seems...
     
  47. 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.
     
  48. 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.
     
  49.  
  50. Excellent video. Thanks Will for posting it!
     
  51. 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.
     
  52. 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
     
  53. 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
     
  54. 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. :(
     
  55. 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.
     
  56. 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!
     
  57. 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.
     
  58. 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:
     
  59. 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)
     
  60. Correct.
    Bad curve fit = bad projected IV = bad greeks and T+X lines
     
  61. John Locke's 11/19/15 comments on the current software modelling landscape (posted with permission from John):

    Essentially, the deal with OptionVue is as follows:
    .
    There have been 3 recent changes that I know of, a data provider change, a model update that was done a few months ago that had to be reversed and the most recent one that had to be reversed.
    .
    .
    Since the data change and the earlier update and subsequent reversion I have noticed larger than normal Delta fluctuations and larger than normal P/L fluctuations when using Quote View. From my understanding this has always been an issue with TOS and IB feeds.
    .
    I don™t know what happened for sure but my belief is that this issue is due to very slow updating of far from the money options.
    OV says that is not possible as the new data provider is supposed to be faster than the previous one however I disagree. This is because I™ve noticed some of my options have been taking up to 5 minutes to update and Id think that I would have noticed it by now since Ive been doing the same thing for nearly 10 years.
    .
    This slow updating can throw the Greeks around quite a bit and if those options are deeper ITM then that makes for drastic P/L changes when the underlying moves and the option price does not update on that option. Think about it if you have just one 100 Delta option and RUT moves 10 points, the value of the option will change $1000. If the price in the matrix on that option is delayed then you p/l will be way off. The same phenomenon with higher Gamma options.
    .
    Despite these fluctuations however the T+0 line and Greeks numbers seemed to be reasonably the same as they always have been.
    .
    .
    Since the second update and subsequent reversion, the T+0 line and Greeks numbers have been proven to be significantly different than the previous versions. In addition, the fluctuations appear to have increased as well.
    .
    OptionVue'™s position is that they know there is a problem but they are unwilling to correct it as they are determined to a new model change. Therefore the previous model that worked so well is likely gone forever.
    .
    The model change in question is designed to make the software much more closely match the actual IV points on the options. Since the EIOIO model and TOS models are the actual IV points on the options, my best guess would be we're going to end up with something very similar to TOS and EIOIO models.
    .
    If this is the case, we will deal with it and make corrections to guidelines as needed.
    .
    The reality is the systems we trade will work in a similar fashion with the current guidelines on TOS/EIOIO models 85% of the time. Its the 15% or the time where the TOS model really breaks down where there is an issue. And that™s only an issue if the market keeps going in the same direction.
    .
    For now I™d suggest the following:
    .
    The EIOIO model and TOS handle OTM options much better than ITM options. The ITM put options are in particular problem for EIOIO projections of the price moving higher. Therefore I™d suggest that we do what we can to keep as many put options OTM as possible.
    .
    This means iron butterflies for the M3, BB and ROCK trades for the purposes of modeling and more stable T+0 and Greeks numbers..
    .
    Regarding the Greeks numbers. The variable settling is currently showing too negative Delta and is projecting too much sag¦ IN THE FRONT OF THE POSITION. The EIOIO is showing too positive Delta and not enough sag ¦ IN THE FRONT OF THE POSITION.
    .
    In contrast the EIOIO settling is currently showing too negative Delta (starting approximately) BEHIND THE SHORT STRIKES. The variable is showing too negative Delta AHEAD OF THE SHORT STRIKES. Once the short strikes are exceeded by 10 points the variable appears to be most representative of reality.
    .
    Therefore I am analyzing both positions and using the average numbers between the models weighted to where I am in the position. Its a bit subjective but is better than using either one over the other.
    .
    I do recommend keeping the matrix strike extents on large while doing this¦. at this time.
    .
    **In OV I suggest keeping the call/put skews on in the variable model and off in the EIEIO model WHEN USING IRON BUTTERFLIES ONLY
    .
    Once we see what we have with the new OV model, we can be more specific with recommendations.
    .
    In addition ONE is working on improving their model so I am keeping up to date with their progress and may have recommendation there as well.
    .
    Feel free to share this statement in other groups and please keep me updated with any feedback you guys have.
    .
    Thank you.
    .
    John
     
  62. No mention of TOS "volatility smile approximation" by John Locke ??
    In my opinion, it gives the most reliable greek projections at the moment.
     
  63. Ok, let's recap John Locke's suggestions for people choosing to continue using OptionVue:

    1) Stop using put BWBs and use irons instead

    2) Look at your greeks with both EIOIO and Variable Variance, and then calculate the average of the two in order to get a reasonable estimation of the "true greeks"

    3) Keep all extents set to Large (even though OptionVue have shown that doing so with the current version produces inaccurate best fit curves and therefore throws off the greeks)

    4) keep the "combine call/put skew" enabled when using Variable Variance, and turn that option off when using EIOIO......but only if you're using iron butterflies


    Now here's my suggestion:

    1) use TOS "volatility smile approximation" for greeks and TOS "individual implied volatility" for current P&L

    That's it.
     
  64. Ron,
    For some reason your suggestion seems simpler.:)

    John advised his members to avoid using Volatility Smile in one of his weekly update videos. I forget his exact words but it was something along the lines of it was too much work and/or too confusing. It is actually dead simple after one gets used to it.
     
  65. John Locke has a pretty unshakable belief that combining call/put skew is critical.
    I've had discussions on this topic with him, and I explained my viewpoint in terms of various technical (options theory) reasons as to why it made little sense to combine the skews.
    Note also that everyone at OptionVue has always recommended turning off the "combine call/put skew" setting when trading the major indexes.
    John didn't argue with any of the points that I had listed......yet he said that his own personal testing, as well as that of some of his students, had found that combining call/put skew gave slightly more accurate results.
    My personal tests found the opposite; my tests found more accurate results by having that feature turned off, as is recommended by OptionVue staff and developers.
    So we had to agree to disagree on this topic.

    I wouldn't be surprised if John's reluctance to use TOS is based on the fact that it doesn't have the ability to combine call/put skews.

    So I would strongly encourage each of you to test it out for yourselves.
    Use the TOS "volatility smile approximation" for your greeks and "individual implied volatility" for your current P&L, and then compare it to:
    a) reality (ie check your new P&L after a price move and see if it matches with what was predicted)
    b) your current trading platform (eg OptionVue, etc)

    After tracking your live positions in both for a week or two, you should be able to make the determination of which is more accurate.

    I've already been doing the above with my trades (which are John Locke style), and I've found that TOS vol smile is currently giving me equal or more accurate greek projections than anything else.

    I refuse to continue paying for software where we have to do half a dozen manual steps in order to get viable greeks.
    I've also had many frustrations with many ongoing bugs in the OptionVue software, so this current issue was the last straw for me.
    I used to think that even though I had all of these frustrations, there was simply no choice other than OptionVue for realistic greeks.
    Now I'm perfectly happy using TOS vol smile to manage the greeks of my live positions, and I use Optionet Explorer (beta) for backtesting and for easily testing potential adjustments to my live positions.
     
  66. Thanks for the info Jay.

    As Ron points out, using large only compounds the issue.

    Quote:- "**In OV I suggest keeping the call/put skews on in the variable model and off in the EIEIO model WHEN USING IRON BUTTERFLIES ONLY"

    My understanding was that the EIOIO model didn´t create a skew curve, as the acronym makes clear it´s just each option on it´s own. So don´t understand what difference ticking the combined put/call skew curve makes in that model.
     
  67. Ron,
    I think Vol Smile is a good idea for now.
    I have an old version of OV working over here (don't ask me how), and I can confirm that it's greeks (as well as it's risk graph) line up pretty darn well with TOS vol smile, at least on a standard 50pt Jan put butterfly.
    OV:
    upload_2015-11-19_19-9-19.png
    TOS:
    upload_2015-11-19_19-9-40.png

    OV:
    upload_2015-11-19_19-27-7.png
    TOS:
    upload_2015-11-19_19-27-36.png
     
  68. Great points Ron and who knows TOS vol smile may come out as the "winner". I have also been following all my trades in TOS and I agree it seems to be pretty accurate.
    Why I would hesitate to jump off the OV train just yet and blindly follow TOS is simply fact that all my JL trades have been backtested in OV with JL guidelines in multiple market environments. Since we have the vol smile feature on in TOS what has happened in the market? Some panic sure but nothing to in either direction to hit home about. I also think John will not be too excited about a product where he can not have years and years of backtests that can prove it is accurate....for the size he is trading I would fully understand that hesitation.
     
  69. All very good good comments regarding the various option analytics, unfortunately for those of us in Europe (UK) our choices are limited to OV or ONE. I used to trade with ONE but dumped it for OV due to its relatively limited analytics. Both are quite poor in terms of datafeed from IB, although that may be due to IB's data restrictions which they apply to all their products, but given the nature of options is particularly more noticeable.
    So, I guess, as I have no plans to emigrate to the US, I'm stuck with very limited options & will have to adapt my strategies to take into consideration the poor analytics available.
    Also John's suggestion to use Irons instead of regular fly's doesn't help with the traders with an IB acct, unless your on portfolio margin, as the margin requirements in IB for Irons is very punitive. So far using Brian's Rhino trade concepts appears to work despite the greeks being all over the place as long as you monitor the separate components of the trade, that is the, put fly component, call calendar or call fly components, once you start applying vertical to the fly components, then the greeks matter, however, I just normally look at the risk graph to get a feel for what my risk really is, not ideal, but like I said my choices are limited.:(
     
  70. Are you sure about that? The risk for all Put or Iron BF (same strikes) is identical.
     
  71. Ron, would this also apply to the new ONE modeling? I've not seen much of an effect checking the Combine Call/Put box.
     
  72. As the Irons are uneven, IB will charge a margin for both sides of the legs, this has always been their policy, so if you do a JL style M3 and start out with an Iron fly, normal margin, the moment you apply verticals and end up with unevens, your margin goes up significantly. Unless they have changed the margin policies, which I doubt.
     
  73. Hans, I don't ever recommend using "combine call/put skew" for the major indexes.
    The only reason you're seeing that config option within Optionet Explorer is that Andy is trying to cater to all of the John Locke traders, who believe that this is important.

    In ONE beta, you can see that I'm currently using all of the config options except for "combine call/put skew":
    ONE-beta-options.jpg
     
  74. Once the new version of Optionet Explorer comes out, you'll should have the ability to dump OptionVue, if you choose.
    I'm currently tracking my live trades with the ONE beta, and the greeks look quite good.
     
  75. That's great news! I am also very dissappointed with the reluctance of the OptionVue people to provide a modern software instead of this anachronistic mess looking like a relic from Windows 95 times with a horrible user experience... I believe no one would be willing to pay the monthly charges if there was an technically up-to-date alternative with equal modelling capabilities. I think they got too used to having the monopoly.
     
  76. Ron I see that in your ONE screenshot you have a cog wheel by CEV, in the beta version I have a value "0.70" by CEV (no cog wheel). Are you testing out a more up to date Beta that is not out yet?

    Thanks
     
  77. Yes, Al.
    I'm on a newer private beta, version 1.27.13 beta.
     
  78. I have not been able to find any write-ups on how TOS Volatility Smile works, does anyone know how it takes CEV into account? Is it a static CEV figure (similar to the current ONE beta) or does it take different CEV for different time frames (Horizontal Skew)?

    Thanks
     
  79. Ron,
    Thanks heaps (as you Aussies like to say) for your diligent work on this issue; you have made a huge contribution to the Capital Discussions community on this important topic. Until you pointed it out in one of the trading group 2 sessions, I was not aware of the "volatility smile approximation" option in TOS. Per your suggestion, I have been testing it for the past week or so on Locke-style trades and I agree with your conclusions: it seems to work pretty darn well so far. I am also very happy that you are working closely with Andy on beta versions of ONE to address this issue. I have been quite content with ONE for the past four years, and I only started using OptionVue a few months ago when I started trading John Locke's M3 and Bearish Butterfly. However, I find the user interface to be a bit cumbersome, and a throw back to the early 1990s, as others have pointed out in this discussion thread. The user interface in ONE is much more intuitive and aesthetically pleasing, so now that it appears that a future release version of ONE will have more "accurate" greeks, I will stay with ONE and will likely cancel my OV subscription. So all I can add is: "good on ya, mate!"
     
  80. I´m another European who is stuck with OV at the moment. If anyone with ONE and/or TOS using vol. smile can be bothered I´d really appreciate it if you could let me know what position delta you get a current SPX position I have, a Jan iron BWB. I get minus 38 on EIOIO, minus 68 with variable and call extent set to small, minus 77 on moderate and minus 191 on large. That´s notional exposure of approx. $80k, $140k, $160k and $380k respectively. Not optimal for risk management :(. This is the position:-
     
  81. Ron,
    Just wondering are there any beta testing protocols for ONE that you and some of the others are going through and if yes would you mind sharing what this includes.
    I assume it is not only looking at a current live trade and checking it against TOS VSA or OV new settings.
    As said earlier huge thanks for the contribution to make ONE better, I am eagerly waiting for the possibility to migrate.
     
  82. Any word on when ONE may release this new update that will be sufficient for the Locke type trades?
     
  83. David,
    Using ONE Beta version 1.27.12 with settings as Ron recommends above (CEV, Volatility Surface, Smooth, Best Fit all checked; Combine Cal/Put NOT checked) I get the following greeks: delta = -44.60, gamma = -0.53, theta = 153.84, vega = -892.85.
     
  84. No idea.
    The developer wants to make sure that the public release of the next version is solid.
    He is therefore making sure that the testing of the various betas is thorough.
    Hopefully it won't be too long....
     
  85. The crew that make ONE are currently also working on an automated backtesting tool.
    This is now in the late alpha stages.
    Jay Winger and I are on the short list of people who will be assisting with the testing of the private betas of this product, which should hopefully be made available within the next month or two.
    Note that this will be a separately sold product, so if you already own ONE then don't expect that you will get this for free.
    ONE will have some buttons within the program which will launch the backtesting tool, but the backtesting product will be sold separately.
     
  86. Ron is the latest beta you are testing close to TOS volatlity Smile? Also, does TOS utilize CEV?

    Thanks
     
  87. Thanks a lot Paul, very good to have that comparison and confirms what I´d suspected.
     
  88. Yes, the greeks in ONE are very close to the TOS volatility smile.
    Note that the public beta version has everything you need in terms of matching up to the TOS vol smile.

    I have no idea about the nuances of what TOS vol smile is using internally to make their calculations.
    All I know is that the greek projections are quite accurate.

    Last week, one of my positions showed a delta of around -10 in TOS vol smile, yet the ONE beta was saying that I was flat (delta of around -0.5).
    We then had a bit of an up move, and my overall P&L went down a bit.
    This may have been a hint that the TOS vol smile greeks were slightly more accurate than what ONE was showing at the time.

    Overall, TOS vol smile and OptionVue and ONE beta are now all fairly similar with the greeks.
    This, plus my many prior and existing frustrations with OptionVue, not to mention the absolutely terrible way they are currently handling the current problems, was enough for me to cancel my subscription with OptionVue.

    I'm now in the process of testing TOS vol smile to ONE, but I plan to keep my subscription to ONE for backtesting as well as for quickly modelling morphs to my live positions.
     
  89. If any OV users out there would like to try a copy of OV 7.64 that I have which works on live data (and on backtrader data with one extra step), email me at jcwing01@gmail.com. I have the folder structure zipped, and it has worked for others. There is no reason we should be in this situation, but if OV won't take any immediate measures to help traders, we can at least help eachother.

    Andy @ ONE is working hard every day to improve the model. The best way to speed up the ETA on the final release is for traders to submit to him systematic studies or backtesting, with observations, to help him fix any issues in the existing model.
     
  90.  
  91. Looking at my Dec M3 right now, OV variable, will give me a delta of -95, OV EIOIO -50, TOS VSA -58 and ONE will give me -29 (doesn't really matter what options are checked).
    TOS seems to be sitting nicely in the middle maybe the most accurate.
     
  92. Great, thanks for the TOS data Paul, of course may depend on price in relation to butterfly but the deltas on my position are in line with what GaborMaly has, OV variable has the highest negative deltas, then TOS VS & OV EIOIO whilst ONE has the lowest. Watching the price action in relation to my positions and EIOIO is most accurate on OV so appears the middle values are reasonable.
     
  93. Screen Shot 2015-11-23 at 22.44.17.png Given that there´s no golden standard to benchmark the various models against and the only non-theroertical input any model has to work on is price, I´ve compared the price of my current Jan SPX position (the one in figure was rolled up today) with the actual price of the same position at Dec expiry over multiple SPX moves then looked at the estimate the EIOIO vs the variable model provide for the equivalent price moves using the analyse tab (as in figure).

    Without a doubt the variable is much closer, EIOIO is way off (e.g., actual price difference between months for a 25 point drop is $13k, variable model prediction $10k, EIOIO $5k). Of course vega would come into it but isn´t relevant for this exercise (actually favours the variable model values if it was taken into account).

    So I stand 100% corrected regarding my empirical day-to-day observation on price movement and EIOIO vs variable, the deltas on the latter appears much more accurate (didn´t see difference for theta that could explain difference).
     
  94. Ron, and others,
    I have OptionVue now, and have had ONE in the past. What is the price point that ONE will end up charging for a year approximately? OptionVue is offering a deal if we add on to our subscription so I have to decide whether to stay with it or switch back to ONE again. I really had decided just to let me OptionVue subscription lapse this June, but the thing is besides from back testing, I'm kind of lazy so I track all my trades etc in OptionVue and keep track of total return etc. In other words an expensive P/L tracking mechanism
    :)
     
  95. 500 GBP per year, or 150 GBP per 3 months
    http://www.optionnetexplorer.com/Pricing.aspx

    There's also a free 1 month trial.
     
  96. I am really tired of OV and their attitude towards their clients. If we are, as a community, going to spend any time and effort on beta testing and analysis, why not offer our collective wisdom to Andy (at ONE) instead of trying to convince OV that there is actually a problem?

    I think having Andy as a guest is a great idea.
     
  97. Having Andy from ONE on a cap discussions session is a real good idea Andrei
     
  98. Hey guys, another question/thought
    Have you all been using quotevue in optionvue, or another source like tos or ib?
    I have found difference in the past
    ditto same thought/question regarding ONE also
    after all as the old saying goes, garbage in garbage out
     
  99. I can ask Andy if he'd like to be a guest.

    I use IB quotes with OV. It's not bad but it can take a few minutes to fill up the SPX or RUT matrix so I leave them open. Len pointed out a problem in that not all of the data gets refreshed at the same time, so your greeks are using some data that is a bit older than other data. The best data I've used is eSignal but it's a bit pricey at over $200/month for option quotes.
     
  100. Know your customers, OV users hate the user interface, yet they focus on the model which until now was their strength i.e. work on make the user experience better not the nuts and bolts in the background. ONE the UI is nice, but the model needs work, so this is what they are investing in. Simple as that!