How does TD calculate the IV for an expiration?
- Thread starter ET180
- Start date
When I asked TDA a couple years ago, IFF they used the same form as that described in the CBOE VIX White paper (single expiry, not the average), they said they did! However, I think they told a "white lie", as it does not precisely jive, but is likely close enough. -- I used the VIX White paper method and found them to be close (but definitely not spot on even with my timestamp jitter).
You may wish to observe the one closest to 30day on SPX and just compare to VIX -- likely close enough.
Matt_ORATS
Sponsor
TOS is not dependable. After hours I think they price on the bid ask of the underlying which doesn't match where the options were priced.
Here's ORATS -
For reference Fidelity is about 30%.
Here's ORATS -
For reference Fidelity is about 30%.
Agree that TOS is unreliable after hours! The BID/ASK is not applicable after hours (unrelated to price as no trades can occur), but still being used in TOS computations results in (Garbage in Garbage out) grief to those not aware or remembering this. One would "WISH" these expiry IV numbers would reflect ATM IV instead of this skewed excrement!
Last edited:
IV is usually computed from the Bid/Ask, ideally from the MidPrice if both are avail.
Since "Day order"s expire automatically at market close, then only the GTC orders remain in the orderbook.
Then of course unrealistic Bid and Ask move to the TopOfTheBook position,
but from which the algorithms try to calculate the IV... and obviously some non-realistic IV is the result.
Same problem at YahooFinance.
Meaning: only during regular market hours (RMH), when the orderbook fills "normally", can the IVs be calculated correctly.
Of course after market one also could use the saved values at market close time or shortly before that, but this requires keeping track of this, ie. saving the data, which the least seem to do b/c of much work (ie. imagine approx. 6000 tickers * 8 ExpDates * 12 strikes * 2 call_and_put * 2 bid_and_ask= at least 2,304,000 numbers + ticker & ExpDate as key for each of them to save... That's much data...)
Since "Day order"s expire automatically at market close, then only the GTC orders remain in the orderbook.
Then of course unrealistic Bid and Ask move to the TopOfTheBook position,
but from which the algorithms try to calculate the IV... and obviously some non-realistic IV is the result.
Same problem at YahooFinance.
Meaning: only during regular market hours (RMH), when the orderbook fills "normally", can the IVs be calculated correctly.
Of course after market one also could use the saved values at market close time or shortly before that, but this requires keeping track of this, ie. saving the data, which the least seem to do b/c of much work (ie. imagine approx. 6000 tickers * 8 ExpDates * 12 strikes * 2 call_and_put * 2 bid_and_ask= at least 2,304,000 numbers + ticker & ExpDate as key for each of them to save... That's much data...)
If the purpose is to calculate the expected move for the given expiration, what method would be best? Take only the ATM IV or average the closest ITM and OTM calls IV vs. whatever computation TD is doing to come up with IV? Seems like averaging the IV of the closest ITM and OTM calls for that expiration would be best. Expected move then calculated by:
http://www.nishatrades.com/blog/mat...ected-move-using-a-probability-analysis-chart
For some reason, I'm never able to see any of the screenshots that you post. Here and in other threads.
http://www.nishatrades.com/blog/mat...ected-move-using-a-probability-analysis-chart
Here's ORATS -
For some reason, I'm never able to see any of the screenshots that you post. Here and in other threads.
Are you interested in precision, or just gross approximations?
Here is what I currently use:
# Compute and return expected moves as well as the %
# Thx to Jacob Perlman (from TastyTrade video)
# https://www.tastytrade.com/shows/th...sodes/the-skinny-on-expected-moves-02-12-2015
# Here I use Calendar days for future time!
# Have not found confirmation my NumSTDs equation is correct, but looks
# seems to pass my gross check validataion.
def SDComp(price,V,NumSTDs,TimeinDays):
EMDwnp=math.exp(-V*NumSTDs*((TimeinDays/365.25)**(.5)))-1
EMUpp=math.exp(V*NumSTDs*((TimeinDays/365.25)**(.5)))-1
EMD=round(price*EMDwnp,3)
EMU=round(price*EMUpp,3)
LowerBound=round(EMD+price,2)
UpperBound=round(EMU+price,2)
return(EMD,EMU,LowerBound,UpperBound)
--------
V is ATM_IV, price may be SPOT, but the forward may be better.
For Expected move, people typically use 1 STD Dev. -- All parameters are floats especially TimeinDays.
Last edited: