Guide

Paper trading vs backtest: how to verify your live code matches your model

Backtesting fundamentals · ~6 min read

An honest backtest can still fail live for a reason that has nothing to do with markets: your live or paper-trading code doesn't actually implement the same logic your backtest tested. These are almost always two separate codebases, and nothing forces them to agree.

The gap most people never check

A backtesting engine and a live or paper-trading engine are, in almost every retail setup, two entirely different pieces of code. The backtest might be a vectorised pass over a pandas DataFrame. The live engine reacts to bars arriving one at a time from a broker's data feed, maintains running state, and places real orders. They were probably written at different times, sometimes by different people, and nothing automatically keeps their logic in sync.

This means a strategy can have a completely honest, non-overfit, properly out-of-sample-tested backtest — and still lose money live for a reason with nothing to do with markets at all: the live code simply computes a different signal than the backtest did, on the same data.

Where the two implementations quietly diverge

Indicator warm-up and rolling windows

A 50-period moving average needs 50 bars of history before its first value is valid. A backtest running on a long historical file has that history sitting right there. A live engine that just started this morning might not — and if it silently produces a signal anyway using a partially-filled window, that's a different calculation from what the backtest did on the identical timestamp.

Bar timing and when a signal is allowed to act

Does your system decide to trade using a bar's close, or as soon as the next bar opens? A one-bar timing difference between backtest and live execution is one of the most common causes of results that look similar in shape but consistently underperform the backtest in practice.

Look-ahead bias baked into the backtest itself

If the backtest computes an indicator using information that wouldn't genuinely have been available at that point in time — for example, using a bar's own closing price before that bar has actually finished — it will look better than any live implementation could ever replicate, because live trading only ever has truly completed data to work with. This isn't a mismatch between two implementations so much as one of them (the backtest) quietly cheating.

Rounding, position sizing, and order types

A backtest might allow fractional position sizes for simplicity; a live broker often can't. Market orders fill at a different price than the bar close a backtest assumes. These aren't bugs exactly, but they're real-world constraints a backtest can easily omit without anyone noticing until live results start drifting from expectations.

How to actually run the comparison

The most direct check: take a chunk of historical data your live system hasn't seen, and run it through both paths — the backtest engine, and your live or paper-trading engine fed the same bars one at a time as if they were arriving in real time. Then diff the outputs bar by bar: same entry signals, same position sizes, same exit timing. Any disagreement tells you exactly which bar the implementations parted ways, which is usually enough to find the bug.

Why paper trading is still worth doing even after this check

Matching signals on historical data proves your two implementations agree on stored data. It doesn't prove your live data feed is clean, your order handling is correct under a real network connection, or that your system reacts sensibly to a genuinely unexpected market event. Paper trading for a real stretch of time — with real-time data, even if the orders aren't real — is the only step that tests those things, and it's worth doing even when the backtest and live signal logic have already been confirmed to agree.

A simple pre-launch checklist

• Same historical bars, fed to both the backtest and the live/paper path — do the signals match, bar for bar?
• Does the live engine wait for genuinely completed bars, the same way the backtest does — no peeking at a bar before it closes?
• Are position sizes and order types the same, or does the live path round, clip, or approximate differently?
• Has the strategy been out-of-sample tested and, ideally, walk-forward tested — so you're not troubleshooting an implementation bug in a strategy that wasn't going to work anyway?

Frequently asked questions