I’ve been a ONE customer for some years. I joined the AlgoNET beta a couple of months ago and they recently released their final product, which I purchased for around $1k for 12 months. I then got full access to their historical data (the beta was limited to 6 months data). I’d email them if you want to try it. I’ve tested quite a few different strategies so far. They give sample code for condors, verticals, butterflies and calendars. I’ve been able to create almost anything I wanted from those examples. I’ve had some encouraging results testing butterflies and BWB and I’m now looking at building more complex layered positions with different types of adjustments. Reporting is very cool and shows you a main equity curve intra-day chart with all positions on. As you track your cursor over that chart, the different positions are shown in more detail in other windows. You can also sort a results table by various criteria, for example, if you are just concentrating on your losers to see why they didn’t perform well. There is also a statistics window (similar to in ONE) showing your winners/losers/largest win/loss etc. You can’t reference technical indicators yet but I requested they add that during the beta.
Thanks for the feedback Norm. I'm good for SPX, but I think I would test drive AlgoNET before I would tackle the database project for a new underlying. I'm wondering about the "script editor" thing ... shouldn't it be straightforward to reference any technical indicators you wanted (and do tons of other things) by including them in your own code and just hooking to their backtesting engine? For example, in a script can I pull a year's worth of SPX underlying time series from their data and do my indicators from this, then make my trade adjustments? Also wondering about hedged strategies, especially because ONE doesn't do futures yet ... do they have the price data all lined up so I can run, for example, an SPX strategy that is dynamically hedged with ES and SPY (would only need the ES futures here, not the options)?
You create your strategy by writing code that’s called every tick. You have access to the underlying market data (OHLC) each time the event is called so I guess you could write your own indicator (calculated each tick) and use that to trigger adjustment decisions, although I haven’t tried this. I don’t know if you can trade other symbols to hedge but they don’t have futures yet. All the strategies I’ve written so far have been for an individual symbol.
No problem Steve. Would be great to get a forum together for this type of strategy development and automatic backtesting. I think it has huge potential.
Steve, I'm interested. I looked at the pricing from https://datashop.cboe.com/. One year (subscription) of SPX costs between $56 (30 min), $104 (5min) and $144 (1min). The whole history back to 2004 is between $350 (30min), $650 (15 min) and $900 (1 min). This is only for the bid/ask quotes, no greeks. Is that the pricing that you paid? Or am I looking at the wrong product? I'm also very interested in your experiences processing all these data. Thanks a lot.
Hi uwe, that's the product I have, and it's pretty much the pricing that I saw when I signed up - very reasonable. Regarding tips on working with the data, I could write 10,000 words right now just to start (same as for any options data project), but whatever would be of actual value to you depends on your skill set, how picky you are about making sure the data is good, how far back in time your history will go and the frequency (1 min, 5 min, etcetera) you will be working with. One problem with the LiveVol data is that the "issues" you encounter may be different than the ones I had to solve, since their downloads have been changeable in my experience ... so for example, if I gave you a list of all the data scrubbing items I had to resolve you may or may not see those items in your downloads, and you may see new ones that I never had to deal with ... so best to proceed point by point. Just post any questions you have on this thread, or any thread, and I will try to help without adding to the confusion.
You might want to PM Ron Bertino - he seems to be tight with the ONE guys and I wouldn't be surprised if he has been thrashing AlgoNET ...
Steve: A deviation from the thread, but: Can you comment on how you compute IV for each option? I'd assume you may use a BSM (or near relative) and resolve the IV to produce the observed price (typically Mid price), but for the underlying price, do you use the Spot price or the Forward price? For SPX, do you actually provide a Dividend input? (adding a dividend seems to add error, so I have been leaving the dividend as zero, as there is really no payout like SPY). I have been using the CBOE VIX white paper algo for Forward price (curious of your opinions).
Hi Gary, this is a "small topic" that gets quite big if you really cover all the bases. I've had several people ask me about this lately so I've been collecting different bits and pieces in a single document; I'll post the latest version later today after I add some interesting images relating to implied interest rates. Here's my short answer though, and if it answers your question you won't have to download the pdf: Just use any garden-variety BSM implied vol calculator with underlying = your estimated SPX-PVDiv, Yield = 0. You are using the PVDiv model where all the yield is in the PVDiv, so Yield is not applicable. Your forward F = Exp(RT) * (SPX-PVDiv), so SPX-PVDiv = Exp(-RT)*F. The CBOE VIX determination of "F" is what I would call "stylized" if it's the one I'm thinking of where they only use the closest-to-the-money strike: It's a fairly poor estimate of the actual forward at the time the chain is snapshotted, but CBOE knows that and they are going after simplicity over accuracy. In fact, the near-the-money strikes are the WORST ones for accuracy of the forward because the F-X values have the smallest magnitudes (hence more random error) and the largest bid/ask errors (more random error, and arguably some systematic error). I would definitely recommend a better estimation of the true forward; see my pdf notes for an example of a very simple improvement, and I also have a sample spreadsheet I can upload if there is any interest.
Hi again Gary, here's the doc I mentioned in the last post. If you've lost interest then no worries, I was looking for an excuse to finish organizing these thoughts anyway.
Steve: Thank you for the previous post (I am correcting a bug I had that your response exposed). In reading this chain_boostrap.pdf, on page #2, you state " 1) get a decent interest rate "R" for this (date, DTE) pair (one rate for all chains all day); " <-- Should the fed rates be interpolated to match the DTE, or should the nearest Fed rate term (4Wk, 13Wk, 26Wk, 52Wk) be used without interpolation for the precise date? (I'd guess the latter, but may as well not guess if you know) (IE, for a 2DTE, should I just use the 4Wk interest?) I'm still reading, so will likely have more questions. Thank you for your assistance!
After you read the obscenely voluminous comments on rates (and check out my charts, and that Hull paper) you will have a better idea of what questions to ask ... but just so you know, I'm in the camp holding that Treasury rates have never been the best choice, and never will be - if they happen to be better than something else for a particular date and DTE, that's by accident and not because you should be using Treasury rates. The answer to your question depends on whether your data is actual treasury yields, or bootstrapped zero rates. If nobody has done it for you then you have to bootstrap, and that's a drag. After bootstrapping you do linear interpolation of zeroes.
I know that could change and in fact I'm praying it does, but with rates in the range we're trading options this low, is it worth all the effort?
Arguably no, and that's a point I tried to make repeatedly in my notes. Arguably yes, because it's neither the absolute level of rates nor the volatility of rates we are talking about (both of those are MUCH more interesting topics!), but the way rate estimation errors impact the calculation of volatilities. For any individual trader to figure out the magnitude of error where you being to care, you have to actually spend some days/weeks/months looking at the numbers while you do your skews. Arguably yes, because if you're not prepared there's going to be a lot of scrambling on these trader community web sites with accustomed models going screwy and they don't know how to fix things because they have never traded through even a "normal" rate environment, much less a truly volatile one.
Steve S: Thank you so much for the detail provided in your chain...pdf. From my current implementation of the algorithms you detailed (I may have some additional work needed), the derived IV for the strikes I have most interest in, seem viable (have not spend time validating) A side question for you regarding observing IV: Have you observed IV Surface of SPX by substituting the Y axis of Delta or Strike, by "Moneyness"? This seems to make interesting characteristics of IV more easy (for me) to observe. And can you comment on the plots below where I attempt to show the IV surface for Call's and Puts on SPX for today? I found a moneyness formula that also encompasses Time, which seems to make better visualization of the IV surface. (less mental gymnastics required) I am using the following for PUT moneyness: ln(price*exp(dte*intrate/365))/strike)/((dte/365)**.5) The calculated IV obtained by using the "U" value derived from your PDF, as the underlying price input to BSM model iteration for the specific OPRA Mid price. For CALLs, swap positions for "price" and "strike"; Below is a chart I just extracted for reference (cannon fodder). Legend: RED dot: The calculated IV of a specific OPRA with Volume == 0; Green dot: The calculated IV of a specific OPRA with Volume > 0; BLUE dot: The TOS "Individual Implied Volatility" value for the specific OPRA. Note: Any IV shown as zero (0) is not real, but indicates the data is suspect. <-- Note: these all were options with No trades today. When I changed the TOS calculation to Vol Smile, the data retrieved from TOS seems questionable: Below are similar graphs with TOS set to Vol smile.
Yes you are on the right track with translating to Black-Scholes space from strike space by viewing your skews as functions of Black-Scholes standard deviations ... this is the correct space to work in when comparing skews across DTEs. You can take your independent variable to be Ln(F/X)/Sqrt(T) as you are doing, or if you are comparing different vol regimes it can frequently (not always, and you will hear arguments about this) be better to also add the atm vol so your variable is Ln(F/X)/[Vol_atm * Sqrt(T)]. Regarding your charts, TOS and your calculations: For a given chain there is only one correct implied volatility (obviously with small variations depending on algorithmic details) ... everyone who is doing the job right will agree, and if someone disagrees then they are wrong, not just "doing it different". I have TOS but don't really use it, but from what I have heard they don't do their forwards correctly so their skews are wrong and the smoking gun is different call and put skews. I do use OVue so I know from personal observation that they have the same ridiculous problem. Their vols will still be in the same ballpark as yours - the errors aren't crazy wild, otherwise nobody would use TOS or OVue. You can still check your vols against theirs whenever you get paranoid about your numbers, just don't expect to be really close. What you need is to gain confidence that they way you are doing your vols is "right", period, and then you won't worry about anyone else's vols, except occasionally when your vols or greeks look weird, and then you do a spot-check against someone else to make sure your system is working.