Devin Hartcastle
At the end of a bad week, a trader studies a dashboard showing a sharp equity drop, several rejected orders and a position that does not match the strategy log. The bot is still running. A red "stop" button is visible, but it is unclear whether it will cancel working orders, close positions or only block the next signal.
That uncertainty is the design failure. A kill switch is not a button or a single percentage. It is a defined set of trip conditions, actions and checks that moves the account from trading to a known state.
Separate the trigger from the action
Many implementations disable signal generation and call the job done. That can leave resting orders in the book, partially filled orders in flight and positions exposed to further price moves. A process restart may even re-enable trading before the account has been reconciled.
Model the switch as a state machine. A trip should persist a latched state, stop new order intent, cancel working orders and verify the broker's view of orders and positions.
Flattening is a separate policy decision. It may be appropriate for a simple directional strategy, but can create worse exposure in a hedged or partially filled portfolio.
Use distinct states rather than one boolean: normal, risk-reducing, halted and recovery-pending. Risk-reducing permits only actions that reduce exposure, such as cancelling an entry or submitting a bounded close order. Halted rejects all strategy orders. Recovery-pending requires reconciliation and an explicit operator or controlled policy decision before new risk is allowed.
The figures below are typical design ranges, not universal limits. They need adjustment for instrument liquidity, strategy horizon, use and venue behaviour.
| Signal | Typical trip range | Initial action | Trade-off |
|---|---|---|---|
| Daily loss, including unrealised P&L and fees | 1-3% of account equity | Block new risk; cancel entry orders | Fast protection, but sensitive to mark-price noise |
| Peak-to-trough drawdown | 5-10% from a defined high-water mark | Halt strategy and require review | Captures sustained deterioration, but reacts later |
| Market data age for liquid instruments | 1-5 seconds beyond expected update cadence | Block orders that depend on the feed | Reduces stale-price execution; can trip during feed jitter |
| Order rejects | 3-5 rejects in 1 minute | Stop submissions and inspect rejection codes | Limits retry storms; isolated venue issues may cause a false trip |
| Position mismatch | Any unexplained difference beyond a defined lot or contract tolerance | Freeze and reconcile against broker state | Protects against hidden exposure; requires reliable position data |
Trip on measurable signals, not dashboard colour
A useful condition names the metric, its source, its window and the action that follows. "Market looks abnormal" cannot be tested. "Reject rate exceeds four orders in sixty seconds, excluding known post-only rejections" can.
Track account-level risk as well as strategy-level risk. A single bot may stay within its limits while several bots together exceed buying power or concentration limits.
Compute loss from broker-reported positions and marks where possible, and include fees and funding. A strategy's internal ledger can lag fills or miss manual account activity.
- Exposure: set gross notional, net exposure and per-instrument caps. Typical limits may sit between 1 and 3 times equity for gross exposure in a low-leverage design, but strategy and product rules matter.
- Execution health: monitor acknowledgement latency, reject codes, cancel latency and the age of the last confirmed order state. A 2-5 second acknowledgement timeout is a common starting range for liquid API workflows, not a reason to resend blindly.
- Data quality: detect stale timestamps, crossed or invalid books, sequence gaps and missing heartbeats. A connected socket does not prove that its market data is current.
- System health: trip on failed reconciliation, repeated exceptions or an unhealthy clock. If the risk process cannot calculate exposure, fail closed rather than treating missing values as zero.
Use windows and hysteresis to avoid flicker. A short breach can trigger an immediate block on new entries, while a sustained breach can trigger a full halt.
Do not let a metric fall just below its threshold and automatically restart the strategy. Require a recovery condition, such as clean reconciliation for several consecutive checks, and keep the halt latched meanwhile.
Make the stop execute in a safe order
Kill-switch actions race with exchange events. A cancel request can arrive after an order has filled; a close order can then overshoot. Treat every action as asynchronous and reconcile from authoritative order and position updates before advancing.
One workable sequence is:
- Latch the trip. Persist the reason, timestamp, triggering values and strategy version. All order-producing workers must read the same halted state.
- Block new risk. Reject queued strategy intents and stop schedulers from producing replacements. Keep the risk controller available to send permitted cancellation or reduction orders.
- Cancel working orders. Send cancels, then poll or subscribe for terminal states. Do not assume a successful cancel response means the order did not fill.
- Reconcile exposure. Query open orders, fills and positions. Compare venue state with the internal ledger and account for partial fills before calculating any close quantity.
- Apply the configured policy. Hold, reduce or flatten according to the strategy's approved rule. Use bounded order sizes and price protections; verify each result instead of launching an unbounded retry loop.
Make each command idempotent where the API permits it. Give close and cancel workflows stable identifiers, record attempts and cap retries. If the broker is unreachable, the system cannot promise that exposure is flat. It can promise to stay halted, alert the operator and retry reconciliation under a controlled schedule.
Run these transitions in an environment that models delayed acknowledgements, partial fills and rejects. Agentic paper trading at FX-Tech.ai can help exercise order-state logic before live deployment, but a paper venue cannot establish how a particular broker behaves during an outage.
Test the failure path and the recovery path
A dashboard test proves that a button changes colour. It does not prove that every worker stops sending orders, that a cancel race is handled or that the process stays halted after a restart. Inject faults into the components that can invalidate the risk calculation.
- Delay or drop order acknowledgements, then verify the system does not duplicate submissions.
- Return a partial fill during cancellation and check that the close quantity uses the new position.
- Freeze market data while the connection remains open, and confirm the stale-data trip blocks dependent orders.
- Make the broker position disagree with the internal ledger, then verify that recovery remains blocked until reconciliation succeeds.
- Restart the strategy and risk service after a trip. Confirm the latched state survives and no startup routine clears it.
Log the trigger value, threshold, data timestamp, affected orders, broker responses and final position. Page on the trip and on failure to complete its actions. Test recovery separately: the operator should see why the switch fired, what remains live, what is uncertain and which checks must pass before the system can resume.
This design does not apply unchanged to strategies whose risk depends on maintaining paired legs, such as some market-making or hedged arbitrage systems. Flattening one leg can increase net exposure. Those systems need strategy-specific unwind rules, with explicit limits for the risk created while the pair is incomplete.
Frequently Asked Questions
What should trigger a trading kill switch?
Use measurable conditions such as loss limits, exposure caps, stale market data, repeated order rejects or a mismatch with broker positions. Define the data source, time window and resulting action for every trigger.
Should a kill switch automatically close every position?
Not always. Cancelling new risk and flattening existing exposure are different actions, and closing can worsen risk in a hedged or partially filled strategy. Set the response policy for each strategy and verify fills before sending further orders.
How can I stop a kill switch from tripping on temporary noise?
Use time windows and separate thresholds for an initial block and a full halt where appropriate. Keep the halt latched after a trip, then require clean data and successful reconciliation before recovery.
What should happen if the broker API is unavailable during a trip?
Keep the system halted and do not report positions as flat without confirmation. Record the uncertain state, alert an operator and retry reconciliation under a bounded schedule.
