Kill Switches and Human Overrides for ML Models

A model that has run cleanly for a year can still misbehave badly on a day nobody planned for — a corrupted data feed, a corporate action the feature pipeline mishandled, a regime the training data never saw. Understanding why it broke can take hours or days. Waiting for that understanding before doing anything is how a small model malfunction turns into a large loss.

A kill switch is a mechanism, usually automated with a manual override on top, that can shut a model down or cut its position size immediately when something looks wrong — without requiring anyone to first diagnose the exact cause.

What triggers one

Kill switches are usually built around a small number of hard, checkable conditions rather than subjective judgment calls, because subjective judgment is exactly what's too slow in the moment:

• Position or loss limits. The model's positions or daily P&L breach a preset threshold.
• Input sanity checks. A feature value falls wildly outside its historical range, suggesting a feed problem rather than a real market move.
• Output sanity checks. The model's predicted positions change far more between updates than they historically have.
• Manual override. A human on the desk can always cut the model's size or turn it off, independent of any automated trigger, because a person watching the market may notice something no automated rule was written to catch.

Worked example

A signal-driven equity model has a rule that halts trading if any single stock's predicted position changes by more than 3 standard deviations from its typical daily change. On a day when a data vendor mistakenly duplicates a corporate action, one stock's adjusted price feed shows a 40% overnight "return" that never happened. The model, reading this as a genuine dislocation, would normally have taken a large position against it. The kill switch trips on the output sanity check before the order is sent, halting that stock's trading and flagging it for a human to review — the desk confirms the data error within 20 minutes and corrects the feed, and the model resumes with no loss, versus what could have been a large mispriced position if the trade had gone through.

What this means in practice

Kill switches need to be tested the same way the model itself is tested — with drills, not just documentation — because a switch nobody has actually triggered in a live-like rehearsal often turns out to have a gap: a dependency that doesn't shut down cleanly, a position that isn't actually flattened by the "halt" command, or a monitoring dashboard that doesn't update fast enough for a human to notice in time.