How We Backtest Our Portfolios

Tactical Asset Allocation dynamically tilts asset allocation to take advantage of fluctuating market conditions. This approach creates a dilemma: we need to cover many years to test our strategies with many different economic scenarios. But at the same time, markets are constantly evolving, and we need to stay current with our methods and strategies.

Computer simulations, so-called backtests, solve this issue by allowing us to run many sophisticated tests within a short period. Therefore, it is fair to say that backtesting is at the core of everything we do at TuringTrader.com. We aim to provide the most accurate backtests for our portfolios so that you can feel comfortable investing with them. In this post, we explain the assumptions we make and the techniques we use.

Backtesting Engine

It comes as no surprise that we use the backtesting engine from TuringTrader.org. Unlike many commercial backtesters, we designed the TuringTrader engine with portfolio-level simulations in mind, making it an ideal framework for our portfolios on TuringTrader.com.

TuringTrader.org is an open-source project. You can download and use it as you see fit and free of charge. Even better, you can download the source code, analyze how it works, and adapt it to your application. However, the license terms require any derivative work also to be open-source. TuringTrader.org uses the GNU Affero General Public License, which includes running derivative work on a server in its definition of software distribution.

TuringTrader.com uses the same backtesting engine. There are no hidden features we use that aren't also available to you. However, TuringTrader.com uses custom report templates to implement some of the site's features.

Data Feeds and Proxies

Without accurate data, any backtest is bound to fail. We receive most of our data from Norgate, an Australian provider of high-quality daily data. We collect these data after the markets closed and are dependent on Norgate's update schedule. To provide you with updated portfolio allocations as early as possible, we can't wait for all final data. Instead, we use interim releases for the initial site updates, and run two additional updates later each night to include later updates. Here is the schedule (times in Eastern/ New York time zone):

We source a few of the more nichey economic data from FRED. Economic data often do not align with the market days of U.S. stock exchanges. Also, the sampling intervals are often different, e.g., weekly or monthly. We resample these, without interpolation, to align with U.S. market days. Further, some economic data have a publication lag. We aim to account for this lag by delaying the data accordingly in our simulations.

All of our equity quotes are fully adjusted for splits and dividends. This adjustment makes sure that we can calculate indicators without disruption. Even more importantly, using adjusted quotes implies that any interest or dividend received is re-invested in the portfolios.

We aim to provide simulations reaching back to January 2007 for all of our portfolios. We chose this time balancing practicality with the desire to show a full economic cycle. Simulating this far back bears some issues, though.

For strategies trading individual stocks, we need to make sure that the traded universe is free of survivorship bias. Our stock-trading strategies use major indices as their trading universe. For these, we have access to historical index constituents, including de-listed, re-named, or merged instruments.

For strategies trading ETFs, we face the problem that many ETFs have inception dates later than 2007. To test that far back, we extend the history of ETFs using proxy instruments as required. There are many different kinds of proxies available, including similar ETFs, mutual funds, or indices. If none of these are available, we use mathematical models, e.g., to model total returns of Treasuries from the yields.

Portfolio Implementations

Most of our Basic portfolios come from books and publications. Unless otherwise noted, we aim to implement these portfolios verbatim and without making any adjustments. To honor the spirit of the authors who shared their ideas with the world, we provide our implementations of these strategies under the same open-source license as the backtesting engine. Curious investors can review the source code in the open-source repository.

Our Premium portfolios are proprietary. We provide a general description of the mechanics, and often also a background article with additional insights. Please understand that we cannot share their source code, though. After all, these Premium portfolios are what makes TuringTrader.com unique.

Rebalancing and Order Placement

The portfolios on TuringTrader.com require daily, weekly or monthly rebalancing. Unless otherwise noted, we assume that portfolios are rebalanced using market orders submitted while the markets are closed. These will be executed at the next open and within regular market hours.

Portfolios rebalancing weekly typically do so over the weekend, with only a few exceptions. Our monthly rebalanced portfolios do so after the last trading day of the month.

Our backtesting engine does not support fractional shares. Instead, all of our simulations use sufficiently large account sizes to minimize the rounding errors caused by rounding the number of shares to integer values.

Fees and Slippage

For every order placed, we deduct a fee of $0.015 per share. This amount matches the fees and commissions paid at major brokerages. Because we are using split-adjusted prices, the number of shares traded in the simulation might differ from the actual amount traded historically. We are currently unable to account for this issue. However, except for assets performing reverse splits, this usually results in the simulation's assumptions being more pessimistic than reality.

Many brokers use a tiered fee structure and set a minimum fee, e.g., of $1.00 per order. We do not attempt to model this. Instead, we assume that all orders are large enough to exceed that limit. Consequently, the fees adopted by our backtests model the reality of large accounts better than that of small accounts. This model is in line with the assumptions we made above regarding the rounding of shares to integer values.

Orders are currently filled at the open price, not accounting for slippage. We will be revisiting this topic in the future to see if we can implement a better fill model. The portfolios on TuringTrader.com use the most liquid assets available, which should keep slippage low.

We hope this article provided you some insight into the methods and assumptions we use in our backtesting. We recommend interested investors to read how live trading compares to backtested results.