It is Friday afternoon. A developer is looking at a dashboard after a bad week: the strategy is down, a broker connection dropped twice, and the position shown in the agent does not match the account. The agent is still submitting orders. A kill switch should have stopped that sequence, but only if its trip conditions and actions were defined before the week began.
Define what the switch stops
"Stop trading" is not a sufficiently precise instruction for software. A kill switch can block new orders, cancel working orders, reduce or close exposure, disable a strategy, or halt every strategy using an account. These actions have different risks. Cancelling an entry order is usually straightforward. Sending a market order to flatten a position can lock in a loss, cross a wide spread or add exposure if the position data is wrong.
Write down the action for each trigger. A practical default is to block new risk first, cancel outstanding orders next, and leave existing positions untouched until a separate, verified risk process decides what to do.
If the system must flatten, specify order type, price protection, maximum size and what happens if the close order is rejected. Do not make "flatten everything" the universal fallback.
For each strategy and account, document:
- Which process can trip the switch, including a risk monitor outside the strategy process.
- Whether the scope is one symbol, one strategy, one account or all connected accounts.
- Which orders are cancelled, and whether cancel acknowledgements must arrive before further action.
- Who or what can re-enable trading, and what evidence is required first.
Keep the emergency path independent of the model or strategy code it controls. A process crash, stuck event loop or exhausted API connection must not take out both trading and the mechanism that stops it.
Set measurable trip conditions
Choose thresholds against the strategy's normal behaviour, venue limits and risk budget. Use rolling windows as well as hard session limits.
A threshold that is too tight can halt ordinary trading during volatility; one that is too loose may detect trouble only after the account has accumulated unwanted exposure. The ranges below are typical starting points for liquid automated strategies, not universal limits or audited results. Calibrate them with your own order rate, product and venue.
Loss and exposure
Set a hard loss limit for the account or strategy, and a separate limit for gross or net exposure. Calculate loss from a defined reference, such as start-of-session equity, and include realised and unrealised P&L, fees and funding where relevant. Specify how deposits, withdrawals and transfers affect the reference. Without that rule, a restart can quietly reset the loss counter.
| Condition | Typical starting range | First response |
|---|---|---|
| Session loss | 0.5% to 2% of allocated strategy capital | Block new risk, cancel entries and alert an operator |
| Stale quote or book | 2 to 5 seconds for liquid intraday trading; longer for slower strategies | Pause orders that depend on that feed |
| Order rejection rate | 5% to 10% across 20 to 50 recent submissions | Pause submissions and classify venue errors |
| Position mismatch | Any unexplained difference beyond one lot or the venue's rounding tolerance | Block the affected symbol and reconcile from broker data |
| Order submission rate | Strategy-specific cap, often 2 to 10 new orders per second | Throttle or stop the strategy before venue throttling |
Treat these numbers as thresholds to investigate, not plug-in defaults. A market-making strategy can make dozens of legitimate order changes in a second, while a slower signal strategy may need only a few. Use an exposure limit based on what the account can actually carry, not simply a maximum order quantity.
Data, execution and state
Trip on conditions that invalidate the agent's view of the market or its own orders. Examples include a feed heartbeat missing, a sequence gap that cannot be repaired, a broker acknowledgement timeout, repeated rejects, or an order left in an unknown state. Track age of data at the point the strategy uses it, not just the timestamp received by a separate collector.
Position drift needs its own rule. Compare broker positions and open orders with the agent's internal ledger after fills, on reconnect and on a periodic schedule. If the broker reports a fill that the agent missed, continuing to trade from the stale internal position compounds the error. Block new orders for that symbol or account until reconciliation succeeds.
Decide which conditions cause a warning, a scoped pause or a full account halt. A single delayed quote can justify pausing one instrument.
A failed account-wide position check may justify blocking every strategy on that account. Log the trigger value, threshold, source timestamp and action taken so the event can be reconstructed from machine-readable records.
Make the stop reliable and testable
Separate detection from action
The risk monitor should receive independent market, order and position state where possible. Give it hard limits that strategy configuration cannot raise.
Use idempotent stop commands: retrying the same halt must not create duplicate close orders or undo an earlier block. Protect the control channel with authentication and record every state change.
Model the switch as explicit states, for example armed, tripped, cancelling, halted and awaiting operator reset. A timeout is not proof that an order was cancelled. Query the broker for its current status, and keep the symbol blocked while an order remains live or unknown. On reconnect, reconcile open orders and positions before returning to armed state.
Be clear about what happens when the risk monitor itself fails. For unattended trading, a missed heartbeat from the monitor should usually fail closed: the execution service refuses new orders. This reduces availability, but avoids running without the control intended to contain errors. If a venue offers native notional or order-rate limits, configure them too. They are a separate layer, not a substitute for the agent's controls.
Run failure scenarios in a paper environment such as Agentic Trading Index's agentic paper trading. Simulate a stale feed, a burst of rejects, a lost acknowledgement, partial fills during cancellation and a reconnect with mismatched positions. Check both the expected halt and the cases where the agent should continue. A test that only proves the button works says little about whether the right trigger fires.
Run this week's kill-switch checklist
Do not start by tuning every threshold. First make the system observable enough to distinguish a safe stop from a silent failure. The checklist below fits a small service or a multi-strategy account, provided each item has an owner and a recorded result.
- List every process that can submit, amend or cancel orders. Identify which one can stop each process without relying on its strategy loop.
- Choose one hard loss limit, one exposure limit, one stale-data limit and one position reconciliation rule. Write the measurement window and reference value beside each threshold.
- Define the response for each trigger: block new orders, cancel working orders, pause a symbol or halt an account. State explicitly whether any trigger can send an order to flatten.
- Set order-rate and reject-rate limits using recent normal traffic. Add a warning below each hard stop so the operator can see a deteriorating connection before the circuit trips.
- Inject at least three failures in a test environment. Verify broker-side order status after cancellation, confirm that duplicate stop requests are safe, and check that a restart does not reset loss counters.
- Review the alert path. The alert should include account, strategy, symbol, trigger, observed value, threshold and current switch state. A notification without those fields makes diagnosis slower.
- Test re-arming. Require position and order reconciliation, a healthy data heartbeat and an authorised reset. Record who reset the system and why.
Keep a brief runbook next to the control, including the broker's status-check method and a manual contact path. On a live account, first test the switch with order sizes and limits small enough that a defect cannot create an outsized position. Then increase scope only after logs show the expected transitions.
This week, implement and test one independent kill path that blocks new orders when position reconciliation fails.
Frequently Asked Questions
What should a trading kill switch do first?
A common first response is to block new risk and cancel outstanding entry orders. Keep existing positions open unless a separate, verified rule defines how to reduce or close them.
Should a kill switch automatically flatten positions?
Not by default. A flattening order can incur slippage or increase exposure if position data is wrong, so define the order type, size limits and rejection handling before enabling it.
How often should an automated trading system check position mismatches?
Check after fills and reconnects, then run periodic reconciliation at an interval suited to the strategy's order rate. Block new orders while an unexplained mismatch remains.
