Home > Main Forums > Round Table Presentations > Trading Group 2 - March 14, 2017

Trading Group 2 - March 14, 2017

  1. Paul Demers had a very nice presentation of his real time excel butterfly analyzer risk graph
    I was wondering how difficult it would be for someone to build something similar ?
    Also how much hard drive space does all that data collected take up ?
    This a,most good enough if not even better than ONE or OV
    I wonder if that would be for sale how much it would cost ?
  2. status1, I think it will be pretty expensive as you have to by also Paul's time to set it up and customize for you.
    To build it up is not _that_ hard*) just you need to know exactly what you want. Requires time...

    As per being better than ONE/OV I'd say it depends.ONE/OV are good way to get feeling of new trade not so good for extensive back-testing. I cant force myself to sit in front of monitor and click for few hours straight, that's why I'm working on my system. As I said, it is not too hard*) just requires time. Especially when you build it for yourself you don't have to worry about whole GUI.

    Try to get some data and start playing with Excel and VBA (youtube is your friend) - if you have time and if you want to go this way : )

    *) I'm taking about simple data manipulation. If you want go into building/improving models it is different story and I'm not the one to talk to.
  3. It does take a lot of work. I'd imagine it was a struggle learning SQL. I have MS SQL installed on my computer. I have not used it for a few years, so I'm kind of rusty at writing the code. Not easy and I would start with something small first.

    For now, I back test hard on ONE.

    One thing I found useful was trying to read the price action to see when to get in and out of trades. If the price action is wrong, it doesn't really matter what setup you are in with your option strategy. I had one trade that took a few months to make small profit. But reflecting upon the price action,l it would have better to just sit it out and wait for the setup.
  4. Easy if it's a hobby you find fun and rewarding ... otherwise you will probably curse yourself for even beginning.

    A max number would be LiveVol 1-minute data from 2004 - present ... that's 1-2 terabytes depending on how you save it and store it. Any other underlying (RUT, etc.) would only be a fraction. If you only want 5-minute resolution or less then storage would not be an issue on any modern hard drive.

    Doing a risk graph to replace OVue/ONE/TOS is probably the easiest thing out of all the basic stuff you would want once you had a handle on the data ... but keep in mind that most of us will want the skew-adjusted greeks, which opens up an area of moderate difficulty beyond just banging away with Black-Scholes. I believe I've heard Paul say that he doesn't care about the skew-adjusted greeks (Riggio also), which is 100% fine for an experienced trader who knows exactly what he or she is doing ... personally, I depend on skew-adjusted because I know mine are significantly more accurate while doing no harm.

    With no support ... you could probably get someone to give it away for free. With full support ... I'll set you up with my entire system $1/year for the software license & all source code, plus $500,000/year for support, 1-year minimum paid in advance.
  5. Thanks for all the replies
    This would be a hobby for me but also a challenge to see if I can do it
    5 minute or less would be fine for me as a start as I definitely don't have anywhere near one terabyte
    I would probably only use it on SPX and /or RUT
    Is there anyone out there who is offering this for free with no support ?
    I just want to have an idea of how it's done just to get the basic principles and formulas and see if I really want to dive into this

    A couple years ago I was messing with the Black Scholes formula to calculate the greeks (actually just the delta) but for some reason I could never get the results to match what is shown in TOS I am not sure if I was missing something from the formula or it does not work in reality
    I was just using some examples I found on the internet and I would get the results shown on the internet for that example but if I then substitute the underlying with an SPX strike price and a real expiration the numbers would be way off
    so I pretty much gave up after that
  6. Just start small.
    I would argue that you don't have to be anywhere close to 1 min data. EOD should be enough - depends on what you trade.
    Good luck!
  7. Were you calculating Greeks on stocks or indicies? Early exercise feature of american style options can throw off calcualtions. TOS uses Bjerksund-Stensland model for American style options.
    If it is difficult to build some type of VBA macro, then i would suggest http://www.hoadley.net/options/options.htm. It has lot of built in feature to build your own spread sheet. It can do lot more than just options. Especially it is powerful for portfolio finance.
  8. I was planing to start with the SPX so that would be the European model but looking in TOS I don't see any difference between the Bjerksund-Stensland model and the Black Scholes model as far as the greeks and the p/l is concerned

    One of the variable I am not sure about is the Risk free rate value
    A lot of examples are using 4% and I saw one was using 8% so I know that is wrong but what is the right value or where do I get that from ? Do I use the current interest rate 0.75% , the 30 year bond rate, something else ?

    The other variable is the volatility
    A lot of examples are using 30% While I know that number is high I am not sure what is the right number and where to get it from

    I looked at Hoadly a while back but for some reason I did not like it and it does not show the formula so I can't learn too much from it
  9. You should attempt to quantify the level of accuracy/precision you require/desire. If you don't care about accuracy, you may be able to get by with picking some constant for interest rates. However, if you desire accuracy, you need to consider and deal with the details. There are a number of moving parts if you want accuracy. Steve S has produced papers on this which are a good place to start. -- For interest rates from a couple weeks to about 6 months DTE, the like duration LIBOR rates from the FED are a reasonable approximation if you don't mind a tiny bit of error. -- Like most things this is a Garbage In Garbage Out if you supply Garbage as the input!
  10. They won't use Bj-St for European options ... also, anyone using Bj-St for American options be careful; there are three versions and only the third is reasonably accurate ... most platforms will probably use the first because it is the only fast one, but it sucks pretty bad for accuracy. Always compare to a well-programmed binomial model so you know the expected errors.

    Ok you are really starting at the beginning here. If you're not completely clear on rates, yields/PVDivs and vol as Black-Scholes parameters then you need to stop, get yourself a good Black-Scholes calculator with implied vol calculator, and get comfortable with the model. In regards to data, you should probably forget about historical data for now and just start with collecting and processing some TOS chains (after you get comfortable with your Black-Scholes calculator). You can get tons of help from lots of folks here - start some private conversations. I can help with most topics if you want incredibly lengthy, boring, detailed and analytically correct assistance.
  11. I agree with Steve and garyw. You need to be sure about the input, before you proceed. For interest rates, I would use implied finance rate from here or you could use Libor also as quick approximation

    If you are using Black scholes, Hoadley function input's are same as any B/S calculator. He has verified his other functions with several papers.
  12. Yes I understand I am at the beginning that's why I have a few questions
    At this point I am just looking for a model (any model) that I can use to get somewhere near the ballpark of the call and put prices shown in TOS
    Having a good Black Scholes calculator would be great but I haven't found one yet that works with SPX
    Even if I find one I still would need to know what to use for the risk free rate and volatility

    Now having said that even with the known values for those I still can't get the right call and put values for SPX
    In the example I found on the internet it shows a calculation for a $62 stock with a $60 strike price and I got the same result as shown with the calculation $3.72 for the call but if I leave everything the same and just change the stock price with the SPX price 2378 and the strike price to 2370 I get about $100 for the call price while TOS is showing about $26 for 40DTE
    At that value changing the volatility from 70 to 10 makes no difference on the value of the call and changing the risk free rate from 4 to 0 only brings the value down to $94 even if I bring the DTE to 0 the value of the call is still $94

    So obviously there is something wrong there
    Either I am missing some small variable in the formula or maybe that formula does not work on high priced stocks or indexes
  13. You are probably making this too complicated ... basic Black-scholes for European options is very simple, it always "works" ... exact rates are not very important for < 3 months DTE so long as you are in the ballpark (1% - 1.5% right now). Yields/PVDivs are more important, but still not a big issue so long as you are in the ballpark (SPX yield around 1.9% right now). Decently correct forwards ARE important ... if you're not on top of this then you need to be. Volatility is very important ... you need that implied vol calculator if you want to work with real data, although for a start you can use the lousy TOS, OVue or ONE vols (or the much better IB TWS vols).

    If you want to post your Black-Scholes code in a spreadsheet then I will check it for basic correctness ...
  14. I got the formula from this video

    So using the data in the video I got the correct result so the formula seems to be correct but for some reason I can't get anywhere near the values shown in TOS when I substitute for SPX
    If you can tell me if the formula is correct or not that would be a great help
  15. Without looking at the video, I'm virtually certain THEIR formula is correct ... the relevant thing is whether or not YOUR version is correct ... if your code is in some "old fogey" language like C, C++, .NET, VBA or Excel worksheet formulas then great ... if it's in one of these "young people" languages like Python/R/Ruby/Perl then I'll do the best I can ...

    P.S. If you're matching their numbers then it's more likely you have some issue with interpretation of parameters ... can help with that if you give an example or two.
  16. One observation I made of the video is the narrator rounded d1 and d2 so he could look them up in a normal CDF table. That alone introduced a noticeable error.
    My own C functions don't have to round anything because normal CDF is calculated directly with no table.
    Here are his inputs:
    S = 62
    K = 60
    r = 0.04
    v = 0.32
    T = 40.0 / 365.0
    His calculated option prices:
    Call: 3.72
    Put: 1.46

    My results using my functions with the same inputs:
    Call: 3.85895
    Put: 1.59651
  17. Thanks STEVEGEE58
    You could be right about the D1 and D2 They are very sensitive to minor changes
    I did the calculations with and without the rounding and I got those similar results but it still does not explain (I don't think) the big difference in the SPX values although that could be where my problem is
    I have to look up the D1 and D2 values using the SPX calculations and see if that makes a difference
    I was wondering what do you get for d1 and d2 when you substitute for the current SPX value ?
  18. I just tested my BS pricing function with live data and it agreed with IB.

    SPX: 2344.66
    Strike: 2340
    Risk-free rate: 0.5%
    Volatility (IV for 2340 strike): 10%
    DTE: 29 days

    My calculated call price: 29.2
    IB call price (mid): 29.0
  19. Possibly part of your trouble: I glanced at that video and it looked like they were not talking about the yield parameter at all ... the no-yield formula will work fine for SPX (in fact, it's "more correct" than the yield formula), but you have to input SPX - PVDiv for the price, not SPX. If you don't want to estimate the PVDivs then you need the formula with yield.
  20. Thanks Stevegee58 for the values
    I will go over the d1 and d2 calculations again and see if I missed anything

    Steve S ---- Can you tell me what does the PVDiv stand for and how is that used in the formula or is this a different formula you are referring to ?
  21. Keep in mind: Everything we are talking about is simple, easy, plain old Black-Scholes formula ...

    The PVDiv for a given trading date and expiration is the present value of the dividends that will go ex-dividend between now and expiration. Professionals price index options using the PVDiv model, where they know the PVDivs very precisely and the Black-Scholes yield parameter is zero because all the yield is in the PVDiv.

    The naive or "easy" model is the yield model where you just take a stab at the true PVDivs by inputting a yield number, which right now is about 1.9% - 2% for SPX. With this model you get "bad" pricing (because yields are lumpy, not constant) and "wrong" deltas (more complex to explain that), but it's not a big deal for retail traders.

    At your level, your best bet is to get going with the yield model since that will teach you the most while getting your numbers right ... but if you really just want to use Black-Scholes with rate and no yield then just set yield = 0 and "manufacture" your PVDivs according to this formula:

    PVDiv_fake = SPX * [1 - Exp(-YT)]

    Where Y = yield and T = DTE.
  22. PVDiv = present value of Dividends. I'll let Steve S fill in the gaps but generally speaking, you need to adjust the spot index price for the dividends that the index constituents will pay between now and the expiration date of the option. This can be done by inputting a constant dividend yield into the formula (good for approximations) or explicitly calculating the discreet dividends and calculating the PVDiv. See snippet from Wikipedia below:


    Extensions of the model[edit]

    The above model can be extended for variable (but deterministic) rates and volatilities. The model may also be used to value European options on instruments paying dividends. In this case, closed-form solutions are available if the dividend is a known proportion of the stock price. American options and options on stocks paying a known cash dividend (in the short term, more realistic than a proportional dividend) are more difficult to value, and a choice of solution techniques is available (for example lattices and grids).
    Instruments paying continuous yield dividends[edit]

    For options on indices, it is reasonable to make the simplifying assumption that dividends are paid continuously, and that the dividend amount is proportional to the level of the index.
    The dividend payment paid over the time period {\displaystyle [t,t+dt]}[​IMG] is then modelled as
    {\displaystyle qS_{t}\,dt}[​IMG]
    for some constant {\displaystyle q}[​IMG] (the dividend yield).
    Under this formulation the arbitrage-free price implied by the BlackÔÇôScholes model can be shown to be
    {\displaystyle C(S_{t},t)=e^{-r(T-t)}[FN(d_{1})-KN(d_{2})]\,}[​IMG]
    {\displaystyle P(S_{t},t)=e^{-r(T-t)}[KN(-d_{2})-FN(-d_{1})]\,}[​IMG]
    where now
    {\displaystyle F=S_{t}e^{(r-q)(T-t)}\,}[​IMG]
    is the modified forward price that occurs in the terms {\displaystyle d_{1},d_{2}}[​IMG]:
    {\displaystyle d_{1}={\frac {1}{\sigma {\sqrt {T-t}}}}\left[\ln \left({\frac {S_{t}}{K}}\right)+(r-q+{\frac {1}{2}}\sigma ^{2})(T-t)\right]}[​IMG]
    {\displaystyle d_{2}=d_{1}-\sigma {\sqrt {T-t}}={\frac {1}{\sigma {\sqrt {T-t}}}}\left[\ln \left({\frac {S_{t}}{K}}\right)+(r-q-{\frac {1}{2}}\sigma ^{2})(T-t)\right]}[​IMG]
  23. Good post Andrew, except we're trying to keep status1's head from exploding. I'm thinking it's very possible that the whole problem is that status1's formula leaves out the yield parameter ... can somebody just post the dad-blasted general Black-Scholes formula?
  24. upload_2017-3-22_21-18-20.png
  25. I like this topic.
    Thanks status1 for bringing it up and thanks to all participants.
  26. Thanks again for all the replies
    Does SPX pay dividends ?
    I know the SPY pays dividends but I haven't heard the SPX specifically paying dividends at least in TOS it shows N/A for the dividend yield
    That's another thing I have not used in the formula since I did not know the SPX pays dividends
    Where do I get this dividend ? is this published somewhere ?
    Do I use the SPY dividend as a substitute which is 1.77% according to TOS

    I have to back and recalculate but I think the main problem was the rounding off of the d1 and d2 which has a very big influence on the final result Just going from 0.4 to 0.3 it cuts the final result by almost half
  27. The dividends are the ones paid by the 500 constituent stocks; the PVDiv calculation is like the SPX calculation with weights and divisor. SPY dividend is better than nothing and close enough to start with, or look up S&P500 yield on Google. Believe me, if you don't include the dividends your Black Scholes numbers will be junk except for very short DTEs.
  28. Here is my calculated price
    It's getting better but still not quite there yet

    SPX: 2343.98
    Strike: 2340
    Risk-free rate: 0.5%
    Volatility (IV for 2340 strike): 9.95%
    DTE: 26 days
    My calculated call price: 27.29
    TOS call price (mid): 23.15

    For some reason the put price is further away
    My calculated price is 22.47 while TOS shows it as 32.0
    I know the dividend is not factored in but I would have to use about 8% dividend to make the put and the call about 3 points away from the TOS price but I think that dividend is too high so I am thinking TOS has something else factored in
    At least it was a good exercise for me on the formula
  29. It looks like your formula is correct (but you need a more realistic rate and you need the dividend yield) but you're not synchronized with the TOS data. Why don't you practice on the April chain on the attached spreadsheet. If you use the exact numbers on the spreadsheet for SPX, days, rate, yield, vol (that is, if you include all decimal places) then your prices will agree with the market mids on the spreadsheet to at least 12 decimal places. Even if you don't use full precision you can easily get very close. If your formula works for all the options in this chain then it is very likely 100% correct ... then you can tackle the more difficult problem of figuring out the lousy TOS data.
  30. You are correct I need more realistic values for the variables
    Thanks for the spreadsheet I will play around with it over the weekend
    Do you have the put values also by any chance ?
    I want to see how those compare to the results

    Actually looking back now at the numbers that 27.29 was actually the call price while the 23.15 was the put price in TOS so with the TOS price of 32 the numbers are a little closer than it looked earlier
  31. Steve, can you elaborate a bit on above.
  32. The spreadsheet included samples for both puts and calls (calls near the bottom) ... if you want to check your formula for puts versus calls at the same strike then all you need to do is verify it satisfies the parity formula:

    C - P = Exp(-RT) * (F - X)

    Where F = Exp(RT) * (SPX - PVDiv) if you are using the PVDiv version, and F = Exp[(R-Y)T] * SPX if you are using the yield version.

    Once you trust your formula and go back to TOS you will need to deal with bad forwards and TOS model details ... if you are serious about nailing TOS prices and greeks you will probably need to learn a little more about the intricacies.
  33. Not intelligently as I don't use TOS numbers for anything ... just going by comments of others, and TOS skews frequently appearing kinked at the money which means bad forwards, and Riggio's reported TOS greeks which are frequently way off any sane values. I have been using their raw chains (bid/ask values only), and those are fine although not as good as IB's.
  34. A case in point, TOS weighted implied volatility for ES May and June options were at a whopping 30+% as of last Friday afternoon. Such elevated IV is way out of line with the SPX and SPY options. For a brief moment, I thought there would be an arbitrage opportunity. Needless to say, that was purely wishful thinking.

    By the way, I planned to switch from TOS to OptionVue mainly because TOS does not do proper book keeping of adjusted complex positions (To get a reasonable idea of my P/L, I have to manually import as simulated trade each adjustment previously saved in a text file). However, after a test drive of OptionVue for 3 weeks, I have decided to put the plan on hold as I have found some serious problems with OptionVue too. I am waiting for OptionVue to resolve the issues before I shall re-consider. In fairness to OptionVue, their customer support is very good and responsive which is a major consideration for the purchase of any product.
  35. Steve S
    Here is the recalculated price using your values from the spreadsheet
    Time to expiration0.082192
    Exercise price$2,340.00
    Current stock price$2,347.74
    Risk free rate1.30%
    Put option value23.83
    Your price from the spreadsheet23.85
    Tos Price using think back to 30 days 24.2

    So the values I got almost match your values and only a little off the TOS price
    I did not have the call price on the spreadsheet so I am not sure how close it would have been but my calculated price was 31.62 while TOS was at 30.20 so that's not too far off
    I used 30 DTE while your spreadsheet had some kind of fraction of a day (30.041) so I figured it was close enough
  36. Ok, it's mostly semantics then. Saying 'TOS data' I think raw data )BID, ASK, OI Volume etc) not greeks.
    Now: why TOS raw data are not as good as IB ?
    I'm asking because I'm in process of deciding to which live data to choose. I noticed huge changes in P/L over short period of time using TOS and I'm not sure if it is source specific or it is just the way it is (my assumption). Next week I will try to get TOS API (I heard they relaxed rules) - just because it seems easiest for now and will cover live and historic data,
    if not I will try to find equivalent of RTD for program lang or other source.

    Status1, I'm watching your quest with interest. It seems I'm not completely grasping what you want to accomplish. Are you tying to match TOS greeks? Why can't you just change IV? How do you evaluate your forwards (how do you evaluate that your greeks are ok)?
  37. That was my point; you can check your formula by adding the parity value to your put. Using the parity formula I gave above with the values on the spreadsheet gives 7.79531665727378 for the parity so the call is the put plus this = 31.6453166572738. See my next post regarding new info on TOS greeks ...
  38. Will be interested to hear your report on this ... I've been told the API is too limited to be useful.

    First of all, the TOS raw data is fine and dandy ... I check it every day against both IB and LiveVol, and it is fully adequate.
    The reason it is not quite as good as my IB data has to do with how often they update the chain and how internally synchronized their chain is, strike-wise ... a "good as it can get" chain would have all call and put bid/asks for all strikes sampled at exactly the same time, but you can't expect this from a retail-level data source like TOS or IB. For my IB chains I subscribe to real-time data for all strikes, and then when it's time to pull the data I wait until the chain is static for at least 800 milliseconds before I grab it ... that algo is probably the only reason why my IB data is a little better than TOS.
  39. To all readers of this thread: I swore I would never do this, but today I plunked down the time investment to reverse engineer the TOS RTD greeks for equity index options. That means I figured out how to take the greeks from 6 options and coax them into coughing up the exact rate, DTE, underlying and implied vol that TOS is using for inputs to the Black-Scholes formulas. The results were mildly shocking: At least today, TOS is using yield = PVDiv = 0 as well as one rotten interest rate (0.75%) for the two DTEs I looked at (May and Sep). The yield = 0 thing is VERY bad, so I hope they don't do this when the market is actually open (but it would explain their kinky skews) ... will check this out next week if I have time.

    My reverse engineering algo works for the PVDiv model all the time, and it works for the yield model when yield=0 ... if TOS is ever using the yield model with yield<>0 then my algo won't work, you need to do something different that I haven't tried to figure out yet. With that caveat, some of you may be interested in implementing this yourself ... if so I can post more details and perhaps a sample spreadsheet.

    If anybody wants to help with refining this project, I would be interested in the following:

    Any way(s) to directly get the interest rate(s) and yield(s) that TOS is using.

    Any way to get RTD to deliver the "theoretical" option premiums coming out of their model (I only know how to get BID/ASK/MARK, which are all useless for this project).

    If I had just one of these (rate, yield or premium) then it would be easy to expand the algo to work with yield<>0 ...
  40. Marcas: Can you please clarify what you mean by TOS API? It is my understanding there is NO TOS API, only a TDA API. I keep hearing people over the years reference a TOS API, which so far has turned out to be false! I would love to be wrong!
  41. As you know I started this thread because I liked Paul Demers's presentation where he built his own risk analyzer so I was curious as to what it would take for anyone who is not so experienced to build one
    Than I just happened to mention about the problem I was having with the Black Scholes formula and with the help from other members here I was able to make it work
    So I am glad I was able to accomplish at least that part
    1 Are you tying to match TOS greeks? Well that would be great next step which I could not have done without knowing what goes into the Black Scholes formula
    2 Why can't you just change IV? I am not sure what you mean Change it to what ?
    3 How do you evaluate your forwards (how do you evaluate that your greeks are ok)? I am not sure what you mean by forwards but I am trying to look at the greeks next (baby steps)
  42. Thanks, I noticed this and, for now, it no issue for me, so here I'm good with TOS.
    I let you know about my quest for TOS API. I only heard it is/was hard to get rest is from their webpage - sounds very ok. We'll see.

    About your RTD play, I regret but I can't help it is little out of my reach and also little out of my focus at the moment.
  43. Marcas: That referrers to the TDA API, NOT a TOS API. I have the TDA API, which is not being actively supported. The relationship between TDA API and TOS is loosely linked. Trades which occur within TOS are propagated to TDA after market close. The TDA API is the very old and not supported TDA interface. You can obtain updated positions via TDA, but they are delayed until after market close and do not contain proper execution timestamps. -- I use this when I do not require accurate time of trade reporting. --- Note TDA purchased TOS, but a TOS API was never provided for users. -- If you have conflicting information, I would be very interested! -- BTW: I use the TDA API for trade history only at present!
  44. Me to, and I'm working on something similar not copying Paul's sheet. I want to see data I need.

    I think I think I might get it : ) It is exercise.
    My thinking is if TOS greeks are not so good then why to try to copy them rather than work on better ones. Question is what 'better ones' mean and how to verify that new greeks are better. The only method I know is to compare what greeks predict with real data and this requires... some work.

    I'm not working on models leaving it for future. Sure I implement some model in my program but it will be mostly to try keep consistency so I can compare greeks over time (as opposed to greeks calculated by somebody else where somebody else may change model in fly).

    By changing IV I meant change it so to get right price.
    As I said. I'm watching this tread and I'm learning with you.
  45. Oh! I wast talking with TOS and they gave me this link and e-mail I intend to use. I suppose you have better info then. I will contact them anyway because access to historical data is valuable to me as I don't want to deal with big database yet.
  46. FYI: I was using BSM to reproduce option prices and observed the IV surface results of my calculation to try to get a feel of whether I was accurately representing the IV for the PUTs and CALLs. I observed anomalies in the IV surface that suggested a huge flaw must be present. The graphs would produce multiple inflections (an indication something is amiss), or the CALL VS PUT IV surface would have differing shapes. Many of these "issues" would coincide with the TOS view of the same at the time (suggesting I was making similar error to TOS). I had three big issues with my values that I was providing to BSM (1) Interest rate, (2) Yield, (3) spot price. My underlying is SPX. I referenced Steve S.'s paper on "U" derivation, and these three issues now seem resolved. My solution required marshaling the option chains, which I do. (He addresses solutions for I interest rates, as well as formulas for "U" which include -PDIV.) While I may not be spot on, I am much closer than previously (and closer than TOS for my usage)
  47. Thanks garyw. I don't want to go into details as I'm not ready yet.
    Do I understand correctly that goal here is to achieve right balance between Puts and Calls (means to get similar IV on both sides and be darn close to real prices)?
    And then, if we have this balance within our formula, does that means that we are close to _right_ greeks (means greeks that predicts options prices behavior with acceptable accuracy)?

    I don't intend to interrupt thread flow , but I have another question: talking about bad greeks from TOS are we taking about IndVol or VolSmile or both?
  48. I have been watching this thread with interest. It is my humble opinion that you will never find the right greeks that will predict any type of future options behavior. How are you going to be able to create a formula to know what the future pricing of each option is going to be or how the skew curve is going to move?
  49. I'm leaning to your position, and for now I don't care much about greeks accuracy (the way I.m trading), but I don't mind to have right greeks that can predict where the prices will be with such and such price and IV movements. My t+x lines will have more value.
  50. Hi Paul,
    I am inclined to agree with you. Although we cannot predict its shape, the skew may predict something else uselful. 10 years ago, somebody had studied the reliability of options vol skew in predicting their underlying equity future returns.
    The paper is here:

  51. The key word I picked up on in your comment was "predicting". That is the best that you can expect from any type of model. I guess the point I was trying to make is the fact that the greeks of a position and the resulting T-0 line are just a model and are accurately predicting what the pricing and greeks would be if the underlying price was different at that moment in time. What is going to happen to that position going forward in time is just a prediction based on the current model and nothing more.
  52. I can't agree with you more.

    In bringing up the paper, I was just suggesting that it may be easier to predict stock prices with the skew curve than to predict options prices and their Greeks. And IMHO, trying to exploit the volatility surface may not be worthwhile for small retail options traders trading 10 lots butterflies. Even some professional traders are not that enthusiastic in playing the volatility surface anymore. I had been told that the skew slope accounts for less than 10% of total volatility risk. Most of the risk is attributed to the general level of volatility. i.e. the volatility surface may as well be flat as originally predicated by the BSM for practical intents and purposes.
  53. Marcas: I am unaware of access to "historical data" via the TDA API. You can access your trade history via the API.
  54. garyw, I only read what www says:
    Streaming data - Level I, Level II,
    Historical data - Daily and intraday

    that is all I need. If, as you say, it doesn't work... well, what a pity. I'll see if they want to charge me for that.
  55. Hm! They do seem to state that! If anyone gets that to work for accessing historical intraday option pricing, I'd appreciate a heads-up. Would be of interest.
  56. This basic calculator from IVolatility is nice because it fills in the interest rate and dividend yield based upon the expiration date. Does anyone know how they are calculating the values for these two fields?
  57. If you look at their data notes, I believe they state that they use Libor for shorter dates and swap rates for DTE > 1 year, which are ok but not really "good" in general.

    However, there appear to be some bugs in their script: Looking at July and December I'm seeing very wrong rates (way too low). June and May are consistent with Libor but Libor is a chunk lower than what the market makers are using.

    Their yields appear to be constant for different DTEs, which means they are again "barely ok" but not "good". SPX yield appears to be just the same value you can get from a million google hits.
  58. What are all the market makers using?
  59. I don't have expert knowledge there ... I tweak my rates so the forwards make sense, but when DTEs get shorter than a couple of months it's impossible to draw a bead ... but for those DTEs accurate rates don't matter. Actual rates were way over Libor for the last year until Libor started rising; by late last year they were much closer for shorter DTEs; right now Libor is probably quite good for DTEs out to 6 months and a little high for months like Dec. Actually, looking at the latest Libor curve I kind of take back what I said ... Libor is pretty darn good right now for the DTEs most of us trade ... but that's accidental; if you look at recent history Libor has definitely been too low, and if you look at periods when rates were much higher Libor tends to be too high.
  60. Please forgive my lack of experience. How do you know if the forward prices "make sense"?
  61. There are three independent methods I know of that give useful information about the interest rates used in the chains. None of them work for short DTEs ... somewhere between 1.5 and 3 months is where they begin to give information ... but this is ok because the reason they don't give information is because for shorter DTEs the rates are having less significant impact on option pricing and risk management ... that is, by the time we can't get much information, we don't care much any more.

    None of the methods has high precision.

    In brief, the methods are:

    Chart the chain's implied forwards by strike and tweak the rate until the line is flat. This is the easiest and most direct method. The resolution of the method is something like 10 bps for 3-4 month DTEs and 5 bps for 5+ month DTEs.

    Calculate the chain's average implied rate from the matrix of parity diffs (j, k) = [F-X(j)] - [F-X(k)]. This is also easy for any particular chain, but the results are so twitchy that you need to chart the results as a time series to extract the central tendencies, which is a hassle.

    If you have a handle on the PVDivs and you have a way of roughly feeling out the index arbitrage fair value diff for a particular chain's time stamp (for example, this is easy if you look at the chains for a bunch of DTEs side by side), then you can just tweak the rate until the chain's implied index price is roughly correct. This is a good method for casual tweaking if you have the numbers in front of you - then use method #1 for checking when desired.
  62. So, what is going on with my API request from TD?
    Not much. I sent request, few days later they replayed with back to fill, I filled it and that's it for now, I'm waiting.
    I don't push this too hard as I'm working on something else, also additional research confirmed what was said here: no or limited access to historical data. Too bad. I would have to go with higher resolution so it limits my options.

    And requirements for td API didn't change:
    A TD Ameritrade account with either an account value of $500,000 or more OR 30 trades per quarter
  63. Steve, were you able to verify that TOS is using a dividend yield of 0% and a fixed interest rate of 0.75% during market hours? Also were you looking at individually implied volatility or volatility smile approximation?
  64. Yes, I verified during market hours. To do the initial reverse engineering you need to use vol smile so the parity relationship is there ... this can probably be used to bootstrap the IIV reverse engineering, but I have not tried that yet.

    My current questions to any TOS user who cares to contribute are:

    Can yield be changed/set by the user anywhere in TOS?

    There is a place where interest rate can be changed, but this does not seem to flow through to the RTD data ... can anyone confirm or refute this?

    With vol smile, do the RTD greeks match the screen greeks for real and/or simulated positions, or are they different?

    Same question as #3, for IIV.
  65. Steve:
    I have verified that The RTD "IMPL_VOL" follows the TOS setting of IIV and Vol Smile.
  66. Good information Gary but I need the package of all Black Scholes inputs U,X,T,R,Y,V together and simultaneously ... the way to verify is to put on a position (both real position and simulated position, both vol smile and IIV are interesting separately), get the position greeks going with RTD on a spreadsheet, and confirm or refute that they are "exactly" the same as the Tos screen greeks (to within the accuracy possible) ... any way you could check that?
  67. Steve:
    Do I understand correctly you are trying to solve for 4 unknowns "likely" used by TOS? U,R,Y, & V? (kinda assuming they get T correct, X is not in dispute) My eyes glaze over with more than one unknown! -- I can fairly easily extract whatever set of RTD is desired (across a span of strikes/expiry's) -- If you think I can help; provide more details.
  68. I should preface by saying that I am completely, 100% ignorant of TOS ... I just use the RTD, not the GUI ...

    So this looks like the area where I changed the interest rate and it did NOT flow through to the RTD greeks ... but I would like to try the yield also ... but I'm not seeing how this would work for an index underlying. Can you give a wider screen shot of doing this for SPX, or if I can't do that then how do I get an option in there so I can change it for 1 option and see if it flows through to RTD?
  69. No Gary, I can already solve for all the unknowns used by TOS RTD to within 0.001% ... that's the reverse engineering part ... what I'm trying to find out is if the RTD greeks are the same as the screen greeks.

    P.S. Should have added to the previous post: If you are checking this then use your longest DTE position, or if a simulated position then use something like Sep or Dec ... that's where the yield/PVDiv thing will show up most obviously.
  70. Steve:
    If you fill this out, I can run it now, and capture.
    Below is entry in my script for identifying RTD to extract. This is applied to the complete request. Can do it for any/and/or all expirys.
    The values separated by commas. are the codes supported by TOS for RTD. Or just type in the order and name you want, & I'll correct the spelling to match the RTD rqmt.
  71. I'm only interested in DELTA, GAMMA, VEGA, THETA, RHO ...

    But it won't help for you to post numbers ... what I need is some hands-on expertise with TOS, for you to be looking at these RTD greeks on a spreadsheet calculated for a net position and comparing to the position screen greeks simultaneously ... my experience indicates that this can be done precisely after the close, and only imprecisely during market hours ... both captures are separately interesting and useful.
  72. Steve:
    This may not be of interest, but I'm still guessing:
    I pulled out the following for RTD on SPX just now:
    The spreadsheet generated is attached. I copied the sheet and pasted the values as well, incase you don't see the RTD working.

    Let me know if there is anyway I can help.
  73. A typo in my entry for IV in above.
    I have no indication that the greeks used for the analyze tab should differ from those fed to RTD, unless they are manually tweaked on the Analyze tab. The RTD greeks match the Trade tab greeks.
    I analyze my positions externally (using RTD for Price only), and they do slightly differ from TOS, but I suspect it primarily due to the TOS derivation of IV, which I do not use. (I'm using one of your methods, which I prefer). - I'm still likely missing something!
  74. I'm not at my computer right now to take a screen shot, but you can access the yield box on the Analyze tab by clicking the gear icon just above the simulated trades box near the bottom right hand of the screen.

    I'm pretty sure this only changes the greeks on that screen and it will not flow through to RTD. This is all pointless if the TOS IVs are wrong anyways.

    Did somebody say that you published a paper on this subject? I'd love to read it if you're willing to share.
  75. It's not pointless because the whole project is just an egghead thing ... everything about TOS is pure junk to me except their raw chain bid/asks delivered via RTD, but I got involved in this reverse engineering project against my will. I'm going to try and catch up a little with the GUI so I can stop bothering you folks.

    If you mean the subject of TOS greeks, "no", and that would be pretty funny as I'm the King of Ignorant on the subject ... but I did work out the reverse engineering and would be happy to share that with anyone who cares.
  76. Do you have a paper you'd recommend for fixing up a chain and computing IV?
  77. Yes, that would be www.dtsconsulting.net/white_papers/chain_bootstrap.pdf ... just be careful, if you get into it, not to get too immersed in all the interest rate stuff, as you can waste a lot of time there on something that is not too important for the DTEs that we mostly trade.

    Ok Ryan and Gary, I got off my butt and figured out how to set up a simulated position in TOS. My observations are:

    Changing the interest rate in TOS never flows through to RTD greeks.

    Changing the yield in TOS never flows through to RTD greeks.

    The RTD greeks are always vol smile greeks ... changing to IIV in TOS never flows through to RTD greeks.

    If anyone reading this can get different results then please post ...

    Assuming my conclusions are accurate, TOS RTD greeks are even more useless than I thought ... and separately, I hope all you TOS users are using a better rate than 0.75% and a MUCH better yield than 0% for your screen analytics.
  78. In my opinion and from my observations your conclusions are correct.
  79. Steve: I agree with everything save one:
    "3.The RTD greeks are always vol smile greeks ... changing to IIV in TOS never flows through to RTD greeks." <-- Untrue, Unless you happened to test with TOS screwed this up previously! I have observed that the RTD connection seems to need re-establishing after tweaking the TOS setting for Smile VS IIV. -- If your re-establish the RTD links after the TOS change (and after the change is observed within tos), then the RTD reflects the new IV setting results.

    However, I agree with your final conclusion that using the TOS IV is a sloppy approximation of IV. Your paper aids in providing a much better approximation of IV.
  80. Thanks for the correction Gary ... after fiddling around for an absurd length of time after the close (in the end had to shut down and restart TOS itself, as well as my RTD spreadsheet), I'm in agreement with you. I was able to do what I wanted which was to check that the IIV modeling is the same as the lousy vol smile modeling. I think I'm done with this stinky project.
  81. Thanks! I can't wait to dig in. I'll heed your warning.
  82. Interesting conversation about IV
    A couple of weeks ago when I was doing the calculation for gamma I noticed that the put and call gammas are different even though the formula is the same for both So I did not know why at the time but I figured it had something to do with the IV
    So now that I learned where to change the IV in TOS I was wondering which IV is best to use as far as "fair price" is concerned
    There are 3 choices
    1 Volatility smile approximation
    2 individual implied volatility
    3 Fixed volatility per expiration date
    I was playing with all 3 settings and from what I can see the individual implied volatility would be the closer one
    None of the settings have any effect on the bid / ask price but looking at the price slice the individual implied volatility showed (+/-43) when buying or selling a put at the mark
    The volatility smile showed +/- 104
    While the Fixed volatility per expiration date showed +/- 427
    Using the Theo price the Individual IV is even better at +/- 0.45 while the others showed +/- 60 and +/- 471 respectively

    Is there any reason to use any of the other 2 settings ?
    Is it maybe just to look at the greeks only ?
    For some reason the Vega and Gamma numbers on the individual implied volatility setting are a little off between the price slice and the trade tab while the other 2 settings match exactly
  83. Steve, I was able to back out the interest rate using your paper for guidance. It was a lot of fun. Thanks!

    I'm curious about one thing though. What interest rate do you use for contracts under 60 DTE since your methodology works better for longer dated contracts? Right now I'm simply constructing a libor curve when trading closer to expiration. Do you think this will suffice or would you recommend something else?

    Sent from my SM-G955U using Tapatalk
  84. Rates_June_2016.JPG
    Yes, IMO Libor suffices very nicely, not because it's accurate but because it doesn't matter much for the short DTEs. However, for periods when short rates were very low you can do better with something very simple and conservative to take into account the market reality that option chain rates remain much higher than Libor for short DTEs ... for example, what I do to "take the edge off" the error is to freeze my option chain rates at 30-day Libor for DTEs less than 30 days. This isn't so important right now with the much flatter short-term yield curve. See the charts below for some examples.

    What I actually do: Is brainless ... for the most part, I just leave the old rates and stop changing them as DTE gets short ... if/when I think about it, I chop them down a little. Again, this works because the error doesn't matter.

    What you can do if you're still having fun: For the strike-by-strike forwards approach, write the algo into code where you can estimate with greater precision than the "eyeball method." For the chain-implied rates approach, extrapolate the well-determined curve from higher DTEs, either by eyeball or with code. See the charts below for how this might work.

    If you have IB's Trader Workstation, you can use their rates for short DTEs and be much more accurate than Libor ... that's what I would do if I cared, since I have these rates in front of me all the time ... to me this is not worth the 60 seconds per day it would take as I'm very lazy.

    Note: These charts are using my "30-day freeze" rule for Libor ... the older ones don't show the final plunge of Libor to near-zero.

    Chain-implied rate versus Libor: March 2017 contract


    Chain-implied rate versus Libor: June 2016 contract

    Chain-implied rate versus Libor: March 2016 contract

  85. Steve, I'm on IB. For LIBOR are you referring to the symbol EM which is the 1 month LIBOR rate?
    I've also joined the club of folks that read your chain bootstrapping paper and implemented code to do it. I've noticed that the rate I've been routinely deriving is 1.4-1.5%, yet the LIBOR (based on EM) is around 0.99%. Does this make sense?
    I'm using the 20170720 SPX expiry for these calculations - 76 DTE.
  86. Yes, I noticed the same. This is exactly what I am doing as well. Anything less than 30 days will use the 1 month Libor rate. I leave out the overnight and 1 week from my yield curve construction.

    To get an accurate Libor rate you must bootstrap a yield curve based upon the current USD rates which are quoted at 1 month, 2 months, 3 months, 6 months and 12 months. I'm using QuantLib for this. For those of you who are not programmers you may simply use IVolatility's Basic Options Calculator and type in SPX and your expiration. This will output today's calculated Libor rate for the DTE in question.
  87. I've been using the section from the paper "Implying rates from the chain (2 methods)" to derive the rate from a snapshot of the chain prices for the given expiry.
    Basically I iteratively calculate the linear regression slope of the calculated pvdiv values for the strikes with different rates. The iteration that produces the slope closest to 0 is the "real" rate.
  88. No, I'm talking about the rates that IB actually uses in their option modeling, which should be "the real ones" since IB is (now, "was") Timber Hill. They are not that good, but they are usually better than Libor and I would especially not mind using them for short DTEs.
  89. Short answer is "yes" (see chart), but it sounds like you may have a small upward bias in your estimates.

    Chain-implied rate versus Libor for July 2017 contract:

  90. That's fine but beware the well-known sensitivity of linear regression to outliers (this data is ferociously plagued with them). That's why I use the "simple-average-with-culled-outliers" algo, but regression should be equally good or better if done well.
  91. I'll try your SMA with culled outliers method and compare results. Based on your chart I'm pretty close using the LRS method which makes me happy. I've been filtering out far OTM strikes because I noticed way more noise out there.
  92. Wait, I sowed confusion talking about the simple average method as that's not directly related to rate estimation (MA is worthless here so far as I can tell) ... I was thinking too slow and typing too fast. I have not implemented any code for the "find-the-flat-line" algo, but if I did I would do exactly what you did with linear regression, with a loop or two for culling outliers, and perhaps doing calls, puts and calls+puts. Would need to take a fresh look at a bunch of data to make these ideas jell ... in any case, looks like you are doing a great job!