← All articles

Quant

Risk limits and the kill switch

2026-08-01 · 6 min read

Design your risk controls for the algo you have on a bad day, not the one you tested on a good one. Not because your logic is wrong — because a config will get mistyped, a feed will deliver a zero, a deploy will ship the wrong file, and a loop will submit ten thousand orders in a second. Knight Capital lost around $440 million in roughly 45 minutes in 2012 to a deployment bug. The strategy wasn't the problem. Nothing stopped it fast enough.

Assume the bug

The mental shift is this: risk limits don't exist to manage trading risk. Position sizing and Kelly do that. Limits exist to bound the damage of a defect — a state your strategy was never supposed to reach. So they can't live inside the strategy, because the strategy is the thing you've assumed is broken. They sit in the order path, outside it, and they are deliberately stupid.

Pre-trade checks and the breaker checks run in the order path — the strategy cannot skip them new order ✓ max size ✓ price sanity ✓ submit rate ✗ daily loss breaker trips flatten + halt one failed check stops everything — no override, no retry
Every order runs the gauntlet. Any single failure rejects the order and trips the breaker — and re-arming it requires a human.

The layers

Pre-trade checks run synchronously in the order path. Nothing reaches the venue without passing all of them:

  • Max order size and notional — the fat-finger check. If your strategy asks for 10,000 lots when it's never asked for more than 10, the answer is no. Not a warning: a rejection.
  • Price sanity — a limit more than a few percent from the last trade is a bug, not a bargain. Bad ticks are common and a zero in a feed is a classic way to buy the entire order book.
  • Position limits — per instrument and gross across the portfolio, so no combination of individually-reasonable orders adds up to something insane.
  • Submit rate — cap orders per second. A loop bug is the fastest way to lose money ever invented, and it's the one failure mode where milliseconds genuinely matter. This is a rate limiter pointed at yourself.
  • Duplicate detection — same client order ID, same intent arriving twice? Reject.

Portfolio monitors run continuously, out of band, watching the aggregate rather than the order:

  • Max daily loss — down more than X today? Halt. Not "reduce size". Halt.
  • Max drawdown from peak — the slower-moving version of the same idea.
  • Position divergence — your book and the broker's disagree? You no longer know what you own. Halt immediately; this is the one that turns a small bug into an unbounded one.
The gist

Assume your algo will one day try something crazy. Put dumb, hard limits between it and the exchange — max size, sane price, max orders per second, max daily loss — and one big red button that cancels everything and refuses to trade until a human says otherwise.

The kill switch

One command. It cancels every open order, optionally flattens every position, and refuses all new orders until a human explicitly re-arms it. A few properties are non-negotiable:

  • It must not depend on the strategy process being healthy. If your kill switch lives inside the thing you're killing, you don't have one. Separate process, separate connection, heartbeat-monitored.
  • Decide "flatten or hold" in advance. Blindly flattening into a dislocated market can be its own disaster. Write the answer down now, while you're calm.
  • Re-arming is manual, always. Auto-recovery means the bug that tripped it gets to try again, at speed.
  • Test it. On a schedule, for real. An untested kill switch is a comment.

Two principles that make it hold

Fail closed. If the risk system can't verify a check — the position service is down, the P&L is stale — the answer is reject, not allow. Every system built to fail open eventually does exactly that, at the worst moment, and the reason is always that failing open was more convenient during development.

Limits are not the strategy's to set. A strategy must never be able to raise its own limit, and no limit should be adjustable from the code path that trips it. If raising a limit takes a config change, review, and deploy, the friction is the feature — it's what stops a 2am "just this once" from becoming the incident.

This is the trading version of the circuit breaker: stop a failure fast so it can't cascade — except the blast radius here is your capital rather than a downstream service. It pairs directly with the execution engine's fail-closed reconciliation, gives the lower rungs of the deployment ladder their safety, and is the mechanism behind the halt when a strategy stops behaving like itself. Build it before the edge. You will never regret having it, and you'll only notice it once — on the day it saves you.

Risk managementKill switchLive tradingQuant
← Back to the blog