What Paper Trading Catches, and What It Misses

Paper trading runs a strategy against live market data with simulated fills and no real money. Its value is almost entirely in validating the system rather than the strategy: it catches the engineering failures that a backtest cannot see, while telling you nearly nothing about whether an edge exists. Treating it as evidence of profitability is a category error, and a common one.

Educational material, not trading advice. Algorithmic crypto trading is high-risk and most retail algo traders lose money.

Why it exists at all

A backtest and a live system are different programs, and paper trading is the only place to test the difference. A backtest reads a clean historical file in one pass. A live system consumes a streaming feed that arrives late, out of order, and sometimes not at all; maintains state across restarts; talks to an API that rejects, throttles, and times out; and must know its own position without being able to assume it.

None of that is exercised by replaying history. Paper trading is where the strategy meets real-time data plumbing while the cost of a mistake is zero.

What it reliably catches

The failure classes paper trading exposes are the ones that most often kill a first live deployment.

The forming-bar bug. In a backtest every bar is complete. Live, the current bar is still forming, and reading its close as final means acting on partial information — then acting again when it changes. This is the single most common live-only bug, and paper trading surfaces it within hours as inexplicable duplicate signals.
Feed handling. Reconnection after a dropped socket, backfilling the gap the disconnect created, discarding duplicate messages, and handling out-of-order arrivals. All of these are absent from a backtest by construction.
State across restarts. If the process dies, does it come back knowing what it thinks it holds? Paper trading with deliberate restarts tests the persistence layer, and deliberate restarts are the right test because unplanned ones will happen.
Timing and scheduling. Whether the strategy runs when it should, whether a run overlaps its predecessor, whether a clock or timezone assumption holds at midnight and at daylight-saving transitions.
API error handling. Rejections for precision violations, minimum notional, and rate limits arrive live and never in a backtest — see the exchange abstraction layer, and what it hides.
Signal frequency sanity. If the live system generates dramatically more or fewer signals than the backtest did over a comparable stretch, something differs between the two code paths. That divergence is the most valuable single number paper trading produces.
Operational blind spots. Whether you can tell what the system is doing, whether alerts fire, whether logs contain enough to reconstruct a decision. Discovering that you can’t answer “why did it do that?” is much better discovered now.

What it structurally cannot catch

Anything that depends on your order actually existing in the market is invisible.

Fill realism. A simulated fill is generated by your assumption, not by a counterparty. Whether a limit order would have been reached in the queue, whether a stop would have gapped, whether your size would have moved the price — a paper system answers these with whatever model you coded, which is the same guess your backtest made. Paper trading does not validate the fill model; it reuses it.

Your own market impact. By definition, a simulated order does not consume liquidity and does not change anyone else’s behaviour. Nothing about paper trading can tell you what happens when the order is real.

Whether an edge exists. This is the important one. A few weeks of live-simulated results is a tiny sample from a noisy distribution, and the range of outcomes consistent with “no edge whatsoever” is very wide over that horizon. A profitable paper period is weak evidence and an unprofitable one is weak evidence. The statistics here are the same as everywhere else: distinguishing a real effect from noise takes far more observations than a short forward test provides, per what the Sharpe ratio actually measures.

Behaviour under stress. Paper trading during a quiet period tells you nothing about the venue’s behaviour when the market moves violently — the moment when latency rises, rejections spike, and feeds fall behind. You can’t schedule that test; you can only be running long enough to catch one.

Your own psychology. Simulated losses do not feel like losses. The discipline question — whether you would override the system during a drawdown — is precisely the one that paper trading cannot pose, because nothing is at stake.

Reading the divergence

The output to study is not the paper P&L; it’s the comparison between the paper run and a backtest over the same period. Run both on the identical window and reconcile:

Trade count. Should be close to identical. A difference means the signal path differs between the two code paths.
Trade timing. Signals should occur on the same bars. Systematic lateness means the live path is waiting for something the backtest didn’t.
Signed positions over time. Plot both position series. Divergence points are bugs, and each one has a specific cause worth finding.
The set of assets traded. If the live universe differs from the backtest universe, the universe construction is not shared between them, which is a reproducibility problem as well as a bug.

When these reconcile, the plumbing is correct. That is the deliverable. Anything about profitability remains an open question that the paper run has not addressed.

How long, and what next

Run it long enough to see a restart, a feed disconnection, a rejected order, and at least one volatile session — that is a duration set by events, not by a calendar target, though in practice it usually means weeks rather than days. Ending the run because the P&L looks good is ending it for the wrong reason.

The step after paper trading is not full size. It is the smallest real size that produces real fills, because the only way to learn what your fill model gets wrong is to compare modelled fills against actual ones. That comparison — expected price versus realized price, per order — is a measurement you cannot obtain any other way, and it feeds directly back into the cost assumptions discussed in modelling transaction costs in a backtest.

Alongside it, the safety machinery has to be live too: size caps, rate caps, a kill switch, and a pre-set maximum drawdown at which the system halts, per position sizing and risk management basics and what sits between a backtest and a live bot.

The takeaway

Paper trading is an engineering test wearing the costume of a trading result. Used as intended it removes an entire class of bugs at zero cost and is close to mandatory before real capital is involved. Used as evidence of edge it is worse than nothing, because a favourable stretch of noise is the most persuasive thing that can happen to you — and unlike a backtest, it feels like the future rather than the past.