Trading Group 2 - March 14, 2017

Discussion in 'Round Table Presentations' started by status1, Mar 18, 2017.

  1. garyw

    garyw Well-Known Member

    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.
  2. Steve S

    Steve S Well-Known Member

    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.
  3. Ryan Simmen

    Ryan Simmen Well-Known Member

    Thanks! I can't wait to dig in. I'll heed your warning.
    Last edited: Apr 23, 2017
  4. status1

    status1 Well-Known Member

    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
  5. Ryan Simmen

    Ryan Simmen Well-Known Member

    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
  6. Steve S

    Steve S Well-Known Member

    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

  7. stevegee58

    stevegee58 Well-Known Member

    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.
    Last edited: May 5, 2017
  8. Ryan Simmen

    Ryan Simmen Well-Known Member

    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.
  9. stevegee58

    stevegee58 Well-Known Member

    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.
  10. Steve S

    Steve S Well-Known Member

    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.
  11. Steve S

    Steve S Well-Known Member

    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:

  12. Steve S

    Steve S Well-Known Member

    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.
  13. stevegee58

    stevegee58 Well-Known Member

    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.
  14. Steve S

    Steve S Well-Known Member

    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!

Share This Page

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