Paper trading vs backtesting vs live trading

The short answer: three different modes

Backtesting applies rules to historical data. Paper trading, also called demo trading, simulates trades with virtual funds as new market data arrives. Live trading sends real orders and affects real funds. Check the mode, data source and execution method separately.

OKX Help describes demo trading as a simulated environment that does not use real money. That describes OKX’s mode; it does not establish an integration with Clerix. A moving current price on a screen does not mean that the displayed trade is real.

Backtesting: a question for historical data

A historical test is useful when you need to repeat a calculation with a saved version of the rules. Choose a period and assumptions, then examine signals, hypothetical trades and equity. Our guide to fees and drawdown helps prepare execution assumptions.

We suggest asking three questions about the report: what information was available when the decision was made, how was the fill price calculated, and which expenses were deducted? Without those answers, a chart alone is insufficient to evaluate the method.

In an educational scenario, a signal becomes available after an hourly candle closes. The test should distinguish candle time, signal calculation time and assumed execution time. Otherwise, an unnoticed one-step difference can change the trade sequence. This scenario illustrates a testing method rather than recommending a timeframe.

Paper trading: a question about current behavior

Virtual trading lets you observe decisions while a new data stream develops. TradingView’s documentation describes paper trading as practice with simulated money. Available instruments and settings depend on the platform.

Prepare a log before observation begins. Record signal time, expected order, virtual fill, position change and reasons for skipping actions. If a strategy stays silent, the log should help distinguish “no signal” from a stopped data feed.

A useful check compares the expected action with the observed one. For example: “The condition is true on the closed candle, there is no open position, and a new order is allowed.” Then check whether exactly one action occurred. This evaluates compliance with the specification even when the financial outcome provides little useful information.

Why simulation differs from live trading

Real execution depends on the order book and the venue’s rules. Binance explains the differences between order types: a market order uses available prices, while a limit order restricts the price and may remain unfilled.

When evaluating a simulator, check whether it models:

• spread and price changes before execution;
• partial fills and remaining quantity;
• rejected orders and size restrictions;
• fees, funding and the currency used for costs;
• delayed data, lost connections and recovery;
• cancellation and a fill occurring during cancellation.

These are questions for the implementation. They do not imply that every paper trading environment supports each case. If a simulator fills every order completely at the latest price, interpret its results with that limitation. Virtual funds also do not reproduce your personal response to a real loss.

How to structure sequential validation

Treat a change of mode as a separate decision and preserve the rule version. A suggested research workflow is:

1. Define entry, exit and halt conditions; remove ambiguities.
2. Review historical trades and execution assumptions.
3. Freeze the strategy version and the paper observation plan.
4. Investigate every difference between expected and observed actions.
5. Create a new version after rule changes and record which checks were repeated.
6. Treat live trading as a separate mode with separate permissions, state controls and exposure to real losses.

There is no universal number of paper trading days after which a strategy automatically becomes ready for real funds. Duration alone says little about scenario coverage. A week without a signal and a week containing many orders provide different evidence; neither promises future profit.

What a discrepancy log should contain

A practical entry has five fields: rule version, input data, expected action, observed action and an explanation of the difference. Do not silently rewrite an old entry. Append the decision and a reference to the new check.

For example, suppose duplicate data arrives after a reconnection in a hypothetical test. The specification allows one order per signal. If the simulator creates a second order, that is a duplicate-handling issue even if both virtual trades close at a profit. The financial outcome does not replace a correctness check.

Compare modes using the same rules. Record changes to size, market or logic separately. Otherwise, “the backtest and paper results differ” combines several possible causes that a single experiment cannot isolate.

Next step: save the validation plan

Before changing modes, record what stays the same: rule version, market, size and log format. List changed assumptions separately. A discrepancy can then be investigated instead of being explained away as “it looked different on history.”

Use our AI brief with explicit rules and limits to prepare your own specification. Explore the path from an idea to rules and testing in Clerix.