Looks really interesting but I'm getting a runtime error from the Rebalance function when I try to backtest it myself... I don't think I've made any changes to the algo.

What's the error that you are getting?

Backtests have worked for me but i didn't run them too far in the past. Might be due to a symbol not being available within a selected time frame.

@Tim - Can you elaborate on what decisions this algo is making? I like the performance but did not completely understand what its actually doing.

It looks too good to be true. It's such a short backtest history.

@Minh Ngo: Well, I suppose you are not going to use it then, right?

@Brandon: Yes, this is the earliest the backtest can be started because some of the symbols do not go further back.

Here's the same algorithm without the VIX ETF component (XIV), which makes it possible to run the backtest from 2004.

The EDV bond has also been replaced by the TLT for the same reason, but this is not very important.

The XIV spices things up, though, and provides for additional returns.

@Brandon: The algorithm essentially uses a cross-over signal from a short and a long moving average of a S&P 500 ETF in order to enter and exit positions in this same index and in a government bond.

The VIX ETF (XIV) is essentially assumed to move in the same direction as the market, since a bullish market is linked to decreasing volatility and the other way around.

@Tim thanks for the elaboration.

I have experimented with your Algo and made a few modifications that might help the Robinhood implementation a bit. In addition I added the signal indicator to the chart to help view the progress of that a bit. With @Tim's addition of TLT, I made a modification to do 50% TLT and 50% EDV instead of 100% of one or the other

One more note: Since Robinhood clears their sales after 3 days you cannot use proceeds from a sale to purchase again on the same day. So I build a variable in that limits the Algo. The context.value variable should be not more than half of the cash balance in the account to allow for the sell and purchase on the same day.

EDIT: Forgot to attach the Algo...see below

Here are the results

Thanks Brandon, I did not realize that proceeds from a sale cannot be used immediately.

Your welcome, I put this to the true test by going live with it yesterday. It was a down day, but the loss was less than SPY. So far the Algo has performed as expected.

Brandon, please be very careful !

My original algo, at least, goes into negative cash from time to time. I only discovered this yesterday. If you are trading with a non-margin account, such us RobinHood (I believe), this could trigger a margin call !

If you are using RobinHood, I would strongly suggest that you record (plot) the context.portfolio.cash variable in your backtest to see whether it goes negative.

I am very sorry about this development, but I was totally unaware about this problem until very recently when one of our fellow Quantopians turned my attention it.

Thanks Tim. Hopfully having the context.value variable should help limit my exposure because it should limit the purchases, so far it is working as expected.

I will backtest to confirm the fuctionality as you noted.

Just ran a few backtests and they responded as expected.

FYI, in the past I have noticed that with Robinhood and live trades they will not allow you to go negative with cash. Any orders that will cause a negative cash balance are automatically denied.

Many thanks for coming back with the results so quickly, Brandon, and good luck with your live trade!

For those interested, here is a version of my original algo with improved cash management -- thanks to @garyha and his PrV routine !

It still goes into negative cash sometimes, but to a negligible extent.

It checks for positive cash before placing any orders. This should in principle take care of the three-day delay in the a availability of sale proceeds as well, but the only way to know and to see what side effects this may have would probably be to go live with it, unfortunately. Perhaps I should put the money where the mouth is and cough up some cash ...

The volatility is very high and the drawdown periods protracted, but the profits are not bad and the Sharpe ratio is more or less acceptable, I suppose.

Below I am also attaching a Pyfolio tear sheet of the backtest for your peruse.

The Pyfolio sheet.

Hi Tim,

You might also consider what I posted here:

https://www.quantopian.com/posts/minimum-variance-w-slash-constraint

Grant

The first algo: Profited 22829 on 39165 activated/transacted for PvR of 58.3%   0.0505 %/day  
Most recent:    Profited 20194 on 10095 activated/transacted for PvR of 200.0%  0.1766 %/day  

blue pill (to forget about The Matrix and continue to live in the world of illusion) or a red pill (to enter the [...] world of reality). -- Morpheus, Wikipedia

Tim chose the red pill, PvR. Result, a dramatic increase ... 58.3% ==> 200.0%

In 60 algos that I ran this week with PvR, there is only one higher in PvR per day (that could not yet be eliminated as overfitting)
  than this one by Tim Vidmar, at 0.1766 %/day.

I will share privately with anyone demonstrating that they are working with PvR and understand it, which algo that is.

(The code above by GK ranks 8th even with the negative cash).

Hi Grant,

Many thanks for drawing my attention to your optimization algorithm. Brilliant job! I can only wish I knew that much Python ...

I do believe, however, that the issue of negative cash, as pointed out by garyha, is an important one. Have you tried running your algorithm with his PvR metrics?

Regards,

Tim

One final version of the algo on my part. Negative cash is now completely avoided, so the algo should work for live trading with Robinhood. Also added is a simulation of the 3-day delay in the availability of sales' proceeds. Please comment out the related parts only suitable for backtesting when going live and the other way around.

To stay on the safe side, only 95% of the available cash is invested at any time. Since the assumption is that Robinhood charges no commission, trading is now carried out daily, rather than weekly., to catch market downturns earlier. The result of all these measures is that the profit is much reduced with regard to the more risky version, but so are the volatility and the drawdown.

The main advantage of this algo as compared to simply investing into an index ETF is that it should be able to avoid a major crash in a serious crisis, like the one in 2008.

Regarding cash going slightly negative, I hadn't considered how that would play out with Robinhood. The obvious solution is that the sum of the allocations needs to be less than 1, to compensate (i.e. create a small cash buffer). But what should the factor be? I suppose one approach is to run successive backtests, tweaking the leverage until it always stays below 1.0, but that wouldn't necessarily guard against bad things from happening live on Robinhood.

He meant your own -$22,362 (started with $10k), 120% negative cash.
Repeating his question, have you tried yours, GK, with PvR?
Maybe a similar increase in fully accounted-for profitability could come out of that.

Hi Gary,

I'm not sure what you mean. If the leverage is around 1, how could the algo have borrowed -$22,362?

Grant

Because record() only records the last value seen in a day, explained further at Max Intraday Leverage

@Tim, great additions I plan on migrating my live trading to this now.

Thanks again for your trust, Brandon, all the best with your trades!

Please let me know if anything seems suspicious or goes wrong.

The only thing going wrong today is the market direction! ;-)

@Brandon: Sorry to hear that, if the trend continues for a few days, the code should realize that and take action, i.e., switch the investement to bonds.

+0.54% today, i'd say it worked. Once it went live the Algo bought in then decided to sell in the afternoon.

A note...I am getting this during live trading with this code. I don't understand what is causing it to drop into the IF statement.

def do_unsettled_funds_exist(context):  
    """  
    For Robinhood users. In order to prevent you from attempting  
    to trade on unsettled cash (settlement dates are T+3) from  
    sale of proceeds. You can use this snippet of code which  
    checks for whether or not you currently have unsettled funds  
    To only be used for live trading!  
    """  
    if context.portfolio.cash != context.account.settled_cash:  
        log.info("Unsettled Funds EXIST")  
        log.info("Portfolio Cash = '%s'" % (context.portfolio.cash))  
        log.info("Settled Cash = '%s'" % (context.account.settled_cash))  
        return True

2016-02-16 14:32 do_unsettled_funds_exist:115 INFO Settled Cash = '416.56'
2016-02-16 14:32 do_unsettled_funds_exist:114 INFO Portfolio Cash = '416.56'
2016-02-16 14:32 do_unsettled_funds_exist:113 INFO Unsettled Funds EXIST

Brandon,

I believe the message is related to the T+3 settlement rule and is simply informing you that due to it, less funds (cash) are actually available than one might expect. The algorithm takes this into account and waits for the fund to be settled, i.e., on the days when you get the message, the algo does not (should not) trade.

Unfortunately I do not think that's the cause. As you can see from the live log message above, it is actually determining that context.portfolio.cash and context.account.settled_cash do not equal (lines 113,114,115) in the algo.

To troubleshoot I added the two lines to print the values and they match.

if context.portfolio.cash != context.account.settled_cash:  
        log.info("Unsettled Funds EXIST")  
        log.info("Portfolio Cash = '%s'" % (context.portfolio.cash))  
        log.info("Settled Cash = '%s'" % (context.account.settled_cash))  
        return True  

It appears that the algo is somehow determining that 416.56 != 416.56.. which is wrong and should not run any of the if statement
if context.portfolio.cash != context.account.settled_cash:

I think something is not functioning properly with quantopian's implementation of robinhood algo's.

Here is the complete code with the modifications...I can't figure out why its thinking the two equal values of context.portfolio.cash and context.account.settled_cash and not equal.

Brandon,

I think waht we have here is a typical example of the not very savvy programming practice of directly comparing two real numbers for equality .

Even a slightest difference in some decimal places, which can be caused by rounding errors, will make them appear different.

I think one could try the following few lines of code instead:

if np.abs(context.portfolio.cash / context.account.settled_cash - 1) > 0.001:
log.info("Unsettled Funds EXIST")
log.info("Portfolio Cash = '%s'" % (context.portfolio.cash))
log.info("Settled Cash = '%s'" % (context.account.settled_cash))
return True

Variation on the theme, for those with a margin account (IB ?) and a stomach for large volatility and drawdowns.

Advantage: exceedingly simple, could even be executed manually.

See also http://seekingalpha.com/article/3924056-xiv-svxy-go?ifp=0 .

Tear sheet for the algo above.

Thanks for the great discussion here, everyone. For those trading the algo since this discussion, how has it performed? I just backtested the most recent Robinhood-compatable version from Tim from 02/04 to 03/27 and it returns about 10% lower than SPY. Is that expected variance, or is the algo not working out of sample?

Hey @Tim,

Thanks for the algo. I'm new to this and trying to learn more about it. I figure an interesting way, besides tutorials and books, is to look at other people's codes and dissect them to learn what each component is doing. Upon running some back tests of your second iteration posted in this thread from 3/24/15 to 3/24/16, it seems like the algo only purchased 3 stocks total. They were RSP, XIV, and EDV. It purchased and held most for a long period of time. Is this the correct implementation of the algo? For the heck of it, I hit run Live Yesterday just to see how Live Trading worked. It ended up buying RSP and XIV.

Thanks!
Zach

Hi Zach,

Sincerest thanks for your interest in this algorithm and for your comments.

You have analyzed the algo's behaviour absolutely correctly, it invests into an equal-weights S&P 500 ETF (RSP), plus an inverse volatility index (XIV), which is highly correlated with the RSP and spices things up -- in the sense of higher returns, but also higher risk -- except during the periods of profound market draw-downs, which are detected through a simple crossing of a long and a short moving averages of the RSP and the VIX, when it goes 100% into a government bond ETF (EDV), until the market rises again. The idea is thus to follow the market, as it is often recommended to retail investors, while avoiding as much as possible the highly bearish periods (i.e., the 2008 crisis). Quite simplistic, therefore, but not entirely un-effective.

Good luck with the algo if you intend to trade trade it live. Should you have any suggestions for improvement, please feel free to implement them and/or let me know.

Regards,

Tim

Hey @Steve,

According to the Pyfolio tear sheet analysis (the various versions of) this algo indeed perform worse out of sample then otherwise, but the average yearly return should still be around 10%.

That being said, the algo can indeed experience long periods of drawdown or very low growth. It is also not really clear how is it going to perform in this era of extremely low interest rates.

Please be careful if you are trading it live. If there are people out here who do, I would very much like to hear about your experience.

Regards,

Tim

Thanks @Tim - I think it's worth emphasizing what you've already said on this thread: the main value of this algo is to protect against severe market downturns, rather than to earn abnormal returns regardless of market conditions.

Thanks Tim!

As soon as I sent it and went back in to deconstruct it, I figured out that may be the context.m etc. may be the 3 stocks. Low and behold, I just didn't read the comments next to them saying which stocks there were... I really appreciate the context of the algo; it'll help me better understand the code and math when trying to piece it together. I'm coming from a Matlab background so I have an idea of the syntax but need to do a lot more studying a practice!

As a side note, up 1% so far today with my chump change investment :D !!

Thanks,
Zach

Here is the latest incarnation of the algo, with garyha's PvR routine, and Luca's cash management. Thanks for your brilliant code, guys!

It no longer obeys the T+3 rule, since it has been apparently abandoned by Robinhood in the meantime, and it stays in positive cash all the time.

It needs a warm-up period, though, to come to full leverage (1.0).

Thanks @Tim! I'll see if this is the one that I've implemented. And one last dumb question, but how long is the warm-up period? I figure the code will go back in time and start using previous data to calculate market averages and cross over. Or does it use the starting data for that as the point at which the code was initiated?

Thanks again!
Zach

@Zach, the algo takes about a week to "warm up" because when switching between the investment into any of the three different assets it deals with it only invests 1/5 of the allocated cash into the asses that is to be made part of the current portfolio at each time step in order to prevent over-leveraging and to smoothen its overall performance, so that in the beginning the leverage only gradually builds up to unity from zero.

Hi @Zhang,

My reasoning / numerical experimentation went approximately like this:

-- XIV is by definition inversely related to market volatility;
-- Market rallies are linked to periods of low volatility and turmoils to increased volatility;
-- XIV should therefore be fairly well correlated with the performance of the market itself;
-- I use SPY as a market proxy and later came accross the article that indeed demonstrated the existence of high correlation between XIV and SPY;
-- My entry / exit signal is thus based on both SPY and XIV and it looks for a simple crossover of two MAs -- this latter finding is purely empirical.

Hope this makes sense.

Sorry, should have addressed you as Meng, I suppose, my apologies. I assumed Zhang was the family name and I believe it is Chinese tradition to refer to persons by their family name. Please forgive me if I got it wrong.

@Zhang, thank you for sharing the graph of live trading with the XIV. I assume you programmed the same signal that my algo is using in in the environment of a live-trading platform? Was this easily done?

Hi Zhang,

Good luck with your trades, thanks for the trust and please let me know if anything goes wrong -- or if you have great success, of course ! :-)

Hey Tim, thanks for all your help on this! is your algo from 3/29 ready for live trade?

And what do you mean by warm up period.... does the algo already account for this or does it mean i should just put in a small amount, then dump in the rest a week later?

Any ideas on how to get Robinhood instant? Its apparently got a wait queue.

edit:After review of the algo i see it 'warms up' on its own.

Hi Corey,

I have to point out that I am actually not able to say whether the algo is ready for Robinhood trading or not, because I have never traded it live myself. It is my understanding that only US citizens can currently open a Robinhood account and I am unfortunately not one of them. :-)

That being said, it would certainly be a good idea to incorporate into the algo all the special elements linked to Robinhood trading, as they are presented in a dedicated framework sample on the Quantopian help pages:

https://www.quantopian.com/help#sample-robinhood

And yes, you are absolutely right, you can invest the entire sum that you intend to from the very start, the "warm up" is automatic.

I made some coding changes that have no immediate impact to the Algo that Tim last posted as a learning tool for myself. I basically changed some literals to variables, so that I could do iterative backtesting a little easier. The sections modified are initialize and rebalance. You can get interesting results by changing the values for betFuturesPercent and betEquityPercent to say .5 the returns go > 340% over the period.

My purpose as I mentioned is to learn. I was hoping someone could point me to some documentation that would help me understand the following lines;

    P = history(100, '1d', 'price').dropna(axis = 1)  
    x = (P.tail(10).median() / P.median() - 1).dropna()

    go = signal[context.m] and signal[context.x]

I have never worked in python before, though I have worked in BASIC (of a number of flavors, including .NET) emacs languages including awk and actionScript as well as languages used when dinosaurs roamed the earth.

I decided to take a stab at documenting the code I wasn't clear on.

If there is a kind soul that will look over my comments and provide knowledgeable insight I would appreciate it;

#   Get last hundred days worth of prices for universe, removing rows where the price is NaN.  
    P = history(100, '1d', 'price').dropna(axis = 1)  
    x = (P.tail(10).median() / P.median() - 1).dropna()  
#   Get 1 value for each member of the universe.  
#   The value will be the median of the last 10 days divided by the median of the entire set.

#   Check if the datatable x contains the members of our universe.  
    if context.m not in x.index:  
        return  
    if context.f not in x.index:  
        return  
    if context.x not in x.index:  
        return  
#   Check if the datatable data contains the members of our universe.  
    if context.m not in data:  
        return  
    if context.f not in data:  
        return  
    if context.x not in data:  
        return  
#   Check if the datatable data contains prices for the members of our universe.  
    if 'price' not in data[context.m]:  
        return  
    if 'price' not in data[context.f]:  
        return  
    if 'price' not in data[context.x]:  
        return  
#   create a datatable signal with boolean values that indicate whether the last 10 days median > last 100 days median.  
    signal = (x > 0)

#   Check if the datatable signal contains prices for the members of our universe.  
    if context.m not in signal.index:  
        return  
    if context.f not in signal.index:  
        return  
    if context.x not in signal.index:  
        return

Well if you've got the stomach for it, here is a version that adds another position to the mix, and fiddles with how much to bet on the various positions.

Pointers on max draw down reduction without hammering the return might be good.

Hi Paul,

Thanks for adding the comments, as far as I am concerned they are spot on -- or at least what you describe is what I intended to achieve with the code. :-)

The code itself is probably awful from an experienced Python programmer's point of view. My apologies, my "primary" language is Fortran.

Hi again Paul,

Your latest version of the algo really achieves some exciting returns. May I trouble you for an explanation of its logic?

Paul,

You have quite obviously sucessfuly figured it out by yourself by now, but just for the sake of completeness, the explantion of the lines in the algo that you quote:

P = history(100, '1d', 'price').dropna(axis = 1)
x = (P.tail(10).median() / P.median() - 1).dropna()

The history command fetches the last one hundred days of daily close price values for all the equities used in the algo and stores them as a Pandas DataFrame into the variable P. Then, a simple way of estimating their momentum follows by taking the ratio of the median value of the last ten days of P and the full 100 days.

go = signal[context.m] and signal[context.x]

This is just a simple assignment to a logical variable that combines the values of the logical "array" signal (actually , a Pandas Series object) for two different equities.

I hope this helps.

Thanks for the compliments Tim. I dabbled in Fortran a long time ago.

The first thing that I did was to change some of the literals to variables so that I could easily change the values and run different values. Other things I did was;

Added a second symbol, TMF to the treasury side, so that I had two symbols on either side to buy/sell. I then added some logic to decide which of the two symbols on either side might be best at the moment (lines 184 and 202). I also changed the split of how much to bet from 70%/30% to 80%/20%, I also changed how much to bet on a single day from 20% to 30%.

One thing I read which I need to be careful of is fitting the algo to match the backtested data. It seems as though if you tweak an algo too much it performs well on backtested data but sucks when put into production. I believe that max drawdown is supposed to help you avoid that by showing you cases where your algo bites it.

I am not overly risk averse, and my next step is to try live trading, if I can figure out how to put the latest iteration into production.

Thanks for the explanation of gist of your algo, Paul.

Overfitting can indeed be dangerous, but as long as an algorithm performs reasonably well once the original basic idea behind it has been implemented, some amount of optimization should not be a problem, I suppose.

All the best with the live trade!

Paul, have you or anyone else been trading this algorithm live? Also, has anyone tried this on Quantopian 2 yet? I am no expert and have been really just reading the code to understand what it does. I tried some tweaks, but none of them have ran without any errors. Thx all and nice work.

I plan to try it as soon as my robinhood account gets 'instant' but I will need someone help setting it up.

@corey windsor what kind of help do you need? You can check out the Live Trading Section in the FAQ on how to setup your account and integrate it with Quantopian. There's also the Algorithm Framework for Robinhood for implementing the proper code for live trading.

Let me know if that helps at all.

I have taken the step of paper trading $10,000 on an "enhanced" version of my (Tim's) algorithm. Didn't start until about 11:00 AM and it booked $19.04 profit in paper money.

I started moving money around so that I can fund my newly created Robinhood account. I will probably fire it up live on Monday feeding it $10,000 assuming nothing goes haywire between now and then.

Thanks for the feedback Paul, I hope you can find time to keep us updated on how it goes and whether you decide to tweak it. Have you tested it on Q2? Currious, do you know of any algos that trade based on trading pattens?

Paul

Did you have to update any code before going live with your Robinhood account for the latest algorithm that you posted? I'm thinking about putting a couple thousand in live to see how it does.

Steven, this is still a work in progress. I did add a line of code that I hope will keep me from over spending when live;

    long_cash = min(long_cash, context.account.settled_cash, context.account.available_funds)

I am still paper trading the algo, and so far since 11:00 AM on Wednesday the version I am running is up about $83, based on $10,000 start.

Having said all of that I am waffling between IB & Robinhood. As I mentioned in a separate thread I am concerned about Robinhood from a "ready for primetime" perspective, and IB because of costs. I have created accounts on both, but as of yet they are unfunded.

Where did you add that line of code?

I also ran a back-test in the new version of Q2. Results are the same, back-testing is insanely quick but I'll work on upgrading the below things.

Line 122: The `history` method is deprecated. Use `data.history` instead.  
Line 138: Checking whether an asset is in data is deprecated.  
Line 140: Checking whether an asset is in data is deprecated.  
Line 142: Checking whether an asset is in data is deprecated.  
Line 144: Checking whether an asset is in data is deprecated.  
Line 148: `data[sid(N)]` is deprecated. Use `data.current`.  
Line 150: `data[sid(N)]` is deprecated. Use `data.current`.  
Line 152: `data[sid(N)]` is deprecated. Use `data.current`.  
Line 154: `data[sid(N)]` is deprecated. Use `data.current`.  
Line 301: `data[sid(N)]` is deprecated. Use `data.current`.  

Actually I wasn't looking at the right backtest. It's actually a difference of 100% or so.

Here is the link to a thread that has the backtest on Q2.
enter link description here

So I went ahead and put 1k in Robinhood and am running Pauls latest version to see how things go. If there are any new changes you want to share please let me know.

I'll update in a couple days to let everyone know how it's running.

Hi Steven, thanks for your input. Did you change the deprecated coding? I have been "Live Testing" the algo through Quantopian for a few days now. It is currently up over 8%. I would love to know if you or anyone else is seeing any discrepancies with the Real Time/Real Money trading vs. Quantopian's live trading, and if the algo is trading as expected in regards to the coding.

I suspect the markets may shift a little soon and we should see some pullback off these high levels from the major indexes. I am anxious to see how the algo will treat any change in market conditions.

Thanks

Hi Sid

I haven't changed it yet. I plan to work on that some tonight. As of right now i'm up 4.52%. It has only bought XIV so far. I'm using the last version that Paul put up. Are you using that same version? Did you make any changes to it?

I'm also using Robinhood, did you change anything in the code that relates to that before going live? I didn't see anything in it having to do with 3 day settlement which i'm not to worried about since I'm hoping to get Robinhood instant soon but just wondering if you messed with any of that.

Steve, I havn't had a chance to look at the deprecated code or new documentation. I will hopefully have a chance soon. I will keep,you posted.

All - I have an updated the algorithm for Q2, which is based on Paul Stearns' 4/6/2016 post. I have been trading live with it since that time (minus a few Robinhood crashes). So far up 5.2% on 1k initial investment. Waiting for a switch from equity to treasury before I start investing more. Very thankful for this group. Learning something new every day.

Thanks Caleb

Ignore previous post, backtests match up perfect. I had a different starting balance. Great work!!!

Would it be possible to incorporate some of the things in the following back-test that I found here: https://www.quantopian.com/posts/universal-portfolios

It would be interesting to use the logic that determines if the market is in a downturn. If you see attached it held cash throughout the 2008 crash. I think this might be a great addition if someone knows how to implement it into the latest one above.

Steven and Caleb,
Happy to hear your algo's are performing well on Robinhood. Just to clarify, are you two trading under the T+3 restrictions with Robinhood (aka you don't have Robinhood instant yet)? I'm wondering because this code doesn't follow the T+3 restrictions anymore, but I would assume the algo would still perform as long as there is enough settled cash when making an order.

Anyone using Robinhood with Robinhood Instant? Would love to compare insights.

I am using Robinhood with Robinhood Instant. What would you like to know?

Hey Banana Bread,

So I just got Instant and I am trading with a dollar amount below the PDT rules. The algo buys and sells only one security each day. Seems like I am getting PDT rejections on the sell side, but not the buy side. As a result, the algo started building up a position and holding overnight. Have you written any code that accounts for T+3 but adjusts for the $1K that will automatically turnover from Robin Instant? (I am going to work on that soon, but looking for a shortcut). Also, I am wondering if you have noticed any period where Instant does not immediately turn over the $1K? I had a situation where the algo was supposed to sell one minute and buy the next minute. It missed the buy, but not because of PDT rejection, rather just a lack of cash. Wondering if you have seen anything similar?

Thanks

Thanks Caleb for posting the update. I am glad to hear it is working out well for you. I'm waiting to see how the algo exits it's current positions before gong live. Unfortunately, what Frank posted about the PDT issues has me concerned since I am hoping to start well below the PDT requirement level.

Frank, are you referring to this particular algo that Caleb posted or another algo you are using with Robinhood? As far as I can tell the algo Caleb and the others posted does not necessarily conduct day trades.

Thanks.

Hey Frank,

Yes PDT restrictions only applies to selling the stock not buying it. If you have RobinHood instant you get all your money instantly when you sell a position. The $1K you are referring to only applies to recurring deposits. I haven't written any code for the T+3 rule because it's unnecessary as an RH instant user. There can be periods where trades may take longer than a minute to process but that usually happens in low liquidity stocks and I know RH has in the past month have had issues where orders wouldn't go through. What I would do is check every minute for rejected trades and reopen them if they had been rejected, if your sell order goes through eventually your buy order will go through too because you will have enough cash. Let me know if you have any additional questions.

Jake - I am trading under Robinhood classic (T+3) and am currently in line for Robinhood Instant. Although, I'm not sure I will sign up for Robinhood Instant once I'm offered the chance. Overall, there just seems to be more restrictions with Robinhood Instant. I would rather have the flexibility of being a PDT if the algorithm calls for it. I'm already trading above the $1k max deposit for instant, and will now be subject to the 4-5 day deposit/withdrawal waiting period going forward...although is it $1k total or up to $1k/deposit, but at what frequency??? Low dollar value stocks and leveraged ETFs have different rules under Robinhood Instant, so that will be another thing to account for in the algorithm.

Sid - From the backtest and what I can tell, the algorithm does not fall under the PDT rules. It does not buy and sell the same stock within the same day. It also only performs trades once a day.

@ Banana Bread - Thanks for the input. Very informative.

@ Sid - My apologies. I am not referring to the algo in this thread. Sorry if I caused confusion.

Apparently we have unknowingly created a strategy very similar to this one,

http://seekingalpha.com/article/3967731-hack-market-math-part-2?ifp=0 ,

except that we use the long equivalents of the short positions they take and that we have a filter, i.e., a way of gauging the direction the market as a whole is presumably heading for.

Actually, the the guys who created the strategy that I mentioned in the previous post also seem to have a few long-only versions:

http://seekingalpha.com/article/3165846-the-zomma-strategy-index-master-sheet .

I have been using Pauls latest version of this Algo in live trading with 1k. It has only bought XIV. I thought it was going to be buying more than 1 stock at a time. Is that not correct.

What determines if it buys RSP, EVD and TMF? Is this functioning how it should. I have around 223 available cash right now. Haven't seen any additional buys. Have not seen it sell anything yet either.

Has anyone been able to update Tim's algo from Feb 25, 2016 that only trades XIV/EDV for Q2? The move to Q2 has deprecated multiple lines of code.

The algo is the simplest I have found and can manually trade on my retirement account.

Hey Tyler,

Here's a backtest of a Q2-adapted version of the algo you mention.

Please be careful trading it, the volatility and drawdowns are huge.

The algo also goes slightly into negative cash at some point, so the associates trades would be rejected by Robinhood, I understand, but it probably only happens once or twice.

Forgot to mention that I changed the trading frequency in the above-mentioned algo to daily. Here's the original approach with weekly trades. For some reason it performs quite a bit worse.

In both cases the trading period in the day has been changed from market_close - 30 min to market_open + 30 minutes, to assure enough time for the trades to be filled.

Why is there a difference between the updated Q2 algo and the one from Feb 25, 2016? The older one was traded weekly and was up to 600% before the switch over to Q2?

@Tyler,

Here a Q2-adapted version of the original algo: like that one it trades weekly, on market-close minus 30 min.

The difference in the performance must stem from the changes introduced with Q2.

I think this also indicates that the algo is highly volatile, sensitive and in a way unstable. I do not recommend trading it.

I fear it's too overfitted. I can't play with volatile ETFs knowing that your half of your money can disappear in a month. It's psychologically demanding.

Why does the algo buy and sell in multiple transactions? I see 10+ sell orders of the same security minutes apart.

3:31 RSP SELL
3:33 RSP SELL
3:35 RSP SELL
3:36 RSP SELL

@Corey: Because not all orders can be filled immediately.

So if I have robinhood but no instant, which version should I use?

Are there any updates from those live-trading this? XIV has taken a large downturn lately, very curious as to how it fared.

I'm down 13.2%. :'(
I' m trading SVXY since they won't let me trade ETN due to being under 21 :(

The last version has a DD of 29%.... If you cannot stomach that type of DD (Whihc I can't) then don't trade it. If a DD is in the Backtest, assume it will happen again

I have been trading a modified version of this Algo on IB for about a month. It has been up as high as 7%, and is currently down 1.3%. The modifications I made include;

1) Added trailing stops on individual stocks based on the stock's volatility.
2) Added total portfolio trailing stop based on fixed loss (15%).
3) Added skim profit % weekly. Removes % of profit from available cash at the beginning of every week.
4) Trade RSP & XIV vs EDV & TMF.

Total initial investment is $10,000.

I have been using this algo on Quantopian's live trading environment and I was up over 20% at one time. Right now, I noticed this is the second time I've watched a downturn occur and the algo does nothing about it (sell or take profits, leverage itself, etc.). This down turn has been fast and hard so I sit at about 4% on the upside from over %20. Since this is a long term strategy, I am still interested in Seeing what the algo does at this point. I suspect another day or two of downside pressure before a bounce from oversold territory. Being that the algo has the account fully invested, It would have been great to see some profit taking and then some more buying at the dips. I guess I will wait and see. Interestingly enough, since this algo trades only a few stocks, it is easy to use as a guide and manually trade referencing it. I will report more.

Paul is your modified version using the trailing stops effectively? Are the trailing stops based on percentage, moving averages or somethng else? TIA

Paul

I'm interested to see how your handling trailing stops and skimming profit. Thankfully I stopped the Algo 2 weeks ago and bought VXX which I sold yesterday, and have been buying and selling manually for VXX and XIV so I'm up almost 20%. My worry was I wanted to capture 5% gains and lock that profit in then either buy XIV again or VXX depending on how the markets moved, I had to hold VXX for 2 weeks but was worth it. I would be interested to see an algo that using trailing limits and stops on XIV to buy at low point and sell right when it turns and maybe even add VXX in it some. I may try to work on that some.

For anyone who lost money I wouldn't be that worried since I'm sure you will make it back in a week or two.

Here are some log entries from live trading, that explain the trailing stop a bit;

2016-06-13 09:31 trailingStop:511 INFO asset:Equity(40516 [XIV]) cost basis:27.6978740157 current price:29.734 high price:34.0334516129
2016-06-13 09:31 trailingStop:509 INFO Trailing stop sold all:Equity(40516 [XIV]) shares:127 stop:10.93%
2016-05-19 15:59 trailingStart:528 INFO Equity(40516 [XIV]) rehabilitated - current:27.5659354839 low:26.3741290323 threshold:27.54
2016-05-19 10:32 trailingStop:511 INFO asset:Equity(40516 [XIV]) cost basis:28.9441756303 current price:26.693516129 high price:29.6287741935
2016-05-19 10:32 trailingStop:509 INFO Trailing stop sold all:Equity(40516 [XIV]) shares:119 stop:8.87%

To calculate the trailing stop percent threshold I take the high price - low price / average price for the last 42 days, with a maximum of 15%. I also set a flag so I don't buy the stock again until it has been rehabilitated, which I define as inverse of a trailing stop, in other words it must bounce off a low by its volatility * .5 (1/2 its volatility factor).

My profit skimmer takes the current portfolio value, if it is greater than the portfolio value from last week, I calculate the profit, multiply by .4 and add it to "cash reserve" which is an amount of cash I do not trade with. The next time I rebalance the portfolio, I sell enough to cover cash reserve.

Paul,

I would love to see the code behind that since it's still kind of going over my head.

Ouch to whoever shorted volatility. Yet another reason to treat these dangerous instruments with respect.

Well we bounced a little, then Brexit happened. The latest code version, the one without the stop loss, never exited XIV or RSP. It basically gave up all its gains (over 20%, I think 24%). That's a big move, BUT I noticed it is not down, or at a significant loss. At this point, I would definitely look to improve the exiting strategy. Paul, I would love to know how your latest version is trading. Have you thought about using SMA or EMA crossunders?

It looks as though I sold and it rehabilitated. At this moment I am up .1%

2016-06-24 10:30 trailingStart:528 INFO Equity(40516 [XIV]) rehabilitated - current:25.9231935484 low:24.1366774194 threshold:25.6  
2016-06-24 10:01 trailingStop:511 INFO asset:Equity(40516 [XIV]) cost basis:24.7971740157 current price:25.4919354839 high price:29.7525483871  
2016-06-24 10:01 trailingStop:509 INFO Trailing stop sold all:Equity(40516 [XIV]) shares:127 stop:12.14%

Paul can you share your trailing stop/rehabilitation?

How can the algo Caleb Mellbom posted on Apr 22, 2016 be modified to ensure all cash is used? There is always a lump of cash sitting on the sidelines - want to try and push the leverage to 1 as much as possible.

Is there an updated algorithm? I tried to update the Algorithm with newer version, but its not working.

Is this algo safe for smaller accounts (less than $25,000). Will it trigger the "Pattern Day trader" rule (by executing four roundtrip daytrades within 5 days)?

Seconding Yogi's question. I'm assuming the Pattern Day Trader rule shouldn't be a problem, but with the most recent updated version of this algo, would it be safe/make sense for a smaller account?

I did a forward test and it looks like it still works. Got a popup saying that the code was automatically updated as well.

Hey all, is this still a recommended robinhood-friendly algo to start with?

@anyone interested

After trying to study the history of this thread:
It started out with XIV, but then for a little while in the beginning, the algo was changed to trading RSP vs. TLT based on a crossover. That was the highlight. Unfortunately, after they reduced the balancing from weekly to daily, the statistically significant advantage disappeared. But even the original wasn't trustworthy because of trading rarely. Also, as far as I can tell from research and study, all of general US indices are - for the most part - systemically similar (if someone knows otherwise, please enlighten me), so I avoid using indices other than the S&P500 to avoid overfitting. Also, TLT, bonds, and assets in general have been inflated (Or more specifically future values have been pulled towards us in time. Also literal inflation.) because of QE from the fed and the bank of China, so returns from long bonds can't be expected to continue any more unless you know what the central banks are going to do.

Speaking of that, I've heard that there are reasons to be concerned about a possible junk bond bubble. I don't know the technicals of that, yet, but be cautious if someone does invest in high-yield-bonds (relevant ETFs being JNK, HYG, and ANGL).

As far as the rest of the thread, I think the other algos might just be taking their profit from XIV, and looked more complicated. If you don't know, XIV was a trainwreck from the beginning, which crashed 6 months ago. XIV was terminated, thank god. If there was ever anything good in it, you can just buy/sell the VIX futures. But VIX performance is meaningless anyway without an extreme degree of understanding and studying 100-year or ideally 1000-year old volatility events.