Backtesting vs Paper Trading vs Live Trading

Paper trading is sometimes called forward testing. The term can also describe other tests that move forward through time, so check whether someone means a live-data simulation or a historical walk-forward experiment.

A backtest applies explicit trading rules to a historical dataset. It lets you inspect when a bot would have generated signals, how a simulated portfolio would have changed, and which assumptions drive those results.

Before focusing on the return, check what the simulation knew at each decision. A strategy that calculates a signal from a completed daily candle cannot also assume it traded earlier in that candle using that information. That is a timing error, even if the code runs successfully.

Other questions matter too:

• Did you select the rules after trying many alternatives on the same data?
• Does the dataset represent the instruments available at the time, including those that later disappeared where relevant?
• Are corporate actions, fees, spreads and slippage handled consistently?
• Have you examined a reserved period without repeatedly tuning the strategy to it?

These checks help expose misleading results. They cannot establish that a strategy will keep working. QuantStart’s guide to backtesting biases explains why optimization, look-ahead and survivorship bias deserve separate attention.

QuantConnect Paper Trading runs an algorithm with incoming data and fictional capital. Its own simulator handles the fills. With the default brokerage model, its documentation specifies no slippage and immediate, complete market-order fills. Other model choices can change that behavior. See QuantConnect’s paper trading documentation.

A broker’s paper account is a separate simulation. Interactive Brokers explicitly warns that order execution can differ between its paper and live environments. See its paper trading API documentation.

Alpaca lists several things its paper environment does not reproduce, including market impact, latency-related slippage and queue position for non-marketable limit orders. Those are Alpaca-specific limitations, not a universal specification for every simulator. See Alpaca’s paper trading documentation.

Connecting software to a paper account therefore does not make its fill assumptions equivalent to live execution. See how this applies to Claude and Alpaca MCP.

In live trading, the broker reports actual order outcomes. An accepted order is not necessarily a filled order. Your bot needs to handle partial fills, rejections and cancellations, and distinguish the position it requested from the position it actually holds.

Backtest and live results can also differ because data arrives at different times, historical data is revised, or fees and fills differ from the model. QuantConnect documents these issues in its backtest-to-live reconciliation guide. A new 2026 study of AI trading bots shows how those gaps changed across backtests, exchange paper trading and real-money crypto execution.

Compare individual decisions before comparing the final equity curves. If the two systems generated different signals, start with the inputs and timing. If the signals match but the positions differ, inspect order handling. If quantities match but profit differs, inspect fill prices, fees and accounting.

Suppose a hypothetical bot buys 100 shares at $100.00 and sells them at $100.20. That is a $20 gross profit before costs.

This gives you a defined system to evaluate. Otherwise, a change in the results may simply reflect a change in what you tested.

Check signal timing, data handling, costs and the separation between development and evaluation periods. Inspect a sample of trades manually, including losses. Examine sensitivity to less favorable execution assumptions instead of reporting only the most attractive configuration.

Separate a software check from a performance finding. Correct code can implement a strategy with no useful edge.

Observe ordinary sessions and deliberately test recoverable failures in the paper environment. Check the response to disconnects, stale data, rejected orders and restarts.

For a timeout, inspect the broker’s order state before retrying. A missing response does not necessarily mean the first order was never received. Record discrepancies and fix their causes before treating the deployment as ready for another stage.

Document permitted instruments, exposure limits, stop conditions, monitoring and who can intervene. Establish how to reconcile open orders and positions after a restart. Confirm the account and endpoint before enabling order submission.

There is no universal number of paper trading days that proves readiness. A low-frequency strategy may produce too few observations in a month, while a busy strategy can accumulate many highly correlated trades. Use sufficient observations to investigate the relevant behavior, and keep unresolved execution issues visible.

It can reveal operational behavior that a historical test did not exercise. It does not automatically produce more realistic fills. Accuracy depends on the data and execution assumptions in each environment.

Yes. Possible causes include overfitting, a change in market conditions, different inputs, timing errors or different simulation assumptions. Investigate the specific discrepancy before changing the strategy.

Where the platform supports it, sharing strategy logic across stages reduces the amount of behavior you must reconcile. Keep environment-specific settings explicit and verify each deployment. Reusing the same code does not guarantee identical data, fills or results.

Educational content about trading-system development. No test or example here establishes future profitability.