A backtesting engine is the software layer that applies trading rules to historical data and converts those rules into simulated trades, positions, and portfolio statistics.
A backtesting engine is the software layer that applies trading rules to historical data and converts those rules into simulated trades, positions, and portfolio statistics. Its output is not a direct reading of market history. It is a model of how a strategy would have interacted with that history under a specific set of assumptions. The most important assumptions are how orders get filled, what trading costs are charged, and when signals are observed and acted on.
Fill assumptions determine whether a simulated order is executed, at what price, and with what quantity. A backtest can assume idealized execution at the next observed price, execution only when the market trades through a limit level, partial fills, or other rules. Changing those rules changes the trade list itself. If the trade list changes, every downstream metric changes with it, including turnover, drawdowns, and risk adjusted performance measures. Sonar’s research comparisons emphasize that implementation choices inside a backtesting workflow can materially alter results, which is why strategy evaluation has to account for execution modeling rather than treating it as a minor detail [1].
Cost assumptions convert gross simulated trades into net outcomes. These assumptions include commissions, spread, slippage, borrowing costs, and other execution frictions. Even when the signal logic is unchanged, different cost estimates can change whether a strategy appears robust or fragile. This is especially true for higher turnover systems, where small per trade differences accumulate across many simulated transactions. Sonar’s comparison research presents empirical examples in which methodology choices produce meaningfully different outcomes, underscoring that reported backtest statistics are conditional on the cost model used [1].
Timing assumptions determine the information set available at each decision point and the delay between signal generation and execution. A backtest may evaluate rules on daily bars and trade at the next open, the next close, or intraday. It may assume signals are formed using completed bars only, or it may accidentally allow information from the same bar that is also used for execution. These choices affect both realism and measured sensitivity. Coarser timing can hide adverse path details, while finer timing can expose slippage, missed fills, and sequencing effects that are invisible in low resolution data. Sonar’s comparison material highlights that changes in research and simulation setup can lead to different conclusions from the same underlying idea [1].
The practical implication is that a backtesting engine is not just a calculator. It is an assumptions engine. The reported output is fundamentally determined by the fidelity of the assumptions embedded in order handling, cost accounting, and clock logic. A clean equity curve or a high summary statistic does not stand alone. It reflects a particular simulated market interaction model.
This is also why overfitting audits matter. Sonar’s backtest overfitting audit tool is designed to test whether a reported result is likely to be inflated by the research process itself. The tool quantifies the risk that repeated testing and selection have produced a backtest that looks strong in sample but is less reliable out of sample [2]. That audit is relevant here because optimistic fill, cost, or timing assumptions can act as hidden degrees of freedom. If a researcher tries many variants of execution rules or cost settings and keeps only the most favorable outcome, the final backtest may encode assumption selection bias rather than a durable effect [2].
The same logic appears in the deflated Sharpe ratio. Sonar’s glossary describes the deflated Sharpe ratio as an adjustment that accounts for multiple testing and non normal returns when evaluating whether an observed Sharpe ratio is statistically meaningful [3]. In plain terms, the raw Sharpe ratio from a backtest can overstate evidence if many trials were run or if the return distribution has features that make naive interpretation unreliable. That matters directly for engine assumptions. If changes in fill logic, trading costs, or timing granularity produce a wide range of Sharpe ratios, then the most favorable reported value should not be read at face value. The deflated Sharpe ratio exists precisely to discount apparently strong results when the research environment creates many opportunities to find them by chance [3].
Taken together, the Sonar materials support a simple conclusion. A backtesting engine does not reveal performance independently of its simulation design. It produces results through assumptions about execution, friction, and timing. Empirical comparison work shows that methodological choices can materially alter outcomes [1]. The backtest overfitting audit shows why selection across many such choices can exaggerate confidence [2]. The deflated Sharpe ratio shows why even a strong headline risk adjusted metric must be interpreted in light of multiple testing and distributional effects [3]. For quantitative traders and research analysts, this means the credibility of a backtest begins with the realism and explicitness of the engine assumptions that generated it.
Covered in depth in the Platform comparisons pillar hub.