Paper Trading Bot Operations
The hardest part of paper trading is not keeping a loop alive. It is proving that the loop still represents the strategy that earned promotion in research.
Operations should make that proof routine. The core tools are promotion gates, launch contracts, parity checks, dry-run smoke runs, limited paper loops, kill switches, and daily review.
Promotion ladder
Use the same ladder for every candidate:
- Local targeted test gate.
- Clean workspace or clean environment check.
- Import-origin preflight so the runtime loads the expected package.
- Historical parity replay on benchmark sessions.
- In-session dry-run smoke.
- Limited paper loop.
- Daily review before changing scope or risk.
The point is repeatability. If one candidate gets a stricter route than another, the comparison is less useful.
Parity checks
Parity checks replay known sessions and compare the live-style path against the formal backtest path. They should answer:
- Did the paper runtime see the same setup?
- Did it select the same option contract family?
- Did timing rules match the historical config?
- Were quote and microstructure filters applied consistently?
- Did the formal backtest reject a trade that the live route would have opened?
- Did the live route reject a trade the formal backtest expected?
A mismatch is not automatically bad. It is evidence that needs classification. For example, a quote-side rejection can be a valid realism improvement, while an entry-timing mismatch may mean the paper bot is no longer testing the same strategy.
Dry-run smoke
Before running a paper loop, run one dry-run cycle against live data. The smoke should prove:
- credentials are configured without printing secrets
- market data requests work
- broker account lookup works or is safely stubbed
- selected artifact paths are writable
- state, trade, funnel, and execution logs can be created
- no duplicate-entry state exists from a prior run
- kill switch baseline is available if enabled
The smoke command should come from the launch contract, not from a manually assembled shell command.
Paper loop
A paper loop normally polls live data on a fixed interval. The loop should:
- load the launch contract
- load existing state
- fetch current market data
- evaluate the strategy profile
- update the daily funnel
- close due positions before opening new ones
- evaluate kill switch and daily loss cap
- block entries when risk controls require it
- select an option contract
- route entry or exit orders through a broker adapter
- append immutable trade and execution rows
- write state atomically
If the bot supports baskets, each symbol should have isolated state, trade, and funnel artifacts. A multi-symbol paper loop should not let one symbol corrupt another symbol's session state.
Risk controls
Paper bots need risk controls even though no real money is allocated. The controls validate the operational behavior that would matter later.
| Control | Purpose |
|---|---|
| Max trades per day | Prevent runaway repeated entries |
| Duplicate-entry guard | Prevent one signal from opening multiple positions |
| Option premium stop | Exit when the option leg violates the profile risk rule |
| Kill switch | Stop or flatten when live paper performance diverges from a baseline |
| Daily loss cap | Stop or flatten after realized paper loss exceeds a configured threshold |
| Expiry cutoff | Force close near expiration when the profile requires it |
| Quote freshness | Reject stale markets instead of pretending the mid is tradable |
Each control should write both a machine-readable reason and a human-readable review clue.
Order routing
Marketable limits are usually safer for paper validation than unconditional market orders because they expose quote quality and fill behavior.
A bounded routing policy should define:
- entry order type
- exit order type
- initial limit price
- cross-spread fraction
- absolute cross cap
- timeout
- poll interval
- maximum reprices
- entry fallback
- risk-exit fallback
- maximum allowed spread or slippage
One common pattern is conservative entries and more aggressive risk exits: skip an entry if the marketable limit cannot fill, but allow a documented fallback for stops, kill-switch flattening, or expiry risk.
Daily review
Every session should end with a short review. The checklist should cover:
- opened trades versus expected trades
- no-trade symbols and the rejection reason
- parity mismatches
- contract mismatches
- quote rejects and spread failures
- broker rejects or stale orders
- duplicate-entry prevention
- open positions and forced closes
- kill-switch state
- daily loss-cap state
- whether the trade set still fits the intended portfolio role
This review is the difference between paper trading as observation and paper trading as validation.
Observability
Minimum useful observability:
- one daily funnel row per symbol or sleeve
- immutable trade rows for entries and exits
- execution rows for order attempts and fallback decisions
- state snapshots with active and closed trades
- named rejection counts
- broker reconciliation summary
- review markdown for each session
Do not judge a paper bot only by paper PnL. Judge it by whether it can explain every trade, every no-trade, and every risk-control decision.