Apex Backtesting Engine: Eliminating Look-Ahead Bias at 425M Rows

The original Apex backtesting framework reported a 47% win rate on early experiments. Live trading produced 10%. The gap was not a strategy failure. It was an infrastructure failure: the backtest was contaminated with look-ahead bias at multiple layers.

Three specific violations were found in the audit. First, daily bar data was queried using the bar's close timestamp as the available-as-of date, when in practice that bar was not ingested until the daily downloader ran hours later. Second, signal features used a 20-day rolling mean computed across the entire dataset before the backtest loop started, meaning the mean at day 5 of the backtest included data from day 300. Third, macro regime labels were computed once over the full history using a hidden Markov model fit on the complete dataset. The regime label at any historical time step therefore incorporated information from months that had not yet occurred.

The redesign was organized around a single primitive: the point_in_time_cursor. Every data access during a backtest accepted a sim_clock parameter and returned only rows where ingested_at <= sim_clock. The ingested_at column was distinct from ts (the event time of the data) and reflected when the row actually landed in the database.

Historical rows that predated this schema change were assigned ingested_at values by backfilling with a conservative estimate: ts + INTERVAL 8 HOUR, encoding the assumption that end-of-day bars arrived eight hours after market close. This was a worst-case estimate rather than an optimistic one, deliberately.

Macro regime labels were recomputed using a walk-forward approach: the HMM was trained on data up to each quarter boundary, and a separate regime label set was stored per training window in a regime_labels_walk_forward table.

Feature computation changed from batch-over-history to rolling-at-time. Rolling means, volatility estimates, and momentum indicators were computed using only rows with ingested_at <= sim_clock. This was slower by roughly 8x on the initial implementation.

Feature computation was accelerated by precomputing and caching rolling windows up to the current sim_clock in 1-day increments and storing the intermediate state in a BTreeMap keyed by date. The simulation advanced in 1-day steps. At each step, the feature cache extended by one day rather than recomputing the full window, bringing rolling-mean computation back to approximately the same speed as the original contaminated batch approach.

A second architectural requirement was determinism. The same strategy parameters applied to the same date range had to produce identical results across runs. All randomness in the engine was seeded from a fixed seed derived from (strategy_id, start_date, end_date) using a hash function. Random number generation used the rand_chacha crate for reproducible ChaCha20 output.

After the point-in-time rebuild, win rate in backtest dropped from 47.0% to 34.2%, and live win rate rose from 10.0% to 32.8%. The backtest-to-live delta collapsed from 37 percentage points to 1.4 percentage points. The strategy-selection process filtered from 24 candidate strategies to 7 that passed a minimum Sharpe of 0.5 on clean backtests. The 7 survivors ran on live paper trading for 4 weeks and produced win rates between 30 and 38%, consistent with the clean backtest projections.

Strategies that showed a 15 to 40% PnL reduction under empirical slippage modeling were correctly eliminated. A strategy that requires perfect execution to be profitable is not a strategy.