A backtest often counts trades as if a signal turned directly into a position. Paper trading inserts an order in between. That order can rest, fill partially, get canceled, be rejected, or remain live after the signal has changed. If your simulated strategy skips that lifecycle, its trade count and exposure may have little to do with what the paper account records.
The practical fix is to make orders persistent objects with states and timestamps. A signal is an instruction to try to trade; it is not evidence that a trade happened.
Why does my paper strategy have fewer trades than my backtest?
Start with orders that never filled. A backtest may assume every limit order filled whenever the market touched its price. In a live market, a touch does not tell you whether your order was ahead of the queue, whether enough volume traded, or whether the quote was still available when the order reached the venue.
Consider a strategy that places a buy limit at $100 and cancels it after 30 seconds. The market prints $100.00, but only a small amount trades there and other orders have priority. Your order might fill a fraction, or nothing. A touch-based backtest records a full position. A paper account that tracks queue assumptions may record no fill at all.
Market orders have a different mismatch. A backtest might fill the entire quantity at the next bar’s open, while paper trading rejects a quantity that breaches an exchange filter or fills in pieces as the book moves. A bar is a summary of trades; it does not promise that your whole order could have traded at one price.
What should a backtest do when a signal changes before the order fills?
Keep the old order live until the simulator receives and processes a cancellation. If the signal flips while a buy order rests, the strategy may want to cancel it and submit a sell. That intent does not erase the buy order immediately. It may fill while the cancellation is in flight, leaving the account long just as the new signal says short.
Model this as a sequence: the signal changes, the strategy sends a cancel request, the venue acknowledges it or reports a fill, and only then does the strategy know the final order state. Even a simple fixed delay can reveal races that an instant-cancel backtest hides.
For a deliberately simple model, a one-second cancellation delay and next-event processing can be more informative than pretending cancellation is instantaneous. The right delay depends on venue and system; the point is to represent a delay at all. If your order is a market order with no cancellation window, the same issue still matters for partial fills and late reports.
Which order states should a paper trading simulator record?
Use a small state machine and preserve each transition with its time. The exact venue vocabulary varies, but the core distinctions are stable:
- New or pending: submitted, but not yet acknowledged.
- Open: accepted and still eligible to fill.
- Partially filled: some quantity traded; the remainder may still be open.
- Filled: no remaining quantity.
- Cancel pending: a cancellation request is in flight; the order can still fill.
- Canceled, rejected or expired: no more quantity can trade under that order.
Record filled quantity separately from requested quantity, along with fill prices and fees. A partially filled order is both a trade and a live obligation for its remainder. Treating it as simply open or simply done loses information the strategy needs to size its next action.
| Order event | What the strategy should know | Common backtest shortcut |
|---|---|---|
| Partial fill | Executed quantity, remaining quantity, average price | Mark the whole order filled at one price |
| Cancel request | Request time and eventual cancel or fill confirmation | Remove the order immediately |
| Reject | Reason and whether retrying is valid | Assume the requested trade happened |
| Expiry | Time the order stopped being eligible | Leave it open until a later price touch |
How do I compare backtest trades with paper trading fairly?
Compare order events first, positions second, and P&L last. If the backtest filled an order the paper account never did, the later P&L difference is a consequence, not the place to diagnose the fault.
For every intended order, match the two runs on a stable strategy decision or order identifier. Then inspect submission time, requested price and quantity, time in force, fills, cancellations, rejects, fees and final position. Keep the reason for a simulated no-fill too: the price never reached the limit, assumed queue ahead was not cleared, or the order expired.
A small example makes the sequence clear. The signal asks for 10 units. Both systems submit at 10:00:00. The backtest assumes a full fill at 10:00:01. Paper trading fills 4 units at 10:00:01, receives a cancel request at 10:00:02, then reports another 2-unit fill before cancellation is confirmed at 10:00:03. The honest comparison is 6 units filled versus 10, with 4 canceled. Averaging both into one “trade” hides the exposure the strategy actually carried.
Do I need a full exchange simulator to get this right?
No. A backtest can start with a few explicit assumptions: whether a limit touch is enough, how much volume must trade through the price to clear assumed queue ahead, how long orders remain open, and how cancellation delays work. Run the strategy under more than one plausible setting. If performance depends on every resting limit filling completely, you have learned something useful about the model.
Paper trading is also not ground truth for execution quality. It may use simulated fills and lack a real queue. Its value here is narrower: it reveals whether the strategy and its order manager agree about pending quantity, cancellation, position and retry behavior as events arrive over time.
One minor pleasure of this work: a good order log can make an otherwise baffling discrepancy boring. “The second child order filled after the cancel request” beats “paper trading looks weird.” When the backtest and paper account disagree, follow the order lifecycle before editing the signal.
← All posts
