Event-Driven Backtesting

The computational backbone relies on a priority queue that processes events in strict chronological order. Unlike vectorized backtests that iterate through uniform time bars, the engine jumps directly from one market event to the next.

• Event types include: MARKET_DATA, SIGNAL, ORDER, FILL, and CANCEL
• The event loop pops the earliest timestamped event and dispatches it to the appropriate handler
• Idle periods with no market activity consume zero compute cycles, making the architecture highly efficient for sparse data

Every simulated order transitions through a deterministic finite state machine that mirrors production order management systems. This prevents impossible states like a cancelled order receiving a fill.

• Valid states: PENDING_NEW, NEW, PARTIALLY_FILLED, FILLED, PENDING_CANCEL, CANCELLED, REJECTED
• Transitions are triggered by exchange acknowledgment events, not instantaneous assumptions
• Enforces realistic queueing behavior where cancellation requests can race against fills

Strategies are implemented as event handlers rather than loop iterations. The engine invokes specific callbacks only when relevant events occur, replicating how a live strategy receives streaming market data.

• on_bar(Bar bar): Triggered when a new OHLC bar completes
• on_tick(Tick tick): Fires on every trade or quote update for tick-level granularity
• on_fill(Fill fill): Called when an order is executed, enabling dynamic position sizing
• on_signal(Signal signal): Dispatched when an alpha model generates a prediction

This pattern enforces path dependency naturally, as strategy state evolves strictly through event sequences.

Multi-asset strategies consuming feeds from disparate exchanges require rigorous timestamp alignment to prevent look-ahead bias. The engine maintains a single authoritative simulation clock.

• All incoming events are stamped with the simulation's reference time, not the local arrival time
• NTP-style synchronization logic resolves sub-millisecond ordering ambiguities between co-located feeds
• Events with identical timestamps are processed in a deterministic order (e.g., signals before orders before fills)
• This guarantees that a strategy never peeks at a correlated asset's price before making a decision

Rather than assuming execution at the mid-price, the engine simulates fills against a reconstructed limit order book or volume-at-price distribution. This captures the adverse selection cost of aggressive orders.

• Volume-weighted average price calculation across multiple price levels for large orders
• Queue position modeling: limit orders are filled only when sufficient opposing volume trades through that price level
• Slippage models apply temporary impact based on order size relative to historical volume at that timestamp
• Partial fills are generated when available liquidity is insufficient to satisfy the full order quantity

Every simulation run is bit-for-bit reproducible when initialized with the same random seed and event stream. This is critical for debugging, regulatory compliance, and strategy comparison.

• All pseudo-random number generators are seeded explicitly and logged
• The event queue serialization order is fixed for identical timestamps
• Checkpointing allows the simulation state to be saved and resumed from any point in time
• Discrepancies between two runs indicate either a code change or a non-deterministic data dependency that must be eliminated

The computational backbone of event-driven backtesting. The system model advances through time by jumping directly from one event timestamp to the next, skipping empty intervals. This contrasts with fixed-time-step simulation where the clock ticks uniformly regardless of activity. Key characteristics:

• Maintains a priority queue of future events sorted by timestamp
• Processes all events at the same timestamp atomically before advancing
• Enables deterministic replay when random seeds and event orderings are preserved
• Essential for accurately modeling race conditions between market data and order acknowledgments

A behavioral design pattern that governs the lifecycle of simulated orders within the engine. Each order transitions through a finite set of deterministic states triggered by market events:

• PENDING → Order accepted by the engine, awaiting market check
• WORKING → Order acknowledged by the simulated exchange
• PARTIALLY_FILLED → A portion of the quantity has been executed
• FILLED → The entire order quantity has been matched
• CANCELLED → A cancellation request was processed before execution
• REJECTED → The order violated a limit check or exchange rule

State transitions must be atomic to prevent inconsistent internal bookkeeping during concurrent event processing.

A validation framework that simulates the experience of deploying and periodically recalibrating a strategy in live markets. The historical data is partitioned into a sequence of rolling windows:

• In-sample window: Used to optimize strategy parameters
• Out-of-sample window: The immediately following period where optimized parameters are tested blindly
• The window pair then advances forward by the out-of-sample length, and the process repeats
• The concatenated out-of-sample equity curve represents the uncontaminated performance of the adaptive strategy

This method directly penalizes backtest overfitting by exposing parameter choices to unseen data at each step.

A statistical test that corrects for multiple testing bias when selecting the best strategy from a large universe of trials. The standard Sharpe Ratio becomes inflated when a researcher tests thousands of variations and picks the highest. The Deflated Sharpe Ratio accounts for:

• The number of independent trials conducted
• The variance inflation from correlated strategy variations
• The non-normality of financial return distributions

A DSR above 0.95 indicates that the observed performance is unlikely to be the result of pure data mining, providing a rigorous probabilistic confidence metric for strategy selection.

The engine logic that determines whether a simulated order interacts with historical liquidity. In an event-driven architecture, fill simulation is triggered by trade and quote events and must model:

• Aggressive orders: Consume resting liquidity at the best bid/offer; fill probability depends on available volume at that price level
• Passive orders: Rest on the order book and fill only when a contra-side aggressive order arrives; requires queue position modeling
• Partial fills: When available volume is less than order quantity, the remainder stays working
• Latency delay: A configurable time delta between the strategy's decision timestamp and the order's arrival at the matching engine

Accurate fill simulation is the primary defense against look-ahead bias in execution modeling.

A historical dataset constructed to reflect exactly the information available at a specific past moment, without any subsequent corrections or restatements. This is critical for eliminating look-ahead bias in event-driven backtesting:

• As-reported financials: The original earnings figures, not the restated versions filed months later
• Survivorship-bias-free universes: Includes securities that were later delisted or bankrupt
• Timestamped consensus estimates: Analyst expectations as they existed before the earnings release, not revised figures
• Corporate action chronology: The exact sequence of split and dividend announcements as they occurred

Without point-in-time data, a backtest implicitly uses future information that was unavailable to the strategy at the decision point.