Back to Community
New Features! Paper Trading! Live Trading!

Yes, I know the subject line has three exclamation points, but we're that excited!

Paper Trading: You can now run an algorithm in "paper trading" mode. Paper trading is a big step for anyone who is getting ready to live trade. There's no way to "overfit" an algorithm that is in paper trading mode - this is an out-of-sample test that simply can't be beaten. You can fool yourself by just backtesting over and over again. But you can't fool yourself while doing paper trading.

Paper trading runs off of a live data feed (actually 15-minute delay, but effectively live). Quantopian bundles the live feed into minute bars, and pushes those bars into your algorithm. Your algorithm issues any orders it thinks it should, and the Quantopian backtester sends back any order fills. You get minute-to-minute updates on your returns, risk metrics, etc. You get to watch the results live.

The data feed for this is new to Quantopian. We're using NxCore from Nanex. This feed is interesting because it hasn't been completely cleaned. As a realtime feed, it includes bad prints and other anomalies. We may need to write defensive code in our algorithms to help identify and discard bad prints.

Paper trading is free. To start, you first have to have an algorithm that you ran a full backtest. Then click the "live trading" button and you're off!

Live Trading: We're ready to start live trading with a pilot group of traders. If you're interested in live trading, make sure you're logged into your Quantopian account and then sign up for the pilot program. We'll select new additions to our pilot group from the pool of applicants.

Live trading isn't robust enough yet for general use. When you have a bug in paper trading, it's frustrating, but the stakes are low. When you have a bug in live trading, the stakes are much higher. To mitigate that we're doing a lot of hand-holding with the pilot group and working with them to launch their algos. I tell you - it's very exciting to see orders sent to Interactive Broker and come back as trades in Quantopian!


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.

21 responses

Hello Dan,

I'll give paper trading a go when I get the opportunity. In this mode, I am not clear how the code will handle the "events." In backtesting mode, as I understand, the algorithm doesn't actually run on a real-time wall clock...if the algorithm takes longer than a minute to process a bar (or trailing window of bars), no trading time is lost, and the next sequential datetime stamped bar can be processed. However, under paper trading with a live feed, how is the timing handled? Is there a built-in sub-minute time-out? Or have you modified the code to be real-time and event-triggered?

Also, are the data from NxCore buffered/stored? Is it possible to access a trailing window of NxCore data over multiple trading days? Are the backtest data also available under paper trading?


BTW, when will trailing stops be rolled out? Hopefully before live trading.

Also FX and commodities

Hi Grant - You are right about backtesting not running on a real-time wall clock. What you may have never run into, though, is that if your algorithm takes longer than 50 seconds to process a bar, then the algorithm throws and error and cancels. We've definitely had some backtesters run into that limitation. When it happens, that basically means you need to make your algorithm perform better so that it can complete a handle_data in under 50 seconds. That limitation is enforced in live/papertrading for the obvious reasons! I think that answers your question.

We are storing the NxCore data. Unfortunately, we don't have the same 11-year library; we only have back a few weeks for NxCore. For now, backtesting is going to use the old data source, and paper/live trading is going to use the new data source. I imagine that we'll make backtesting against the NxCore data available in the future, but we haven't decided on a course.

I did check the two sources against each other, of course. They are almost the same, but not quite. Not surprisingly NxCore is "noisier" with some trades being reported that presumably were data-entry mistakes and don't appear in the cleaned source. There are also a few places where a trade is put in the next bar. For instance, in the old source bar 0 has an open, high, low, close and volume of 1000 and bar 1 has a volume of 2000. In the new data source, bar 0 has a volume of 900 and bar 1 has a volume of 2100. It all worked out in the wash, but some 100-share trade was reported in a different minute.

It's all quite fascinating to me how the different data sources all report differently. There is no "truth" in this stuff, no definitionaly correct version of events. Every data source has a slightly different perspective on what happened.

@Suminda I don't have a schedule for trailing stops. They're definitely doable with the tools you have already, but we haven't prioritized getting them as built-in yet. FX and commodities are definitely post live trading. We want to expand the set of tradeable items, but we're focused on getting people to trading US stocks first.

If someone deploys an algo for live-trading, will it run in a snapshot of the quantopian environment as it existed when deployed? Or is there a possibility that an algo that is running live will wake up one morning and throw exceptions due to some new change/bug in the quantopian env?

Great question Simon. The short answer is "the latter" - it is possible that an algo will "wake up" one morning and throw an exception. Keeping a snapshot of the Quantopian environment isn't practical for a number of reasons.

We are working on a number of measures to prevent the "wake up and fail" problem from happening. It's something we've been giving a lot of thought to. Part of it is product maturity - as Quantopian and Zipline get more mature, they're stabilizing. We're having a cluster of "this algo doesn't work" bugs right now, but I think it is directly attributable to us trying to get a bunch of changes in to the system before live trading.

I expect we'll be talking about this more over time and our stability improves.

In a way, the exception case is the easy one, because at least you know something has gone wrong. If an update introduces a change that doesn't break anything, but changes how the algorithm behaves, one might never know... Maybe backtest regressions would help? Or maybe your customers won't care, and I'm just being a worry-wort!

Btw gave paper trading a whirl yesterday. It did not seem to be working . My algorithm logs some stuff on handle_data and nothing logged.

I also have some improvements to suggest :
On the backtest panel
log_output: -We can define and log.warn and every levels but in log output there is no way to filter to get only the logs above a certain level.
- a "end" feature, ie go to the end of the log without having to scroll for ages.

whoa, had forgotten about quantopian for a while. Hope this will be open to canadians when it goes public.

Pre filter / pre processing function to remove bad data will be interesting.

If this function discards the data then there will be no call to handle_data. Developers can have custom logic to see what is sent in and perhaps edit and pass the bar as needed.

@Simon I agree a silent failure would be worse in many ways. We've been working from the beginning so that we'll know whenever we touch something that might change the algorithm results. For instance, changing the logic about how the website works is strongly separated from the logic that runs a backtest. Of course, that still leaves the case where we change the backtest logic on purpose and it has an unexpected result. We have other tests to help minimize that risk.

@Quentin give it another try, and if it doesn't work, tell us at [email protected] so we can figure out what's going wrong.

@Chris the only limit is the brokerage.

@Suminda That type of filtering is very interesting, and very challenging. There's risk of false positives and missed negatives, both.

Dan , seems to be running now.
Now one last question in paper trading are you checking every live trade or bid/ask to check if we would be executed (in case of limit orders) or is it same way as in backtest ie execution only if close of next bar is >= (resp <=) our limit sell (resp limit buy) .


Quentin, it's the same as in backtests - the exact same engine in both places. I'm sure we'll do more robust methods in the future, but that's the only one we have so far.

Thanks for the heads up.
It's the right way to do it. I'll be able to check tomorrow, if everything is equal in backtest mode to paper trade mode.

Thanks a lot

It would be really nice if you offered various interactive brokers order algos. Say if I was a fundamental trader and wanted to fire a basket of orders every morning, it would be great to have this ability.

Could someone please elaborate on how the connectivity to Interactive Brokers works? Are you running an instance of IBGateway for each client and giving it a username/password entered on the site?


Nick, that's exactly what we do. We store your username and account number (encrypted of course) in our database. We do not store your password. When you want to trade an algorithm, we bring up an instance of IB Gateway for you to use. We pass your user information to the gateway. We prompt you, in the Quantopian website, for your password and any captcha-type challenge information. That authenticates you in the IB Gateway, and then we can pass orders into IB on your behalf. When you stop the algorithm we log you out of the Gateway.

Check out this video to see what it looks like in the browser. The IB specific stuff starts at about 1:45.

Can I ask why you would implement this way as opposed to doing FIX to ib?

I'd have to go back and check my notes to be sure. I think it was because we thought FIX would talk longer to implement, and would be harder to secure, and we wanted to get live trading to market as fast as we safely could.

I imagine that we will probably implement FIX to IB, and to other brokers, in the long run.

Hi Dan,

I have seen that Quantopian's backtester, Zipline, is open source. Is your API open source as well?


Whatever in Zipline is open source. Whatever built additionally on top of Zipline (Web UI, data, transforms, etc.) is not open source.

From Zipline Apache license:
"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

So eventually, from my POV, the only argument could be that part of the elements of the 'Live Feed Modules' could be open sourced under Apache (the rest "remain separable"), the rest having been written in a generic way. But why bother considering the interest here is to benefit from their infrastructure .... if one wants their own, get a team and design it.