Paper Trading vs Live Trading for Algo Strategies
Paper trading and live trading answer different questions. Paper trading tells you whether your system does what you built it to do: reads data, generates signals, places orders, and handles errors. Live trading tells you whether the strategy still works once real fills, real costs and a real account balance are involved. Skipping the first step wastes money on bugs. Treating the first step as proof of profit is a mistake to avoid.
This guide explains what paper trading can and cannot tell you, how to run it so the results mean something, and what to check before going live with a small size. It is general education, not investment advice, and nothing here promises returns.
The short answer
- Use paper trading to test the machinery: data feed, signal logic, order placement, position tracking, restarts and error handling.
- Use live trading, at a deliberately small size, to test the market contact: slippage, partial fills, rejected orders and your own behaviour when the account moves.
- Do not use paper results to size up. A simulated fill is a model of a fill, not a fill.
What paper trading is good at
Catching engineering bugs cheaply
Some early failures in an automated strategy are engineering problems rather than strategy problems. Examples include an order sent twice, a stop that never gets placed, a position count that drifts out of sync after a reconnect, or a timestamp read in the wrong time zone. Paper trading exposes these with no money at risk.
Testing the full daily cycle
A backtest runs on stored data. Paper trading runs on the live clock, so it exercises start-up, the first candle of the day, the end-of-day square-off, and what happens when your script or connection dies mid-session. Run it for several full sessions, including a day with a sharp move and, if your strategy trades options, an expiry day.
Building a baseline to compare against
If you have already backtested the strategy honestly, paper trading gives you a second data point: does the live-clock behaviour resemble what the backtest said it would do? Large unexplained differences can point to look-ahead bias in the backtest or a data problem in the live feed.
What paper trading cannot tell you
Realistic fills
A simulated account fills orders by its own rule, which may use the last traded price or the best bid or ask. In a real market your order can be partly filled, filled at a worse price, or not filled at all. This matters most for illiquid contracts and for fast markets, which is exactly when your strategy may be most active. How a given simulator fills orders differs between platforms, so read how yours does it rather than assuming.
Costs and friction
Brokerage, taxes and other charges reduce real returns, and a strategy that trades often can lose a large share of its gross edge to them. Check whether your paper environment includes these. If it does not, enter your actual cost assumptions into the simulation, or subtract them manually when you review results.
Your own behaviour
With simulated money, it is easy to leave a losing system running. With your own money, you may override it, switch it off at the worst moment, or move a stop. Paper trading gives no information about whether you will actually let the system run as designed. Only live trading, at a size small enough to be tolerable, does.
Capacity and market impact
At small sizes you rarely move the price. That is true on paper too, but it also means paper results say nothing about how the strategy behaves at larger size.
How to run paper trading so it means something
- Write the pass criteria first. For example: no duplicate orders, every entry has a stop, positions reconcile at end of day, and the system recovers after a deliberate restart. Decide these before you start so you cannot adjust them to suit the outcome.
- Log everything. Signal time, order time, fill time and price, and the reason for each action. If you cannot reconstruct why a trade happened, you cannot trust it.
- Add costs and a pessimistic fill rule. Assume you buy slightly above and sell slightly below the quote. If the strategy only works with perfect fills, it does not work.
- Break it on purpose. Kill the process mid-session, drop the network, feed it a stale quote. Watch what it does.
- Run long enough to see different conditions. A week of calm trending days proves little. Include volatile days, gap openings and, for options, expiry.
- Do not tune it while it runs. Changing parameters after seeing paper results turns the paper period into another backtest, with the same overfitting risk.
When to move to live trading
Move on when the engineering checks pass cleanly over a meaningful number of sessions and the paper behaviour is broadly consistent with the backtest. There is no magic number of days, and anyone who gives you one without context is guessing. Go live with a size you could lose entirely without it changing your life, with hard limits built in: a maximum daily loss, a maximum position size, and a kill switch you have tested.
Treat the first live weeks as a test of execution, not of profit. Compare each live trade with what the paper system would have done on the same signal. The gap is your real cost of trading, and it is information you cannot get any other way.
Comparing the two at a glance
| Paper trading | Live trading (small size) | |
|---|---|---|
| Money at risk | None | Real, deliberately limited |
| Tests code and logic | Yes | Yes |
| Tests real fills and slippage | Only as well as the simulator models them | Yes |
| Tests costs | Only if you add them | Yes |
| Tests your discipline | No | Yes |
| Best used for | Debugging and rehearsal | Measuring real execution |
Common mistakes
- Treating a good paper run as validation of the strategy. It validates the plumbing.
- Going live at full size after a short paper run. Scale gradually, and only when live results match expectations.
- Ignoring legal and broker rules. Automated trading in India has its own rules on how orders may be placed; see our guide to whether algo trading is legal in India before you automate.
- Changing the strategy after every losing day. One bad day is expected noise. Decide in advance what evidence would actually mean the strategy is broken.
Where this fits in a build
A sensible sequence is: write the rules down, backtest with costs and out-of-sample data, paper trade to prove the machinery, then go live small and scale slowly. If you are planning an automated system and want to talk through the stages, see the services and process on this site.
Sources
The only legal point here is the summary of Indian rules in the linked guide, which lists its own primary sources. Statements about simulator behaviour are deliberately general; check the documentation of the platform you use for its exact fill and cost rules.
This article is general information, not legal or financial advice.