Backtest to Paper Trading: The Parity Checklist

Abstract

Paper trading is useful only if it tests the strategy that passed research. If the paper loop changes contract selection, fill rules, timing, or risk gates, it is no longer validating the backtest. It is testing a new system.

The parity checklist exists to keep that from happening.

Freeze The Object

Before a strategy enters paper mode, freeze the profile name, parameters, symbol list, DTE rules, risk budget, fill policy, quote constraints, and launch contract. The paper loop should not discover new defaults at runtime.

This is where developers benefit from manifests. A manifest makes the research object portable. It also makes accidental changes easier to detect.

Replay Benchmark Sessions

Run benchmark sessions through the paper code path in dry-run mode. Compare selected contracts, rejected candidates, signal timestamps, entry prices, exit policy, and final PnL against the research artifact.

Small differences can be acceptable if they are intentional. Silent differences are not acceptable. A paper candidate should be blocked until mismatches are classified.

Preserve Reject Reasons

A live paper loop will hit messy conditions: stale quotes, no listed expiry, wide spreads, no option contract, market window closed, or daily risk caps. These reasons should be recorded without being overwritten by later generic states.

The point of paper trading is to learn why the route diverges from research.

Takeaway

Backtest-to-paper parity is an engineering contract. Freeze the object, replay it through the production path, record mismatches, and let paper trading validate drift rather than hide it.