Paper trading vs backtesting: what each proves

Backtesting and paper trading answer different questions. A backtest asks how fixed rules behaved on historical data. A paper test asks how a fixed process behaves as new data arrives, without committing capital. Neither result predicts future profit or reproduces every condition of live execution.

Which test should you use?

In most research workflows, backtesting comes first because it is faster. Paper trading then tests an unchanged candidate on unseen, incoming data. Reversing the order means waiting days or weeks to discover basic defects that a historical replay could expose in minutes.

What a backtest tells you

A backtest applies specified rules to historical observations. It can estimate trades, returns, drawdowns, exposure, turnover, and cost sensitivity over the selected period. It is useful for rejecting ideas that do not trigger, depend on one event, or fail under plausible fees and slippage.

Its speed creates a risk. Each new parameter, asset, timeframe, or date range is another chance to fit noise. Bailey, Borwein, López de Prado, and Zhu explain in the Notices of the American Mathematical Society how repeated trials can produce an impressive in-sample result without useful out-of-sample information.

A backtest is strongest when the rules and assumptions are recorded before the final evaluation period is opened. It becomes weaker when the researcher repeatedly changes the strategy after seeing every result.

What paper trading tells you

Paper trading applies a strategy without putting actual money at risk. Depending on the platform, it can mean a broker simulator with virtual orders or a strategy engine that maintains modeled positions.

Its main value is temporal honesty. Tomorrow's observation was not available when today's rules were frozen. A paper run can also expose stale data, scheduling errors, missed events, duplicate processing, restart behavior, and rules that rarely trigger outside the development sample.

Paper trading still uses assumptions. A simulated fill can ignore queue position, partial fills, spread changes, market impact, or the delay between a signal and an order. It also removes the financial pressure of losses. The National Futures Association's hypothetical-performance rule highlights hindsight and the inability of hypothetical records to capture all market and implementation factors.

The biases that matter most

Look-ahead bias occurs when a decision uses information that was not available at that time. Examples include a completed candle used before it closed or a later database revision applied to an earlier date.

Survivorship bias occurs when the test includes only assets or entities that still exist. Failed, delisted, or unavailable members can materially change the result. CFA Institute's investment model validation review discusses both look-ahead and survivorship bias.

Selection and data-snooping bias grow with every strategy variant that is tried and discarded. Reporting only the best variant hides the number of opportunities the research process had to find a lucky result.

Cost and fill bias appear when the simulation uses a convenient candle price or understates commission, spread, slippage, funding, and market impact. Testing several cost assumptions is more informative than treating one estimate as exact.

Coverage and timestamp errors include missing bars, duplicated bars, inconsistent time zones, changing asset identifiers, and incomplete warmup data. A sophisticated strategy cannot repair an invalid input series.

Paper trading reduces some forms of hindsight because data arrives after the rules are fixed. It does not remove optimistic fill assumptions, a short sample, or regime risk.

How Tradee's paper pool differs

Tradee uses a specific meaning of paper trading. A backtest replays stored candles for a strategy or bot. A paper pool evaluates incoming candle data, including the forming bar on each evaluator poll, and maintains Modeled positions against modeled funding. A strategy can gate entries to bar close, so record that setting when you compare paper timing with a backtest.

The paper pool is not a broker demo account. It has no exchange login, exchange wallet, or broker fill. A paper execution does not receive a generated feed. An output execution can publish the same types of modeled position transitions through the Live API, but Tradee still does not route or execute orders.

• Backtest
• Held-out range
• Paper pool
• Output test

This distinction keeps the evidence clear:

• A Tradee backtest checks historical strategy behavior under the selected data and cost assumptions.
• A Tradee paper execution checks the evaluator, funding model, risk settings, and Modeled positions on incoming data.
• A Tradee output execution checks generated events for a receiver that the user operates.
• None of these stages records an exchange fill.

A reproducible backtest-to-paper experiment

The purpose of this experiment is not to prove profitability. It is to learn whether a fixed result survives a new sample and whether the live-data process behaves as specified.

1. Write the hypothesis. Record the asset, timeframe, entry and exit rules, position sizing, costs, and metrics that would reject the strategy.
2. Choose the split before testing. Use an earlier development range and a later held-out range. Do not inspect the held-out result while tuning.
3. Record the search. Count every meaningful strategy, parameter, asset, and timeframe variant. Keep failed trials.
4. Run the development backtest. Fix data coverage issues and implementation errors, but record any rule change as a new variant.
5. Freeze one version. Save its exact strategy version, settings, cost assumptions, and acceptance criteria.
6. Run the held-out backtest once. Compare trade count, expectancy, drawdown, turnover, and exposure with the development result.
7. Start the same frozen version in paper mode. Do not tune it during the paper window. Any change starts a new experiment.
8. Define the paper window in advance. Use a minimum calendar period and a minimum number of closed Modeled positions. Extend the test if one threshold is not met.
9. Log operational events. Record missing data, restarts, version loads, skipped decisions, duplicate processing, and risk-control actions.
10. Compare like with like. Re-run a backtest over the exact paper dates after the window closes. Compare decision times and Modeled positions before comparing summary metrics.

Use a small comparison sheet with the version ID, date range, trade count, win rate, average win, average loss, expectancy, maximum drawdown, exposure, and assumed costs. Why win rate is not enough explains why the hit rate cannot stand alone.

How to interpret the result

A weak held-out result can mean the original pattern was noise, the new period was different, or the sample is still too small. A paper mismatch can point to timing, data, state, or implementation differences. Investigate the cause before changing the rule.

A close match between backtest and paper decisions is useful operational evidence. It does not establish future returns or real execution quality. If the next objective is a generated output test, document the receiver's stale-event, duplicate-event, size, and stop controls separately.

For a Tradee workflow, start with a first strategy, run a first backtest, freeze the candidate, and then create a first bot for the paper stage.

Methodology and sources

This comparison separates historical, held-out, and live unseen samples. Its bias checklist draws on CFA Institute's investment model validation review and the peer-reviewed discussion of backtest overfitting. The limits of simulated results follow the NFA's required hypothetical-performance disclosure. This article is educational and does not provide personalized investment or trading advice.