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:

• it is fundamentally sound representation of history
• allows you to compare it to a benchmark if it is appropriate
• it produces good results that satisfy your threshold for investment
• allows the ability to analyse drawdowns and imagine how you would have coped

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
• event-driven

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

• market prices received
• signal generated
• order sent
• fill received

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

• survivorship bias: ensure all companies, even if they are now bankrupt, exist in your backtest engine and your strategy was allowed to hold those positions historically as it would have.
• lookahead bias: make sure that all your data on a given day is accurate and was known at that point-in-time. Your backtest engine can only use information that was available to the whole market.
• execution/fill models: ensure that the fills your strategy received were achievable and modelled correctly.
• cost model: ensure that you have realistic commissions and fees built into the backtest engine.
• impact costs: have an impact model in your backtest engine that accounts for both temporary and permanent impact, as highlighted in the previous section.

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.

Strategy backtest results showing comparison to benchmark on secondary axis.

We can also output nice summary statistics such as risk, return and drawdown.

Overall return, risk and other statistics for our strategy comparison to benchmark.