Why Your Backtest Doesn't Match Live Trading

Some Gap Is Normal

A backtest is a simulation built on assumptions about data, fills and costs. Live trading has none of those assumptions. It has real orders, a real queue and real latency. Some difference between the two is normal.

The goal isn't a perfect match. It's knowing where the gap comes from, how big each source is, and whether what's left is small enough to live with. Nearly every gap comes from one of eight places.

1. Costs You Didn't Model

Commission is charged on each side of a trade, and exchange and regulatory fees come on top. Slippage is the difference between the price you expected and the price you got.

Costs matter most for strategies with a small average trade. A hypothetical example with simple numbers: if a strategy's average trade is 2 ticks before costs and live slippage averages 1 tick on each side, the edge is gone before commission.

Fix: set commission per side and a slippage assumption you'd be comfortable defending, then check the average trade after costs, not before.

2. Optimistic Fill Assumptions

Backtesters have to decide when and at what price your orders fill. Common sources of optimism:

• Bars that touch both stop and target. Bar data doesn't record which traded first, so the backtester guesses. See Tick vs Bar Backtesting.
• Limit orders that fill on a touch. Live, a limit order fills only when enough size trades at your price to reach your place in the queue. The trades where price touches your level and reverses are often the good ones you miss, while the ones that trade straight through are the ones you get.
• Stop and market orders in fast markets. Gaps and fast moves fill stops at worse prices than the stop level.
• Order size. A fill model that ignores available depth assumes any size fills at the displayed price.

Fix: test with the most realistic fill data you have for the strategy's style, and treat limit-order fills in a backtest as a best case.

3. Look-Ahead Bias and Repainting

If the backtest used information that wasn't available at decision time, live trading can't reproduce it. Typical cases:

• deciding on a bar's close but filling at the same bar's open;
• using the day's high or low before the day is over;
• reading a higher-timeframe indicator before that higher-timeframe bar has closed;
• signals that repaint while a bar is still forming.

Look-ahead usually produces results that are too good, with trades that sit at or near the best price of the bar.

Fix: check the trades with the best entries on the chart. If a trade needed to know the bar's close before it closed, you've found it. Look-Ahead Bias in Backtesting: 7 Real Examples lists more patterns to check.

4. Different Data in Backtest and Live

When the backtest uses one data source and live trading uses another, the two can disagree: different trade prints, different bar construction, different session boundaries. Other data traps:

• Timezones and daylight saving time. A session rule written in UTC shifts by an hour twice a year relative to New York time.
• Holidays and early closes. Time-based exits may never trigger on a shortened session.
• Futures rolls. Continuous contract data is stitched together from several contracts, while live orders go to one specific contract.

Fix: use the same data source for research and live where you can, and write session rules in the exchange's local time with daylight saving time handled.

5. The Live Code Isn't the Backtested Code

A strategy tested on one platform and rewritten for another is two strategies. Small translation differences, such as an off-by-one bar, a different rounding rule or a different default order type, change the trades.

Fix: run the same code in both places, or compare the two implementations trade by trade over the same days before going live.

6. Configuration Drift

Even with identical code, live settings drift from the backtest:

• parameters differ from the tested set;
• position size is calculated from a different account balance than the backtest's starting capital;
• symbol or timeframe differs;
• risk limits stop trading on days the backtest kept going;
• someone intervened by hand.

Fix: record the exact configuration of the backtest you're relying on, and compare it field by field with the live setup.

7. Execution and Operations

Live systems meet problems a backtest never does: rejected orders, disconnects, restarts, a position left open from the day before, a broker account read that fails. Each can add or remove trades.

Fix: read the live logs for every day where live and backtest disagree. Operational causes usually show up there.

8. Overfitting and Regime Change

If you tried many parameter sets and picked the best, part of that result is luck, and luck doesn't repeat. Markets also change: a strategy tuned on a quiet period can behave differently when volatility doubles.

Fix: validate on data you didn't optimize on (out-of-sample or walk-forward), prefer parameters in a stable plateau over a single sharp peak, and look at trade count before trusting any metric.

Diagnose a Gap Step by Step

1. Export the live trades for a period with a meaningful number of trades.
2. Rerun the backtest over exactly that period with the live parameters, symbol, timeframe, costs and position size.
3. Match trades one by one. Sort each into: in both, live only, backtest only.
4. Explain each group using the table below.
5. Quantify each cause. Slippage per trade, missed trades, extra trades.
6. Fix the model, not the strategy. Raise slippage, change the fill model or fix the data issue. Don't re-optimize parameters on the live period; that's fitting to the answer.

Symptom	Likely causes
Same trades, worse prices live	Slippage, optimistic fill model, order size
Backtest trades missing live	Limit orders not filled, risk limits, disconnects, data or session differences
Live trades missing from backtest	Different data, repainting, manual trades, code differences
Backtest far better from day one	Look-ahead bias, missing costs, overfitting
Matched at first, drifting later	Regime change, parameter drift, futures roll handling

How Roboquant Narrows the Gap

No platform removes the gap, but some sources of it are design choices:

• Same compiled code. A Roboquant strategy is compiled once into a .rqc artifact. The same artifact runs in backtest, optimization, replay and live deployment, with no rewrite into another language.
• Same data source. CME is the market-data source in both research and live. The broker, Tradovate, only routes orders and reports account, order, position and fill state.
• Causality enforced by the engine. In bar mode the strategy sees the bar that just closed. In tick mode the forming bar contains only what was known at that tick, and higher-timeframe indicators expose the previous completed value.
• Fill models to match the strategy. OHLCV bars, the tick trade tape, or order-book depth, depending on your plan and data coverage.
• Validation. In-sample/out-of-sample and walk-forward optimization, depending on your plan.
• Live sizing from the real account. The deployment form reads the actual Tradovate balance before launch and doesn't fall back to the backtest's starting capital.
• Explicit configuration. Parameters are fixed when a deployment starts; changing them means stopping and redeploying, so the running configuration is always the one you chose.
• Safety controls outside strategy code. Maximum order size, maximum position size and a daily-loss halt that cancels working orders and flattens.

What still differs: live fills depend on the market at that moment, so slippage, queue position and partial fills are never guaranteed to match a simulation. Live deployments currently trade one symbol per deployment, and deployments are available on Pro and higher. The live deployment docs list the current scope.

Checklist Before You Go Live

• Commission and slippage set to realistic values
• Fill model chosen for the strategy's style, with tick fills for tight stops or stop entries
• Best trades checked on the chart for look-ahead
• Session rules in exchange time with daylight saving time handled
• Parameters validated out of sample
• Live configuration matches the backtest you're relying on
• A demo period compared trade by trade with a backtest of the same days

Related Reading

• Tick vs Bar Backtesting: When Intrabar Fills Change Everything
• How to Backtest an Opening Range Breakout Strategy
• Understanding Sharpe Ratio, Drawdown & Key Metrics
• Look-Ahead Bias in Backtesting: 7 Real Examples
• Turn a Trading Idea into Code with AI
• Docs: Backtesting, Live deployment

Try It

Backtest a strategy, then run the same compiled strategy on a Tradovate Demo account and compare.

Start building · See pricing

Trading involves risk of loss. Backtest results are hypothetical and do not guarantee future performance.