Backtests are a crucial tool in quantitative finance. They are essentially a time-machine that allows you to measure how a systematic strategy built today would have performed if you had invested in that strategy in the past. This is extremely intuitive: use historical data in conjunction with your strategy to see what returns your strategy would have generated.
Backtesting is expensive, it requires access to the worlds best financial data. Lucky for you, we purchase and process that data over the period back as far as 2006. Meaning any pre-built or Xplore strategy is run against 17 years of historical performance.
The fundamental properties of a backtesting are:
Backtests therefore allow for the delivery of a clear report back to the user that summarises the risk, return and drawdowns of the strategy, which is a very powerful tool to help investors make their capital allocation decisions.
There tends to be two types of backtest engines that are used in the industry
For-loop backtesters are built using the classic coding loop iteration, where each day for example is an iteration of the backtest. Analysing a daily rebalanced strategy for example from 2012 to 2022 therefore involves simulating, on a daily basis, how your strategy would have entered, exited positions, the fill prices used and the returns of the strategy. It is a very structured form of backtesting and simpler to code.
Event-driven backtesters are built based on a more complicated codebase and involve events being logged by the backtest engine and then these events being executed in a queue system. These events can be items like
Event-driven backtest engines are more difficult to code but can be re-used more easily in live trading so there is one codebase operating for backtesting and live trading, which is a robust method.
With any testing system, there are advantages and disadvantages. The advantages are clear to see as seeing backtest results gives the user confidence in their strategy. Backtest results can then be used to decide if an investor wants to allocate real capital to the investment strategy.
The one big disadvantage of backtests is they typically over-inflate performance metrics so a prudent thing to do is treat them as an upper bound. It is probably less common for a strategy to have actually outperform the backtested results than to have underperformed.
For a backtest engine to be very accurate, it needs to incorporate accurate transaction costs as well as market impact costs. Market impact is a difficult topic but it relates to the concept of attempting to model how your trades would have affected the fill prices and strategy performance if the trades had occurred in history. Given the strategy being tested is new and was not executed in reality back in time, your backtest engine needs to account for the impact that would have occurred. This is less of an issue for retail investors than large firms, given their investment sizes and market-moving impact.
There are some crucial things to ensure your backtest engine accounts for and has accurately modelled. We provide a list below
The last point to mention for advanced users of backtests, is that a user can create an environment where they try to avoid as much as possible overfitting and in-sample testing. By this we mean that you can split out backtesting data into training and test data and hold-out this test data for a 2nd pass test. The temptation for tweaking a strategy to achieve the best backtest results on training data is very high. Having a test dataset means after your final strategy is chosen, you can then analyse how your strategy performed on the unseen test data.
Once your backtest engine is built, the graphical and statistical output can be fully incorporated so a user gets a full standardised report on each strategy that was executed by the backtester. We give some examples of useful performance output below.
We can also output nice summary statistics such as risk, return and drawdown.
Tutorials on investing and portfolios