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.