Paper trading bot checklist: orders, failures and positions

A paper-trading bot is ready for review when you can explain its decisions, reconcile its virtual positions and demonstrate how it handles failures. A positive simulated balance is only one observation. Start the test with fixed rules, a realistic virtual budget and written acceptance criteria; keep every run, including those you would rather reset.

Paper trading can observe a strategy as data arrives, but fills remain simulated. Use it to test the process you can actually inspect. Do not interpret a clean paper run as proof that orders will receive the same prices or liquidity on an exchange.

Freeze the object you are testing

Save the strategy version, market, timeframe, parameters and cost model. Record the data source and whether it provides live, delayed or replayed observations. A manually updated price sheet and an incoming-data simulator answer different questions.

Choose a virtual balance similar to the budget whose behavior you want to understand. A large default balance can hide minimum-order and capital constraints. Record whether the simulator models fees, partial fills and available liquidity. Unknown assumptions should remain unknown in your report, rather than quietly becoming favorable ones.

If you change an entry or exit, start a new version. Keep the earlier record. A test that continuously edits away losses measures your intervention as well as the original strategy.

Reconcile one order across partial fills

Suppose an invented order requests 0.020 units. The simulator reports 0.008 filled at 50,000 USDT and another 0.007 at 50,010. Filled quantity is 0.015; the unfilled remainder is 0.005.

The weighted fill price is (0.008 × 50,000 + 0.007 × 50,010) ÷ 0.015 = 50,004.6667 USDT, approximately. Bought notional is 750.07 USDT. With a hypothetical fee of 0.10% paid in quote currency, fees total 0.75007 USDT, before any rounding convention.

Canceling the remaining 0.005 does not close the 0.015 already bought. A bot that records the requested 0.020 as its position will overstate exposure; one that records only the first fill will understate it. Keep requested, filled and canceled quantities separate. This exercise tests accounting consistency, not whether those fills would be available live.

Inject failures as well as normal signals

Build a small scenario list with an expected response for each case:

• A repeated signal arrives twice for the same candle.
• A connection drops after an order is submitted but before acknowledgment.
• Only part of the requested quantity fills.
• An order fails the venue's quantity or minimum-value filter.
• Price data becomes stale while a position remains open.
• The process restarts with an existing order and position.
• Two strategies attempt to use the same available balance.

An uncertain submission is especially important. A missing response does not always mean the venue rejected the order. In a test harness, verify status before deciding whether a retry represents a new action. Binance's API documentation explicitly distinguishes timeout uncertainty from a confirmed failure; other venues need their own implementation review.

Make Stop behavior observable

“Stop the bot” can mean pausing new entries, canceling pending orders or closing positions. Write these as separate actions. A button that stops the process may leave an exchange-side order active; a rule that closes a position may itself fail.

For your simulation, specify the expected state after each stop action and the recovery path after a restart. Test the case where the account state disagrees with the bot's local record. New entries should not continue on an unexplained mismatch. Preserve the discrepancy and escalate it for investigation.

Review evidence before changing modes

Keep a compact log: signal time, data timestamp, decision, requested quantity, simulated fill, costs, resulting position, error and version. Compare decision-by-decision behavior with a replay of the same period. Explain differences before interpreting aggregate profit.

Set operational criteria in advance: no unresolved duplicate orders, quantities reconcile, stale data blocks entries, and recovery scenarios produce the expected state. These are example acceptance criteria you can adapt, not a statistical proof of an edge. Duration and trade count depend on how often the strategy acts and which conditions it has encountered.

Our guide to trading modes explains the limits of this transition. Clerix presents a workflow from AI-assisted rules through Backtest and Paper to a robot and analytics. Public panels are illustrative, while testing engines and live execution are in development. Explore Clerix features with your checklist and confirm which parts are available before any account connection.

Questions about paper-test readiness

How many days should I paper trade?

There is no universal duration. Predefine the decisions, failure cases and market conditions you need to observe. A quiet week with no rejected orders cannot test rejection handling.

What if the simulator never produces partial fills?

Record the limitation. Use a controlled scenario or separate test harness if available. Do not claim partial-fill handling has passed because every simulated order filled immediately.

Does passing the checklist mean I should trade live?

No. It shows specific observed behavior under simulated assumptions. Real execution, account eligibility, available integration and willingness to bear losses require a separate decision.