Pre-Launch Simulator Parity Checks

A strategy's research backtest and the system that will actually trade it live are, in almost every firm, two separate pieces of software, built at different times, sometimes by different people, and sometimes in different programming languages entirely. The backtest exists to test ideas quickly; the live system exists to place real orders reliably, handle exchange connectivity, manage risk limits, and log everything for compliance. Nothing guarantees these two systems agree with each other, and the gap between them is one of the most common — and most avoidable — ways a strategy that looked great in research underperforms once it goes live.

A parity check runs both systems side by side on identical historical data and confirms they produce the same output at every step: the same input features, the same computed signal values, the same target positions, and ideally the same simulated trades and fills. Any discrepancy needs to be tracked down and explained before launch, not discovered afterward. Common sources of mismatch include subtle differences in how each system handles missing data, off-by-one errors in how each system aligns a signal computed on data through yesterday's close with today's tradeable price, rounding or lot-size conventions that differ between a research prototype and a production order management system, and timezone or market-holiday-calendar handling that a backtest often glosses over but a live system cannot.

A useful discipline is running the parity check not just once before launch but as a recurring automated test, since a live system's dependencies — market data feeds, reference data, exchange calendars — get updated over time, and any of those updates can silently break parity that held perfectly at launch. Some firms wire this into continuous integration, so that any code change to either the research or production codebase automatically re-runs the comparison and flags a failure before it reaches a trader.

For example, a momentum strategy's backtest computes its signal using each stock's closing price from the prior trading day. A parity check discovers that the live system, due to a data feed configuration difference, is actually using a delayed closing price that arrives fifteen minutes after the official close on days with unusually heavy after-hours order imbalances — a discrepancy invisible in normal backtesting but capable of shifting real trades by a meaningful amount on exactly the days that matter most.

What this means in practice

Parity checks are a form of insurance bought cheaply before launch against a failure mode that is expensive and hard to diagnose after launch, because once a strategy is live and underperforming, it can take weeks of investigation to distinguish "the strategy stopped working" from "the live system was never actually implementing the strategy that was backtested" in the first place. Any strategy moving from research to production deserves a documented parity check as a standard gate, not an optional nicety left to whichever engineer happens to think of it.