Event-driven backtesting is a simulation method that advances a strategy one timestamped market event at a time.

Event-driven backtesting is a simulation method that advances a strategy one timestamped market event at a time. Instead of evaluating logic only at the close, open, high, or low of a bar, it processes the sequence of events that would have reached the strategy during trading. This makes the simulation slower than a bar-based backtest, but it is designed to better reflect how orders, signals, and market state interact through time.

The key mechanism is event sequencing. A market data update arrives, the strategy evaluates its rules on that update, an order may be generated, and execution logic then determines whether and how that order is filled given the state of the market at that moment. The simulation then moves to the next event and repeats the process. Because the backtest is driven by the arrival of events, it can represent timing dependencies that a bar-based approach compresses into a single interval.

This distinction matters because bar-based backtesting works on aggregated price information. Aggregation removes the exact order in which intrabar changes occurred. When a strategy depends on the path of prices, on order timing, or on whether a fill would have occurred before or after another market change, the bar can hide information that execution logic needs. Event-driven simulation preserves that sequence and therefore aims at higher execution fidelity.

A more faithful replication of execution does not mean that every event-driven backtest is automatically realistic. Realism still depends on the quality of the event data, the execution model, and assumptions about latency, queue position, and transaction costs. But processing each timestamped event individually gives the backtest a structure that is closer to how live trading unfolds than a model that evaluates only bar summaries.

The Sonar comparison research supports the general tradeoff between speed and fidelity in backtesting design and frames event-level simulation as the approach used when execution details matter most. The same research emphasizes that simplified simulations can produce optimistic results when they abstract away the mechanics of fills and timing. That is the central reason practitioners use event-driven engines when they need the backtest to reflect implementation details more closely than a bar-based engine can. [1]

This has direct relevance for overfitting control. Sonar’s backtest overfitting audit tool is built to evaluate whether backtest results are likely to overstate a strategy’s robustness. When the simulation engine itself omits execution detail, the measured performance can be overstated before any statistical audit begins. An event-driven framework can reduce one source of that optimism by modeling the timing and execution path more explicitly, which improves the quality of the inputs to an overfitting audit. The audit tool is therefore complementary to event-driven simulation rather than a substitute for it. One addresses statistical overstatement in the research process, and the other addresses mechanical realism in the simulation process. [2]

The same caution appears in Sonar’s glossary entry on the deflated Sharpe ratio. The deflated Sharpe ratio is presented as a method for adjusting a reported Sharpe ratio to account for multiple testing and non-normality, with the goal of reducing the chance of treating a backtest result as more significant than it is. If a backtest benefits from simplified execution assumptions, the original Sharpe ratio can already be inflated by the simulation design. Better execution fidelity does not replace deflation, but it can help ensure that the input performance series is less distorted by unrealistic fills or timing assumptions before statistical adjustment is applied. [3]

Covered in depth in the Platform comparisons pillar hub.