Hi Simon,

I only skimmed the paper but this looks really interesting. Can you provide a quick intuitive explanation for what this is trying to do? Of course only if you want to but I think it would provide nice context.

Thomas

Sure. To start off with, the VIX is a CBOE index of the implied volatilities of options on the S&P 500 (nowadays). It's a measure of how much volatility is being priced into S&P options; it's calculation is interesting but not totally relevant, there's a great paper here http://papers.ssrn.com/sol3/papers.cfm?abstract_id=871729 that explains it all.

There's a hypothesized "Volatility Risk Premium", which is the premium that option sellers charge to S&P hedgers in exchange for assuming the risks of the volatility of the index. This is, in theory, above and beyond the fair value of the options. For those willing to take this risk, this premium should result in excess returns as the reward. Whether or not this premium really exists, or in what fashion, is debatable.

The VIX index is not directly tradable, which makes volatility plays sometimes challenging. There are futures contracts on the VIX, and these are traded, but they discount future expectations of the VIX and have their own term structure. There are, now, ETPs on the VIX, which are usually internally implemented using VIX futures. VXX and its ilk are relatively well known; people think that they are tradable securities that behave like the VIX. Unfortunately, due to the fact that these products buy medium-term futures and sell short-term futures, they are usually on the wrong side of the VIX term structure contango during quiet markets. Hence, buying VXX will almost perpetually lose money.

XIV and ZIV are much more interesting products; these do the opposite, they short further contracts and buy the near contracts. Hence, these ETPs tend to do well during quiet markets, but then get very severely shocked during market disruptions.

This paper is trying to harvest the volatility risk premium during quiet times by being long the XIV ETP, while avoiding the shocks. Of the several methods he provides, #3 and #4 look the most interesting, with #4 being basically "if the Volatility Risk Premium is above some threshold, be long XIV, otherwise be long VXX". The Volatility Risk Premium is defined as the smoothed difference between VIX implied volatility and the realized volatility.

I am sure there are some calculation errors in my code, particularly related to the subtleties of calculating and normalizing standard deviations as a proxy for the realized volatility of SPX (SPY in the system) when the underlying distribution is not lognormal, but at least with fetcher we can start doing VIX-based studies and systems!

Simon.

Another line of research would be to combine XIV or ZIV with a short position in SPY to get beta-neutral exposure to the VRP, if it exists. Discussion and references are here: http://epchan.blogspot.com/2012/07/extracting-roll-returns-from-futures.html?m=1 and http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2094510

Simon.

this is really excellent, thanks

The other major improvement would be to use a better estimator of historical volatility than the standard deviation of closing prices. http://www.fea.com/resources/a_estimation_of_security_price.pdf looks pretty good, and I've been meaning to read http://www.atmif.com/papers/range.pdf and implement it, so that's another option.

EDIT: lots of interesting reading at http://vixandmore.blogspot.com/ about this sort of thing!

Very cool study Simon - thanks for sharing! I particularly like your suggestion of hedging with a short on the market, have you tried that yet? Please share if you do.

For Quantopians who are wondering about term structure 'contango' I think this article is a pretty good basic overview. Would love to see other refs on this if you have good ones.

More food for thought: http://marketfader.com/2013/04/20/visualizing-the-vix-term-structure-over-time/

I'm a little confused about the calculation of SPY volatility. Are you calculating the rolling std of the price level rather than the log returns?

Aha that would explain it! I knew I was making a basic error in there.

I've attached the corrected version. This one also uses the rolling_median rather than rolling_mean, which Tony mentioned in an email is what they use, and reset the VXX threshold back to 0 for comparability. I still plan to try a different less noisy volatility estimator tonight or this weekend.

Thanks for the catch Ray!

This is with the historical volatility estimator outlined in the Yang & Zhang paper I mentioned above. The historical volatility is a lot smoother which means we ought to be able to shorten the sampling period and possibly get rid of the rolling median on the VRP in order to respond quicker to downdraughts.

This is with the lookback period of the Yang&Zhang volatility estimator reduced to 5 days, and the rolling median of the VRP removed.

the really concerning feature of this strategy is the very short time the ETN is available to trade. if you were actually going to trade this you'd be much better off implementing with futures on vix (I tested this) or options on S&P.

You mean in terms of trading hours during the day? Aren't the signals similarly constricted by the trading hours of the options themselves to calculate the VIX? (and how did your personal tests work out?)

sorry for the ambiguity. I mean the xiv has a very short history, which is not good. the futures on VIX go back to 2004 but they had almost no open interest until several years later. My testing on futures showed promising results. The liquidity problem in the early years means that I can't trust anything early on so I am left with more history than the xiv but it is still too little.

To really get a feel for the characteristics of this strategy you would need to create the equivalent delta hedged portfolio and trade the portfolio over the history of the vix (~1990-now). This is not trivial (just getting the data can be a serious issue).

Oh yes, well, a proper backtest could perhaps use the S&P 500 VIX Short Term Futures Index: http://www.standardandpoors.com/indices/sp-500-vix-futures-index-series/en/us/?indexId=sp-500-vix-futures-index-series which is what the ETNs are tracking, and might be simpler than dealing with the futures and converting them into continuous contracts etc.

EDIT: though we'd of course have to use zipline for that

This is a version that attempts to hedge with the XIV/VXX positions with SPY. It appears to be an improvement, but there are so many parameters now, it's impossible to say whether this is anything useful ex ante anymore. Find out in a year, or when I try a backtest using the index data mentioned above!

There is a lot about volatility that I didn't have room for in the paper and that exists in my head only.

Volatility is a strange thing - it exists but you can't measure it.

The Volatility Risk Premium (VRP) is even stranger - it doesn't exist and you can't measure it. By "doesn't exist" I mean that there is no single unique value that you can define to be the VRP. Like stock valuation it differs from person to person so is not uniquely defined.

The VRP is a premium that an investor is prepared to pay over and above what they should pay for volatility. But how can they decide on a premium if they can't measure volatility? They have to measure volatility in some way and my guess is that most people measure it using recent historical volatility (which is kind of what the brain does naturally).

So you will find that if you measure volatility using sophisticated estimators such as GARCH or Yang Zhang then you will get better estimates of the volatility but not of the VRP.

For the paper I couldn't decide whether to use 10 day or 21 day historical volatility to estimate the VRP since most traders seem to use one or the other. So I compromised by using 10 and by applying a 5 day moving median smooth (to reduce trading costs) to that. So in a way it is similar to a 15 day estimator but a bit smoother. (It is a bit smoother than a 15 day estimator because it also smooths the VIX.)

Thanks for the comment Tony, and thanks for the excellent paper.

One question for you (and/or Simon): I am backtesting your strategy 4 on the limited range where we have historical data for XIV, specifically I am trying to match up your ~5x investment return with 8 trades from Oct 2011 to Feb 2013 that you quote in the Summary, and I am only calculating a 3x return over the same period for strategy 4. Still not a bad return, but I want to make sure I'm implementing your strategy correctly.

I thought that I might have been making a mistake in my code, but Simon's chart above (the corrected one still using historical vol with a zero threshold for VXX to match your results) also shows a ~3x return over this time period.

Am I missing something? Thanks.

I am new to this site. I was trying the original code and other code posted, but the error pasted below is always generated. I am not sure how to fix/debug this since, for most of the modules, the code is not available, and it is not possible to run a debugger. Has anyone resolved this?

File testalgorithm_sycheck.py:17, in initialize
File algoproxy.py:1320, in fetch_csv
File requests_csv.py:336, in __init_
File requestscsv.py:249, in load_df
File frame.py:1971, in __getitem_
File generic.py:534, in _get_item_cache
File internals.py:884, in get
File internals.py:1016, in _find_block
File internals.py:1023, in _check_have

It looks like something has broken with the fetch_csv function. I am sure the quantopian folks will fix it soon!

Hi Greg and Simon,

We did recently change the behavior of fetch_csv. Previously we had been ignoring the "usecols" keyword argument that could be passed to pandas' read_csv, but recently we "fixed" it, so now it's passed through. However, this means that in this algo, the pandas DataFrame only gets the 'Adj Close' column. Then our attempt to map the 'Date' column from a string to a datetime dies because there is no such column.

I removed line 15 ("usecols=['Adj Close'],") from the original code, and it ran for me with no errors. Is removing the "usecols" argument from the algo code the right solution here, or do you think fetch_csv should be ignoring it internally?

Thanks,
Rich

I think, at the very least, a better error message would be helpful. In the absence of a debugger, everyone who uses the site is flying blind.

More generally, I don't think it's very helpful when back-end changes render entire threads of shared backtests unreproducible. With this stuff, people expect reproducibility above all else, if the results cannot be reproduced, there's no way to isolate problems, or whether a system is even worth pursuing ex ante.

In this specific case, yeah, removing usecols is fine -- can you adjust all the backtests I posted to remove that from the source code? I don't see an easy way to edit them, and I no longer have them all in My Algorithms.

@Rich, I think fetch_csv should pass "Date" along with any value in "usecols". It seems instrinsic to the function (since it requires a date column). That should resolve most issues with code that specifies "usecols" yet assumes "Date" will be available.

@Simon: I agree that that's frustrating. I think we need a test-suite that runs shared algorithms and tests if they break and produce the same results. Given the number of algorithms it's very hard to foresee which change will break one of them.

I do like Dennis' suggestion of always adding the date column to usecols. That way the above posted algorithms should just go back to being functional again. We'll post here once that's fixed. Sorry for the hick-up.

Simon, we agree with you on all points. And I'm very sorry for the frustration you're feeling.

There are parts of this product that we knew we had to be really good at, and reproducibility was one of them. We built a lot of testing around results and known data sets so that we could always have a reproducible result. That's enabled us to have relatively few bugs in terms of data errors in the backtester (saying that knowing full well there are some still there, just waiting to be found).

What we didn't anticipate as well was the reproducibility challenges coming from the backwards compatibility of code, or the lack thereof. It took me a bit longer to wake up to that as being a problem. It's become a much higher priority. One of the projects we're kicking around is building a bigger test suite for user-generated algorithms so that we test a broader set of algos before we push code live (like what Thomas mentioned). That test, as envisioned, would have caught this before we shipped. I suspect we still would have shipped it, but we could have handled it a lot better.

Sorry again. We hear the frustration of things like this and we want to prevent it in the future.

The details of my strategy are presented in my paper and if you aren't getting the same results as me I can't really say why. One note that people forget is that when I use a moving average I use a moving median not a moving mean. This sometimes confuses non-statistical people.

Simon and Greg,

We've implemented Dennis' suggestion of appending the date column to usecols (Thanks Dennis!). The original looks to work again, but definitely let us know if you see otherwise. Sorry for the regression.

Thanks, things seem to be working.

Tony, one last question for you. I couldn't help but notice that the VRP strategy has had a ~50% drawdown in the last few months since your paper was published in February. While this isn't outside the range of historical performance, the other major drawdown occurred during the GFC as you pointed out. This recent one seems more concerning as a regime problem since the market was fairly calm/uptrending during this time, and the VRP strategy just happened to be on the wrong side of several fairly minor VIX movements. Do you have any thoughts on this last regime, or possible methods to address it? Thanks.

Hi John. VRP has not had a sell signal since the 14 February when the data series in it ended. So it has been long XIV and the drawdown is (22.94-19.3)/22.94 which is 16%. There is no period this year when the drawdown has been 50%.

Expected roll yield has been positive all that time but has been eaten by volatility drag which has been at record levels. This has left XIV about even up till recent weeks when the rise in the VIX has clobbered it. The markets have been acting a bit abnormal and there were plenty of signs that volatility was rising - if I were an options trader I may have put in some hedging.

I'm still long XIV. Till I get a sell signal I'm staying that way.

It's interesting to note that for the last few days, on few volatile moments, VIX futures has been trading in backwardation in relation to each other and the spot. However, the discount relative to the spot is very minimal.

So whatever was the fat roll yield on VXX is minimal. And the risk premium has also evaporated. You can check out vixcentral.com for the latest. On the last glance, it looks like VIX term structure is back to its normal contango with a small risk premium over the spot.

Thanks for the added detail Tony. My model gives negative VRP/XIV sell signals on March 3, 2013 and April 18, 2013, and it looks like Simon's above does the same thing. It is these brief VXX positions that account for the remaining drawdown in my model over the last few months. Not sure what is causing the disconnect since we are all using a rolling median, perhaps because he and I are calculating HVOL off of the SPY ETF?

@Simon,

I appreciate your shared posting of hedging the VXX/XIV VRP strategy with SPY. It seems to dampen volatility and draw-down by a good amount.

I'm trying to grok on how you do the hedging, it seems like you calculate a on-the-fly beta of VXX to SPY based off a 5 day rolling window. Then, you hedge by executing the dollar-amount of (your current VXX allocation + cash) * beta ratio. I have two questions on this approach,

Question #1: Is there a particular reason to decide on the 5 day rolling window? Seems like VXX and SPY's correlation varies a lot, e.g., VXX spike while the HV of the market over a span of a week remains flat. And I wonder if having an optimal beta calculation based off the previous volatility level and market condition makes a difference.

Question #2: Why in your algo, you hedge against your overall capital (value of VXX/XIV + cash) against SPY; and not just against VXX only? Seems like the algo is not delta-neutral and would trend with the market.

Thanks again for sharing your insights. And much appreciation to Tony also for writing up the paper in the first place. Finally also kudos to Barclays for making this instrument for the first place and promoting it.

Heya - no particular reason for 5 days, it was just a number I picked when fooling around with it. For the hedge capital, at is either a bug, or I assumed I was already 100% invested in VXX. I am not too certain how the given capital/cash/assets state variables are calculated, especially in the presence of shorts.

Hopefully at some point, people can start sharing modules somehow, then one person could focus on a solid hedging sub-component, someone else on a Kelly/empirical bet sizing sub-component, etc etc.

If I was going to revisit the above, I would probably try using various linear regression methods to size the hedge, OLS, minimize absolute error, etc.

Please share your findings!

@Simon,

Thanks for the quick response. I plan to experiment with different hedging regime and post back if I find something interesting.

As for Kelly/empirical bet, VIX is mean-reverting while VXX has a tendency to bleed slowly due to negative roll-yield and spike quickly on news. So sizing allocation to handle 30-40% spike on VXX shorts would def. be interesting too.

http://www.cxoadvisory.com/22268/volatility-effects/capturing-vix-misvaluation-with-etns/

CXO does a review of this basic strategy. The gist is that there is something here, but the sample size is too short to be sure. I won't repaste their entire analysis since I think they do good work and it's worth paying for. :)

I stumbled upon this discussion, and was a bit startled to see retail customers even contemplating trading an institutional product with the complexity of the VIX. Curious as to how many realize, for example, that the VIX futures expire on a Wednesday (not a Friday) thirty days prior to the third Friday of the calendar month immediately following the month in which the contract expires, and the special (HOSS) settlement is based on a huge series of SPX option strikes (not just ATM). The devil is in the details.

Since the publication of my paper quite a few people have emailed me asking me questions about my calculation of the VRP that they wouldn't be asking if they understood the gist of the paper. After answering a few of these I realised that I was doing them harm by not letting them work it out for themselves.

So even though investing in VIX futures is "easy" it's not for everyone and to that extent I agree with @Abraham Kohen.

Yes, we are talking about a system to trade etfs that systematically trade futures on an index composed from the volatilities of options of the components of an index. It's nightmarishly complicated.

But, two counterpoints:

1) there are a lot of institutions that don't understand them either
2) alpha is with the devil in the details.

EDIT: wrote that quickly while I was walking and it came off a little trite. I agree that these instruments are dangerous, and that systematic trading is dangerous and doing either of these things is likely to bankrupt more folks than enrich. Still, I lean towards exposing, sharing and vetting these ideas. I learned a lot reading about VIX futures and options back when I started, even if my personal decision was not to trade them for the time being.

Yes, the fact that there are a lot of institutions that don't understand them is scary. Even more so when it is retail traders, who don't have the capital, the utility function, or the risk tolerance that institutions have.

Siimon,

Thanks for providing these interesting algotithms. I've been paper trading a few of them to learn how they work, and one thing confuses me. My sense of Tony Cooper's VRP system is that it is either in XIV or VXX. Your algorithms seem to borrow on margin under certain conditions. Could you explain the reasoning behind this feature, and, if you don't mind, what the conditions are that the algorithm is looking for in order to invest on margin?

Thanks,
Alex

If you are paper trading it, you are ahead of me, I haven't looked at it in a couple of months. Using margin wasn't intentional, it's a bug, presumably in the position sizing.

So far, it's a profitable bug. But, of course, XIV has been on a tear of late.

Some clarification of my remark of July 10 above:

My formula for the VRP is:

5 day moving average of (VIX - 10 day historical volatility)

My opinion is that someone who can't calculate a moving average or the historical volatility of a market should not be trading the VIX. I am not licensed or permitted to give financial advice to people so I can't tell such people that they should not be trading.

The paper points out many different ways of estimating the VRP - these are only 'estimates.' The VRP is not an absolute number that can be calculated, it is only a concept. So my formula above is certainly not the best one around. I used it for academic illustrative purposes.

The big danger in trading the VIX is regime change. If you are trading using a formula that you found in a paper that you don't understand then you won't be able to relate what's going on in the market to your trading. When the regime changes you may start losing and not recognise why.

You should trade the concept of the VRP and not a particular formula.

Also note that my formula comes with a Grim Reaper icon. That is a warning that the formula will do worse in the future than in the past. If you don't understand that concept then you should not trade ANY formula. How much worse? Well you should play around and figure that out for yourself.

Why would you trade a formula that some guy in a paper says will perform worse in the future? You must be nuts to do that.

The scientific approach is to understand the concept of the VRP, work out some formulas for calculating it, try them out to get a feel for how they work and HOW ROBUST THEY ARE. Then pick one you feel safe with. Monitor it and the market closely. When the regime changes, change your formula.

Hello everybody,

I implemented Strategy III from Tony's paper based on Simon's implementation of Strategy IV. Given the paper was publish in April I like to test everything for the period April-today because I find it more meaningful (despite the limited time frame). Over this limited time frame it looks like Strategy 3 beats 4 (but I don't think the test is that meaningful). Strategy 3 is very powerful because there is very little that can be optimised and it gives interesting results. I've not added the SMA soothing that Tony suggests but I plan to add it in the future to check if it improves somehow the returns. On the other hand, I've added the standard deviation filter Tony discusses in his paper. I welcome any comment or suggestion.

Aurelien: as far as your question on shorting vxx vs. being long xiv, the way I look at it is that shorting vxx involves an unlimited risk. On the other hand being long vix the risk is limited to the invested capital. However, there might be more to it.

Umberto

Regarding Aurélien's comment:

Using the standard deviation of the S&P500 prices rather than the returns is an example of the fact that there are many ways to estimate the VRP. If you try many and use the best the Grim Reaper will strike. If you try many and use the worse then the Grim Reaper may come along and give you better returns in the future. I would suggest trying many and using one from the middle of the distribution.

Asking why shorting vxx is more profitable than being long xiv assumes that it is. It may not be. I would want to see a test of statistical significance before asking the question. I wouldn't assume much from your sample size of one.

I tried many different combinations and calculations. I didn't find any significant difference between most of them. Using ZIV and VXZ did reduce returns - but not for regime 5. The regimes seem to have more effect on performance than the formulae traded.

The VIX doesn't even have to move. There is a "significant chance" of the volatility ETNs going to zero even if the VIX remains flat. That's a quote from the VelocityShares prospectus.

If you don't understand these products (for example you don't know how to calculate historical volatility) then they are not for you.

Agreed, though that bug is only in my first attached backtest and Rich's unfortunate copy of it. I don't know how I can go back and correct the original post, or if it's even couth to edit posts like that.

Interestingly, a "functions for the market" out today (bloomberg note) regresses the VIX against the SPX price levels (as I incorrectly did in my first algorithm), as a measure of the historical skew over short time frames. Not relevant for anything to do with this system, but interesting that some people do this intentionally!

It's called marketing. It's not a hedge fund revealing their secrets.

Marketing for whom? I don't follow your argument.

There is a .86 correlation between "dow future" google searches and vix: http://www.google.com/trends/correlate/search?e=id:7XkwqWkbvoS&t=weekly&p=us

The correlation is slightly off because the number of searches is down on saturday and sunday. This may help predict the price of vix?

I found this discussion fascinating, even though I am a bit late to the party. Still hoping that some people are still checking this discussion out. I decided to first replicate Tony's findings using an Excel model, but I have to agree with John ("My model gives negative VRP/XIV sell signals on March 3, 2013 and April 18, 2013"). I got sell signals on 3/5/2013, 4/11/2013 and 4/18/2013 - I used the SP500 Index closing values instead of SPY, so I'm not sure how Tony didn't receive a sell signal from Feb 2013 to Jun 22 2013 when he posted his comment regarding trade status. If anyone has been able to solve this discrepancy, I'd love to hear how you did it.

what hapens if you use SVXY instead and rebalence 50/50 of portfolio from SVXY to spy daily or weekly so the gain from SVXY are moved to spy durring good days and in bad days you buy more SVXY . and what about 50% T-bonds 50% SVXY

Give it a shot!

Has anybody fixed this code so batch transform isn't required? It's no longer supported in the current Quantopian. My python zen isn't strong enough to figure out how to eliminate it and change over to history(). If have fixed it, it woul be great if you could share the changed code. The offending line is: @batch_transform(window_length=10, refresh_period=1).

Hi Chandra, here's a version of the algorithm that uses history instead of batch_transform. There are some differences in the returns between this version and the original algo from 2013 because there were updates and fixes made to the backtester. Enjoy!

Might be worth someone's while adapting this strategy to try out the changes mentioned here:

http://www.tradingtheodds.com/2014/11/ddns-volatility-risk-premium-strategy-revisited-2/

It's shown some absolutely bananas results, 70% annualized return...

More info here: http://quantstrattrader.wordpress.com/2014/11/14/volatility-risk-premium-sharpe-2-return-to-drawdown-3/

I have a question, in the calculation of volatility, why isn't it
hvol = pandas.stats.moments.rolling_std(spy, 10) * math.sqrt(254/10)
rather than
hvol = pandas.stats.moments.rolling_std(spy, 10) * math.sqrt(254)
Don't we have to adjust for the length of the volatility calculation?

No, the 10 is just the window over which we are calculating the volatility as ... hmm... not sure if I can type equation markup in here, but the 1/(n-1)*(sum of squared deviations). This will produce the standard deviation of a day. The sqrt(254) is just a dodgy way of annualizing that standard deviation to produce an 'annual' volatility.

Something is wrong with the code, but I haven't figured it out. Most of the time, say 80% or thereabouts, implied volatility is higher than realized volatility.But the graph shows that the exact opposite. The vrp should most of the time be positive. I think something is amiss.

The first backtest was definitely bugged, but it's impossible for me to correct it. Later ones were correctly using the standard deviation of returns, not prices.

Right you are Simon. I was using the last version posted from Alisa Deychman, which uses History, but was based on the first version you posted, not the fixed version. I'll play with this some. If I get any additional insights, I'll let you know. Thanks for you help. There are a few issues with using history, but they are solvable.

Hi, with some modification to the Alisa's code and fine tuning of threshold - Florent

Nice!

All of these simulations are Daily mode. Does anyone know when the daily algorithm buys and sells, and at what prices. Do they use close prices to do calculations, and then buy or sell at the open the next day?

I believe daily mode orders are filled at the following day's closing price. Generally orders are filled at the next bar's closing price and in daily mode 1 bar = 1 day.

Thanks Matt. I wouldn't have expected that, but it makes sense.

I cloned the latest algo, and for fun tried to run it in the Live environment with paper trading. I received a runtime error:

AttributeError: 'SIDData' object has no attribute 'price'
... USER ALGORITHM:41, in get_vrp
vrp = current_vix.price - hvol

I found it interesting that the live environment would show an error compared to the backtesting environment since its the same code. It doesn't like the "current_vix.price"

I found it interesting that the live environment would show an error compared to the backtesting environment since its the same code. It doesn't like the "current_vix.price"

I think this is because it uses VIX prices from a CSV, and it's looking up a price that doesn't exist.

Try with :

    if 'price' not in data['VIX']: return  
    if 'price' not in data['VXST']: return  
    if not(context.spy in data): return  
    if not(context.xiv in data): return  
    if not(context.vxx in data): return  

Hi All,

I made a Zipline version of this as a learning exercise.

best regards,

EDIT: And now I see it's using the wrong volatility calculation.

Yeah I really wish I could go back and edit that post, it's terribly misleading.

Hi Folks,
Before we further discuss these algorithms, I would encourage you to take a look at this and give your opinions:
https://www.quantopian.com/posts/quantopian-miscalculation
This would helps us better understand the day level back test results. IMHO, the daily back tests we saw here are far from reality. That make our discussion here less meaningful.
I could be wrong, I hope I am wrong, but I think I am correct:)

I second Alan suggestion and recommend anyone following this thread to read the one posted above, the return of this strategy is actually -5% when adjusting for Quantopian INCORRECTLY calculating daily trading. I'm still not sure I understand, it is trading of the NEXT day close AFTER a signal, so even though it's a day late there is still no look ahead bias? Or is it the opposite?

I'm not sure this is as bad as you're making it out to be. Isn't Quantopian's daily order behavior essentially the same thing as placing a market-on-close order the following day?

I would think a 24 hour lag between signal and execution is a pretty big deal, especially if one is unaware of it. The other interesting thing to consider is why the strategy performs so much better on a 1 day lag then market on close the same day as a signal? Unless I am missing something with timing of execution & signal.

Sounds like a bug tbh.

Yeah it's not ideal. My point is that at least it's behaving in a way that one could actually behave in real time if one were so inclined (as opposed to placing an order today using tomorrow's signal, for example).

Better link http://www.naaim.org/wp-content/uploads/2013/10/00R_Easy-Volatility-Investing-+-Abstract-Tony-Cooper.pdf

One side though - kurtosis can be very larger