Paper trading tests your plumbing against the live feed, which is genuinely valuable and catches a class of bug no historical backtest can. What it cannot test is anything downstream of an order actually reaching the exchange — and that is where most go-live incidents live.
The eleven checks
Decision funnel
Five gates between a paper signal and live capital
The eleven checks cluster into progressively harder evidence: software stability, independent controls, broker failures, emergency recovery and live approval.
First prove a full paper session is stable and observable. Then prove independent position, loss and kill controls. Next force broker rejection, token expiry, websocket reconnect and margin paths. Then execute the manual rollback and live kill drill. Finally require a named go-live review before enabling one-lot production.
A failed gate sends the system back to paper mode. “Known issue” is not a pass condition when the issue affects position truth or emergency control.
In order. Each one is a gate — do not proceed past a failure by noting it as a known issue.
Before the first live order
A full session of paper trading with zero unhandled exceptions
Not "zero crashes". Zero exceptions in the log, including the ones you caught and swallowed. A swallowed exception is a code path you have not read.
Position limits enforced at a gate outside the strategy
And verified by deliberately asking for a position that breaches them. An untested limit is a comment.
External kill switch, fired against a real open position
One lot, quiet afternoon. It must cancel open orders, flatten from the broker's reported position, verify flat, and stay disabled until re-enabled by hand.
Reconciliation script that compares system, broker and fill-sum positions
Run it at the end of the paper session. It should already agree, which tells you the comparison logic works before you need it.
Margin headroom computed for the worst intraday case
SPAN and exposure requirements move with volatility. Size assuming the requirement rises, not assuming it stays where it was at 09:20.
Every broker rejection reason mapped to a defined response
Insufficient margin, invalid order, rate limited, session expired, market closed. Each needs a decision: retry, resize, or stop. "Log and continue" is not a response.
Session token renewal tested, including the failure path
Most Indian broker APIs expire the token daily. Know what happens at 09:14 when renewal fails, and make sure it is not "place no orders and alert nobody".
Websocket reconnect tested by killing the network mid-session
Verify it resubscribes to the full instrument list, and check whether ticks during the gap are replayed or lost. Mark the gap either way.
Alerts that fire on silence, delivered somewhere you will see them
A log file you check in the evening is not an alert. Feed heartbeat, strategy heartbeat, reconciliation mismatch, rejection rate.
A written rollback: how you stop everything and go flat, by hand
Assume all your automation is unavailable. The steps should be short enough to execute while stressed, and you should have done them once.
What changes when the orders are real
System architecture
The exchange boundary introduces six new realities
Paper and live share data and signal logic; they diverge where an order meets the broker, exchange, margin system and order book.
The same feed and strategy send intent into either a paper simulator or a live broker path. The simulator applies assumed fills and unlimited synthetic margin. The live path encounters real spread and depth, partial fills, broker rejection rules, finite changing margin, network latency and an external broker position record. Reconciliation compares the two paths and attributes expected versus unexplained differences.
Keep a shadow paper instance beside live. Differences caused by fills and fees are expected; differences in signals or intended positions are bugs.
Behaviour
Paper
Live
Fill price
Whatever you modelled
Whatever the book offered
Partial fills
Usually not simulated at all
Regular, and the main source of unbalanced legs
Order rejections
Rare or absent
Margin, band, freeze quantity, session
Margin
Unlimited
Finite, and it moves intraday
Latency
Ignored
Adds to slippage, worst when it matters most
Position truth
Your own record
The broker's record, which may disagree
Paper trading versus live, for the same strategy
Structuring the first month
Timeline
A first month designed to expose operational risk
Supervision decreases only after evidence accumulates; size remains at one lot until the review is complete.
In week one trade one lot under continuous supervision and observe real order outcomes. In week two remain supervised and reconcile every day. In week three step away from the screen and rely on alerts while retaining one-lot size. In week four compare slippage, rejects, reconciliation and per-trade distributions. Only after a clean review may size increase.
A profitable week does not advance the timeline. Clean controls, explained execution and reliable alerts do.
The objective of month one is to find operational bugs, not to make money. Size accordingly: one lot, or the minimum the contract allows, regardless of account size. A profitable first month at one lot tells you nothing statistically; a clean first month at one lot tells you the system works.
1
Week 1 — supervised, one lot
You are watching the screen. Goal: see a full range of order outcomes, including at least one rejection and one partial fill. If you have not seen a rejection, you do not yet know how the system handles one.
2
Week 2 — supervised, reconcile daily
Still one lot. Run reconciliation at the close every day and investigate any mismatch, however small. A one-lot mismatch is the same bug as a fifty-lot mismatch.
3
Week 3 — reduce supervision, keep alerts
Step away from the screen and rely on the alerts. This is the real test of the monitoring, and the point where "alert on silence" earns its place.
4
Week 4 — review, then decide about size
Compare realised slippage against the backtest assumption, count rejections by reason, and check that live P&L per trade is inside the range the backtest predicted after costs.
5
Only then, scale size
Size, not strategy count. Adding a second strategy before the first is understood means two sets of unknowns interacting.
1 lot
Month one size
Independent of account size
≥ 1
Rejections you should have seen
Before removing supervision
Daily
Reconciliation frequency
Every session, without exception
The go/no-go review
Decision tree
One unexplained control failure overrides profit
Scaling requires both operational integrity and execution economics inside the modelled range.
First ask whether any reconciliation mismatch remains unexplained. If yes, stop. If no, ask whether rejection paths were all classified and handled. If no, hold at one lot and fix them. Then compare realised slippage and per-trade P and L distribution with the backtest range. If materially outside, hold or redesign. Only when all checks pass should size scale gradually.
Total month P&L is intentionally absent from the first gates. Profit can coexist with a control defect that becomes catastrophic at larger size.
At the end of the month, four numbers decide whether to scale, hold, or stop. Write them down before you look at the P&L, so the P&L does not colour the interpretation.
Realised slippage versus assumed. If realised is materially worse, the backtest edge was overstated by that difference on every trade.
Rejection count by reason. Any reason you had not anticipated is an unhandled path, whatever the outcome was this time.
Reconciliation mismatches. The acceptable number is zero. One unexplained mismatch means stop.
Per-trade P&L distribution versus backtest. Not the total — the distribution. A matching mean with a much wider spread means the fill model is wrong.
A first live month that made money and had an unexplained position mismatch is a failed month. The mismatch will recur, and next time it may not be one lot.
Frequently asked questions
What can paper trading not test?
Anything downstream of an order reaching the exchange: actual fill prices, partial fills, order rejections for margin or price bands, finite and intraday-varying margin, latency, and whether the broker's position record agrees with yours. Paper trading is valuable for validating the feed handler, signal timing, uptime and logging, which a historical backtest cannot test either.
How large should my first live position be?
One lot, or the minimum the contract allows, regardless of account size. The objective of the first month live is to find operational bugs, not returns. A profitable month at one lot is statistically meaningless; a clean month at one lot tells you the system works.
How should an automated strategy handle a partial fill on a multi-leg position?
With a rule decided in advance. A partly filled multi-leg position is a different position, not a smaller one — a short strangle with one leg filled is a naked short option. Either complete the missing leg at market or unwind what filled; both are defensible, but the decision must exist in code before it is needed.
What should I review after a first month of live trading?
Four numbers: realised slippage against the backtest assumption, order rejections grouped by reason, the count of reconciliation mismatches, and the per-trade P&L distribution against what the backtest predicted after costs. Write them down before looking at total P&L so the result does not colour the interpretation. An unexplained reconciliation mismatch means stop regardless of profit.
Should I keep paper trading after going live?
Yes. Running the same strategy in paper mode alongside the live instance gives you a reference. When the two diverge by more than fills and costs, there is a bug in one of them, and having both makes it much easier to determine which.
QK
QuaTick Risk Desk
Risk & compliance
Position sizing, margin mechanics, kill switches and the operational controls that decide whether an automated book survives a bad week.