You see the same shape in nearly every paper-trading setup: an API accepts an order, a status says filled, and the account balance changes. That proves the request path works. It does not prove the strategy could have traded at that price, size or time on the live venue.
For software placing orders without a human watching, paper trading is an execution test. Its value depends on how well it reproduces the venue's order lifecycle, market data, costs and failure conditions. Start with the mechanics most likely to change a trading decision, then measure what the simulator still leaves out.
Decide what the simulator must represent
A useful simulator has a clear scope. It may reproduce a broker's API and approximate the exchange, or it may model a particular venue's order book and fee schedule. Those are different tests. A broker sandbox often checks request formatting and account rules, while a venue-like simulator asks whether an order would plausibly have filled.
Write down the markets and order types the agent will use. A system trading liquid shares with small market orders has different requirements from one quoting futures or placing large limit orders in thin markets. The first version should cover the strategy's actual instruments, trading hours, tick sizes, minimum quantities, price bands and account permissions.
Separate facts from approximations. Tick size and session hours may be specified by the venue.
Queue position and market impact usually need an estimate. Record each approximation in configuration, not as an invisible assumption in code. This makes results easier to interpret when the model changes.
Platform capabilities vary. A comparison of agent trading platforms at fx-tech.ai can help identify which interfaces and testing environments are available, but the simulator still needs to be checked against the venue mechanics relevant to the strategy.
Model the order lifecycle, not just the response
Track every order through explicit states: submitted, acknowledged, open, partially filled, filled, cancelled, expired or rejected. Keep the broker's order identifier separate from the agent's client order identifier. The latter helps reconcile a timeout: the request may have reached the broker even when the response did not reach the agent.
Do not turn every accepted limit order into an immediate fill. A basic model should compare the limit price with subsequent market data, account for available displayed size, and leave the remainder open when only part of the quantity could trade.
A more demanding model estimates queue position from order-book updates. Level-one data cannot reveal the exact queue ahead, so mark that estimate as uncertain.
Market orders need a fill price based on available liquidity, not automatically the latest quote or last trade. For a buy, consume eligible ask-side size; for a sell, consume bid-side size. If the order quantity exceeds displayed depth, apply a documented rule for additional slippage or cap the simulated fill and leave the remainder unfilled.
Rejections are part of normal operation. Simulate invalid ticks, insufficient buying power, closed sessions, quantity limits, price collars and rate limits.
Preserve the original request, response, timestamps and state transitions. That record lets the operator distinguish strategy behaviour from simulator behaviour.
- Test duplicate submissions and delayed acknowledgements.
- Represent partial fills and cancellations racing with fills.
- Keep rejected orders in the audit trail rather than silently dropping them.
Make data and timing part of the test
Execution depends on what the agent knew when it acted. Store exchange event time, local receipt time and order submission time separately. A quote that arrived 300 milliseconds late can produce a different decision from a fresh quote, particularly in fast or thin markets. Replay should preserve the original ordering of events and the agent's observed delay.
Use the same market-data fields and update rules in paper and live modes where possible. A bar-based backtest cannot validate an agent that reacts to quote updates. If the live feed can drop, duplicate or arrive out of sequence, test how the software handles those conditions. Do not silently repair feed gaps in the simulator unless the live system performs the same repair.
Synchronise clocks and log timestamps in UTC, while retaining the venue's session calendar. Test opening and closing auctions, holidays, daylight-saving changes and overnight sessions if the strategy can trade through them. A simulated fill during a closed session is not a small accounting error. It can hide a broken schedule check.
Keep replay deterministic when debugging: the same market events, configuration and random seed should produce the same outcomes. For capacity tests, vary seeds and report a range instead of presenting one run as a forecast. The Agentic Trading Index paper-trading service starts at $9.99 a month; whichever environment is used, check its data coverage and execution assumptions before treating a paper result as evidence.
Put typical execution costs in the model
Costs can turn a plausible paper strategy into an unprofitable live one. The ranges below are typical market ranges for common instruments, not quotes for a particular broker or venue. Actual costs depend on instrument, account tier, order size, venue and market conditions. Spread and slippage are often stated in basis points, where 1 basis point is 0.01 per cent.
| Cost item | Typical range | What to model |
|---|---|---|
| Liquid equity spread | 1 to 10 bps | Buy at the ask and sell at the bid, unless the order rests and earns a fill. |
| Thin equity spread | 10 to 100+ bps | Use the instrument's observed spread, not a fixed market-wide value. |
| Market-order slippage | 0 to 5 bps for small liquid orders; 5 to 50+ bps in thin or stressed conditions | Vary by size, volatility, depth and time of day. |
| Equity commission | $0 to $0.005 per share, with venue and regulatory fees potentially additional | Apply the relevant account schedule and minimum charges. |
| Short borrow | About 0.25% to 20% annualised; hard-to-borrow names can exceed 50% | Accrue by holding period and model availability or recall where relevant. |
| Futures commission and fees | About $0.50 to $5 per contract per side, depending on product and account | Apply per contract and distinguish commissions from exchange fees. |
These costs do not all apply to every trade, and the ranges should not simply be added together. Model the charge at the point it occurs: spread and slippage on execution, commission per fill or contract, and borrow over time.
Record gross and net performance separately. Otherwise, a fee change can look like a strategy change.
Test the failure modes before trusting a paper result
Paper trading will not reproduce every live condition. The simulator may have no real queue competition, may not model hidden liquidity, and may treat market impact as a formula. It may also provide fills from data that the live account cannot access at the same speed. State these limitations alongside performance metrics.
Run fault tests as well as ordinary sessions. Disconnect the market-data feed, delay order acknowledgements, return rate-limit errors and restart the agent with open orders. Verify that the system reconciles positions and outstanding orders before submitting replacements. A paper environment that never produces these states can still be useful for strategy logic, but it cannot validate unattended recovery.
Compare paper and live execution only through a controlled rollout with strict size limits and independent risk checks. Track fill rate, fill delay, slippage against the decision-time quote, rejection rate, cancel rate and fees per unit traded. Break results down by instrument, order type, time of day and volatility. A single average can hide poor fills during the exact conditions the strategy targets.
Use a checklist before moving beyond simulation
Paper trading is a stage in testing, not permission to remove safeguards. Before enabling any live order path, an operator should be able to answer these questions from logs and configuration rather than memory.
- Define the scope. List instruments, sessions, order types, account rules and feed fields the simulator covers.
- Document assumptions. Mark queue position, impact, hidden liquidity and latency as measured, estimated or omitted.
- Exercise state transitions. Test partial fills, rejected orders, cancel races, timeouts, duplicate requests and restart recovery.
- Apply costs. Include spread, commissions, exchange fees, borrow and realistic slippage where they apply.
- Replay known events. Confirm event ordering, timestamps and agent decisions are reproducible from saved data.
- Set acceptance limits. Define tolerances for rejects, exposure mismatches, stale data and execution-cost drift before running tests.
- Keep an independent stop. Enforce position, loss and order-rate limits outside the strategy process, including a way to cancel open orders.
Start with a narrow strategy and one instrument. A smaller, well-instrumented test gives clearer evidence than a broad paper run with unrecorded assumptions. This week, run one replay that includes a partial fill, a rejected order and a delayed acknowledgement, then record where your simulator diverges from the venue.
Frequently Asked Questions
What is paper trading?
Paper trading simulates orders and account changes without placing trades with real money. For an automated system, a useful setup also models execution conditions such as partial fills, fees, order rejections and market-data delays.
Does paper trading guarantee the same fills as live trading?
No. A simulator usually cannot reproduce the exact queue, hidden liquidity, competition or latency of a live venue. It should disclose these limitations and model their likely effects rather than report every accepted order as a full fill.
How should a paper trading simulator model limit orders?
It should leave a limit order open until market events make a fill plausible, and account for available size and partial execution. Queue position is uncertain without detailed order-level data, so the simulator should label any queue estimate as an approximation.
Which costs should a paper trading system include?
Include the spread, commissions, exchange or regulatory fees, slippage and borrow costs where applicable. Apply them at the right point in the order lifecycle and report gross and net performance separately.
How long should an agent paper trade before going live?
There is no universal minimum period. Test enough sessions and market conditions to exercise the strategy's order types, failure handling and risk limits, then compare execution metrics against explicit acceptance thresholds before considering a tightly controlled live rollout.
