Backtesting is a historical simulation of trading or decision rules with explicitly defined data, chronological order and execution assumptions. It allows a rule's behavior in a past sample to be examined, but its evidential value depends on the design of the entire test.
Backtesting replays rules on historical data and calculates what result they would have produced under the chosen assumptions. Bailey and coauthors describe it as a historical simulation of an algorithmic strategy while warning about the risk of false discoveries. Our editorial boundary is that the result belongs to a particular version of the rules, data and execution model. It does not establish that anyone actually executed those trades. A reproducible calculation can reveal an error or an unsuitable idea, but does not itself turn the past into a reliable forecast. [1]
QuantConnect describes the bias that arises when a simulation uses future information, such as financial figures before their publication or subsequent revisions. Our own timing contract requires the availability time of each input, not just the date of the period it describes. A signal from a closed candle cannot, without an additional assumption, obtain a trade at a price that was no longer available. In our example, prior closing prices are used only for the following period, whose opening fill is explicitly specified by the model. [2]
QuantConnect warns about testing only securities that survived to the end of the period and applying today's index composition retrospectively. Our broader question is whether the historical dataset also preserves instruments available at the time that later disappeared. Missing data, changes in methodology and market selection must be documented. For a Bitcoin simulation, a price from one service cannot automatically be treated as an attainable price on another. Clean data means traceable corrections, not removal of inconvenient results. [2]
QuantConnect documentation separates the signal and order from the model determining fill price and quantity. It also highlights the difference between partial fills in live trading and the assumption of complete fills in prebuilt models. Our own requirement is to describe when an order may execute, what happens with insufficient liquidity and how stale prices are handled. A price level touched in historical data does not itself establish an available counterparty for an arbitrarily large order. The fill model's output remains a simulation assumption. [3]
QuantConnect describes Slippage as the difference between expected and actual fill prices and notes the effects of latency, connectivity and market conditions; the deviation can be favorable or unfavorable. Our cost check separates fees, fill prices and any other holding or financing costs. A cost already included in the fill price must not be deducted again. A zero value is a specific modeling assumption, not evidence of a costless market. Sensitivity to worse costs helps establish whether a small historical profit depends on optimistic settings. [4]
The TimeSeriesSplit documentation explains chronological splitting to avoid training a model on the future and evaluating it on the past. Our methodological requirement is to designate a period for designing the rules and a period for subsequently validating them before looking at results. If failed rules are adjusted again based on the validation period, that period has already influenced development. Chronological splitting alone does not resolve leakage from preprocessing, overlapping targets or repeated variant selection. Both the process and the data boundaries must be described. [5]
Bailey and coauthors show that repeatedly searching for the best configuration on the same data increases the risk of false discoveries and fitting past noise. Our reporting rule is to disclose the history of attempts, not just the winning curve. This includes changes to parameters, periods and instrument selection. A result chosen after many trials does not carry the same evidential value as a predefined, unchanged rule. Their method for estimating the probability of overfitting is neither performed in our simple example nor replaced by a single data split. [1]
NFA warns that hypothetical results do not reflect actual trading, may benefit from hindsight and may imperfectly model liquidity, slippage or behavior under a real loss. Our report should therefore retain the data and code versions, rules, fill assumptions, included costs and complete list of simulated trades. Total return needs risk context and comparison under identical conditions; a selected attractive chart is insufficient. Even a flawless implementation of a historical test does not guarantee feasibility or returns in a future market. [6]
A signal from the previous period, a fill in the next
For the clearest picture, read this entry together with Trading Plan, Trading Journal, Slippage, Overfitting, Walk-forward Analysis. The reverse links also lead from Technical analysis, OHLCV, Timeframe, Candlestick chart.
01Does a profitable backtest prove that a strategy will make money?+
No. The result may depend on specific data, costs, the fill model or selection of the best variant. Timing correctness, assumptions and the selection process need verification; even then, there is no guarantee of future returns.
02Is it enough to deduct fees only from the final profit?+
Only if that method exactly matches the model and does not affect available capital or subsequent decisions. Usually costs need to be booked at the corresponding events, with fill prices distinguished from fees and double deduction prevented.