Kill switches and risk limits for automated trading systems
Which pre-trade limits, loss limits and kill switches an automated trading system needs, based on SEC, ASIC, FIA and CME guidance and the Knight Capital case.
Most trading bots are built around the strategy: the signal, the entries, the exits. The part that decides whether a bad morning costs you a few trades or the whole account usually gets written last, if at all. That part is the set of limits that stop the bot from doing something you never intended, and the switch that stops it completely when those limits aren't enough.
Regulators and exchanges have written a lot about this, mostly for brokers and professional firms. The guidance translates well to a small system run by one person or a small team, and it's a better starting point than inventing your own checklist after something goes wrong.
What a runaway algorithm looks like#
The case everyone cites is Knight Capital. According to the SEC's 2013 press release, on 1 August 2012 Knight's automated router sent more than 4 million orders in the first 45 minutes after the open while trying to fill 212 customer orders. It traded more than 397 million shares and lost more than $460 million.
The cause wasn't exotic. The SEC says a code change in 2005 left a defective function in the router, and new code deployed in July 2012 triggered it. Before the market opened, an internal system sent 97 automated emails that identified the error, and nobody acted on them. The SEC's news digest adds that those emails weren't designed as system alerts.
The deficiencies the SEC listed read like a checklist of what to build. Knight's pre-submission controls were inadequate. For example, it didn't properly compare orders leaving the router with the orders entered. Its financial risk controls couldn't block orders that exceeded firm-wide capital thresholds. Its code deployment lacked adequate controls and testing. And it didn't have sufficient written procedures telling staff how to respond to a serious technology incident. Each of those has a small-scale equivalent in your own bot.
The limits regulators expect before an order leaves#
In the US, the SEC's market access rule, Rule 15c3-5, applies to broker-dealers with market access, not to individual traders. It's still a clear statement of what pre-trade controls should do. The final rule release requires controls that prevent orders exceeding pre-set credit or capital thresholds in aggregate, and controls that reject erroneous orders exceeding price or size parameters, either order by order or over a short period, or that indicate duplicative orders.
Australia's version is in ASIC's Regulatory Guide 241 on electronic trading, which covers trading participants using automated order processing. It describes filters as the principal means of checking orders before they reach the market. It also says a participant can't rely on the market operator's controls to meet its own obligations. That's worth taking literally even if you're not a participant. Your broker's checks exist to protect the broker. They're tuned for its whole client base, not for what your strategy should plausibly be doing.
FIA, the futures industry association, published best practices for automated trading risk controls in July 2024. Its pre-trade list is the most practical of the three:
| Control | What it checks | Small-system version |
|---|---|---|
| Maximum order size | Rejects any order above a size limit ("fat-finger" check), on submit and on modify | A hard cap per instrument, set from your largest intended position |
| Price tolerance | Rejects limit prices too far from a reference price | Reject limits more than a few percent from the last good quote |
| Maximum intraday position | Counts working orders as well as fills, so the limit holds if everything fills | Position plus open orders must stay under the cap |
| Repeated execution limit | Caps how many times a strategy or identical order is filled | Disable the strategy after N fills in a window |
| Stale market data | Alerts and blocks orders when data may be stale | No new orders if the last tick is older than your threshold |
Two details from the FIA paper are easy to miss. First, after a repeated-execution limit trips, FIA says the strategy should stay disabled until an authorised person re-enables it. The bot shouldn't reset itself on the next loop. Second, a message throttle should never reject an order cancellation. Whatever rate limiting you build, cancels must always get through.
Limits that watch what already happened#
Pre-trade checks look at one order at a time. Some failures only show up in aggregate: a strategy that's individually sensible on every trade but is bleeding money, or a position that drifted from what the bot thinks it holds.
FIA describes daily position and loss limits by account as a form of credit control, with alerts at thresholds before the limit is reached. It also recommends drop copy reconciliation, which means comparing your system's view of executions against an independent feed from the exchange or clearer. For a retail-scale bot the independent feed is usually the broker's own positions and fills endpoint. Compare it against your internal state every few minutes, and treat any mismatch as a reason to stop opening new positions.
ASIC's guide asks for real-time or near real-time monitoring of all trading messages, and it points to order-to-trade ratios as a way to spot a faulty system or a poorly programmed algorithm. A bot that normally sends three orders per fill and suddenly sends three hundred is telling you something, even if every individual order passes its checks. That's close to what the Knight router did.
What a kill switch should actually do#
The FIA paper defines a kill switch as a last-resort control that immediately disables all trading activity for a participant or group of participants. It typically blocks new orders and cancels all working orders. FIA notes it may still allow risk-reducing orders while blocking risk-increasing ones, and that it should be operable by both the trader and the person responsible for risk.
ASIC's version is broader. RG 241 expects automated controls that allow immediate suspension, limitation or prohibition of automated order processing, and gives examples including terminating the system, shutting down a subsystem, forcibly logging out a user, or setting a filter parameter to zero. That last one is handy: setting your maximum order size to zero is a kill switch you already have if your filters are built properly.
Exchanges build the same thing at their level. CME's Globex kill switch cancels day and good-till orders, and prohibits new order entry. CME says the block takes effect within one second, although cascading cancellations can take longer. Note what it doesn't do: CME says mass quotes aren't cancelled. Read the fine print on any switch you depend on, including your broker's "cancel all" call, so you know which orders survive it.
For your own system, a workable kill switch has a few properties:
- It lives outside the strategy process. If the bug is a loop in the strategy, a switch inside that loop may never run. A separate watchdog process, or a flag the order gateway checks before every submission, is more reliable.
- It cancels open orders at the broker and then confirms they're gone. A cancel is a request until the broker acknowledges it.
- It blocks new orders by default and only permits orders that reduce exposure, if you allow any at all.
- It doesn't flatten positions automatically unless you've thought hard about that. Dumping a large position with market orders during a fault can cost more than the fault.
- It stays off until a person turns trading back on, after they've reconciled positions with the broker.
- It can be triggered automatically by your limits and manually from somewhere you can reach on your phone.
Treat deployments as a risk event#
The Knight loss started with a deployment. The SEC press release names inadequate controls and testing around code deployment as one of the failures. FIA's paper says firms should have a process for testing trading software before release to production. RG 241 expects changes to be adequately tested before implementation and change management to be documented and auditable.
In practice that means a few habits. Run new code against paper trading or a replay of recorded market data before it touches real money. Deploy with tight limits for the first session, then loosen them. Remove dead code paths rather than leaving them switched off behind a flag that someone might reuse. And check that every machine running the bot is on the version you think it is.
Alerts somebody will read#
Knight's warning emails arrived and were ignored. Plenty of small systems have the same problem in a different shape: a log file full of warnings, or a chat channel that pings so often it gets muted.
Split your alerts into two kinds. Informational messages go to a log or a daily summary. Anything that means "trading should probably stop" should trip the kill switch automatically and then tell you, so the safe action doesn't depend on someone noticing. Write down, in a short runbook, what you check before turning trading back on: open orders, positions against the broker, the cause of the trip, and whether the limits that fired were set correctly. When we build trading automation at TheAILAB, this runbook gets written alongside the limits, because the limits only help if the restart is careful too.
Start with the cheapest version of all this today: a maximum order size, a maximum position, a daily loss limit, and a manual switch that cancels everything and blocks new orders. Then trip that switch on purpose in paper trading, and check that it does what you think it does.
This article is for education only and isn't financial advice. Trading involves risk of loss.
Sources
- SEC Charges Knight Capital With Violations of Market Access Rule (Press Release 2013-222) — U.S. Securities and Exchange Commission (16 October 2013) (checked 2026-10-22)
- SEC News Digest, October 16, 2013 — U.S. Securities and Exchange Commission (16 October 2013) (checked 2026-10-22)
- Risk Management Controls for Brokers or Dealers With Market Access (Final Rule, Release No. 34-63241) — U.S. Securities and Exchange Commission, Federal Register (15 November 2010) (checked 2026-10-22)
- Best Practices for Automated Trading Risk Controls and System Safeguards — FIA (July 2024) (checked 2026-10-22)
- Regulatory Guide 241: Electronic trading — Australian Securities and Investments Commission (August 2022) (checked 2026-10-22)
- Kill Switch – CME Globex Credit Controls — CME Group (checked 2026-10-22)
Trading a strategy by hand?
If you have rules you already follow and want them automated, tell us about them. You define the strategy; we help automate it.