What is paper trading? How simulated fills flatter your results
Paper trading is running a strategy’s orders against a simulated account with virtual money, where a simulator — not a real market — decides whether and at what price each order fills.
That last clause is the whole concept. Everything a paper account reports, from the fills to the profit and loss, is the output of a set of fill rules someone wrote. This page explains how those rules usually work, how paper trading differs from a testnet and from a backtest, and how to adjust a paper record so it says something closer to what live trading would have. It is for anyone wiring an API integration or an AI agent to a practice account before going live.
Why this matters now
Paper is the standard first environment for a new integration, and for good reason: every order you get wrong there costs nothing. With language models placing orders through tools, it has become the default place to find out what the model actually does with an order tool — see practising on testnet before going live.
The risk is in what happens next. A paper account produces a balance, a win rate and an equity curve, and those numbers look exactly like live ones. They get quoted as evidence that a strategy works. A paper profit is evidence that the fill simulator was generous, until you have shown otherwise.
How it actually works
- A virtual account is created with a starting balance you did not deposit.
- Your orders go to the practice environment through the same kind of API calls you would use live — often the same specification, at a different host or with different credentials.
- A fill engine decides the outcome. In a paper environment this is a simulator reading real market data. In a crypto testnet it is usually a separate market with its own order book and its own participants.
- Positions, balances and P&L update as if the fills were real.
The two kinds of practice environment fail in different ways:
| Paper (simulator on real data) | Testnet (separate practice market) | |
|---|---|---|
| Prices | Real market prices | The testnet’s own, which can drift from the real market |
| Liquidity | Assumed by the simulator | Synthetic and often thin |
| Your order’s effect | Usually none | Real, on a book nobody relies on |
| What it tests well | Logic and workflow against real prices | Plumbing and order mechanics |
How each venue separates practice from live — separate host, separate credentials, or a header on the same host — decides how you can accidentally cross from one to the other, and is covered venue by venue in the testnet article above. For one venue in detail, see the Alpaca paper trading API.
The fill rules are the whole game
Find your simulator’s fill rules in its documentation before you trust any number it gives you. The questions that decide how optimistic it is:
- Market orders. Filled at the current quote, in full, with no market impact? A real market order of any size walks the book — see what is market depth.
- Limit orders: touch or trade-through? Filling a resting limit the moment price touches it is the most generous rule. In a real book you are in a queue behind everyone who was there first, and price can touch your level and leave without reaching you. A trade-through rule — filled only once price trades beyond your level — is closer to reality.
- Partial fills. Does a large order ever fill partially? If not, a whole category of order-handling code is going untested — see order lifecycle and partial fills.
- Costs. Are fees deducted? Funding on perpetuals? If either is missing, the paper P&L is gross.
- Stops. Does a triggered stop fill at the stop price, or at the next available price after it? Real stops fill after, and worst in fast moves.
Every one of these simplifications, where a simulator makes it, favours the paper result over the live one. The gap is not noise that averages out — it is a bias.
Paper trading vs backtests and forward tests
| Method | Data | Who decides fills | Main weakness |
|---|---|---|---|
| Backtest | Historical | Your simulation code | Look-ahead, overfitting, optimistic fills |
| Paper trading | Live, as it arrives | The venue’s simulator, or yours | Optimistic fills, no real stakes |
| Forward test, live | Live | The real market | Slow, and puts real money at risk |
Paper trading’s advantage over a backtest is that the data is genuinely unseen when the decision is made. For a language model that matters more than usual, because a model evaluated on history may already know what happened — see why AI backtests do not survive live trading. Its disadvantage is shared with the backtest: somebody else’s fill rules.
Worked example: adjusting a paper record
An illustrative paper record, measured in R multiples: 50 trades, 20 winners averaging +2.0R and 30 losers averaging −1.0R.
paper expectancy = (20 × 2.0 − 30 × 1.0) ÷ 50 = +0.20R per trade
Now apply three illustrative adjustments for things the simulator left out:
- Costs: 0.05R per trade for fees and spread on entry and exit. Your own figure comes from your fee rate and stop distance — the trading fee calculator gives the fee part.
- Stop slippage: a further 0.10R on each loser.
- Touch fills: 4 of the 20 winning limit entries were filled on a touch and would not have filled under a trade-through rule. Remove them.
winners: 16 × (2.00 − 0.05) = +31.2R
losers: 30 × (−1.00 − 0.05 − 0.10) = −34.5R
adjusted expectancy = −3.3R ÷ 46 trades ≈ −0.07R per trade
Each adjustment on its own leaves the record positive: costs alone take it to +0.09R, the fill correction alone to about +0.04R. Together they turn it negative. The adjustments above are assumptions, not measurements — which is the point. Until you have measured them, the paper figure is an upper bound with an unknown gap beneath it.
Where the boundary should sit
Use paper for what it tests well, and discount it for what it cannot:
- Treat paper as a test of the system, not the strategy. Authentication, order construction, error handling, reconciliation, your approval workflow, what an AI agent does with a bad instruction. Those results transfer.
- Report paper P&L with its fill rules attached, and re-run it with a trade-through rule and a cost haircut before drawing conclusions.
- Log intended versus simulated price on every fill. It is the same record you will need live to measure real slippage.
- Derive the environment from one setting. Host, credentials and any environment header should come from a single switch so they cannot disagree, and the process should log which environment it is running against.
- Expect yourself to behave differently with real money. Paper cannot simulate that, and it is worth knowing before concluding you are ready.
FAQ
What is paper trading?
Paper trading is placing orders against a simulated account funded with virtual money, so strategies and integrations can be run on live market data without financial risk. A simulator decides whether and at what price each order fills, which means the results depend on its fill rules rather than on a real market’s response to your orders.
Is paper trading the same as a testnet?
Not quite. A paper environment usually simulates fills against real market prices. A crypto testnet is typically a separate practice market with its own order book, synthetic liquidity and prices that can drift from the real market. Both avoid real money; they give different kinds of misleading results.
Why are my live results worse than my paper results?
Because the usual paper simplifications all favour you: market orders filled at the quote with no impact, limit orders filled the moment price touches them, stops filled at the stop price, and fees or funding sometimes left out. None of these errors runs the other way, so the gap is a consistent bias rather than random noise.
How long should I paper trade before going live?
There is no duration that makes a paper record reliable as evidence of profitability, because the fill bias does not shrink with time. Paper trading is complete when the integration behaves correctly — orders, errors, reconciliation and workflow — and when you have deliberately tested what happens with a bad order.