@Tjerk, thank you for the questions.
The best answer, I think, is to share our simulation code. To that end I've shared the source code of our transaction simulator. Shortly, we will be offering the entirety of Zipline, our backtester, under BSD-3. Until then, I hope this critical piece of the system will be enough to clarify the transaction simulation behavior.
How our simulator works
The prose description is that orders are placed asynchronously and queued inside our simulator. Orders are then compared to the flow of historical trades, and we simulate "transactions" to represent the filling of an algorithms orders.
- Orders are filled asynchronously. If you place an order at minute=3, we start filling in minute=4. This is to avoid any look ahead bias.
- Orders are treated as market orders with a "good 'til close" time to live. If an order is partially filled, we keep the remainder open for the rest of the market day. If an order is not filled by market close, the unfilled portion is canceled.
- Our simulator runs with style=PARTIAL_VOLUME. This means that we calculate a price impact, based on the share of volume an order would take from the current bar.
- We also limit the algorithm to no more than 25% of a given bar, to avoid expected discontinuities in the market response to a huge order.
- Impact is treated symmetrically - long orders will push the price up, short orders will drive it down, but in equal measure based on the order amount.
- Orders do not always succeed. If an order cannot be filled by the end of the day, the unfilled portion is canceled.
- Algorithms cannot currently cancel orders.
Why open source
On a more philosophical note, we are open sourcing our backtester precisely because we want the behavior to be well scrutinized by the community. We think blackbox backtesting for investment algorithms is a scourge. There is a desperate need for standard backtesting, simply to provide coherent comparisons between algorithms and algorithm authors. Our goal is to make Zipline a common yardstick to compare many types of algorithms, whether developed on Quantopian, by individuals, or by firms. We chose the BSD license to make it very friendly and easy to reuse Zipline internally, in other commercial products, and other open source projects. We are also following in the footsteps of major opensource advances in data science, like Pandas/numpy/ipython.
A quick note on live trading
For a backtester to be at all accurate, it needs to be compared to the results from real trading.
We are working on providing not just simulation, but also live trading via Quantopian. We have a lot of work to do before that can be possible, but our vision is to provide a seamless transition from backtesting, to paper trading, to live trading. One of the most important benefits for users will be the aggregation of real life order and transaction data, which can then be used to test and improve the backtester and simulation itself.
