A kill switch should not wait for a catastrophic loss.
For software placing orders without a human watching, it is a set of explicit conditions that move the system into a safer state. That may mean blocking new orders, cancelling working orders, reducing exposure or shutting down a strategy. These are different actions. A single emergency button that terminates a process can leave live orders at the broker and positions unmanaged.
Design the switch as part of the order and risk architecture, not as a last-minute command-line option. Each trip condition needs a measurable input, a threshold, a defined response and a reset rule. The numbers below are typical starting ranges, not universal limits. They need calibration against the instrument, strategy, account and venue.
Define what the switch does
Separate a trading halt from a position close. A halt blocks new risk while the system reconciles its state. A close attempts to reduce or flatten existing exposure, which can incur spread, slippage and fees. For a thin market or a venue outage, repeated market orders to flatten may increase losses rather than contain them.
Use a small state machine. For example, normal operation can move to restricted operation when a warning threshold is reached, then to halted operation when a hard limit trips. In restricted mode, the agent might cancel entry orders and allow only risk-reducing orders. A halted state should reject strategy-generated orders, even if a strategy process continues running.
Keep the risk decision outside the strategy process where practical. If the process placing orders also decides whether it is allowed to place them, a bug or runaway loop can bypass the control. A separate risk service, or a broker-side limit where available, creates another boundary. Broker controls vary, so verify their scope and behaviour instead of assuming they protect every order type.
Write down the response for each trigger. A price-feed fault might block new orders but leave existing protective orders intact. A daily loss breach might cancel entries and alert an operator, with flattening handled by a separate policy. Make the response specific enough to test in code.
Choose trip conditions that catch distinct failures
Use more than one kind of threshold. Loss limits catch adverse outcomes, while order and data limits catch faults that may not immediately show as losses. Measure realised and unrealised P&L together where possible. Otherwise, an agent can cross a limit on open positions while its realised-loss counter still looks safe.
Useful conditions include:
- Loss and drawdown: Compare intraday equity with a defined baseline, including fees and open-position marks. Use a separate limit for a strategy and for the account if several agents share capital.
- Exposure: Cap gross notional, net notional, use, instrument concentration and order size. Recalculate after fills, not only after order submissions.
- Order behaviour: Trip on an abnormal submission rate, repeated rejects, unexpected duplicate orders or a mismatch between requested and broker-confirmed quantity.
- Market data: Block new orders when quotes are stale, timestamps move backwards, required fields disappear or the spread exceeds a strategy-specific ceiling.
- Connectivity and reconciliation: Stop new risk when broker responses time out or local order and position state cannot be reconciled with the broker.
Make thresholds conditional on the market where that matters. A two-second-old quote can be stale for a fast, liquid instrument, while a slower instrument may tolerate a longer interval. A spread ceiling should account for normal spread variation and the strategy's expected edge, rather than using one value across every product.
Use ranges as starting points, then calibrate
The following are typical ranges used as engineering starting points. They are not audited results for any named platform or account.
Small accounts, leveraged products and strategies with tight risk budgets may need lower limits. Measure normal behaviour in paper trading and controlled live tests before setting production thresholds.
| Signal | Typical starting range | Measurement window | Possible first response |
|---|---|---|---|
| Intraday loss | 0.5% to 2% of allocated strategy equity | Realised plus unrealised P&L, reset at the trading-day boundary | Block new entries, cancel working entries, alert |
| Gross exposure | 1.0 to 2.0 times allocated equity, depending on mandate | Recalculate on every fill and position update | Reject risk-increasing orders |
| Quote age | 2 to 5 seconds for liquid instruments, 10 to 30 seconds for slower markets | At order validation, using exchange or vendor timestamps | Block orders that depend on the stale feed |
| Order rejects | 3 to 5 rejects in 10 to 20 consecutive submissions | Rolling count, separated by reject reason | Pause the affected strategy and inspect responses |
| Order submission rate | 2 to 5 times the strategy's expected peak rate | Rolling 1 to 10 seconds, with venue limits respected | Throttle or halt new submissions |
| Unreconciled state | One material position or open-order mismatch | After each broker update, with a short retry window | Block new risk until state matches |
Define the denominator and timing precisely. A loss of 1% of strategy equity could mean equity at the start of the day, at deployment, or current equity.
Those choices produce different limits after gains and withdrawals. For an intraday stop, a fixed start-of-day baseline is often easier to reason about than a moving denominator.
Set warning levels below hard limits. A warning at roughly 70% to 80% of a loss cap can give an operator time to inspect the system, but the warning must not be treated as permission to keep trading. Record both warning and trip events with the same inputs used to make the decision.
Make the trip reliable under failure
A trip path should be idempotent. If a timeout causes the risk service to issue the same halt twice, the second attempt must not create a second flattening order. Persist a trip identifier and state transition. On restart, read that state before enabling order placement.
Cancellation and flattening need separate logic. Cancel open entry orders first if they can add exposure. Then query broker-confirmed positions and orders. Do not assume a cancel request succeeded because the API accepted the request; wait for a terminal order status or reconcile by querying the broker. If an order is partially filled while cancellation is pending, calculate exposure from the confirmed fill quantity.
Broker APIs can delay, duplicate or omit updates. Use unique client order identifiers where supported, but still reconcile against broker order IDs and executions.
A network timeout after submission is ambiguous: the order may exist even if the client saw no acknowledgement. In that state, pause related submissions and query before retrying. Blind retries can turn a connectivity fault into duplicate exposure.
Choose what happens if the halt service itself fails. A conservative design fails closed for new risk: if the agent cannot obtain a valid risk decision, it cannot submit an order. This reduces availability.
It is generally preferable to silently trading without a functioning limit check. A separate, tested emergency path can handle protective or risk-reducing actions.
Log the trigger value, threshold, instrument, strategy, broker response and resulting positions. Store timestamps in a consistent format and preserve the data needed to reconstruct the sequence. An alert without enough evidence to distinguish a feed fault from a strategy fault is a weak control.
Test these paths with delayed acknowledgements, partial fills, rejected cancels, stale quotes, process restarts and broker disconnections. Paper trading can exercise order and state logic before live capital is involved.
For a practical environment to test agent order flows, agentic paper trading is available from $9.99 a month. A sandbox or paper account still needs deliberate fault injection; a normal successful session does not prove the kill path works.
Reset only after state is known
Do not clear a trip merely because a timer expired or a process restarted. A reset should require the cause to be understood, broker state to be reconciled and the relevant market data and connectivity checks to pass.
For a loss breach, the system may remain halted until an authorised operator changes the limit or starts a new session. Avoid automatic resets that can repeatedly reopen trading into the same fault.
For routine deployment, record the threshold configuration alongside the code version and strategy settings. Give each limit an owner, a unit, a scope and a reset rule. Test one trigger at a time, then test combinations, such as a stale feed during an open position. A controlled paper run can reveal whether cancellation, alerts and restarts behave as intended. Agentic Trading Index also provides a setting to evaluate agent workflows before they place live orders.
Keep a short operational list of habits to remove:
- Stop treating process termination as order cancellation.
- Stop retrying timed-out submissions without checking broker state.
- Stop resetting a halt before positions and open orders reconcile.
- Stop using one loss, spread or data-age threshold for every strategy.
Frequently Asked Questions
What should trigger a trading kill switch?
Common triggers include a loss or exposure limit breach, stale or invalid market data, a high order rejection rate, excessive submission speed and an unresolved mismatch with broker state. Choose conditions that cover distinct failure modes and define the response for each.
Should a kill switch cancel open orders or close positions?
Usually it should first block new risk and cancel orders that could increase exposure, then reconcile confirmed positions. Whether it should flatten positions is a separate policy decision because market orders can add slippage, especially in illiquid markets.
What is a typical daily loss limit for an automated strategy?
A typical starting range is 0.5% to 2% of allocated strategy equity, measured using realised and unrealised P&L. The appropriate limit depends on the mandate, use, instrument and strategy risk budget, so treat the range as a calibration point rather than a universal rule.
How should a trading system recover after a kill switch trips?
Keep the system halted until the trigger cause is understood, broker positions and orders reconcile, and data and connectivity checks pass. Require an explicit reset for material risk events rather than automatically resuming after a timer or process restart.
