Automated Strategy Risk Checklist

A kill switch is a mechanism that immediately cancels all open orders and halts new signal processing when triggered. It is the most important control because every other risk limit assumes the strategy code itself is operating correctly. If the code enters an unexpected state, an infinite loop, a corrupted variable, a mistaken signal, the kill switch is the only thing that stops it. Kill switches should be testable without placing real orders and reachable via a method independent of the main strategy process (a separate process, a network endpoint, or even a hardware interrupt). A kill switch that has never been tested in a realistic scenario should be treated as if it does not exist.

A common starting point is to set the daily loss limit at two to three times the expected average daily loss from backtesting. For example, if the backtest shows an average losing day of $200, a daily loss limit of $400-$600 would stop the strategy on a 2-3 standard deviation bad day without triggering on normal variance. The limit should also account for the maximum realistic drawdown in a single session from a flash crash or major news event. For new strategies, start conservatively, a daily loss limit that is too tight is correctable; a strategy that blew through a large daily loss on its first week is not.

Paper trading validates the mechanics, order routing, position tracking, fill handling, error recovery, but does not replicate live execution quality. Paper fills are typically simulated at the last trade price or mid-quote with no market impact or queue position modeling. Slippage, partial fills, and order rejection rates in live markets are consistently worse than paper trading suggests, especially in thinner or faster-moving instruments. Paper trading is necessary but not sufficient: use it to confirm the strategy works mechanically, then validate execution quality by starting live with a small fraction of the intended capital before scaling.

A runbook should enable someone with general technical knowledge, not necessarily the strategy's author, to safely operate or shut down the strategy in an emergency. At minimum it should cover: the exact command or URL to trigger the kill switch; how to verify all orders are cancelled at the broker; how to query current positions and P&L; how to manually close a position at the broker if the strategy cannot; the contact list for the responsible party if the secondary operator cannot resolve the issue; and the steps to safely restart after an incident including position reconciliation. The runbook should be stored somewhere accessible independent of the trading server, a shared drive or printed copy, not only on the machine running the strategy.

Yes. Critical controls are not sized to capital or trade frequency, they exist because the failure modes they protect against (runaway loops, data feed outages, kill switch failures) can occur in any automated strategy regardless of how simple or slow it is. A strategy that trades once per day still needs a kill switch because a code defect can cause it to place the same order repeatedly without one. A strategy trading $1,000 still needs a daily loss limit because on a bad day it can lose more than intended. The implementation effort for Critical controls is usually low; the cost of omitting them is potentially unbounded.

At minimum, review the strategy's performance, error logs, and fill quality once per week during the first month of live trading, then move to bi-weekly once behavior is consistent with expectations. Outside the scheduled review, establish specific trigger conditions that require an immediate review: a new drawdown high, three consecutive losing days, any alert from the monitoring system, a broker platform update, a major market regime change (e.g. a sustained spike in VIX), or any change to the underlying data feed. A strategy that has been running quietly for months without review is accumulating undetected drift risk, not proving its robustness.

A hard limit stops activity automatically when it is breached and requires a deliberate human action to resume. A soft limit raises an alert and may reduce sizing but allows the strategy to continue. Hard limits belong on outcomes that are unacceptable regardless of explanation, such as a maximum daily loss or a position size ceiling. Soft limits suit conditions that are usually explainable but worth knowing about, such as elevated rejection rates. Making a limit soft because a hard stop would be inconvenient defeats its purpose.

Without live history there is no reliable distribution to size against, so limits are set from what is tolerable rather than from what is expected. Choosing a loss level that would be acceptable if it occurred on the first day, and a position size small enough that a modeling error is survivable, avoids anchoring on backtested statistics that may not hold. Limits can then be widened as live data accumulates, which is a safer direction of adjustment than starting wide and tightening after a loss.

Any control implemented inside the strategy stops when the strategy stops, which is precisely when resting orders may still be live at the venue. Controls that survive the process include venue-side or broker-side order cancellation on disconnect, account-level position and loss limits configured with the broker, and an independent monitor that can act on the account without the strategy running. Identifying which items on a checklist depend on the process being alive is what separates real coverage from apparent coverage.