Backtest to Paper Trading: The Parity Checklist
CuteMarkets Team
Research
Backtest to Paper Trading: The Parity Checklist
Backtest-to-paper parity means the paper bot uses the same strategy profile, timing, contract selection, fill policy, and risk gates as the promoted backtest.
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.
What Parity Means
Backtest-to-paper parity means the paper bot uses the same strategy profile, timing assumptions, option-selection rules, fill policy, risk controls, and rejection rules as the promoted backtest. The data source can be live or delayed depending on the plan, but the decision contract should remain the same.
Parity does not mean paper PnL will match backtest PnL exactly. Live markets drift. Quotes arrive differently. Delays, outages, and order behavior matter. Parity means the paper system can explain those differences instead of hiding them behind new defaults.
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.
| Research field | Paper equivalent | Blocker if missing |
|---|---|---|
| Strategy profile | Bot profile id and config hash. | Bot could run a different rule set. |
| Symbol universe | Allowed tickers and session calendar. | Bot could trade untested names. |
| DTE policy | Contract-selection filter. | Bot could choose a different expiration regime. |
| Fill policy | Quote-aware simulated order policy. | Paper PnL cannot be compared to research. |
| Risk budget | Sizing, max positions, daily stop, kill switch. | Paper run can exceed tested exposure. |
| Reject policy | Fail-closed rules and reason codes. | Bot can route trades research would reject. |
The launch contract should be the single object both research and paper trading can point to.
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.
Useful benchmark checks include:
- same signal timestamp
- same selected OCC ticker
- same rejected alternatives
- same DTE and strike-ranking outcome
- same quote window and spread decision
- same entry and exit fill policy
- same risk sizing before rounding
- same end-of-day or stop/target reason
The benchmark does not need to cover every historical day. It needs to cover enough representative sessions that the team trusts the production route.
Preserve Reject Reasons
A live paper loop will hit messy conditions: stale quotes, no listed expiry, wide spreads, no option contract, market window closed, duplicate signal, 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. A clean rejection log gives the team a map:
| Reject reason | What it usually means |
|---|---|
no_listed_expiry | Calendar or expiration validation failed. |
contract_pool_empty | DTE, strike, type, or liquidity filters were too narrow. |
quote_missing_near_entry | Data coverage or market activity was not enough for a fill. |
spread_above_max | The idea may be too expensive to express in that contract. |
signal_too_old | Live data timing drifted from research assumptions. |
risk_cap_hit | The strategy fired, but portfolio controls blocked entry. |
These rejects are not noise. They are the paper run's most useful diagnostic output.
Compare Decisions, Not Only PnL
PnL is a late-stage comparison. First compare decisions. Did the bot fire when research fired? Did it choose the same contract? Did it skip the same bad markets? Did it size the same way? Did it exit for the same reason?
Only after those questions pass should PnL be interpreted. If decisions match and PnL differs, the drift may come from live quote timing, broker simulation, or delayed data. If decisions do not match, the paper route is not validating the backtest yet.
Daily Review Checklist
| Check | Pass condition |
|---|---|
| Signals | Every paper signal links to a strategy profile and input timestamp. |
| Contract selection | Selected contracts match the frozen DTE, strike, and liquidity policy. |
| Fills | Entry and exit records include bid, ask, timestamp, and fill assumption. |
| Rejects | Every skipped trade has a specific reason code. |
| Risk | Position size and daily exposure stay inside launch-contract limits. |
| Drift | Differences from research replay are labeled and reviewed. |
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. The strongest paper system is not the one that makes the best first-week PnL. It is the one that tells the truth about whether the backtest survived contact with live data.
FAQ
Related questions
When should a paper candidate be blocked?
Block promotion when replay mismatches change entries, exits, contract choice, reject reasons, sizing, or PnL without an intentional rule change.
Product links
Build the workflow with CuteMarkets
This article is part of the broader CuteMarkets product and research stack. Use the landing pages below to move from the blog into the specific API workflow you want to evaluate.
Paper Trading
See the product workflow for resettable paper accounts and quote-aware simulated orders.
Paper Trading Bot Docs
Map parity, launch contracts, risk controls, and operational review into a bot workflow.
Backtesting Framework
Review the replay standards the paper route should preserve.
Options Backtesting API
Connect historical contracts, quotes, trades, and artifacts to the paper handoff.