Paper trading or backtesting

Backtesting evaluates a strategy’s rule set on historical data, while paper trading evaluates execution and operational workflow in real time. Backtests cannot fully capture live issues such as slippage, latency, and fill behavior, and paper trading cannot establish rule robustness across market history. Sonar’s Backtest Overfitting Audit and deflated Sharpe ratio help detect whether a strong backtest may be the result of overfitting or multiple testing. Both backtesting and paper trading are necessary because they validate different failure modes in a trading system.

Backtesting and paper trading answer different questions. Backtesting tests whether a strategy’s rules would have produced the intended signals on historical market data. Paper trading tests whether the strategy can be operated correctly in real time under current market conditions. Neither substitutes for the other.

Backtesting is the process of applying a defined trading rule set to historical data. Its purpose is to evaluate the internal logic of the model. A backtest shows how entry rules, exit rules, position sizing, and portfolio construction would have interacted with past prices under the assumptions built into the test. In that sense, backtesting is a rule validation tool. It helps a researcher check whether the strategy behaves as designed, whether the rules are internally consistent, and whether the results depend too heavily on a specific historical sample. Source material from Sonar’s comparisons page defines backtesting in this historical and rule based way.

Paper trading is different. It simulates trading in real time without committing capital. Its purpose is to validate the execution process and the operational workflow around the strategy. A paper trading run can reveal whether market data arrives correctly, whether signals are generated on schedule, whether orders are formed and routed as intended, whether the system handles rejections or partial fills, and whether the full research to execution pipeline works consistently from one session to the next. Sonar’s comparisons page describes paper trading as a real time simulation environment used to test execution and operations rather than historical rule logic.

This difference matters because historical rule validation and live process validation fail in different ways. A backtest can show that a rule set is coherent on past data, but it cannot fully reproduce real time execution conditions. It depends on assumptions about order handling, slippage, latency, and fill quality. Those assumptions may be simple, fixed, or optimistic. If the live system experiences delays, stale data, partial fills, missed trades, or routing problems, a clean backtest will not necessarily detect them. Paper trading is the stage that exposes those process issues because it runs the strategy forward in actual market time.

The reverse is also true. Paper trading can show that the system operates correctly in real time, but it does not establish that the strategy’s rules are robust. A paper run covers only a limited and recent slice of market behavior. That makes it useful for observing process quality, but weak for testing whether the rule set generalizes across different historical regimes. A strategy can paper trade smoothly while still being fragile, overly tuned, or dependent on a narrow market pattern that happened to persist during the paper period. That question belongs to backtesting and related robustness checks.

One major risk in backtesting is overfitting. Overfitting occurs when a strategy is tuned so closely to historical data that it captures noise rather than durable structure. In that case, the backtest can look convincing even though the rule set is not likely to generalize. Sonar’s Backtest Overfitting Audit is designed to examine this problem. The tool evaluates whether reported backtest results are likely to have been improved by excessive search, repeated specification changes, or selective reporting. Its role is not to replace a backtest, but to challenge the credibility of an attractive backtest by asking whether the observed result could be an artifact of model selection.

The deflated Sharpe ratio addresses the same problem from a related angle. Sonar’s glossary explains it as a Sharpe ratio adjustment intended to account for multiple testing and non normal return features when judging whether an observed Sharpe ratio is statistically meaningful. A plain Sharpe ratio can look strong after many trials because some specifications will appear successful by chance. The deflated Sharpe ratio reduces that risk by adjusting the interpretation of the measured result in light of the testing process. In practical terms, it helps a researcher distinguish between a backtest that looks good because the rule set has real signal and a backtest that looks good because many variants were tried.

Taken together, these tools reinforce the distinction between backtesting and paper trading. Backtesting asks whether the rules make sense across history. Overfitting diagnostics ask whether the historical result is credible. Paper trading asks whether the strategy can actually be run, monitored, and executed in real time. A robust research process needs all three functions because each one checks a different failure mode.

A simple example makes the separation clear. Consider a strategy that generates intraday orders from a historical signal and produces acceptable results in backtesting. The backtest may assume that trades are filled near observed prices with modest slippage. When the same strategy is paper traded, the team may discover that orders arrive late relative to signal time, that quoted liquidity is thinner than expected, or that partial fills break the intended position sizing logic. In this case, the strategy passed historical rule testing but failed process validation. The failure is not necessarily in the idea itself. It is in the live implementation assumptions that the backtest could only approximate.

The opposite pattern can also occur in a limited sense. A strategy may run cleanly in paper trading because the data feed, signal engine, and order workflow all function as intended. Yet that smooth paper operation does not prove the rule set is robust. If the historical testing is weak, too short, or overfit, then the paper exercise validates only that the machinery works. It does not validate the strategic logic across broader market history.

The practical lesson is straightforward. Use backtesting to test the strategy rules on history. Use overfitting checks such as the Backtest Overfitting Audit and the deflated Sharpe ratio to assess whether the historical result is credible. Use paper trading to test the real time execution path, data handling, and operational workflow. If a strategy succeeds in only one of these stages, the evaluation is incomplete. Historical validity without operational validity is not enough. Operational validity without historical robustness is not enough. They test different parts of the system, and both are required for a robust trading process.

Drafted with AI assistance from cited sources. Reviewed and approved by Sonar Sciences Quant & Research Team.