One operator sees a paper order fill at the displayed price and approves the strategy for live trading. Another sees the same fill and blocks release because the simulator ignored queue position, latency and a competing order. Both are responding to the simulator they have, but only the second has asked whether it behaves like the venue.
For an agent placing orders without a human watching, paper trading is an execution test, not just a way to record hypothetical profit and loss. A 30-day build should reproduce the venue behaviours that can change an order's state, price or risk.
It will not reproduce every participant or market event. It should make its assumptions visible and fail safely when those assumptions stop holding.
Days 1 to 5: define what the simulator must reproduce
Start with one venue, one instrument family and a small set of order types. Write down the complete order lifecycle: submit, acknowledgement, open, partial fill, filled, cancel request, cancel acknowledgement, rejection and expiry.
Keep the agent's requested state separate from the broker's reported state. A cancel request is not a cancellation, and a timeout is not proof that an order was rejected.
Build the simulator around timestamped events rather than immediate function calls. Store the market-data timestamp, the agent's decision time, the send time, the simulated venue receipt time and each response time.
Use monotonic clocks for elapsed-time calculations. Preserve the original event sequence so a run can be replayed and compared after code changes.
Set a fidelity boundary in writing. For example, model the venue's supported order types and trading hours, but state whether queue position is estimated or omitted.
Define what happens when a quote is stale, data is missing or a price moves during submission. If the agent should stop under those conditions, encode that behaviour rather than quietly filling at the last known price.
Days 6 to 12: build order and market-data events
Connect the simulator to the same order-management interface the agent will use later. Avoid a separate paper-only shortcut. The agent should receive asynchronous acknowledgements and market updates, and should handle duplicate, delayed or out-of-order events. Give every client order a stable identifier. Make retries idempotent so a network timeout cannot turn one intended order into two live orders.
Use recorded market data where licensing and availability allow. Preserve bid and ask sizes, trades, session state and timestamps, not just candle closes. Candles cannot show whether a limit order had priority at the touch or whether the price moved through the queue. When replay data is unavailable, generate events with explicit rules and label those results as synthetic.
- Apply configurable delays to outbound orders, acknowledgements, market data and cancel requests. Sample from a distribution, not one fixed delay.
- Represent order state transitions explicitly. Reject illegal transitions, such as marking an order filled after a confirmed cancel unless a fill event arrived first.
- Keep separate logs for agent decisions, simulator events and calculated positions. Their differences are useful evidence during a replay.
By day 12, run the same input twice with the same random seed and confirm that the event sequence and resulting position match. Then vary the seed to test different delays and partial fills. Deterministic replay makes a failure debuggable; variation tests whether the agent depends on a lucky event order.
Days 13 to 18: model fills, costs and venue ranges
A limit order should not fill merely because its price touched the best bid or ask. Estimate queue position from displayed size ahead, trades at that price and cancellations, or use a conservative fill probability when the data cannot support a queue model. A marketable order should consume available depth, apply slippage and report partial fills if the book cannot cover the requested size.
Include commission, exchange or venue fees, spread, financing and borrow charges where relevant. Apply them at the correct event or accounting interval. A strategy that trades frequently can look profitable before costs and lose its edge after fees and spread. Keep each cost component visible so changing an assumption does not conceal the source of a result.
The figures below are typical market ranges across electronic venues, not guarantees for a particular broker. Instrument, session, order size, routing and market conditions can move them substantially. Use them to choose initial stress cases, then calibrate against the actual venue's data.
| Behaviour | Typical market ranges | Paper model starting point |
|---|---|---|
| Market-data age | About 10 to 100 ms for direct feeds; 100 ms to 1 s or more for aggregated feeds | Track feed age per update and reject decisions past a configured limit |
| Order acknowledgement | About 20 to 300 ms in ordinary conditions; 0.5 to 2 s or more during congestion | Use a latency distribution and test the long tail |
| Major FX spread | About 0.1 to 1.5 pips in active conditions; 2 to 10 pips or more around rollover or major news | Vary spread by session and volatility |
| Small market-order slippage | About 0 to 2 basis points in liquid conditions; 2 to 10 basis points or more in thin or fast markets | Consume book depth and add a volatility stress case |
| Cancel acknowledgement | About 20 to 500 ms on typical API paths, with longer delays possible | Keep the order exposed until cancellation is confirmed |
These are broad working ranges, not audited results for a named company. Record your own observed distribution when you have venue access. A hosted option such as Agentic Trading Index agentic paper trading starts at $9.99 a month; check that any external environment exposes the order and fill behaviour your agent needs before relying on it.
Days 19 to 24: inject failures and test recovery
Normal fills are only part of the test. Delayed responses and broken connections create ambiguous states, exactly where unattended software can duplicate orders or misstate exposure.
Inject faults deliberately, then check that the agent pauses, reconciles and resumes only from a known state. Do not treat an exception handler that logs an error as recovery.
- Drop an acknowledgement after the venue accepts an order. Confirm that the agent queries by client order ID before retrying.
- Delay a cancel acknowledgement while a partial fill arrives. Confirm that position and remaining quantity reflect both events.
- Send duplicate fills and out-of-order status updates. Confirm that the ledger applies each execution once and does not move an order backwards.
- Freeze market data, widen spreads and return rejects for invalid size, price increments or trading-session rules. Confirm that stale or rejected orders do not remain in the agent's working-order count.
Test account limits as well as individual orders. Reconcile cash, positions and open orders after each scenario. If internal state differs from the simulated venue, stop new submissions and run a defined recovery path. That path should identify the source of truth, fetch current state and alert an operator when the discrepancy cannot be resolved automatically.
Days 25 to 30: validate the gate for live operation
Run the agent against recorded sessions that include quiet periods, volatile moves, openings, closings and any relevant rollover. Keep strategy decisions fixed while comparing simulator versions. Measure order acknowledgement latency, fill ratio by order type, partial-fill frequency, slippage against the decision-time price, reject rate, cancel completion time and position-reconciliation errors. Report median and tail values, not just averages.
Set release criteria before reviewing results. A useful gate might require no unexplained position mismatch, no duplicate order after a retry, and acceptable execution cost under a defined stress case.
Set numerical limits from the strategy's risk budget and venue observations rather than borrowing a universal threshold. If the model consistently assumes better fills than recorded venue behaviour supports, adjust the model or reduce the strategy's size before progressing.
- Require a reproducible replay for every incident that changes order or position state.
- Compare simulated and observed event timing, including tail latency and stale-data frequency.
- Run a small, supervised live phase only after the paper gate passes, with hard order, position and loss limits in the live adapter.
Paper results cannot prove live performance. They can expose software defects and optimistic execution assumptions before those assumptions carry capital risk. This week, instrument one complete order path from agent decision through acknowledgement, fill or cancel, and position update.
Frequently Asked Questions
What should realistic paper trading simulate?
At minimum, model asynchronous acknowledgements, order-state transitions, partial fills, cancellation delays, rejects, spread and fees. Add queue position and depth-based fills when the available market data supports them. Make unsupported assumptions explicit.
How long should a paper trading test run?
A 30-day implementation can build and test the simulator, but the length of a strategy evaluation depends on its frequency and the market conditions it needs to encounter. Include different sessions and volatility regimes, and replay difficult periods rather than relying only on recent quiet data.
Why do paper trading fills differ from live fills?
Simulators often fill at a touched price without accounting for queue position, competing orders, latency or available depth. Live venues can also reject orders or delay acknowledgements. Model these effects and compare them with venue observations where possible.
Can a trading agent go live after passing paper tests?
A paper test can validate software behaviour under its model, but it cannot guarantee live results. Start with supervised live execution, conservative size and explicit order, position and loss limits. Reconcile broker state against the agent's ledger before increasing autonomy.
