Last Updated: 2026-10-26
Automation can repeat a specified decision and record what happened. It cannot establish that the decision is profitable, make an unsupported strategy fit a platform, or remove execution and custody risk. Start by separating the rule from the machinery that submits it. This guide is an engineering checklist with synthetic arithmetic, not a live-trading recommendation or a report of personal results.
Turn the idea into an execution contract
“Buy when RSI is low” leaves most of the behavior undefined. A teaching specification could say: evaluate RSI(14) on a completed four-hour candle; permit a long entry only above a separately defined daily moving average; allow one open position; and record two exit thresholds. Those parameters are arbitrary. They do not establish an edge.
Before testing, fill in the missing fields:
Scroll sideways to see every column. Keyboard: focus the table region and use the arrow keys.
| Field | Decision that must be explicit |
|---|---|
| Data | Venue, instrument, timezone, completed-bar rule, indicator calculation and warm-up history |
| Entry | Exact condition, permitted order type, price constraint and signal expiry |
| Quantity | Units versus notional, precision, minimum order size and total exposure limit |
| Exits | Partial quantities, stop versus stop-limit behavior, priority when conditions overlap |
| State | Existing orders, partial fills, manual trades and the rule for re-entry |
| Failure | Stale data, unknown submission outcome, disconnected stream and persistent halt |
Write down what should happen when there is no valid answer. “Skip and record the reason” is a useful result. Replacing missing data with the previous signal silently changes the experiment. Human judgment can remain a manual approval step, but then the system is partly discretionary; document that boundary.
Select a route that can express this exact rule
Scroll sideways to see every column. Keyboard: focus the table region and use the arrow keys.
| Route | Useful capability | Required check |
|---|---|---|
| Exchange-native bot | A supported grid, scheduled purchase or other predefined template | Does this product implement your entry, exit and inventory rules? What happens when it is stopped? |
| Third-party platform | Supported visual rules, alerts and order management | Which account permissions and plan features are needed? Which failures remain your responsibility? |
| Self-built executor | Explicit state and custom decision logic | Can you maintain reconciliation, precision, limits, retries, storage and monitoring? |
A grid is not a substitute for an RSI rule merely because both automate trades. Scheduled fixed-dollar purchases and an averaging-down bot with safety orders also have different capital paths. Match the actual implementation before comparing subscription costs. Native bots can avoid sharing a separate third-party trading key, but they retain account, platform, custody and configuration risks. Hosted status notifications are evidence to inspect, not proof that reliability work is complete.
For a self-built system, an API library can normalize some interfaces; it does not make every venue's order types, precision or failure semantics identical. Consult the CCXT manual and the selected venue's official order documentation for the exact version in use. No account connection or library execution is performed by this article.
Reconcile before retrying
Suppose a paper executor intends to buy ten units. Its submission times out. That does not mean the order failed: the server may have accepted it before the response was lost. Blindly submitting ten more can double the intended exposure.
Persist an intent identifier and the intended quantity before submission. Record the unknown outcome, then reconcile the venue's order and fill records using supported identifiers. A client order ID is useful only according to the venue's actual uniqueness and lookup guarantees. If three units filled and seven remain open, a second ten-unit order is not a retry of the same state. Cancellation can also race with fills; a cancellation request is not confirmation that exposure disappeared.
Keep signal time, input availability time, submission time and fill time separate. After a restart, load the durable halt and unresolved-order state before considering new signals. A healthy process with stale data or an unrecognized fill is still unsafe to treat as ready.
Calculate the quantities the marketing examples omit
Win rate needs a payoff distribution. In a synthetic 100-trade sample, 55 wins of $10 and 45 losses of $20 produce $550 minus $900: a $350 loss before costs. The 55% win rate alone proves neither profitability nor an appropriate position size. Smaller sizing can reduce some exposure, but it cannot turn negative expectancy into positive expectancy.
Grid inventory can lose while realized grid profit rises. Buy one unit at $100 and another at $80. The average purchase price falls to $90; it does not rise. At a current price of $70, two units are worth $140 against $180 spent: a $40 unrealized loss before fees. Track total equity, inventory and costs alongside completed grid cycles. A wider second grid adds a separate exposure; it is not automatically a hedge.
Costs use the relevant turnover. For $10,000 of filled notional on each side, a synthetic 0.05% entry fee and 0.05% exit fee total $10. If gross trading profit is $15, $5 remains before spread, slippage, funding or other costs. Do not subtract slippage again if the fills already include it. A subscription or data bill belongs in the same evaluation, with its allocation method recorded.
Establish controls before any execution decision
For a trading service, disable withdrawal permission unless a separately justified workflow explicitly requires it; a trading bot does not need withdrawal authority to place trades. Use the narrowest supported account scope, separate service keys and supported IP restrictions. A trade-only credential can still cause severe losses through malicious or oversized orders. Removing withdrawal permission is not an account-loss guarantee.
A halt should first prevent new risk-increasing intents and persist across restarts. Canceling orders and closing positions are separate operations with their own failure and price risks. A button labeled “flatten” cannot guarantee a fill or bounded loss during an outage. In paper tests, demonstrate partial cancellation, a fill arriving after a cancel request, a rejected close and an unavailable venue. Preserve unresolved states instead of reporting “all closed.”
Monitor different failures separately
Scroll sideways to see every column. Keyboard: focus the table region and use the arrow keys.
| Observation | What it can establish | What it cannot establish alone |
|---|---|---|
| Process heartbeat | A reporting path was alive at a timestamp | Fresh inputs, correct positions or a functioning order route |
| Data timestamp and sequence | The latest received input and detected gaps | That every upstream event was captured |
| Order/fill reconciliation | Agreement with the records checked at that time | Future availability or complete account history |
| Rejection and retry counts | A visible failure pattern | That an unacknowledged order never existed |
| Equity and exposure checks | Breach of defined observed limits | An enforceable maximum loss during gaps or custody failures |
An absence of trades can mean no signals, paused execution, stale data or a broken process. Make those states visible. Alert delivery also needs a test; a local log entry does not prove that someone received it.
Use evidence gates, not a calendar to live trading
First inspect a read-only or offline run against the written rule. Then test synthetic failures, retries, restart behavior and accounting. Keep a holdout period that was not used to tune the rule, and account for all known costs and open inventory. A paper or venue sandbox run remains a simulation with different liquidity and fill behavior.
The result may be “the rule is not specified,” “the platform cannot express it,” or “the state cannot be reconciled.” Those are reasons to stop the experiment. Passing the checks does not demonstrate future profits or authorize a live account. There is no fixed number of weeks after which an unproven bot becomes suitable for real capital.
For a complete offline state example, see persistent paper controls. For the broader responsibilities and failure boundaries, see system design. Use the backtest worksheet to inspect whether a simulator actually implements the same rule.
Risk and method: educational engineering examples only, not financial advice or a tested profitable strategy. Crypto trading can lose capital. This page contains no affiliate signup recommendation; other site pages may contain disclosed affiliate links.