You backtested a strategy, paper traded it, and now you’re watching it live, and the three don’t quite agree. Before you assume the strategy is broken, it’s worth knowing which differences are expected and which ones are real warning signs.
Why the three should mostly agree
If the same strategy code runs in all three modes, the decisions it makes, when to enter, when to exit, how to size, should be identical given the same inputs. So when results diverge, the cause is almost always in the inputs and the fills, not the strategy logic. That’s the useful part: it tells you where to look.
What legitimately differs
Some divergence is normal and doesn’t mean anything is wrong.
Fills and slippage
This is the big one. In a backtest, fills come from a model, typically the bar price adjusted for an estimated spread and slippage. In paper, fills come from a broker simulator. In live, fills come from the real market. The same order can fill at three slightly different prices, and live is the only one that’s real.
Timing and data
A backtest steps through historical bars; paper and live run in real time against a live feed. Real-time data has gaps, late prints, and latency that historical replay smooths over. A strategy that’s sensitive to exact timing will show small differences for this reason alone.
Order types that don’t model identically
Be careful with order types. The behavior you rely on in live may not be modeled the same way in a backtest, for example, don’t assume a stop fills in a backtest the way it would at a broker. Know which order types your strategy depends on and how each one is handled in each mode.
What should not differ
If these diverge, treat it as a real problem to investigate:
- The set of orders the strategy tries to place. Same data in should mean the same intended orders out. If the strategy wants to do different things, something is feeding it different inputs.
- Position direction and rough sizing. Small fill-price differences are fine; a long where you expected a short is not.
- Entry and exit conditions firing. The logic should trigger on the same events.
How to compare them in practice
Don’t compare a single summary number. Compare the records:
- Orders. Line up the orders each run placed. Are the same orders there, in the same sequence?
- Fills. For matching orders, how far apart are the fill prices? A consistent gap points to slippage assumptions; a random one points to data or timing.
- Positions and ledger. Did exposure and cash track the same path, allowing for the fill differences?
- Issues and logs. Did one run hit a rejection, a data gap, or an exception the others didn’t?
This is detective work, and it depends entirely on having the underlying records, not just an equity figure.
A checklist when backtest and live diverge
- Are the intended orders the same? (If not, it’s an input/data problem, not a fill problem.)
- Are fill-price differences consistent (slippage) or random (data/timing)?
- Did either run rely on an order type that behaves differently across modes?
- Was the account flat at the start of the live run?
- Did a calendar or session edge case hit one run and not another?
How Periscøpe makes the comparison possible
You can only compare what you can see. Every Periscøpe run, backtest, paper, or live, is a first-class record with its orders, fills, trades, positions, ledger, classified issues, and logs, all exportable. Because the same strategy version runs in every mode, a difference in results points straight at the fills or the inputs, and the run diagnostics give you the order-by-order detail to find it.