Back to Community
Robin Hood VIX Mix Extreme Vetting

This is the latest version of Robin Hood VIX Mix Rogue Trader. I am live trading this.

It is a work in progress. It includes an integration of Robin Hood Extreme Vetting.
If you search through the forums, you will eventually find a consensus that low volume stocks are difficult to accurately backtest. For that reason, the only real test of low volume stocks is live trading. So the high returns that are due to the low volume stocks are much less reliable than returns from higher volume stocks.

Clone Algorithm
344
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: 597417ef975ccf4e0f43b370
There was a runtime error.
50 responses

I was comparing this and the previous algorithm (without extreme vetting ) and noticed that consistently this algorithm had substantially higher leverage swings.

Besides just setting leverage to a certain value ( context.account.leverage , which still provides some swings), in theory what other ways can you control leverage?

I imagine a text book would say alter your (long value + abs(short_value)) / context.portfolio.portfolio_value ratio. Although, I feel like there would still be a lot of underlying variables that also cause leverage swings.

With Robinhood accounts, selling short is not currently allowed. So that is not an option. Not sure about other methods.

I imagined that would play a factor.

Does it have something to do with trading volume of the stock and the time delay between bid and purchase?

This version may not be as profitable long term as much as Robin Hood VIX Mix Rogue Trader. At least that is what back testing shows. If that worries you, then stick with Rogue Trader.

Oh, I am not trading. I was just wondering. Don't worry about me. :)

When the low volume stock is bought, you will get rejected sell limit orders, because it may cause Pattern Day Trader. The fix for that is to have $25,000 or more in your trading account. Again, if these are issues that concern you, probably stick with Rogue Trader.

Also, I am still working on tweaking position sizing and ordering to have fewer rejected orders.

Still a work in progress. I think there will be less rejected buy orders now. I added a couple of lines to TarPer function to limit the size of the order.
Because this is a work in progress, you may want to remain with Rogue Trader.

Clone Algorithm
344
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: 5977c7173a9cf84e27a16df3
There was a runtime error.

I could not tell whether a limit order being used for buying low volume stocks. The spread could be too big for them.

I was comparing this and the previous algorithm (without extreme
vetting ) and noticed that consistently this algorithm had
substantially higher leverage swings.

Besides just setting leverage to a certain value ( context.account.leverage, which still provides some swings), in
theory what other ways can you control leverage?

I imagine a text book would say alter your (long value + abs(short_value)) / context.portfolio.portfolio_value ratio.
Although, I feel like there would still be a lot of underlying
variables that also cause leverage swings.

https://www.quantopian.com/lectures/leverage

Not sure how I missed this. Obviously this will not work with all these additional stocks involved.
All my low volume stocks sold at 9:34 market time. I removed the following code in VIX_Mix function:

    for stock in c.portfolio.positions:  
        if stock not in c.VIXstocks and stock not in c.SetAsideStocks:  
            TarPer(context, data, stock, 0.00)


Sorry, another one needed in Initialize.
context.Agree = False

Clone Algorithm
344
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: 5978c5c5b8ee044dee843cd2
There was a runtime error.

I posted my version of XIV Shotgun at https://www.quantopian.com/posts/xiv-shotgun-trading-inverse-vix-with-wvf

It includes TarPer function and margin. Hopefully it just works, so I don't have to fix it.

I am live trading Robin Hood VIX Mix Rogue Trader at this moment. I have temporarily abandoned Robin Hood VIX Mix Extreme Vetting which is still a work in progress.

Do NOT get too excited. I am back live trading Robin Hood VIX Mix Extreme Vetting. It is still a work in progress. However, it does have a more reasonable feel to it.

The micro cap low volume stocks are gone, finito, fired, no longer a part of my family. The ExtremeVetting function uses Q500 worst performers.

There is a significant drop, apparently, in Max DD. This is much improved over the previous version.

Clone Algorithm
344
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: 59820c541f62754fa313053d
There was a runtime error.

I think your drop in DD is due to a portion of your portfolio that's not making any gains/losses: The extreme vetting portion. I removed all the VIX trading and profits/losses were basically nonone. You'd be better off putting that portion into SHY/cash or someting.

Great job.

I turned off my live trade algo. For obvious reasons, I gotta stop relying on it. For now I am going to try to adjust to doing manual trades with the paper trade as a guide. As a small benefit, the paper trade seems to never die, from what I've experienced. Also, the paper trade still shows the current price, fifteen minute delayed I think.

How does everyone feel about live trading being shutdown. What are everyone's plans?

@nick I've been manually trading XIV and VXX. I watch the paper trades of this algo and a number of others, but mostly just to confirm my own hunches. Most of the volatility algos I'm watching are down over the past few weeks. My manual trades are significantly up -- might just be luck. Key is to have stop losses in place. For the most part these volatility algorithms are more crippled by the quantopian platform than they get anything out of it. Will be really easy to get them up and running on my local machine.

Probably not the best place to express how you feel about it, there's a whole thread for that

https://www.quantopian.com/posts/phasing-out-brokerage-integrations

People are also discussing what next there and here: https://www.quantopian.com/posts/questionnaire-for-quantopian-live-brokerage-traders

The more people coordinating on a single thread, the easier it will be to figure out.

@Charles, why have you stopped it? In backtesting it has managed well the big recent spikes in volatility. Do you see a significant difference between real trade and backtest?

@Viridian, since mid March, many vola algos that were making good money drastically reduced the positive results. The low volatility regime and market trendless changed the intraday pattern. This is hurting many volatility algos. I stopped them and am now doing the same as you, manual trade.

Any word on if paper trading will be phased out as well on Quantopian?

@Jay
I doubt it. That is one method that they / we do out of sample testing, I think.

@Charles
Any thoughts about moving this/just the vixmix over to IBridgePy or Zipline-live? Have been running this live with a small position on InteractiveBrokers where the data seems to perform better. It would be a shame to see it go in a month just because live-trading ends on this site.

@Charles

Have you thought about moving to Quantconnect, Zipline-live, or any other alternatives?

Edit: ibridgepy might be a viable option, which you can view right here:
https://www.quantopian.com/posts/ibridgepy-setup#59a596becd58cd0010212a1d

@everyone
All options are on the table. I may be a bit slow to change over to anything. I just now today, finished moving from a 5 bedroom to a 2 bedroom. I am exhausted. I have a lot of distractions going on right now. Not outright ignoring all of this. Simply don't have much energy / time to devote to it at this moment.

slight update: I asked Rh for help / direction on viable options for live trading algo traders such as myself. Waiting for response from Rh.

@charles

I’ve been using a electron based desktop client for robinhood for some time.

I’m currently trying to find some time to take the python robinhood api and couple it to your algos.

I’m a JavaScript developer so it’ll probably be painful to get working.

Do you know if or how these algos could run on a local machine.

From the looks of things, it’s pretty simple to hook into robinhoods api. Unfortunately I only discovered your work after the shutdown and am determined to get a solution up and running. If you have any suggestions on if this code will run locally, I’ll start an implementation.

I’ll start researching as I’m sure it’s straight forward to run this algo on my own machine?

If anyone is interested in joining me, I’ll create a repo. As I said, I don’t write python

No meaningful update from Rh yet.

However, here is my update as to my status. This algo broke when noko.csv stopped being provided by another Q user. I did attempt to adjust this algo to work without noko.csv. The results were not satisfactory. I found another algo which is not currently broken which I am using instead. It is Rolando Retana version of Kory Hoang algo Ballistic XIV https://www.quantopian.com/posts/ballistic-xiv-slash-vxx-my-best-long-xiv-slash-vxx-strategy-to-date#perf-599cda91b97574555fccd7a0

I am able to get Robinhood running in Android emulator Jar of Beans. However, I am not actually using that actively.

I am using:
the above mentioned algo as live paper trade 15 minute delay
PyAutoGUI
Google Chrome extension Little John

My setup is crude. I work on it a little each day. I am doing manual trades until the automation is reliable. I think I will have the automation running by tomorrow trading hours. I am using I3 Window Manager in Ubuntu Linux on my laptop. PyAutoGUI can work on whatever setup you have. I enjoy Linux, Python, and programming. I do not currently have a job except driving for Uber. So I have more time to do this stuff, which I do enjoy, so I am not in a hurry to get another regular job. Right now I am living off of stocks and Uber. My budget is a poor man budget more than ever now. But I love the freedom to spend more time with my wife, who does need my frequent help because of her medical problems.

Some news to me there, thx.
I spend ~97%+ time toward the fund but my Robinhood algo, modified early CWitt code quadrupled in 10 months, would have placed serious $$ in it soon.

I like your approach
Im actually using your algo from another RH vetting thread you have
My main question is how are you actually running the algo which will callback to PyAutoGUI?

Seeing as you know python, check these out
https://github.com/Jamonek/Robinhood
https://github.com/Bekt/robinhood-client
https://github.com/able900/robinhood

My plan is to pretty much use this api to trigger the trades, but i dont know how you get them running locally

Im also thinking of writing a chrome extension which watches the live trade run in quantopain, then posts to a node server which will execute the python commands

Id appreciate any help and would gladly share my work with you :) your algos have backtested beautifully.
Next week ill be running it against the market and seeing what results spit out of quant. If theres something there, then im going to likely run a chrome extension to forward the algo trades to RH

@Blue, Glad to hear you are doing well with one of my algos still! There are plenty of them that do not rely on noko.csv. This algo would get even better returns I believe than the one I am using. But I will have to figure out how to unbreak this algo later. I attempted to fix it, but the returns were destroyed. So for now I punted.

@Everybody else, I finished my automation. It is crude and custom to my situation, but I believe it stands a pretty good chance of being reliable, so I don't have to watch it every minute. It is running on my laptop. And like I said earlier, I am using the Q live 15 minute delayed paper trade with my own PyAutoGUI automation watching it for buys and sells. Because of the 15 minute delay, I set buys to a slightly adjusted limit price. But sells are market orders. We shall see how well it works tomorrow morning. I missed out on a big gain Friday because I didn't do what it said to do. When will I learn?

@Zack, your implementation ideas sound promising. I am using what I feel comfortable with at this point. We shall see how it does this week.

Thanks Charles

I’ll keep you informed of my progress as well. Thank you for you algos and input into the existing challenges we now face.

I am finding more success directly using the Robinhood API reference at https://github.com/sanko/Robinhood/blob/master/ .
There is something extra nice about being able to execute an order exactly with all the parameters I want.

So, it looks like I will use a combination of:
Ubuntu Linux
i3 Window Manager
Google Chrome or Chromium
GNOME Terminal
Monkey Studio
Python3
PyAutoGUI
TCL Expect
Robinhood API reference at https://github.com/sanko/Robinhood/blob/master/
Paper trade Rolando Retana version of Kory Hoang algo Ballistic XIV https://www.quantopian.com/posts/ballistic-xiv-slash-vxx-my-best-long-xiv-slash-vxx-strategy-to-date#perf-599cda91b97574555fccd7a0

Hey Chris

I’m glad you are finding some success :)
I myself have also made some headway. For the sake of documenting this, as well as any input from the community - here is where I’m at.

I wanted a way to keep track of today’s trades and I want to also see yesterday’s.

Problem is, the order table uses a virtual dom and only loads a couple orders.

I’ve developed a extension which pretty much tricks the virtualDom into showing all data. After deciphering their codebase I was able to locate a few global functions which gives me access to the entire web application. With this I am able to load all the trades I’ve done. Their developers store most of their constructors in memory which make accessing script instances extremely hard. I’m considering creating service workers to proxy the applications scripts back onto itself, allowing me to essentially rewrite their frontend and take full control of Quantopians paper trading platform. I would like to move to direct websocket communication, which is pretty simple but I need to replicate Qs sid to stock name. The Json comes back without the stock symbol. There’s another function which translates it that I need to gain access to. I must admit, that table has some terrible performance, extending the amount of rows to and running all their updates on that table is painful. Once the table is loaded, I use mutation observers on the DOM to spot changes, then patch them into my persisted object, which goes back to RH for synchronization.

I’ve noticed a couple forms hidden inside. Along with some iframes, I’ll need more time to investigate but with access to their models along with watiching what chatter happens between frames, I may be able to create a more robust api on both ends.

I iterate over orders in the table and construct a object with a key that’s hashed uniquely based on the data. Now that I have the trades. I run a server which intercepts the object.

On the server side (which might just be another service worker in chrome) I do a call to robinhoods api, and get my trade history there. Pretty much synchronize the trades and make sure that Robinhood is placing the same orders as Q. If there’s a new trade in the order book that’s not in RH, I push a new order to the api.

I have noticed that some Robinhood trades are executed but they are not on Q. I’m looking at setting an exclusion list Incase I want to manually trade something. But if a limit order Q places that is later cancelled because it wasn’t filled. But filled in RH, I track that independently until it’s profitable, then sell it programmatically.

Once I get enough understanding, I should be able to actually pass data back into the python algorithm and make modifications there, such as if I deposit more money or bought a stock that I want to track with the algo. I doubt they will allow cross origin requests, but it should be fairly simple to transcode their authentication into some headers. I’ve done this before to issue local sessions from a remote host with great success.

One of your Q algos places many limit orders, most are cancelled, I do want to try and minimize the amount of queries I do to RH and Q, to avoid suspicious activity. I’m considering some persistent layer that can query endpoints less frequent. Firebase might be an option just because I can asynchronously write and read elsewhere, changing the databse would indirectly execute a RH command.

Digging further into how Q runs. I discovered some websockets and a whole bunch of code. Things that may be beneficial to us, but will not mention them publicly. Luckily, the compilers that are used to build the web app are pretty bad, there’s enough obsfucated code but the manner it’s mangled makes it easy to reverse.

I’m not a fan of this delay of 15 min. Your algo does place limit orders though, so in some cases they appear before being filled, letting me forward them to RH with no profit loss. However, I wonder if it’s possible to use Robinhood as the data source? I can get the endpoint and historical data. With that we would have up to data info. Even mess with the dates so that it appears 15 min behind. I also might have found the golden goose, but need to pick the data apart.

For right now I built a chrome extension. But likely will move to a headless solution that I can host in the cloud for continuous trading. If you, or anyone else is interested in working together on some solutions, or discoveries I may or may not have found under the hood. Be it python algo work, zipline, or JavaScript. [email protected]

Just realized that your name was autocorrected. Apologies.

My time is extremely limited, but am hoping to have a full implementation by this weekend. I do however see more potential lurking inside the codebase, but I’ll need to see how secure their indirect socket to server communication is.

Sounds promising Zack!

I think I finally got my automation wrapper (around the paper trade Ballistic XIV algo mentioned above) running without any showstopper bugs. I am buying at slight discounted limit price and selling at slight padded limit price to attempt to compensate for the apparent disadvantage of 15 minute delayed paper trading. We shall see if this is profitable over the next couple of weeks.

I have also got my chrome extension stable, I’ll be testing it today to see if the my new cacheing system works.

Monday it trades without a problem

Any updates on this guys? I would love to join the development side of things with Python/Javascript.

So far it looks to be profitable the way I am doing it, at least long term, which is what I am aiming for. I've been making small tweaks to my automation wrapper daily. Today, this week actually, is probably a good test. The main thing I like about this method is that I can control it more reliably and customize it according to my needs. Depending on how I fare this week with the larger swings in volatility, I may need to make some more adjustments.

As I said before, this is running in an environment and with software tools that I am comfortable with. It may not work for others. If anyone is seriously interested in using my code in their own environment, I am willing, within reason, to assist. Of course, money helps to motivate me.

I am confident that, even if I end up losing some money short term, long term will trend profitable. This setup feels like I have more influence over my destiny. I hesitate to say "control over my destiny" because so many things out of my control can happen. I think it is good to never forget that.

@Charles If you're still around, would love an update

I tried cloning the latest version of this algo and got the following error "Exception: Could not connect to http://52.15.233.150/noko.csv"

Does anyone know content description of NOKO.CSV and format?
If it's straight forward maybe I can make it available to the community.

@Mike It seems to be working well. I have tweaked the parameters of my automation wrapper a few times, including before market open today. The paper trade on Quantopian has been running since 10/11/2017. The paper trade at this moment made 3.71% return. The 2 or 3 down periods have been a bit difficult for this algorithm to make a profit. Even so, it is a profit. Long term, it tends to do well. My real return was noticeably better, 20.39%. No guarantee of future results. I did benefit from a particularly good period of growth in TQQQ, about 8% return during a very short term. For about the last month or so though, I have only been in XIV. When I get my balance firmly above $25,000 again, then I will probably add TQQQ and UVXY strategies again. Also, keep in mind that I am only using the underlying Quantopian paper trading for buy / sell signals. But I am, in effect, changing the behavior by not buying and selling the same as the algo does.

@chandra Look at https://www.quantopian.com/posts/deployed-two-xiv-slash-uvxy-slash-tqqq-strategies-for-paper-trading-dot-dot-dot-will-make-it-live-trading-after-a-month#59b4530c8c942b00108e556f Honver Lam should be able to answer your question. I believe he was providing the noko.csv resource for the rest of us.

@Charles, Do you have a blog that we can follow? can you share how to build automation wrapper between Quantopian and Robinhood?

@Jeff, I do have a blog at http://charlesweldonwitt.blogspot.com/ . I have not updated it in a while and I have not yet put anything related to algorithmic trading on there. I am currently adding cryptocurrency trading to my automation, so that will keep me busy for a while while I tweak that.

For anybody that checks out the blog. I have retired from audiobook narration. That turned out to be a labor of love because the author was dying and wanted to see and hear his work published as an audiobook.

@Charles, it might be a good idea to manager your blog. Reader can donate and after you gain enough traffic, you can make money by commercials.

@Charles, I tested the algorithm that trades non-liquid stocks. It seems it works very well for small marketcap stocks with low liquidity while it does not work for mid or large CAPs. I wonder what is the fundamental reason that the algo works

It seems it works very well for small marketcap stocks with low liquidity while it does not work for mid or large CAPs

Likely answer is that micro-caps and small-caps are too small for hedge funds to trade, and so there are more market inefficiencies to take advantage of.