I work at an algorithmic trading shop and have spent a fair amount of time studying equity market structure. It's great to see an open source trading platform, but I think it's important to stress the following: Equity markets are highly competitive. If you choose to use this platform for trading, you will lose money on average. As a retail trader, you face numerous disadvantages that many market participants do not face. By increasing your trading frequency, you will increase your costs and decrease the likelihood that you will make money. Good luck!
The topic of this post seems a little off. The description of zipline on its github page is "financial backtester for trading algorithms written in Python" which is a bit different.
The "Hello World" sample algorithm on Quantopian gets a 4000% return if it operates on AAPL for a year. It makes trades each minute using a "3 day volume-weighted-average-price." I find it hard to believe this algorithm would perform so well in the real world.
How much of an impact would factors like latency in a real world environment have on this algorithm?
If you are trading in small lots, not very much. For the example of AAPL which has a daily volume of 20mil shares, at the current price of $450, a $450 million buy or sell order on AAPL will only be 1% of the daily trading volume.
Problem is that the bigger the ticker, the more crowded and optimized your competitors already are. The spread on AAPL options/stock is razor-thin, so using IB to do any kind of arbing/volatility/market-making trades is probably not going to be idea.
The trade-off with smaller ticker is you might have less competitors and even if it's a good opportunity, hedge funds aren't interested because potential profit is less than $1mil but for a retail guy, it's a lot. But the catch is the market is thinner, so in a volatile event, you might not be able to trade out of a very bad situation quickly. So your risk is higher.
Basically anything involving HFT where you are trading for liquidity rebates or sub-penny profits doing market-making or arbitrage, latency is critical; but 1sec tick data is an eternity already, for those operations, you need co-location to the exchanges for quotes and execution, not to mention 1mil+ trading capital for sub-penny profits/share to make sense.
1 second tick data would be more useful in swing trading situations where your profit target is 5-10% in a span of a few days to a week - it matters less if your order gets executed $0.01 less or more. So latency shouldn't be an issue.
The unrealistic aspect of that backtest is the total leverage - the algorithm ends up borrowing something like $700k on an initial balance of $10k.
Why not prevent this borrowing in the backtest? Quantopian's philosophy is to report the results, rather than block you from trying outrageous scenarios.
Backtests are not predictive; they are a tool to investigate the behavior of your algorithm.
Quantopian presented at the New York Software Engineers meetup last week. As somebody who has built proprietary backtesting software before, I applaud their open-source approach to this problem. They have some recorded presentations on their blog for anybody who is interested http://blog.quantopian.com/
This looks pretty good. You already have competitors out there like Collective2. It'd be nice if you guys can get options data with IV; it's probably harder to get data licenses for historical options data but it'll differentiate you guys from the rest of the competition.
The data is more expensive, but the other challenge is the complexity and volume of the data. Our thought is to build an end-to-end system on equity and then add other instrument types.
A little off-topic, but I'd love to hear the experiences of someone who has actually done algorithmic trading using their personal finances. I assume that there are enough hurdles in comparison to the major market participants that you'd have lots of trouble making money on average.
[+] [-] anonDataUser|13 years ago|reply
[+] [-] gourneau|13 years ago|reply
[+] [-] yellow|13 years ago|reply
[+] [-] xntrk|13 years ago|reply
[+] [-] edhebert|13 years ago|reply
You're right that there is a chasm between backtesting and actual trading.
The title may be a little future thinking, we are working on adapting the event/stream-based backtesting engine to drive live trading.
Updating the description to help declare intended goals of being a wider algorithmic trading suite.
[+] [-] babl|13 years ago|reply
How much of an impact would factors like latency in a real world environment have on this algorithm?
https://www.quantopian.com/posts/the-hello-world-algorithm-m...
[+] [-] noname123|13 years ago|reply
Problem is that the bigger the ticker, the more crowded and optimized your competitors already are. The spread on AAPL options/stock is razor-thin, so using IB to do any kind of arbing/volatility/market-making trades is probably not going to be idea.
The trade-off with smaller ticker is you might have less competitors and even if it's a good opportunity, hedge funds aren't interested because potential profit is less than $1mil but for a retail guy, it's a lot. But the catch is the market is thinner, so in a volatile event, you might not be able to trade out of a very bad situation quickly. So your risk is higher.
Basically anything involving HFT where you are trading for liquidity rebates or sub-penny profits doing market-making or arbitrage, latency is critical; but 1sec tick data is an eternity already, for those operations, you need co-location to the exchanges for quotes and execution, not to mention 1mil+ trading capital for sub-penny profits/share to make sense.
1 second tick data would be more useful in swing trading situations where your profit target is 5-10% in a span of a few days to a week - it matters less if your order gets executed $0.01 less or more. So latency shouldn't be an issue.
[+] [-] fawce|13 years ago|reply
Why not prevent this borrowing in the backtest? Quantopian's philosophy is to report the results, rather than block you from trying outrageous scenarios.
Backtests are not predictive; they are a tool to investigate the behavior of your algorithm.
[+] [-] qntmfred|13 years ago|reply
[+] [-] noname123|13 years ago|reply
[+] [-] fawce|13 years ago|reply
[+] [-] msandford|13 years ago|reply
[+] [-] babl|13 years ago|reply
[+] [-] fawce|13 years ago|reply
[+] [-] ios84dev|13 years ago|reply
[+] [-] nilkn|13 years ago|reply
[+] [-] tensaix2j|13 years ago|reply
[+] [-] YoavShapira|13 years ago|reply