Back to Community
VIX trading algorithm return 150% a year over past 5 years but has 50% drawdown from 2015 meltdown

The algorithm switches between XIV, UVXY, and UPRO depending on the VIX level and the term structure of the first two month VIX futures.

Any comments on how to make this algorithm better?

Clone Algorithm
576
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 572667f32121bf0f69087a7a
There was a runtime error.
392 responses

Wow! This is an awesome algorithm, great returns!

I trade volatility and noticed this shift in market behavior too. The truth is that the volatility ETNs have not been around long enough to do better analysis. We still have not seen them go through a recession so we don't know how they would behave. I guess time will tell.

Okay, so I took your algorithm and did the following:

  1. Accounted for SPY MACD moving averages
  2. Accounted for CBOE put/call ratio

Resulted in lower drawdown and higher returns, especially when the timeframe is increased through today.

Clone Algorithm
278
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 57dcbcd8fb4f8e10204f60ec
There was a runtime error.

The biggest problem with this algo is the beta. It is WAY too high. Without reducing the beta, the algo is very risky to trade in the real world.

I know its similar, the same base algorithm as last time.. But I'm working toward lowering the beta on this.. The returns are too good to pass up.

Dramatic change, still thinking of other datasets to utilize..

Clone Algorithm
278
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 57dcd2e8e7b59a131be003b9
There was a runtime error.

Again attempting to lower the smoothed beta.

Clone Algorithm
28
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 57dd9ada8fe3251030911dcc
There was a runtime error.

Hi Joseph --

I'm very interested in the volatility-type systems and am following along. A few comments on this algo:

  1. It seems to have done very well during the August 2015 event, but not so well during 12/15-2/16 or during Brexit. Just an observation, but curious why it was positioned on the right side in Aug 15 but not so well during the other two down drafts.

  2. Playing around with it, I can get lower drawdowns and beta by allocating a portion to something like TLT instead of being all-in XIV, UVXY or SPY. Returns drop substantially as well but are still significantly larger than buy/hold SPY. Is this considered "cheating"? Even a 50/50 ratio of "X" to TLT does help with the volatility.

  3. Is there any merit in being out of the market overnight? Since the algo is trading off the prior day's close, but it probably wouldn't matter much, which leads me to:

  4. Is there a way to get intraday VIX data? Or do these algos benefit from the inherent smoothing of only looking at closing prices?I watch the vix/vxv ratio during the day as a way to gauge contango level. My threshold is around .9. If less than .9, contango (and long XIV) is the play. If >.9 I tend to just stay out as VXX gets crushed when volatility falls and the roll yield takes its toll. In the latest few days, the ratio never quite got to 1 (i.e., never reach backwardation). So, would it help to know the real-time contango level or do we need the filtering of only looking at the close?

Any way -- interesting stuff.

Here's an example of giving 50% to TLT and reducing the exposure to UVXY. Nothing like the returns from the original algo, but 20% drawdown and still 6 times the return of SPY. Pick your poison...

Clone Algorithm
45
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 57ddbe870c091b103975d7e2
There was a runtime error.

@John Galt: Lowered your beta and increased your returns. Simply changed the ratio of shares bought. Check a DIFF of our two sources.

Clone Algorithm
39
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 57de31d7eb7c0910406cd781
There was a runtime error.

@Joseph Orlando,

Why are you putting the date filter param on the fetch_csv url on line 51 of the latest algo posted? That may be throwing off your results. Let me know if I'm missing something.

When adjusting the put/call ratio to use all available dates, performance was significantly negatively impacted. So I took PCR test out, and allocate 50/50 to either XIV/TLT, UVXY/TLT or 100% to SPY.

Clone Algorithm
64
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 57ded369c8571b1034ddc847
There was a runtime error.

One other item to be careful with here is the update time for the VIX futures contract data. The OP algo is set to run every morning 1 min after market open. From what I'm seeing - the VX1 and VX2 futures prices don't update with the previous day's data until later. So the algo would be executing with day old data. I setup a script to ping my own quandl account endpoint to check for updates every minute. So I should know when it updates soon and I will pass along that info here. As of writing this, the quandl endpoint still has not updated.

UPDATE: Quandl data for the VX1 and VX2 futures contracts updates around 11:00 ET daily.

In Paper trading current data points (v, v1, v2) appear as NaN. I first thought it was because of data delay (Quantopian apparently refreshes before midnight ET) so I changed to shift(2) but it still is NaN. It is very hard to debug stuff in paper trading, any ideas why is this happening?

Hi,
The same happened to me. Data in paper trade was nan, but was ok in backtesting . I replaced fetch_csv by vix pipeline and custom factor.
You may check this post: https://www.quantopian.com/posts/upcoming-changes-to-quandl-datasets-in-pipeline-vix-vxv-etc-dot

@Vladimir, try to adapt these lines to your algo. Perhaps that can help.

from quantopian.algorithm import attach_pipeline, pipeline_output
from quantopian.pipeline import Pipeline
from quantopian.pipeline.data.builtin import USEquityPricing
from quantopian.pipeline.factors import CustomFactor, Latest
from quantopian.pipeline.data.quandl import cboe_vix, cboe_vxv, yahoo_index_vix
...

class GetVIX(CustomFactor):
window_length = 1
def compute(self, today, assets, out, vix):
out[:] = vix[-1]

def initialize(context):
pipe = Pipeline()
attach_pipeline(pipe, 'my_pipeline')
close = Latest(inputs=[USEquityPricing.close], window_length=1)
pipe.add(close, 'Close')
pipe.add(GetVIX(inputs=[cboe_vix.vix_close]), 'VixClose')
pipe.add(GetVIX(inputs=[cboe_vxv.close]), 'VxvClose')
context.vxx = sid(38054)
...

def before_trading_start(context, data):
context.output = pipeline_output('my_pipeline')
context.vix = context.output["VixClose"].loc[context.vxx]
context.vxv = context.output["VxvClose"].loc[context.vxx]

def my_rebalance(context, data):
last_ratio = context.vix/context.vxv
log.info('VIX pipe: %s' %context.vix)
print "last_ratio:",last_ratio

Thanks Roberto

I finally got time to implement pipeline instead of fetcher.

Since vxv does not match VX1 more tweaking needs to be done with ratios.

Clone Algorithm
32
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 583e3593e97c6c5e79a8535c
There was a runtime error.

Here is my version, i added a mean reversion portion that tries to profit from the mean reversion in addition to harvesting contango

Clone Algorithm
94
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 5846216e8ad0735e7260f8d3
There was a runtime error.

Here is a version that uses pipeline to pull vxv instead of the fetcher, it may better suit for live trading. I didnt use MACD to time the trade, as it looks like doing nothing to decrease the beta / increase the returns

Clone Algorithm
134
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 58463650fe8cf3624ba3812d
There was a runtime error.

I used the front month since 2004 to ascertain whether the VIX was in contango or not - it has been in steep contango for the vast majority of the period. I then took each front month and shorted when there was contango, exited the trade when there was backwardation. On a daily basis.

The system has been profitable since 2004 with very high volatility and drawdown.

Futures would certainly be a better route than an ETF - you can decide your own leverage if any.

However: will this trade last? I have no idea.

@ Joseph Orlando . Thanks for creating an outstanding algorithm. The returns are amazing.
I have one question about the PCR condition to place the xiv trade. I see that the data for PCR is obtained only for certain dates.
fetch_csv('https://www.quandl.com/api/v3/datasets/CBOE/TOTAL_PC.csv?api_key=n3HuGP2EiSi-x9x8sB_q&start_date=2016-06-01&end_date=2016-09-23'

Can you please clarify?

When I remove the dates in the above link, the returns come down a lot.

Thanks again for your effort.

Joseph,

I really liked your algo that improved the performance of my original one by a factor of 1.3x annually! I am not a professional trader and for my personal account I am fine with a 50% drawdown, and I don't lose sleep over high beta either. But the NaN error is still there, and I don't want to use VXV. There are plenty of VXV algorithms out there. I was to read the vix futures. Here's hoping that Quantopian can solve this NaN issue soon by introducing futures data live.

Thank you!
Macro Investor

I tweaked the algorithm some, here are the results. About 230% return each year.

Clone Algorithm
113
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 5897a53748be4e61a0330b44
There was a runtime error.

Here's a low beta version of the algorithm.

Clone Algorithm
98
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 5898ac79a386bc621516a9ea
There was a runtime error.

And this version basically makes beta 0, increases returns to ~100% each year, lowers drawdown.

Clone Algorithm
98
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 5898c000edfd375e4172233c
There was a runtime error.

@ Macro - can these be traded live, or do they have the same issue as the earlier algos?

They can't be traded live till futures are implemented into Q. I have been trading the very first model live using spreadsheets, but manually and not automated.

2017-02-03 13:00 pvr:199 INFO PvR 0.1331 %/day cagr 1.0 Portfolio value 41790
2017-02-03 13:00 pvr:200 INFO Profited 40790 on 22839 activated/transacted for PvR of 178.6%
2017-02-03 13:00 pvr:201 INFO QRet 4078.96 PvR 178.60 CshLw -21839 MxLv 1.80 RskHi 22839 Shrts 0
2017-02-03 13:00 pvr:294 INFO 2011-10-05 to 2017-02-03 $1000 2017-02-06 15:36 US/Eastern
Runtime 0 hr 3.7 min

It catches spikes very well, namely October 2014 & August 2015. Outside of those, the returns come back to Earth, though it beats the market.

Can anybody explain why the start_date and end_date are fixed to a few months worth of data? Shouldn't they be the same as the backtest length?

https://www.quandl.com/api/v3/datasets/CBOE/TOTAL_PC.csv?api_key=n3HuGP2EiSi-x9x8sB_q&start_date=2016-06-01&end_date=2016-09-23

If you are going to take a 25-30% DD might as well take a 50% for 4x-5x returns, throw $5,000K at it hope you get 5 years of market increases and no 2008 and you are good lol.

This algo is untradable live right now anyways - until futures are made available

I changed the algo to actually get all the PC data with this line

https://www.quandl.com/api/v3/datasets/CBOE/TOTAL_PC.csv?api_key=n3HuGP2EiSi-x9x8sB_q&start_date=2011-01-01&end_date=2017-02-01

It no longer gets that great spike up in 2015 - though still has pretty decent returns - with a high drawdown.

I am not sure the PCR is adding much. So I eliminated it completely. This new algorithm gets all the spikes.

Clone Algorithm
242
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 589e7edea26c915e04e93b5e
There was a runtime error.

Can someone explain why the algorithm is not tradable live? When I search for info about the csv fetcher, it seems like it works okay: https://www.quantopian.com/posts/fetch-csv-during-live-trading

"initialize() is called only once at the very start of your algorithm. However, fetch_csv() is called every day in live trading"

I second that. Can someone please help explain how to trade the latest version of this algorithm live until futures are made available?

It's been a while since I looked at this algo but one the key points is that as josh nielsen mentioned above, futures are updated everyday at 11am Tues-Friday. If you're executing trades at market open, you're front running your data and getting invalid backtest results.

I haven't seen any reason why this algo can't be traded. Algos can download remote csv data from sources such as quandl I believe. I haven't done this so I may be wrong though.

There is no front running of data. That is taken care of in the code. Hence, the backtest results are fine.

I have tried to run the algorithm live and got NaN error. Same has happened for others. In a few months we will get futures on Quantopian and this algorithm could be run live then.

In python NaN stands for "Not a Number". There is a bug in your code somewhere and needs to be debugged.

If you are scheduling your rebalance at market open, then you are front-running the backtest data. Those CBOE csv files are updated at 11am Tues-Friday. If you run it now, there is no row for today's data yet and is probably why you would get NaN.

From you're most recently posted algo:

schedule_function(my_rebalance, date_rules.every_day(), time_rules.market_open(hours = 0, minutes = 1))  

The rebalance should instead be done an hour and 31 minutes after market open (11:01am).

Peter, Please, look at the whole code, especially where the values are fetched (rename_col1). There is no front running.

As for why the NaN, yes, it is because when the algorithm is run, there is no value yet. But that does not mean the algorithm should be run late. The algorithm should be run when it needs to be run. The algorithm simply needs a better data source, which is coming.

I might not have explained it well enough. Futures data isn't available until 11am. It doesn't matter the data source. It's how the futures contract data is made available by CBOE: http://cfe.cboe.com/data/cfemktstat.aspx

It says:

PLEASE NOTE: CFE Data does not become available until approximately 10:00 a.m. C.T. the following business day.

10am CT because they are in Chicago == 11am EST

So in your algo, you have X amount of years of history. You execute your trades at 9:31am because you have the historical data but in reality, that data wasn't available until 11am. So trades you make in your algo, are done in advance of when they really could have been made. This is front-running the data.

If the above link isn't enough to convince you, tomorrow morning at market open, manually download that CBOE csv data and see if it has an entry for that day (it won't). At 10:58am, start downloading the file once every minute and wait until you see the current day show up.

I hope this helps.

Peter,

Once again, we are talking at cross purposes.

1) Is the backtest right? Yes, it is, as the futures values used at 9:31 am are the closing values for the previous day. Which is the intent. Do you agree? Let's settle this first.

2) Is it possible to run the algorithm at 9:31 am in general? The algorithm needs closing values for futures for the previous day. This data is freely available from multiple sources including CBOE (http://www.cboe.com/micro/vix/vixfuturesprices.aspx). So, yes, it is absolutely possible to run the algorithm at 9:31 am in general.

3) Is it possible to run the algorithm at 9:31 am withe CFE data using fetch_csv? No, because that data is refreshed at 11 am. But I already told you that is the case.

So what's your point?

Bottom line, we need to be able to fetch futures values live in order to run this algorithm live. I believe Q is working on that. If not, I will go for another trading platform to implement this.

1) Is the backtest right? Yes, it is, as the futures values used at 9:31 am are the closing values for the previous day. Which is the intent. Do you agree? Let's settle this first.

No. The futures values for the previous day are available at 11am. Not before. (And also likely why you get NaN)

2) Is it possible to run the algorithm at 9:31 am in general? The algorithm needs closing values for futures for the previous day. This data is freely available from multiple sources including CBOE (http://www.cboe.com/micro/vix/vixfuturesprices.aspx). So, yes, it is absolutely possible to run the algorithm at 9:31 am in general.

No - see #1. Plus CBOE isn't a data feed aggregator like quandl, it is THE source for futures contract data that this algo uses.

3) Is it possible to run the algorithm at 9:31 am withe CFE data using fetch_csv? No, because that data is refreshed at 11 am. But I already told you that is the case.

The answers to #1 + #2 makes this question irrelevant.

I'm going to have to retire after this reply. EOD here. Best of luck with everything!

Bottom line, we need to be able to fetch futures values live in order to run this algorithm live. I believe Q is working on that. If not, I will go for another trading platform to implement this.

Sorry last thing. This isn't a limitation of a trading platform or a data feed. This is set by CBOE.

Best!

Best of luck to you too Peter.

You are wrong, however.

1) Anyone can print out the date and the vix futures values that the algorithm uses during backtest and then cross check with actual data to see that the backtest indeed uses the correct values. Evidently, you won't do that, and would rather just say without basis that the backtest is wrong. But I have, and the algorithm is correct.

2) CBOE provides the actual value of the vix futures at any given time. (You could have just clicked on the link that I provided, but evidently, you won't do that, and would rather just say that it is not possible.) People trade these live. To claim that the end of day value for VIX futures is only available after 11 am on the following day is laughable. I suspect you have never traded these futures yourself. I have.

3) The problem is with the way Q pulls the data. That's a data source problem, and not a market problem.

Interesting algorithm. Is there an empirical reason for the cutoffs/ratios? I do wonder if the numbers are causing some overfitting of the data.

So, Macro Investor, from a practical perspective, if I wanted to trade this manually, I could just take the VIX futures index values after closing each day from Yahoo, enter them in a spreadsheet with your formula, see if anything needs doing and if yes, enter the trade on my broker's site any time before the next market opening? And just to make sure I'm not misunderstanding: the two relevant values would currently be ^VIXFEB and ^VIXMAR?

This is where the numbers come from. I took VIX and VIX futures data from the day they started trading (3/26/2004) to the day before the backtest start (10/5/2011), which is also the day UVXY started trading. I calculated the ratio and set the two boundaries at the median and the 95th percentile. That, rounded, amounts to -4.5% and 6.8% respectively. No reason really, but I wanted to be long XIV about half the time. I added the UVXY later, since I found that while in general holding UVXY is crazy, there are some times when it makes sense. and I made the 6.8% into 6.5%, as 6.8% seemed too well fitted.

I was curious as to what the cutoffs would be for out of sample so I just checked with data from 10/5/2011 to 2/10/2017. They are and -6.7% and 3.1% instead. -4.5% and 6.5% amount to 70th and 98th percentile respectively. So, compared to the out of sample period, the in sample period is going long XIV far more than designed, and is holding UVXY far less than designed. Not sure if that is a good or a bad thing.

One thing is clear, average contango has definitely increased. Which is what one would expect as the hedgies all pile on VXX and hence make the inverse trade all the more better.

Hey Macro Investor, I apologize if this is a dumb question ahead of time. But do you think there is any utility to continually rebalancing the portfolio throughout the day, say everything 30 mins, instead of just at market open? Thanks.

You can, if you can pull the vix futures throughout the day. Right now Q doesn't even allow pulling them at the open for last day's close. Sigh.

Added a little long-short flavor to the algo. Improves returns, but also beta and drawdown (marginally).

Clone Algorithm
242
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 58a64c524e657a61a044c3ea
There was a runtime error.

Hey Macro Investor, thanks for the modification and the answer to the previous question. I've modified the algo to run after 95 minutes since the current data structure doesn't pull the values till 11 am. But running the algo after 11 am still results in nan results for last_ratio_v_v1, last_ratio_v1_v2, and last_ratio. Any idea why this is still occurring since the data is supposed to be there at 11 am with the current setup? Thanks in advance

Hey Macro Investor, thanks for the modification and the answer to the previous question. I've modified the algo to run after 95 minutes since the current data structure doesn't pull the values till 11 am. But running the algo after 11 am still results in nan results for last_ratio_v_v1, last_ratio_v1_v2, and last_ratio. Any idea why this is still occurring since the data is supposed to be there at 11 am with the current setup? Thanks in advance

Mark, if you're trying it today, it's a Quandl issue. They very often do not update the futures on Fridays, so you'll have to wait until Monday.

I Tried it not on a Friday, ran the backtest and same results, so something else is up.

Thanks Dave and Elsid, I'll also try it again on Monday to see if I get the same errors.

It's useless to try it till Q supports futures.

Still showing good results if traded after 11 am. Just not sure why the nan error is still occurring if the problem is trying to pull the Quandl data before 11 am. Trying to get to the bottom of the error. Thoughts?

Clone Algorithm
6
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 58a75b5e38ac945e2311eaa0
There was a runtime error.

@Mark

You still have 55% DD, how is that great results? You will get blown out in 08' type scenarios

Anyone live trading this right now?

Elsid, In a 2008 scenario this algo will go long UVXY and give 5-10x return in a matter of weeks. It won't go bust at all. In fact this algo makes most of the money when it can go long UVXY.

If you check the Quandl data the CBOE_VX1 does not have any data for 2/16/17 - might be your issue?

Yeah it should in a perfect scenario, it could barley handle the 2nd half of 2015, doubt it would do any better in 08' or an even worst 08'

I have backtested it from 2004 onwards simulating the VIX ETFs using VIX futures data. Elsid, you should do the same before making random statements. This algo will work like a champ if we get another crisis.

Can you please post the results? And the statement about long UVXY I changed XIV and UPRO into a general money market fund and UVXY performs abysmally, 456% with 40% DD in 5-6 year period.

The results are in Excel as the VIX ETFs were not trading in 2008. But since you first claimed that the algo will blow up in 2008, surely you have backtested that and can post those results first?

The algo only goes long UVXY 2% of the time, so the result you get is not a surprise. I don't think you understand the algo at all Elsid.

Axel, You are right. You can manually trade the algo. But you need to put the order as close to the market open as possible, as the later you put it in the more the information loses it's value.

I've been trying to wrap my head around the large drawdown right after the Trump election. The algo has you go long UVXY, which makes sense given the rising VIX leading up to the election. Once the election results were out, the VIX settled down. This just baffled me. Any thoughts would be appreciated.

I read an article on zero hedge that discussed how the VIX was severely dislocated during that time. I wonder if incorporating a trailing VIX or real vol indicator would be of benefit?

http://www.zerohedge.com/news/2016-11-07/goldman-warns-one-largest-vix-dislocations-record

Marco you said the Algo makes most of it's money going Long UVXY which is clearly False, nothing to understand here, that is what you said that i what I tested to see if it was able to lower DD. Then you go and say the Algo is only in UVXY 2-3% of the time, so how can it make most of it's money from UVXY? I just don't understand when people say good results with 50%+ DD. If you want to throw 5k-10k at it and gamble that's fine.

And no I haven't tested it in 08', and when you post your exact testing method to verify it's correct, and even then the ETF's can have tracking issues to the underlying security. The point that it could barley handle 2015 which was nothing crazy, don't see how to handles severe sharp down days, without a 50%-70% DD in 08' when VIX hit almost 90.

The algo definitely makes most of its money when holding UVXY. Just look at the daily positions & gains in the backtest.

This is the backtest trading only long UVXY and Cash the other times (MINT)

Clone Algorithm
0
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 58a771a1e382b15e0f4c18bf
There was a runtime error.

Josh,

The major "error" that the algo makes post election is thinking that the volatility spike will be sustained. But as we all now know, instead it settled quickly and then there has been a long rally. The algo realized that and quickly changed course, and recovered all of the drawdown, but that one "wrong" UVXY trade hurt it badly.

Why did the VIX spike settle rapidly? I have no clue. But in a 2008 like situation where there is a long and sustained VIX spike, the algo will be in hog heaven.

Elsid,

The long only algo makes about 300x in 5.5 years. Of that, it makes about 6x from UVXY by being long UVXY only 2% of the time. About 70% of the time it is long XIV and makes a decent 10x return, while it is long UPRO 28% of the time and makes another decent 5x return.

So, yeah, the biggest bang for the buck for the algo comes when there is an opportunity to hold UVXY. Those are short and inmensely profitable trades. As I said, you don't understand the algo at all. But others do.

I have been writing investment articles on seeking alpha for a while, and posting algorithms on Q these days too. I have realized one thing. I can show all the proof and the data, but naysayers like you who simply don't like the 50% drawdown will always come up with some excuse as to why all backtests are wrong. Regardless, since 2008 was a sustained VIX spike the algo did fabulously well. you may not want to believe it, but that's your choice.

Any time I waste on you is something I will never get back. So, adios.

Macro

The algo from yesterday with 44k% returns started with $500 and made $176,566 on top of that.
It took $183,808 to achieve that $176,566, so real returns are 96.1%, below the benchmark at 124%.
Quantopian allows infinite margin/borrowing and in the returns assumes only the starting capital ($500 in this case) was used.
Keeping this in mind can save a lot of time. Use PvR to see more clearly.

I have realized one thing. I can show all the proof and the data, but naysayers like you who simply don't like the 50% drawdown will always come up with some excuse as to why all backtests are wrong. Regardless, since 2008 was a sustained VIX spike the algo did fabulously well. you may not want to believe it, but that's your choice.

I understand your frustration but I think there is another side to the story. I don't happen to like this particular algo but have spent several months devising my own to trade XIV and VXX. My back testing was done by backfilling the missing ETN prices to 2004 using futures prices.

In back testing the algo produces a CAGR of 98% with a max DD of around 70%. It has a single parameter.

I have been trading the algo now for a couple of months with small capital.

Unfortunately my experience has been over many years that whatever back testing says things will turn out differently going forward.

I fully expect XIV to go bust at some stage or at least reach the 80% drawdown at which the sponsors are entitled or obliged to shut it down. I hope that my algo will have me out before then but I am not counting on it.

I will rebalance between the algo and cash at regular intervals but of course even this will lead to ruin if the algo goes bust several times.

Our greatest physicists are unable to predict the future. Will the universe end with a bang or a whimper? We do not know. Does time even exist? We do not know.

So "as to why all backtests are wrong": they are not "wrong" as regards what they are competent to show (the past) but it is a brave man (or a foolish one) who believes they say much, if anything, about the future.

Trading forums are populated by an odd mix of characters. There are no-hopers looking for an easy way out of their dull jobs, competent (and incompetent) statisticians and software designers, people with maths skills, people with no apparent skills, successful "traders", unsuccessful traders. At different times I have fitted some of these categories and certainly my success has gone and come and come and gone.

There is however no certainty. And that is what almost everyone here is missing. The biggest fools of all are those who believe otherwise.

No offense intended - I have already caused enough offence on this forum.

A backtest is a simulation of trading, not a model of the future. So, one can conjure up any old trading recipe, but if it is based on a flawed model, then it will be illusory. The physical models of a universe with the Earth at its center and light propagating in the luminiferous aether were just fine and dandy, until somebody realized they were wrong, with a combination of logic/math and observations/experiments. The same goes for finance, it would seem. One works with incomplete/flawed models that can eventually be replaced with better ones as new information becomes available.

Regarding XIV and VXX, what's the model for trading them in combination? How do they work?

I think I may be misunderstanding something about the data and its availability. I use the same URL's as the algorithm and I can pull that days data down about 4 hours after market close. So if the algorithm ran the next day, surely it would by then have the previous's day's data. ... What am I mis-understanding/missing where the data is not available till 90 minutes after market open?

Kevin, Quandl doesn't update CBOE_VX1 and CBOE_VX2 until the next day around 11am. As of Saturday 2/18, VX1 doesn't have numbers for 2/16 and 2/17 and VX2 is missing 2/17, and won't until Monday after 11am. These algos also shift the data by one day, so running the algo today, it'll use the VX1 closing value from 2/14 (11.175) for the 2/15-2/17 backtests. It isn't much of an issue unless you wanted to trade it live.

Regarding XIV and VXX, what's the model for trading them in combination? How do they work?

I don’t consider myself any sort of expert on the matter I’m afraid but these instruments are simply opposite sides of the same coin. It’s all about options and futures. These derivatives are not just for speculators: some fund managers buy volatility as a hedge against a long portfolio of S&P Equities. Volatility has tended to rise during market crashes and hence has provided a balance to falling equity values.

So as a holder of XIV I am effectively selling insurance to fund managers for a premium. The premium can be seen in the contango between (by way of example) the front month futures contract and the spot VIX. The premium will go down as contract expiry approaches in the same way that an options value decreases over time. Most of the time. And at expiry, the option writer can sell a new call on vol for a further premium and the seller of futures can sell the new contract for his return – contango, the positive difference between the front month price and spot VIX.

So it works like any other insurance product: the insurer collects premiums and profits when (and only when) the policy holder makes no claim. The market is in contango 75 to 80% of the time and volatility tends to move sideways (not sharply up). So for most of that time a seller of volatility (insurance) collects the premium and profits. XIV is selling premium and therefore goes up in time unless there is a calamity when it will get wiped out. Just as any insurer can get wiped out if he has overplayed his hand and not re-insured any of the risk.

The object of these systems is to collect that insurance premium while it is there and to exit the market when it is not. As a bonus, if you can get the timing right, when contango disappears in a mega crisis you reverse the trade instead of going flat. You buy volatility: go long futures, buy a call, buy VXX the inverse of XIV.

The existence of contango or its opposite (backwardation) seems to be a good trigger, a good indicator. And that makes fundamental business sense: it’s a business: sell insurance for a premium when you can. Pack up business or do the reverse trade when there is no contango or when contango does not cover the risk of rising volatility.

Its difficult to get the concept of contango and backwardation without looking at the charts of simultaneously trading futures contracts with different expiry dates. And also you should build concatenated time series simulating being long and short of these contracts. That way you get to see exactly how this premium works.

I wish I could post examples here – it’s a lot easier to describe all this with pictures and figures. But there you go!

The reason I like this trade is not that I believe it will necessarily last forever but that at the moment it makes genuine commercial sense. You are selling insurance and like any insurer you are relying on statistics to try to provide that the premiums you collect will, over time, cover not only the occasional claims on the policy but also give a profit margin.

This is exactly the sort of trade despised by Naseem Taleb who (probably rightly) says that the Black Swan will eventually wipe you out if you are too aggressive. These sort of trades have been aptly described as picking up dimes in front of a freight train.

So you need to hedge or re-insure in some way. Not perhaps as difficult as it may seem: rebalance, don’t overtrade, use hopefully reliable indicators. Hopefully a combination of these provisions should / could keep you in the game.

Anthony,

No one can predict what will happen in the future. Yet, every single human activity is based on predicting what will happen in the future. Why do humans do this?

It is really a matter of probability. Some things are far more likely than others. Now, likely doesn't mean 100% probability. However, inaction and negativity based on low probability events is not the mark of prudence. I may die in the next minute from a heart attack, and it's a certainty that I will die one day. That doesn't mean I don't brush my teeth in the morning or take my dog for a walk, as the probability of my dying in the next minute - based solely on past human experience - is fairly low.

Same applies to investing. What are the odds of either XIV or VXX going 80% down in a single day and hence ceasing to exist? There is no way for us to calculate the odds, as we can't predict the future. However, if we look back and simulate how these would have behaved based on past extreme market movements, we will easily conclude that none of those events caused either of these two ETFs to go down 80% on a single day. Can a larger market move happen some day? We can't disprove that - as time in infinite and no one can prove a negative. However, rational, pragmatic people don't choose inaction because something may happen, however improbable.

That's my contention. To bring up the potential of the world ending in a bang and hence saying no investment policy is safe is defeatist and frankly not very wise. One cannot even hold cash as who knows, we may get hyperinflation. One can then only stay in the moment and spend everything they have right now, as it is only the current moment that matters.

That's nihilism, and I am too old to be a nihilist. I am also too old to not invest and consume everything. Perhaps I have grown irritable in my old age, but I see no purpose in talking to nihilists, which was the source of my frustration. To be asked to prove a negative - that this strategy will not end in 100% asset loss at some point in the future - is simply idiotic, as, I repeat once again, no one can prove a negative. But I am happy to talk about probabilities, based both on past experience and future simulation.

Q is a very limited platform, in that it doesn't have any tools for forward simulation. However, these ETFs are fairly straightforward instruments. A little bit of eGARCH and Brownian Bridge is enough to predict their price movements (directionally, and not on absolute terms). So I think it's prudent to take advantage of these while they are still here.

Blue, I believe you are calculating the PvR of the benchmark return wrong. It's not 124%, it is in low single digits.

Macro Investor
Agreed. I would not be trading it if I didn't believe I had a greater than even chance of escaping not only unhurt but with a profit. Provided I re-insure in the ways I have suggested!

Thanks Anthony -

I can't say I understood much, since this sort of derivative stuff is beyond me at this point. But I kinda get the gist of things.

@ Anthony -

So are there hedged stat-arb or otherwise strategies? In other words, can one arbitrage using XIV and VXX, or is this more-or-less gambling? It seems like if one is zigging when the other is zagging, then if they don't quite zig-zag harmoniously, then one could have something. Is that the concept?

While the background to why it "works" may sound a little complex, the operation of the strategy itself is utter simplicity. When the VIX futures markets are in Contango be long XIV and out of VXX. When the VIX futures markets are in backwardation be long VXX and out of XIV. Since Contango exists 70 to 80% of the time you will mostly be long XIV. You will be long VXX the only time it is actually profitable to be invested in it: when volatility is rising sharply.

As for the definition of contango most of the action is in the front months. The back months are also usually in contango (to the front months and spot) but are not so profitable to trade.

At present I have on my IB screen the following which I use for signals:

30 day VIX Index: 11.76
VIX Futures March 22nd 13.00
VIX Futures April 19th 14.20

As you can see, the front month (March) is trading above the spot and the second month is trading above the front month. Contango exists. Most systems posted here on Q are defining Contango as the second month being above the front (or some derivative thereof such as a moving average).

Some of the algos here are also (or alternatively) using an absolute level of the 30 day VIX to enter or exit XIV (short the VIX) or VXX (long the VIX).

I tweaked the algirthin to use the VIX VXV ratio and the absolute level of VIX as well. Improves the returns quite a bit.

Clone Algorithm
242
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 58a9e3cc4bebbf5df1074ce5
There was a runtime error.

@Macro,

I'm not a naysayer I just take issue sometimes when people say this is amazing with something like 50-60% DD. I don't mind running a strategy with that kind of DD given the reward is there which it is, I guess in my book an amazing strategy would be this performance with 20-30%DD. Either way i plan on allocating a small amount of capital to it, even 5-10K is a few million if it performs the way it does.

Also can you please tell me the numbers for 08' returns and DD if you have them, I have no idea how to load historical VIX data, and run the strategy on it. Anyway still a great strategy for what it is, high risk/high return, again my whole issue is when the word great,amazing, gets thrown around with my specific expectations.

Thanks

Elsid, I didn't say that the strategy is amazing. In fact, my first post on this was how to make the strategy better, given the drawdown. So please do not put words in my mouth. Also, I don't really care for what your definition of amazing is, as amazing is not what I am after.

Perhaps in future if you want someone to do your work for you for free, you will be more polite.

There is criticism (e.g., Anthony) and then there is pure immaturity and rudeness.

@Macro,
It looks like the macd is using opening prices whereas all the other instruments loaded up via fetch_csv are using closing prices. When you run data.history() and pass in SPYG, quantopian thinks you want the price at market open (or whatever time it is when you call my_rebalance, i.e., 7:31am). Seems like the impact of this would be negligible, but I'm not sure yet. I'm currently working on calculating macd using closing prices. I will share soon hopefully.

@Anthony - Do you go to cash when say the VIX close is trading above the front month, but the second month is trading below the front month? IE. the spot/front month are in contango but the first/second month are in backwardation?

Or are you only looking at contango as spot vs front month?

@Anthony
If you don´t mind, another question to you. Supposing we are long with XIV via such kind of algo, what would you suggest as a hedge strategy with options to protect against a big and sudden downside?

I'm only looking at contango vs spot. Instead of cash I go to VXX when in backwardation. Hedge: just trading small and rebalancing between system and cash periodically.

@Anthony - are you simply looking for if the VIX Spot is trading above/below the first month? Or are you looking at a ratio - say .90/.95?

A ratio but a single point not a spread which works reasonably well since 2004.

Does anyone know when Q will support futures?

Is anyone participating in the alpha stage testing for futures?

Hey Macro, is there a place you have written the actual formula used for the VIX:VXV version of this algo? If not, can you write it here?
Thank you.

Macro, I love the way your most recent revision looks. The simplicity of it is what gets me, and makes me think it's promising for the future as well.

However, have you messed around with different times of day to execute the trade? As it stands, every single trade is done at 9:32am. Did you find this to be optimal?

I'm thinking about running some backtests using a variable time of day, using intraday changes as signals. Basically, the algo will know at the beginning of the day which trades to make, but will wait until some optimal time to execute them.

Let me know if this is something you've already experimented with.

I had someone help me run a backtest prior to 2011, you will experience severe drawdowns. The Drawdowns actually came between 07-08, until Sept 08 when Markets tanked, that's when the strategy made it all up again.

XIV/UVXY/UPRO with macd disabled
93% Annual Return
81% Max DD

XIV/UVXY/UPRO with macd enabled at -1
47% Annual Return
91% MAX DD

Half position XIV/UVXY/UPRO with macd disabled
49% Annual Return
53% Max DD

Half position XIV/UVXY/UPRO + always half TLT with macd disabled
55% Annual Return
50% Max DD

From 2011+ you only hit like max 30% DD. Which depending on if you use the modified versions or lower your invested amount you can survive.

I know how much overfitting is somewhat frowned upon, but here I decided to see how far I could push this algorithm just by tweaking the constants a little. Managed to improve returns by about 65%, while lowering max DD by about 4%.

Clone Algorithm
70
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 58cf097a55c95c175bf9e95f
There was a runtime error.

I just discovered a relatively fatal error in this code that makes live implementation impossible. The Quandl database for VXV stopped being updated on 12/31/2015. All backtests that go beyond there are missing VXV data, which completely screws with the results if the algorithm makes it past a certain point.

Gonna look for a better data source tonight.

That was quick, thank you! Now if only there was minute-resolution data for VIX futures... This algo would really sing.

VXV is available in Quantopian data via pipeline. Also VIX, VVIX, VXMT and SKEW.
https://www.quantopian.com/data/quandl/cboe_vxv

Got it, thank you.

One thing I'm still trying to wrap my head around is the 1-month and 2-month future data (VX1 and VX2). They seem inherently biased to experience a sharp rise every four weeks, due to the futures contracts rolling over to the next month. Shouldn't these be weighted using a time-until-expiration parameter to produce a rolling futures value? Otherwise it doesn't really reflect what it's trying to reflect, depending on the time of month.

I don't have the link, but there is an algorithm posted here that calculates weights for VIX expiry. Only problem is that every quarter, expiry is five weeks instead of four. The code hasn't been updated to account for it.

Definitely something I'm going to work on tonight, then. I need more coding practice anyway, it'll be a fun little exercise.

Between 2011 and now, I don't think there's a perfect pattern to work off of (tends to be 3rd Wednesday of the month, but it rarely happens on the 4th Wednesday). Root of the problem is that 365 is not divisible by 7, and then you've got leap years on top of that. I'm just going to need to manually make a list of expiration dates and go from there.

Have you tried choosing a known expiry date that ends a quarter, four weeks, then another four weeks, then five weeks. Repeat? I have no idea if it breaks down over the years.

I can't really do any testing until tonight, but my intuition tells me that won't work for every single case. It would start to drift after a few years because 365.25 days per year is not perfectly divisible by 7 days a week.

Hi I am trying to print the date that corresponds to each vix data from the excel file. I tried log.info("Date %s" %data.current('v','Date')) but got a nan in the log. Any help?

if you guys can get these returns, makes you wonder why the pro's aren't using these methods to make billions. Look further into the horrendous volatility of these methods. specifically, what do you think will happen when the market inevitably crashes if its seeing 50% drawdown in 2k15.............

Couple of tools.
1. Hover over the custom chart
2. Click symbol names to turn off two at a time. This isolates the PnL for one at a time.
3. Clone/run
4. Take a look at the logging window (it is output from track_orders)
5. Consider turning pvr on (and pnl off)

2016-09-12 06:31 my_rebalance:191 INFO CASE 5  
2016-09-12 06:31 _orders:421 INFO    1   Sell -78523 XIV at 33.41   cash 66  
2016-09-12 06:31 _orders:421 INFO    1   Buy 38020 UPRO at 69.00   cash 66  
2016-09-12 06:33 _orders:421 INFO    3      Bot 38020 UPRO at 69.15   cash -13231  
2016-09-12 06:33 _orders:421 INFO    3      Sold -78523 XIV at 33.32   cash -13231  
2016-09-13 06:31 my_rebalance:191 INFO CASE 5  
2016-09-14 06:31 my_rebalance:191 INFO CASE 5  
2016-09-15 06:31 my_rebalance:191 INFO CASE 5  
2016-09-16 06:31 my_rebalance:167 INFO CASE 1  
2016-09-16 06:31 _orders:421 INFO    1   Buy 82945 XIV at 32.33   cash -13231  
2016-09-16 06:31 _orders:421 INFO    1   Sell -38020 UPRO at 70.88   cash -13231  
2016-09-16 06:33 _orders:421 INFO    3      Bot 82945 XIV at 32.17   cash 2437  
2016-09-16 06:33 _orders:421 INFO    3      Sold -38020 UPRO at 70.63   cash 2437  
Clone Algorithm
18
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 58d502e9cd422d1b6ebb3729
There was a runtime error.

@jacob

No one can predict unforeseen events, and drawdown during those events is always going to be huge in a high-volatility strategy like this.

I don't personally see this as a "deploy-and-forget" algorithm, it's more of a roadmap on how to use VIX future prices to predict its direction.

That being said, the only ways to trade using this strategy are 1) Have the stomach to weather through those >50% drawdowns, or 2) Simply don't put ALL your money into it.

The only thing this approach is missing is minute-resolution data for VIX futures. The results are already borderline unbelievable at a resolution of one day. I can't even imagine how far improved these backtests would become if the positions were able to pivot in the middle of a mid-day turnaround.

I'm doing this "live" already by checking the results of the algorithm (transposed into a spreadsheet) in real time, and changing positions if the data starts shifting one way in the middle of the day. Requires me to be attentive (although it's to the point where all I need to do is hit "reload" and a signal pops out), but so far it's working like a charm.

I will obviously need to keep this going for at least a month or two until I can definitively say whether or not this approach is better than the once-a-day-at-open strategy. I will keep you folks updated on its progress!

Hi @John O'Leary I am doing something similar as you, Although I enter the vix numbers manually into the spreadsheet. When you say hit reload, do you mean browser window or somewhere in your spread sheet? Were you actually able to refresh the numbers in spreadsheet with a button? If that's true, can you let me know how you pull vix numbers into spreadsheet without typing it in?

The methods I'm using are fairly prone to error and still need a lot of work. Also using a modified version of this algorithm that I'd like to keep under wraps for now. For that reason, I don't think I'd like to share how I'm doing it right now.

But for what it's worth, I'm using Google Sheets to hold the spreadsheet and a combination of Excel commands and Google Apps functions to get everything to work together... sorta. There are a LOT of moving parts.

There is a way to do it in Excel, but sheets works very well with google finance data. This formula will get you the current price for the ticker listed in cell A2. Modify as you need it.

=(GoogleFinance(A2,"PRICE"))

Thanks guys for the ideas, I got something working!
Image

Tried something a little different here.

Since this algorithm works by looking at close data, and making a move the next morning, I was getting worried that it stumbles on a lot of overnight volatility events.

So I changed the algorithm to still use closing data, and make the transactions at close. All other variable held constant, this actually decreased returns by about 50%. Intriguing... Not exactly sure what would cause this but I have some ideas.

This is definitely the next thing I want to play around with. Maybe even using opening data could yield interesting results. Any feedback on the changes I made are appreciated.

And just to clarify, I understand that this implementation is impossible to deploy since most of this data is only available with a 15-minute delay. Just trying to prove a point here.

Clone Algorithm
49
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 58dd59cdda401417a050356f
There was a runtime error.

As a matter of practicality, John: when I as a retail investor place an order any time after close through my online brokerage, that order will only be executed at the next market open, and thus what you report above is a moot point, right?

Axel - Many retail traders have accounts that let them trade outside of regular hours.

In such a case, commissions and/or spread are much higher

Thanks, Bodhi and Femto. But could the overnight trading really cause a 50% reduction in results as John above reports?

I had a guy who does this sort of thing for a living replicate Macro Investor's latest model in Excel, for backtesting. Unfortunately the results do not match what the model here on Quantopian produces. There are a few days where the model decides differently and that throws things way off. Seems that the way the MACD is calculated by the library Q uses is different from the way my guy implemented it in Excel. He's at a loss as to how this could be. So the third signal comes out differently, especially on days with high volatility. (BTW, even when manually adjusting those few days to what the model on Quantopian does, Excel still produces different results, apparently due to the exact timing of the trades.) Is there anyone here who'd like to take a look at this? I believe we are allowed to do this in accordance with Quantopian's TOC, section 3, last paragraph, and given that Macro Investor in this thread seemed open to people trying to replicate his work. Anyone interested should be able to message me through Quantopian but if that doesn't work, please post here and I'll share my email address.

@Axel

According to quantopian they keep broken data in production and don't fix it so they can use it for testing troubleshooting, we found a bunch of differences in VIX data, I see here that it pulls data from quantopian directly for SPY, so don't know if SPY data might be off a few days a year, but a few days a year wrong data can have completely different results especially with such highly volatile instruments.

I also had someone help me backtest this past 2011 during the 07-09 period, and it showed very high DD of 70-80% at that point you're just gambling.

@ Axel Lieber Please review the code. John O'Leary's code at line 72 says

schedule_function(my_rebalance, date_rules.every_day(), time_rules.market_close(hours = 0, minutes = 1))  

Means the rebalance will happen 1 minute before the market close, not after. And yes everything matters, including whether the method is called at market open or market close.

Elsid, thanks, that might explain quite a bit. BTW, which of Macro's models did you backtest? The latest one from Feb 20?

Tony, thanks, got it.

Can't remember probably a more recent one not the last I don't think.

Well, in any case, the Volatility Made Simple blog has back tested many different volatility strategies including an earlier and simpler version of Macro Investor's strategy, and many of them had a bad time in 2007. From what I see there, the only way to avoid that type of decline is to keep in cash when the term structure is too flat to signal a clear bias. But then you also lose out in situations where despite a flat structure, XIV does very well. Choose your poison.

http://volatilitymadesimple.com/macro-investors-vix-trading-strategy/

Gosh, I didn't even know someone took an earlier version of my algorithm and posted it in another Web site. LOL.

Anyone got a hold of VIX futures data? I would really appreciate if someone can convert the latest algo to eliminate fetch_CSV altogether so that it can be traded on line.

VIX futures data is going to be available in algos after Quantcon (are you going? if so we should meet up - ping me)

Having said that VIX settlement data is not going to be available, so you will have to just use 'last traded' (see here).

I am not going. I am not really a quant. I just do this in my spare time. My only exposure to quantitative algorithms was through business school, which was a LONG time back.

If it is as traded, then the algo will have to be changed to trade at end of day. I am not sure what that will do. I will try.

Macro, I haven't made the effort yet to simulate performance of your latest algo all the way back to 2004. Have you done this yourself? If yes, could you share how it fared in 2007? Does it still experience a serious drawdown in that year? Thanks.

Yes it does. DDs are inevitable when you are playing with volatility. But it recovers fast too.

Thanks, Macro. I love the hand grenade you have created. Wish I had about a dozen more of these, all totally uncorrelated, and with a similar level of plausibility/rationale behind them. Your posts on Seeking Alpha have been my induction to volatility trading, and following the evolution of your algo has been a fantastic tutorial for me. Vix & More, and a few other blogs have been helpful as well. I'm about to start trading this live as a minor portion of my portfolio. It most likely won't generate the results from our backtests but maybe it'll beat XIV buy & hold, or XIV b&h with some crash protection. If it does, I'm going to have to send you some beer money. Please keep experimenting.

Hey Guys,
Quick question, I am trying to paper trade this strategy but the cboe data is coming back as Nan which is in turn making last_ratio Nan forcing it to buy the default. Has anyone found a work around for this.
Thanks

@Jacob Nope. We're slaves to Quandl updating their futures data, usually sometime after 11am ET. I think you can manually visit the CBOE web site and get the EOD numbers, they will ban you if you use automated methods.

Bummer, appreciate the quick answer Dave

One way to handle this is to update the data manually from the CBOE website. Wait until 2pm PST so settlement is updated, then collect the data from this page: http://www.cboe.com/delayedquote/quotes-dashboard

Enter it into a googledoc and then use fetch_csv in the algo to pull the data and use it.

This means you can enter the data at 2pm, and the next day the algo will use it to trade. The disadvantage is that you have to do this every day - but it is actually really important because the option expiry date ("third" Wednesday) is not correct every month with this algo, so you can keep an eye on it and manually adjust that too.

There are paid services that offer real-time futures data, no? Is the availability of live future's data the major bottleneck for an algo like this?

That and the backtesting data seems to be suspect...

@Bodhi which data are you referring to?

Macro, why do you feel you need to change the re-balancing from "next day open" to "same day close"? Both "traded" price and "settlement" price data are collected at/after the close...

Guys has anyone checked if UVXY/VXX/TVIX behaves the way it does now, every time it's in negative contango? I could check but not sure how to get volume and order book data to Quantopian backtest.

Basically what I see there is a lot of traders thinking today is volatility break day and buying premarket/or open with huge volume imbalance of any volatility ETF. Basically, I have been making 0.8 - 2K$ a day with small day trades every day this week.

I simply limit order on the first positive bar, and set sell stop around 9% above current entry and monitor level 2 order book for any large sales if I see large volume I sell at ask, else my stop hits at 9% at some point it does not seem to have volume to hit much higher. Today I cannot see volume buildup but there has been one every day since Friday last week.

Maybe this just a symptom of volatility strategies becoming too popular but definitely interesting. I did not have volume data from the last big volatile breakup so I tried to just look at the price chart and it seems to have a small hacksaw movement back forward. My theory is that people buying these are the same buying penny stock based on newsletter alerts so they buy in the morning but there is not enough capital to sustain the price so afternoon and after hours it gets pushed back, as people collect profits and shorts start to bite.

Max -VIX and MACD.

Bodhi,

The current algorithm trades at start of market based on previous days close. If the previous days close is not available, then there are two options. Either trade at start of market using current data, or trade at end of market using current data. I don't know how the algorithm would behave under either situation. The way I can test it now is to simply use end of day trade, and the close value of the futures, knowing full well that is has lookahead bias.

At any rate, I will just wait till the actuall futures data comes out. Manual trading is a pain and I want to automate. Whichever values we use this algorithm will yield better results than buy and hold XIV, which itself will yield far far better results than buy and hold SPY, which itself will beat 90% of hedge funds.

So this is a golden goose no matter which way you look at it.

Just waiting for the vix futures to come out now.

-Macro.

Ha ha ha...I hope you are right and certainly agree about the S&P. I started trading VXX and XIV a few months ago and was up over 30% prior to the recent up-spike in the VIX. I am cautiously optimistic about the trade but have been "fooled by randomness" once too often over the years to bet the ranch.

It's certainly a fun trade.

I tried to recode using continuous futures and got really bad results. Anyone else tried it?

I am not really a coder so if someone can recode and replace all the fetch_csvs with pipeline I would really appreciate it very much.

Macro,

Thank you very much for this interesting algo. I just tried removing the fetch_cvs and replacing with pipeline. I think you can only do VIX and VXV at this time. I think Quantopian is working on futures but I don't see how to get VX1 and VX2 right now. That being said I am not a futures guy.

Clone Algorithm
11
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 590a96c36e344d627359797e
There was a runtime error.

Thanks much Jacob! In the mean time, I had tweaked the algo already to make it simpler and a bit bolder about switching to UVXY, which also improves performance. I have attached the latest backtest.

Unfortunately, then I tried to incorporate the pipeline on top of that, and didn't get the same results. Which means the end of day VIX and VXV values for the pipeline are not match the ones that fetcher got.

I also independently cracked the vix futures code. You have to select it at close of the previous day. Trouble is, Quantopian doesn't have the futures settlement price. So it is impossible to get that.

Plus you can't have the pipeline code and the futures code in the same algorithm

So, I am officially giving up. I am going to hire someone to code this for me outside of quantopian, and then hook up to IB directly. Quantopian is too buggy and unstable, and too slow to add features. All the data that I need for the algo is already available for free online, so it will be a simple case of screen scraping.

If I tweak the algo again to improve performance, I will post updates. But waiting for Quantopian to fix everything to run this live is like waiting for Godot.

Clone Algorithm
242
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 590a9ea57ab77965a63fae34
There was a runtime error.

I looked at the original post almost exactly a year back. The performance has improved some 6-7 fold based on all the feedback I got from folks here. Thank you!

Except, there is no way still to implement this live. :-(

Macro, do you intend to offer this to people on a different platform or maybe as a subscription service of some sort?

Macro Investor

I tried to recode using continuous futures and got really bad results. Anyone else tried it?

You can NOT use a continuous futures contract to back test XIV if that is what you are trying to do. Nor indeed to calculate historic contango/backwardation. You need individual contracts. And so far as testing XIV is concerned you need to form an index of daily price returns. The real trick is to ensure that on the roll date the daily return is that of the old contract / new contract so you capture the Contango or backwardation. Almost any other method will distort the calculated price series .

Thanks Anthony. I knew something was off, just not what it was. Can you please explain just for my edification what exactly continuous futures are and why they are different?

I found a major implementation issue in the original algorithm. I was using fetcher to get VXV. Guess what? Quandl csv stopped updated VXV on December 2015. So the algo was all off. So, I now implemented VIX and VXV with the pipeline. Resulted attached. But even there, if I pull VIX from the cobe_vix pipeline the results are lower. If I pull them from the yahoo_index_vix pipeline they are higher. This is disgustingly corrupt data.

Clone Algorithm
29
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 590b53abbcc6856659d22f79
There was a runtime error.

Axel, IF I get it implemented outside of Quantopian, it will likely run as a automated job every night on the IB platform. I will happily give the code to do that to people who would want to implement it on their own. I wouldn't do a fee-based service. That's like a low paying second job which I can't afford to take, as I am working 80 hours a week on my main line of work, and as I near my 50s, I am thinking of retirement, not taking up more work.

And now, since Quandl will stop supporting yahoo databases (per another post this morning) I have recoded the algo using the cboe_vix pipeline. Attached is the backtest.

It's better anyway as I trust CBOE data the most.

Does anyone know if there is a flag that gets turned on during live testing that I can use to fork the code to make one last attempt to get it working through Quantopian?

Clone Algorithm
54
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 590b6267e7aadb6587576e00
There was a runtime error.

Macro Investor
Jeez....its a bloody big topic. Send me a message via my website with your email address and I'll send you a spreadsheet as to how I calculate the index for a continuous futures contract.

It just entails stringing together individual futures contracts so that you can back test. In general it's not a great idea to use conventional back adjusting methods. I prefer to create an index in the way my spreadsheet will show.

As to concatenating futures contracts and the general methods used you might take a look at:
http://www.csidata.com/ua/backadj.htm
http://www.csidata.com/custserv/onlinehelp/OnlineManual/

The disadvantage of my method of course is that you can't see the prices. But it forms a more accurate picture of what you would gain or lose over time.

The real nub of it is filling the gaps created by contango and backwardation when there is a gap between the expiry price of one contract and the price of the next. Much of the money is made by the roll rather than the price movement or trend. This is why the vix is such a profitable trade if you get the timing right. You are just hauling in the contango or insurance premium 80% of the time and running like hell when it goes wrong!

Anthony, you raise a good point about continuous futures. The implementation on Quantopian is actually quite different from other sources that I've seen. We don't subscribe to continuous future data. Instead, we get individual contract data and build the continuous futures ourselves on top of that contract data. By default, when you ask for the history of a continuous future, it's back-adjusted for the price jumps between consecutive contracts. However, if you just want to use the continuous future to get the historical price of the underlying contract to which the continuous future was pointing, you can explicitly tell to perform any adjustments. If you haven't seen it yet, this notebook demonstrates the features of the continuous future pretty well.

I'd love to get your thoughts on the current implementation. If you have any questions/suggestions, feel free to post them on the thread I linked to so we can avoid changing the topic too much on this thread.

Disclaimer

The material on this website is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation or endorsement for any security or strategy, nor does it constitute an offer to provide investment advisory services by Quantopian. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. No information contained herein should be regarded as a suggestion to engage in or refrain from any investment-related course of action as none of Quantopian nor any of its affiliates is undertaking to provide investment advice, act as an adviser to any plan or entity subject to the Employee Retirement Income Security Act of 1974, as amended, individual retirement account or individual retirement annuity, or give advice in a fiduciary capacity with respect to the materials presented herein. If you are an individual retirement or other investor, contact your financial advisor or other fiduciary unrelated to Quantopian about whether any given investment idea, strategy, product or service described herein may be appropriate for your circumstances. All investments involve risk, including loss of principal. Quantopian makes no guarantees as to the accuracy or completeness of the views expressed in the website. The views are subject to change, and may have become unreliable for various reasons, including changes in market conditions or economic circumstances.

Actually, here you go: I put in on my website. Let me know if there are errors - I had rather a lot of different versions.
Spreadsheet for Continuous futures Index using VIX Futures

I have given up on live trading this through Quantopian for now, and wanted to build a spreadsheet for manual trading. I am still confused where to get data for VIX 1 Month Futures and VIX 2 Month Futures. Can I just use the previous close on Yahoo's ^VIXJUN and ^VIXJUL respectively? When I try this and get the 2017-05-03 close I get:

  • ^VIXJUN = 12.97
  • ^VIXJUL = 13.86

Where as the CBOE data suggests:

  • CBOE_VX1 = 12.075
  • CBOE_VX2 = 12.975

If CBOE is the best source of this data, and it only updates their csv at 11am where do you get this data before open?
Also does anyone know why google finance has VIXJUL but not VIXJUN?

Sorry if this is to basic a question, this algorithm is my first exposure to Futures.

A question for Macro: How did you decide on the inflection breakpoints of 3% for contango and 6.5% for backwardation? I understand the concept but am unsure why those levels are optimal for trading this algo. Thanks!

I have been able to start paper trading this algo. I am creating my own version for the CSV files for vx1 and vx2. I get the data from

http://cfe.cboe.com/market-data/futures-settlements

I will paper trade this for a few weeks and then start to live trade this. The royal pain is that I have to manually update my own csv file each night, but I have written a java program to automate it.

Eugene, the breakpoints are -4.5% and +6.5%. I first calculated the average value for R for the total duration of the futures. That was about -4.5%. So, the first version of my algorithm was to go long XIV at below -4.5%, and go long UVXY at above -4.5%. But I soon realized that it is not safe to go long UVXY that fast. I then tried +4.5% or above as the cut off for UVXY. That worked much better. I then kept raising it, till it seemed to have found the optimal at 6.5%. This was on the training data from 2004-2010. I have used that since and it seemed to have worked.

Macro, to bad you were paper trading today was a good day to be in XIV :)

@MacroInvestor

Were you looking for sometihng like this:

  # execute this code when algorithm is running with an  
  # Interactive Brokers account  
  if get_environment('arena') == 'IB':  
    pass

  # execute this code when algorithm is running with a  
  # Robinhood account  
  if get_environment('arena') == 'ROBINHOOD':  
    pass

  # execute this code when paper trading in Quantopian  
  if get_environment('arena') == 'live':  
    pass  

https://www.quantopian.com/help#api-get-environment

This is perfect! Thank you Kurry!

Jacob, I have lots of investments in XIV already. :-)

What I have been hesitant to do is to switch to UVXY. But that's where the real money is. I will let this algo loose in a few weeks.

Speaking of UVXY, its seems like this algorithm misses the biggest spike on Jun 7th 2013 to Jun 21st 2013. I am looking into why any ideas?

Google didn't have that as a split when I checked but Yahoo did.

The reality is, all these data sources are horrible. I replicated the whole algorithm in Excel plus in java, using all vix/vxv/vix futures data from CBOE, and xiv/uvxy/upro data from nasdaq. Yahoo had data issues. So did google.

After I did all of that, I am getting close to what Q backtesting shows, but not quite. Which makes sense because of slippage and timing.

To run the algorithm I only need end of day values for vix/vxv/vix futures, and all that is available for direct download from CBOE in csv files. So, while the paper trading is going on, I am writing a java code to download and determine which of XIV/UVXY/UPRO to buy, which should be straightforward. Then I will hook the java code directly to the IB java api and be done with it.

I just wasted a year hoping that Q will get VIX futures settlement prices. Oh well, lesson learned.

Hello guys!
I was just wondering if it is possible to integrate the front month and back month VIX futures to Q without using the fetcher now when futures are available?
I thought I saw a post claiming the futures are available but if you import them you have to fetch the VIX spot data instead. I would highly appreciate any information on the matter.

Best,
Carl

@MACRO - I am also trying to build out an excel spreadsheet to manually trade this. When you say MACD "greater than" -1 - do you mean it needs to be -1.01 or "less"

@Carl

you can get the data using VIX futures as below:

# Use futures VIX data  
vx_chains = data.current_chain(continuous_future('VX'))

front_month = data.history(vx_chains[0], fields='price', bar_count=1, frequency='1d').iloc[0]  
secondary_month = data.history(vx_chains[1], fields='price', bar_count=1, frequency='1d').iloc[0]  

Note that these are last traded prices and not settlement prices. Also, as you mentioned, you still need to get the spot price using fetcher.

BTW, this is all useless since you cannot live trade the futures calendar using Q right now. Their futures data is all for academic purposes and worthless for real world trading.

Tyler, I have dropped the MACD check completely now. It didn't seem to add value after I ran my backtests outside of Q. I don't trust Q backtests any more.

Macro, that is good news because getting a accurate MACD on SPYG has been holding me up. The Java ta-lib behaves totally different than the python one. Also the price series from yahoo, google, and quantopian all differ. Its actually starting to mess with me, when I compare numbers from different sites they either differ, they calculate different, or seem just wrong. Makes me question wall street reality. I mean maybe Yahoo is all wrong, but if everyone is using those numbers then that wrong reality is self affirming. This is worst than "fake news"! :)

simply because of a VIX price granularity or closing price matter, yes? If it is MACD or another technical issue, so long as the problem is clear, several of us would be happy to don our cape and fly in to resolve coding struggles. Could just be unhandled nans for example.

Blue, I don't know what it is because I can't find two sources are the same. AKA no two sites have the same closing prices, nor if I use yahoo 40d window closing prices I can't get the same MACD with python ta-lib, java ta-lib, nor if I calculate MACD in excel by hand. I have learned that ta-lib has "memory" so window size matters so it won't match excel, quantopian uses a fixed window version of ta-lib for better backtesting. That is the best I could come up with, without two sources being exactly the same I can't claim a bug in any one source. Just look at MACD(12,26,9) for SPYG on Google vs Yahoo. They are totally different, Yahoo is more like TradingView.

Unless you people intend to trade very short term indeed you are wasting your time. Use whatever you can find. I trade XIV and VXX which I backtested both in python and excel using actual contract months strung together which I subscribe to from CSI data.

Having back tested I have absolutely NO NEED to run any further software. The system trades infrequently and each day all I have to do is to look on IB or the CBOE website to check on contango. Having done that I place the very rare trades necessary.

Don't fuss guys. That would be my advice. String together a back adjusted series for vix futures as per the spreadsheet on my website. Back test using excel. And trade. The instrument is so hugely volatile you are totally wasting your time trying to fine tune an algo.

IMHO as the ghastly phrase goes!

Jacob, Spot on. That's why I have decided only to use VIX, VXV, and VX Futures closing/settlement values from CBOE, and nothing else. I don't need to look back at all. I can get the values downloaded every day at 7 pm EST using a simple java program (right now manually running it but will automate), calculate which one of UVXY/XIV/UPRO to buy, and fire off a request to IB (the last part is still in progress).

Anthony, You are right. My only additional need is to not have to do the infrequent trading myself. That's all. The model will still trade about 15-20% of the time, which means one trade per week. I don't know where I will be any given day at 9:30 am EST. I may be up in the air with no internet. I may be in a meeting. Hence the need for me to automate.

Macro Investor, I just got off the phone with IB and they seem to have front and back month VIX futures pricing. I don't know if your using java or python outside of Quantopian, but if there is anything I can do to help please let me know. In the meantime I'll start converting this algo to IB as well.

I am coding in java. I will post the class here once I am done.

Yep, I use IB and subscribe to the Vix futures. They have weekly and monthly futures and the monthly futures go out to at least 6 months, not that they are needed for this algo (see below). I was going to write the algo in VB.net but I guess I'll wait. Thanks.

Financial Instrument Company Name Bid Ask Last
VIX INDEX CBOE Volatility Index 9.96
SPX INDEX S&P 500 Stock Index 2396.78
VXV INDEX CBOE S&P 500 3-Month Volatility Index 12.71
VIX May17'17 @CFE CBOE Volatility Index 11.4 11.45 11.4
VIX Jun21'17 @CFE CBOE Volatility Index 12.4 12.45 12.45
VIX Jul19'17 @CFE CBOE Volatility Index 13.6 13.65 13.65
VIX Aug16'17 @CFE CBOE Volatility Index 14.3 14.35 14.35
VIX Sep20'17 @CFE CBOE Volatility Index 15.15 15.2 15.15
VIX Oct18'17 @CFE CBOE Volatility Index 15.6 15.65 15.6
VIX Nov15'17 @CFE CBOE Volatility Index 16 16.05 16.05
VIX Dec20'17 @CFE CBOE Volatility Index 16.15 16.25 C16.2000
VIX May17/Jun21 Calendar @CFE 0.95 1.05
VIX May10'17 @CFE CBOE Volatility Index 9.95 10.3 C10.2000
VIX May24'17 @CFE CBOE Volatility Index 11.15 12.8 C11.6500
VIX May31'17 @CFE CBOE Volatility Index 10.05 12.85 C12.0500
VIX Jun07'17 @CFE CBOE Volatility Index 10.05 15.25 C12.3500
VIX Jun14'17 @CFE CBOE Volatility Index 10.05 15.4 C12.4500
XIV VELOCITYSHARES INV VIX SH-TM 79.71 79.8 79.73
SVXY PROSHARES SHORT VIX ST FUTUR 153.98 154.34 154.31
VMIN REX VOLMAXX SHORT WEEKLY ETF 23.2 32 27.34
VMAX REX VOLMAXX LONG VIX FUT ETF 3.15 5.56 3.95
VXX IPATH S&P 500 VIX S/T FU ETN 14.08 14.1 14.1
UVXY PROSHARES ULTRA VIX ST FUTUR 12.45 12.46 12.43
SVXY Jun16'17 157 CALL PROSHARES SHORT VIX ST FUTUR 7.6 8.45 8.4
SVXY May19'17 157 CALL PROSHARES SHORT VIX ST FUTUR 2.34 3.1 3.2

ok, I've been doing IB Algos in Java for over a year, mostly options. If there is anything I can do to help please let me know.

Macro Investor, Will you be able to share the Java program to download Vix and VX futures data?
I use this algorithm to trade using a spreadsheet. My thresholds are -0.045 and 0065. so far the results are good. I manually update the spreadsheet from vix central and take the trade next day morning.

Yes he said he would

(thought I'd save you a response, Macro)

@Macro since you have removed the MACD check - can you share your ordering logic now?

How "infrequently" does this algo trade? I had a guy rebuild this for me in Excel, and I see about 50 trades on average each year. That's with MACD.

Macro, What do you think about varying the weights the front and back contango based on number of days left to settlement? IE what is your reasoning for fixing these at .7 and .3 respectively?

Well after hours of messing with the intricacies of VIX future expiration dates and python date math, I was able to implement my varying weights formula.
and... its worst in backtests :) If you guys think I did something wrong please share.

Clone Algorithm
70
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 591391e012d2f565c3552c1e
There was a runtime error.

Hello all,
I have a question. I implemented a a variation of this algo in an IB paper account a few days ago and it entered an UPRO order. In the stats I opened the algo and ran a backtest for the same period and it ordered XIV. Curious Why?

Thanks for sharing guys!!

@Frank. Your familiar with option strategy algos? I have been looking for someone to help!

Terry, Only way to tell is for you to share your implementation so we can figure out the diff. I have a java program and its still all in XIV as of this morning...

@Macro - can you advise your new ordering criteria now that MACD has been removed?

@Jacob Is your weighted ratio equivalent to the ratio between the VIX index and an interpolated 1 month constant maturity futures? Charting both your weighted ratio and the VIX_VXV ratio, your ratio seems to be a higher "beta" version of the VIX_VXV ratio.

Honver,

Yes that was what I was going for. I wanted to weight the front and back of the formula based on #days left in the 1 month maturity. So if today is maturity date the front is weighted 0, and the back weighted 1.

Here are the values for today (2017-05-12):
Prev Date = 2017-04-19
Curr Date = 2017-05-17
Term = 28.0
Maturity = 5.0
Front Weight = 0.17857142857142858
Back Weight = 0.8214285714285714

I posted this "failure" because the idea might of been sound, but my execution flawed because I am still learning about futures contracts. Just seemed wrong to weight 0.7/0.3 all the time.

The 0.7/0.3 weights seem to be the ratio between VIX and front month, not weights between front and back month futures.

I could be reading the code wrong and/or looking at a different version of the algo.

Here's the new algorithm with macd removed.

Clone Algorithm
92
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 5916777bcc5f2c623974e625
There was a runtime error.

Sorry - posted too soon. Cleaned up the version some more. This is easily implementable in java. Improves the return, too.

This version gives an weird python error, but it finishes fine. Can someone who knows python far better than me help me fix this please? Thanks!

Clone Algorithm
92
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 59167f43279b9f619a8a298d
There was a runtime error.

I completely agree that the 70%/30% split is arbitrary. I tried to implement something that looks at days to expiration and weights accordingly, but that's too hard to code for me in python. Plus, it's trickier than that. The VIX move impacts both the first and second month futures. So more weight should go to that.

Axel, 50 trades a year sounds right. It shouldn't trade more than 20% of the time.

Fixed a bug. Improved results.

Clone Algorithm
92
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 5916b6bd98a3cc65ca0fad5f
There was a runtime error.

@Jacob,

Instead of doing a linear interpolation between the two ratios, perhaps interpolating the constant maturity future using VX1 and VX2 may work better.
last_ratio = vix_close / (front_weight * v1_settle + back_weight * v2_settle)

Could someone kindly explain what principle and/or other market phenomenon this algorithm is based on? Especially, I'm interested in contango backwardation part, as far as I don't believe in vix/vxv thresholds and other kind of thresholding in this algo (as obviously they are going to change in time).
So, basically I want clarification: Am I right in assuming that each day you take VIX close and VX1, VX2 settles and perform linear interpolation between VX1 and VX2 and then looking if VIX is above that line or below, Right?
But then I have a question: if for example VIX on open already moved up for example compared to its previous day close: where this algorithm takes this into consideration?
I understand technical difficulties getting open VIX (Quantopian problems), but even if you get it: so, you properly figured out on market open that VIX is above VX1-VX2 line -> but this line was a settle line from previous day, isn't it? On market open (and during the whole night) VX1 and VX2 were trading, so by the time you are ready to buy ETFs, VX1 and VX2 already moved, Right? So, ETF prices you are buying/selling already reflect those moves. So, how are you going to win.
Please, explain.

Hello, with the new algo we are entering XIV whenever is not contango based in our custom ratio if VIX closed > 19,8?
So we are going to be in XIV many times when there is Backwardation .. I probably read the code bad, but if not I really think that the previous algorithm was much better becouse it puts that condition (VIX_close>19,8) after the backwardation condition of entering UVXY in backwardation scenarios based in our weighted custom ratio of Spot, VX1, and VX2.
So with this algo, for example if we have a VIX of 20, and no contango(which is highly probable logically) we are entering XIV without looking if there is backwardation?

Igor, I think you are right, we are not taking in consideration overnight moves in VX1, VX2 and Spot. Maybe this seems to not affect a lot the algo becouse voaltility overnight dont uses to move a lot, but maybe will be better to take the open values of Spot VIX1 and VIX2 to make it more accurate. However CBOE I think does not provide the data at open...

I am also very interested on hearing the responses of the other questions you presented.

Hey Macro,

I'm trying to wrap my head around a new piece of code you've recently introduced. Specifically - " if (context.vix <> -1) :
vix_ratio = vix_close/context.vix -1". To be called by -"vix_ratio <= l_vc_low" and "vix_ratio >= l_vc_high".

I believe what your saying is - "If yesterdays closing VIX price isn't equal to today's closing VIX price,
then 'VIX RATIO' = Today's closing VIX price divided by yesterday's closing VIX price, minus 1. Otherwise, 'VIX RATIO' = zero." Is this correct?

(It really has quite an effect on the final outcome.)

Just a small contribution.... when you see different behaviour in Live and backtesting and you are using Fetcher something is fishy with the fetcher. I have stopped using fetcher for that reason.
Another feature of fetcher is that it is hard to determine wether you introducing foward looking bias. If I see algo's returning 22,000% in 4 years I'm pretty sure they are either datamined or there is a forward looking bias. Be very very vigilant when trading this

Igor,

I will take a guess. Your argument is that at ETF open the markets have all the information and have priced this in. I don't think anyone believes in 100% market efficiency anymore. There are probably not a lot of investors looking at this stuff, nor trading this everyday. So yes the information is there, but it also has to be acted on for it to be priced into the Market. Macro has probably found a signal that won't last long as people catch on to it and it will go away. Especially because he made it public.

Peter,

I wasn't going to say anything about your "Contribution" but its right over what I was typing. Its not helpful. Its a 112 line program, if you see forward looking bias point it out! Comments like "If it seems too good to be true, it probably is". Has no useful information in a programming discussion. Tell us where its not true.

Bodhi,

vix_ratio should be called "vix percent change" macro is just asking if the vix when up or down 10% yesterday.

Jacob,

In response to your comment about the returns on this algorithm "going away" due to the signals becoming public knowledge... How sure can we be this will happen? My understanding is that this case is different than your usual signal degradation (made-up term) because it's based on a market index and doesn't trade a product that has its price determined by supply and demand.

Jacob,

This is. not a programming discussion, this a trading discussion. If you check my profile you can see I do this for a while and I have worked with fetcher and the vx1/2 sources and every single time I put it live with real money I discovered that the backtesting kept on making money but the live environment lost money quicker then one can make it. In the end, it's not a problem with the logic but with the timing of the data in the backtesting environment and live environment. The live environment triggers fetcher sometime in the night and it's the question whether these feeds are then up to date (they are often not).
Then there is the 15 minute data delay in live you have to cope with, all these factors together make this type of algo highly suspicious and, Jacob, if you really think there is an easy way to create an algo with these type of return profile without raising suspicion about forward-looking bias then I would say: go wild, put real money behind it and share the tearsheets!

Does anyone live trade this algo using Robinhood or IB? If so, how does live trading compare to backtests?

Peter,

It's already been established that this algorithm cannot run autonomously because the data it needs is not uploaded to a fetchable spreadsheet until around 10-11am the morning after. However, all of the data it needs IS available publicly, as of 9:30-9:31am every morning (when the backtest trades). Basically, all the data it needs is settlement data from end-fo-day the day before, and the trade is made (if needed) first thing in the morning). So if you're willing to calculate everything manually every night/early morning, or make a program yourself to fetch everything through other means, you can absolutely do so.

John,

Just a guess. I don't know anything about the future. I have never heard the statement that market indexes are not subject to supply and demand before, will have to think on it. You have any references? Seems like a interesting idea, is it based on there is infinite supply? Not sure that is true, and of course there is demand but is it a different kind of demand?

Jacob,

To my understanding, products like XIV and UVXY (basically, any ETF/ETN that attempts to track an index) are subject to supply and demand ONLY in the short-term. Market makers (paid for by the issuing company) trade large amounts of shares in order to influence the spot price to track the correct number it should represent, according the prospectus of the fund.

So, supply and demand DOES affect these products, but only on a short-term basis (whether that means seconds or minutes or hours... I have no idea). This is where slippage comes into play, which is a totally different ballgame and something I'm not well-versed in at all.

Peter,

Quant trading I think has more than a little to do with programming. My objection is that you were making a broad claim without giving any details. If you had read the thread there was a lot of trading discussion about if this was forward looking. The backtest is not. There is a lot of discussion if this is live tradable. its currently not through Quantopian, but the data is there from CBOE, I myself am trading this with 10k of my own money but trading it manually every morning. So far its done nothing but sit in VIX which is making small amounts of money.

I have manually traded (a less refined version of) this algorithm (from 2016) and it performed just as you would expect it to in backtests.

Though, the word traded is wrong. This algo rarely trades.

I understand the skepticism though. I know that data that is used in the backtest is completely wrong. However, there is no forward looking bias in the backtest, that much I know.

@Macro Investor, are you still working on the Java version? If not I'll get started. I just didn't want to duplicate any effort if you are working on it.

Here's some java code snippets to get the latest vx futures

private static void getValues()  
{  
    String vixUrl = "http://www.cboe.com/publish/scheduledtask/mktdata/datahouse/vixcurrent.csv" ;  
    String vxvUrl = "http://www.cboe.com/publish/scheduledtask/mktdata/datahouse/vxvdailyprices.csv" ;  
    String futuresUrl = "http://cfe.cboe.com/market-data/futures-settlements" ;  

    String Directory = "C:/temp/vix" ;  
    String futuresFile = "C:/temp/vix/settlement.csv" ;  

    String[] vx_values = null ;  

    CleanDirectory(Directory) ;

    try {  
        downloadUsingNIO(futuresUrl,futuresFile);

    } catch (IOException e) {  
        e.printStackTrace();  
    }

    try {  
        vx_values = extractLastVx(futuresFile,1) ;  

    } catch (IOException e) {  
        e.printStackTrace();  
    }  

    System.out.println(vx_values[0]);  
    System.out.println(vx_values[1]);  
}

private static void downloadUsingNIO(String urlStr, String file) throws IOException {  
    URL url = new URL(urlStr);  
    ReadableByteChannel rbc = Channels.newChannel(url.openStream());  
    FileOutputStream fos = new FileOutputStream(file);  
    fos.getChannel().transferFrom(rbc, 0, Long.MAX_VALUE);  
    fos.close();  
    rbc.close();  
}  
private static String[] extractLastVx (String file, int readorwrite) throws IOException {  
   FileReader fr_settlement = new FileReader(file) ;  
   BufferedReader br_settlement = new BufferedReader(fr_settlement) ;  
   String aLine ;  
   int count = 0 ;  
   Double[] vx_values = new Double[2] ;  
   String[] vx_strings = new String[2] ;  

   Date today = Calendar.getInstance().getTime() ;  
   String formatted_dates[] = DateFormat.getInstance().format(today).split(" ") ;  

   /*  
   int trading = isTradingDay(formatted_dates[0], today);  
   if (trading == 0) return null ;  
   */  
   while ((aLine = br_settlement.readLine()) != null) {  
       if(aLine.substring(0, 3).equals("VX "))  
       {  
           String[] args = aLine.split(",") ;  
           vx_values[count] = Double.parseDouble(args[1]) ;  
           if (count++ >=1) break ;  
       }  
   }  
   br_settlement.close() ;  

   String[] args = formatted_dates[0].split("/") ;  

   if(readorwrite == 0)  
   {  
       vx_strings[0] = args[0] + "/" + args[1] + "/20" + args[2] + "," + vx_values[0] + "," + vx_values[0] ;  
       vx_strings[1] = args[0] + "/" + args[1] + "/20" + args[2] + "," + vx_values[1] + "," + vx_values[1] ;  
   }  
   else  
   {  
       vx_strings[0] = "" + vx_values[0] ;  
       vx_strings[1] = "" + vx_values[1] ;  
   }  

   return vx_strings ;  

}  
private static void CleanDirectory(String Directory){  
    Path dir = Paths.get(Directory);  
    try  
    {  
        Files.walkFileTree(dir, new SimpleFileVisitor<Path>()  
        {  
              @Override  
              public FileVisitResult visitFile(Path file, BasicFileAttributes attrs)  
                      throws IOException  
              {  
                  //System.out.println("Deleting file: " + file);  
                  Files.delete(file);  
                  return FileVisitResult.CONTINUE;  
              }  
            });  
    }  
    catch (IOException e)  
    {  
      e.printStackTrace();  
    }  
}  

Frank,

If you can write and post the java code to connect to IB and post the trade, that will be awesome. Assume that you have a stub fucntion that returns 0, 1, or 2, corresponding to XIV, UVXY, and TQQQ, and I will provide the code for that.

I might also add that instead of Java one can just use MS Excel to automate the whole thing including IB trading. To start, below is the macro code to import above Indices/Futures into Excel. Just create an empty workbook and add/rename the following tab sheets in it: General, futures-settlements, vixcurrent and vxvdailyprices. Below is VBA code to add to this workbook through VBA editor.
Just Run ImportAll. Should work. If it doesn't don't ask me why, as it wasn't me who wrote all this and I personally have no idea how excel works. Obviously, it's possible to add IB trading to Excel without market data subscription and use this excel book to implement the whole logic. If someone wants: I can probably do this, but outside of this board.

Sub SortDates(SheetName)  
    Columns("A:A").Select  
    ActiveWorkbook.Worksheets(SheetName).Sort.SortFields.Clear  
    ActiveWorkbook.Worksheets(SheetName).Sort.SortFields.Add key:=Range("A1") _  
        , SortOn:=xlSortOnValues, order:=xlDescending, DataOption:=xlSortNormal  
    With ActiveWorkbook.Worksheets(SheetName).Sort  
        .SetRange Range("A3:E3368")  
        .Header = xlNo  
        .MatchCase = False  
        .Orientation = xlTopToBottom  
        .SortMethod = xlPinYin  
        .Apply  
    End With  
    Columns("A:A").ColumnWidth = 15  
End Sub

Sub ImportWeb(URL, file, extension, sort_dates)  
    ControlFile = ActiveWorkbook.Name  
    Workbooks.Open Filename:=URL & file & extension  
    Windows(file & extension).Activate  
    Sheets(file).Select  
    Cells.Select  
    Selection.Copy  
    Windows(ControlFile).Activate  
    Sheets(file).Select  
    Range("A1").Select  
    ActiveSheet.Paste  
    If sort_dates Then  
        Call SortDates(file)  
    End If  
    Sheets("General").Select  
    Windows(file & extension).Activate  
    Range("A1").Select  
    Selection.Copy  
    ActiveWindow.Close  
    Windows(ControlFile).Activate  
End Sub  
Sub ImportVixCurrent()  
    Call ImportWeb("http://www.cboe.com/publish/scheduledtask/mktdata/datahouse/", "vixcurrent", ".csv", True)  
End Sub  
Sub ImportVXVCurrent()  
    Call ImportWeb("http://www.cboe.com/publish/scheduledtask/mktdata/datahouse/", "vxvdailyprices", ".csv", True)  
End Sub  
Sub ImportFuturesCurrent()  
    Call ImportWeb("http://cfe.cboe.com/market-data/", "futures-settlements", "", False)  
End Sub  
Sub ImportAll()  
    ImportVixCurrent  
    ImportVXVCurrent  
    ImportFuturesCurrent  
End Sub

So, did you switch today? The strategy says NO

Futures Symbol Date Settle
VIX Continuous Futures VXK7 12.2
VIX Front Month Futures V1 12.2
VIX Back Month Futures V2 13.25
Indices Symbol Date Close
SPX S&P500 Stock Index SPY 237.23
VIX CBOE Volatility Index VIX 13.43
VXV CBOE S&P500 3month VXV 14.19
VIX/V1 1.100819672
V1/V2 0.920754717
Front to back Ratio 0.7
Last Ratio 0.046800186
VIX/VXV -0.053558844

I switched this morning. Yes if you use the CBOE close from yesterday the algorithm says "XIV". However, I have a sanity check that uses Yahoo live data (which can be a little off), which was telling me "UVXY". This is because over night trading had the VIX go up 10%+ last night. I made a executive decision to get out of the XIV with the quickness and go UVXY. This appears to be the right decision but its interesting using Close data seemed a bit late. I also learned a bit of a nasty lesson about Market orders. I thought it was more important to execute than get the right price, and ended up selling XIV for a $200 loss because I caught the morning down spike. I made that back already being in UVXY but could of been better.

Do you guys ever place your order's Market or do you always do Limit orders?

My version of this algo has been in UVXY since last week... Can't post my backtests now, but the returns are improved if you add in a "lowest" VIX failsafe threshold before any of the other checks are made. Basically in my algo, if VIX is ever below 11.10, you should be long volatility (UVXY, VXX, etc) no matter what anything else tells you.

Jacob, I'm confused: you are saying that "over night trading had the VIX go up 10%+ last night". So, did you have yours algo running through night? And then a question if you really got a signal at night to switch: didn't you get opposite signal in the morning to switch back? Or its all BS and you just believe your own guts? And if it's true, then this should be discussed on a trading board and not here, Right?

Igor, I have two algorithms 1) That uses CBOE close data, which this morning said VIX 2) One that uses yahoo live data (which includes after hours trading) which said UVXY. I had two algorithms telling me different things, so I made a choice and went with the #2 yahoo live data.

Your seem to think I shouldn't of said I did that because its not quant enough for you. I disagree. Sorry if you were on the wrong side of the switch this morning, but this thread has discussed if it would be better to trade this all the time, not just on start of the day. Which is why I wrote the second version that used yahoo data, to learn from days like today. I am still trading manually so I can oversee this algorithm. I don't think that means I should be posting on a trading board vs a quant board.

John, Would it really of been better to be in the UVXY for the past week over XIV? I think the optimum switch time would of been last night during off hours, not sure when.

Jacob,

Not for last week, but certainly for today. The algo in its normal form would still be hanging out in XIV right now, through this 12% drop, erasing all of last week's gains.

You shouldn't make the mistake of thinking this algo is all about chasing optimum switch times. The nature of VIX (and the market in general) means that unpredictable changes WILL happen, and short-term losses can never be completely avoided. I'd rather take one step back and two steps forward, than take one step forward and two steps back.

Jacob, with all due respect, but if you played #2 yahoo live data, using the same #2 aren't you getting a signal to switch back right now? You should be, so both systems #1 and #2 are telling you to switch back and you are ignoring both. Cheesy, Right?

Igor,

It depends on which version of the algo he is using as well... My algo is actually telling me stay in UVXY right now, and it's a pretty strong signal as well. Mine is pretty heavily edited, though.

Also, unless I missed something, it is not yet proven if a rolling minute-by-minute version of this algorithm is any more successful than the current day-by-day version. I would ASSUME that it would be, but we can't be sure. It's hard to even compare the two because the algorithm was originally built on trading off of numbers that are over 17 hours old.

I also post on seeking alpha. Last night I posted that while the model says XIV, the market news of Trump obstruction of justice says UVXY. The model doesn't consider market news. The model also doesn't use prices at open as, frankly, I cannot be next to a computer at market open as I am likely in meeting starting from 8 am EST back to back all day. Also, since I didn't have a source for live prices at open, it's a bit of a moot point.

I have tried the low VIX check to go long UVXY and over time it yields much worse results.

I remained long XIV and took the lump, but that comes with the territory. Long term the model has to incorporate market news, but I don't know how to as of yet. Again, this is a side hobby for me. But in the spirit of collaboration, if someone can improve the model please share!!!

Alright, finally ready to share my version of this algorithm. A few things to note:

1) I incorporated a system to smooth out the VX1 and VX2 curves, which improved results. It's mathy, but it checks out.

2) I simplified the if/then statements at the end to simplify things and get rid of redundant or unnecessary checks.

3) I overfitted all of the constants (although I did so about 6-8 weeks ago, so the recent performance may be improved by tweaking them a bit more).

I am going to post two backtests in a row, so I can show the effect of have that "lowest VIX threshold" I was talking about.

Clone Algorithm
24
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 591c9f3fba67a8621bf960a9
There was a runtime error.

As you can see, this version (which includes a "lowest VIX threshold" check) reaches higher highs but performed fairly poorly in the last few weeks.

Clone Algorithm
24
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 591c9ed387939766c5e09fdd
There was a runtime error.

John, this is brilliant. Thank you!!!

Igor,

My version of with yahoo data is telling me to stay in UXVY right now, that might change by close.

Edit: I take that back, unless the vix change from yesterdays close goes below 10% there is no way the algorithm will say anything but UXVY. The only thing here is that the yahoo live data is leading the close data.

-Jacob

Macro,

Of course! I come from a math/engineering/programming background with little experience in finance, so any of the math or programming stuff I can help out with. The patterns are definitely there, they've just gotta be mined out.

John,

Thank you for sharing your changes. Couple questions...

1) Why did you decide to decay then vx1 and vx2 settlments based on the days remaining vs changing the 0.7/0.3 weights. I ask because I was trying to solve that problem too but didn't think of doing it this way.

2) Macro has since abandoned the MACD signal, have you tried your code with his new VIX 10% signal?

John, if you change the UVXY threshold to 5.6 you will get far better results. :-)

Here is my latest which is basically: Macro's Last + John's Futures Decay + My Settlement Date math best yet...

Things I am am playing with MACD vs VIX Percent Change, John's Low VIX "Trumps" all signal

Clone Algorithm
70
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 591cbc82ba67a8621bf96324
There was a runtime error.

Macro,

Adding the SPYG MACD test back into the mix adds almost doubles the returns and lowers the beta. Why did you remove it again? Just that we can't trust quantopia's MACD calc?

Clone Algorithm
70
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 591d07ad9a0e8f61887b58d7
There was a runtime error.

Whatever MACD the talib library produces isn't the same as the MACD you'll get performing the calc somewhere else. Why this is, I don't know.

However, does it even matter? If it works, it works. Whatever talib is calculating is obviously giving a pretty decent signal.

It matters because we can't live trade on quantopian yet. This leaves me with having to calculate MACD somewhere else. I guess I could create a notebook to just calculate MACD quantopian style every day :) Kind of lame though.

John, Can you please explaint he smoothing to me if possible please? Why are you doing it, what's the methodology, and how did you arrive at the numbers?

Jacob, I removed the macd precisely because I wanted to implement the algo in java, but indeed the macd is a great signal. I did another version of the algo by removing some overfitting, and even that gives about the same as your results. backtest attached. Your's is clear, so I am going to go with it.

It sucks that we can't trade this live through Quantopian.

Clone Algorithm
29
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 591d39c5979ca66667413a81
There was a runtime error.

The good thing about this version though is that it further lowers beta.

And increases alpha and lowers drawdown.

I would really appreciate it if someone can take my last implementation of the algorithm and use these 2 URls for VIX and VXV

String vixUrl = "http://www.cboe.com/publish/scheduledtask/mktdata/datahouse/vixcurrent.csv" ;
String vxvUrl = "http://www.cboe.com/publish/scheduledtask/mktdata/datahouse/vxvdailyprices.csv" ;

I don't trust the pipeline as I can't replicate that in Excel. I tried to use these two URLs and couldn't ge tthem working.

This is the version that I would need help with. Thanks much in advance!

Clone Algorithm
29
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 591d3d0f979ca66667413aba
There was a runtime error.

Bonehead questions,

1- Why can't Quantopian trade this live?

2- I have cloned several variations above and did not change anything. The backtest picked XIV yesterday while IB demo picked UVXY. What is the difference?

Thanks for sharing your hard work!!!!

@Macro

I have been using the following in my Java program. I don't see any different and these are easy to use with fetch:

https://www.quandl.com/api/v1/datasets/CBOE/VIX.csv
https://www.quandl.com/api/v1/datasets/CBOE/VXV.csv

They both seem to update by 8pm the previous night.

For settlement dates I use:

http://cfe.cboe.com/market-data/futures-settlements

This seems to update everyday at close of trading 4:30pm EST.

Macro,

I'll try to explain the smoothing as best I can. I did it because I didn't like how the VX1 and VX2 data was "sawtoothed", that it experienced a spike every expiration. Trying to use that as a signal for a continuous future seemed counter-intuitive to me, so I started thinking of a way to smooth it.

I wrote all the math out and derived the formula by hand, but basically it applies a decay that is proportional to the number of days left until the expiration, because the longer the contract is from expiration, the more "inflated" the price will tend to be.

I scoured through the historical VX1 and VX2 data to get the constants for decay, and the 19.5 constant is based on a rough average number of trading days per expiration cycle.

If you have other questions, let me know. I didn't really go into it expecting it to improve the algo, I just did it because the sawtoothiness was bothering me.

And Macro, don't know if you noticed, but the backtest officially hits over 1,000,000% returns if run until yesterday :) Pretty huge milestone, even if the slippage is teased a bit!

Quandl is sometimes late updating, either way, they will be deleting the YAHOO database on June 30th. Since 5/15 Yahoo has changed the way many 3rd parties access their finance data. They now require a cookie to be set, thus killing the auto-updating some applications have been relying on.

Jacob/John,

Could you please elaborate on the logic of decay. Not questioning it just want to understand. So, you take days since last expiration and add some value actually equal to: decay_per_day*(19.5-days_since_last_expiration).
So, what 19.5 mean? Is it average number of days between two contracts? But if so should'n we be using 30, as you are not considering trading days but just diff (at least last attached algo shows that)
Also, as we are applying this decay to V1, why not apply the same logic to V2 and instead of 19.5(which is 1 month), use 2 month? Maybe then we don't need that ratio_weight = 0.7 weird logic?

I cleaned up the portion of code that gets the data ready for the algorithm. I changed the data source for VIX from Yahoo to CBOE as well.

Somehow, not getting the same results although they appear close. Can someone help me pin this down?

Clone Algorithm
12
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 591dc60e798df562293c8f43
There was a runtime error.

I think I figured out the great MACD mystery. The current MACD calculation uses the market price for SPYG on day it runs. I figured this out by working on macd in Java. Things I observed:

1) I wan't getting same value in java with yahoo or google 40d window of SPYG close data and the Java talib library.
2) If I used the Quantopian 40d price window Java talib and python talib were the same. So it wasn't talib library (like I mentioned before in this thread).
3) Yahoo/Google/Morningstar all had the same 40d close data only Quantopian was different.
4) I did a diff and they are almost exact except for the last day on Quantopian 40d close. For 2017-05-17 Quantopian = 116.510, everyone else 115.42
5) I realized when then you call data.history on 2017-05-17, Quantopian is giving you a price point for 2017-05-17, which is not a close price! As far as I can tell 116.510 is the current market price on the date it runs.
6) So I tried changing window to 41 price points and only using the first 40. This should give last 40 day closes. Now macd signal gives no information and looses all of its alpha. Which should match java backtesting. (See Attached).
7) Still this is very interesting, the current SPYG price makes a hug difference! This also makes me feel a lot better about the macd signal.

Clone Algorithm
70
Loading...
Backtest from to with initial capital
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Max Drawdown
--
Benchmark Returns
--
Volatility
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 591dc64cca415d6193d27d04
There was a runtime error.

Follow up to my last post... It makes kind of sense that:

prices = data.history(context.spyg, 'price', 40, '1d')  

Would return a 'price' on the run date, but I don't think this should:

closes = data.history(context.spyg, 'close', 40, '1d')  

As far as I can tell these two lines return the exact same data. I think this is a Quantopian bug, to whomever is listening.

John,

I have been trying to answer your question about your algorithm, and there are two major differences:

1) CBOE VIX/VXV fetch data vs pipeline.
2) Hard coded expiration dates vs expiration date calculation.

I played around with it and both these seem to have an effect:

1) I have no idea why and it will take days to figure out why.
2) I think you have something wrong here. Not with the dates themselves but your choosing of them. I printed out your "le_str" variable and it shows some odd selections around the day of expiration:

2013-10-14 08:31 my_rebalance:100 INFO 20130918
2013-10-15 08:31 my_rebalance:100 INFO 20131016
2013-10-16 08:31 my_rebalance:100 INFO 20131016
2013-10-17 08:31 my_rebalance:100 INFO 20131016
2013-10-18 08:31 my_rebalance:100 INFO 20131016

I would think the last_expiration would stay 20130918, until the 2013-10-17 run. Here are my logs for same time:

2013-10-14 08:31 rebalance:109 INFO 20130918
2013-10-15 08:31 rebalance:109 INFO 20130918
2013-10-16 08:31 rebalance:109 INFO 20130918
2013-10-17 08:31 rebalance:109 INFO 20131016
2013-10-18 08:31 rebalance:109 INFO 20131016

I of course like my date math better than hard coded values so I don't have to update dates in the future, but in this case I think your last_expiration code is wrong.