The kill switch: building a system that can stop

A kill switch stops all trading the instant it fires: cancel every open order, block every new one, isolate the system until a human or a rule lets it back in. Every serious trading desk will tell you it has one. Far fewer have one that actually holds up under the conditions where you'd reach for it — which are, by definition, the worst conditions the system will ever face.

The kill switch is the one feature you hope you never touch and absolutely can't afford to have fail. It gets tested the least and matters the most, which is a bad combination. By the time you actually need it, the system is already in the mess that tripped it: positions moving the wrong way, a venue acting up, state you're no longer sure about. Stopping cleanly from there is a different problem than stopping from a calm, healthy system — and the calm one is, in my experience, the only state most kill switches ever got tested against.

Stopping is not one action

"Halt trading" sounds like one clean action. It isn't. A real stop is a handful of things that all have to land, in the right order, against a market that won't politely wait for you to finish:

• Block new orders — right away, at the entry point, so nothing fresh gets created while you're trying to unwind.
• Cancel resting orders — pull everything live on every venue, then actually confirm the cancels landed. Sending the cancel isn't the same as it taking.
• Reconcile what's left — figure out exactly what you're holding once the dust settles, because cancels and fills love to race each other.
• Isolate the system — keep it stopped until something deliberate turns it back on, not until a process restarts and quietly forgets it was supposed to be off.

A kill switch that does the first step and skips the rest hasn't stopped anything. You've locked the front door while the building's still on fire behind it.

The hard part is the state you stop from

Cancelling an order is trivial when you know what orders exist. The catch is that the moment you most need to stop is exactly the moment you're least sure of your own state. A cancel races a fill. A venue acks the cancel, but the fill already went through a beat earlier. You pull what you believe is everything, and an order you didn't even know was out there fills a second later. The worst version of this I've dealt with wasn't a missing order — it was two systems disagreeing about whether one had been cancelled at all.

That's why a kill switch is only ever as good as the consistency model underneath it. If position and order state are solid, stopping is basically mechanical. If they drift — if the system isn't certain what it's holding or what's still live — then the switch is flying blind at the precise moment precision matters. The switch doesn't give you the ability to stop cleanly. It borrows that ability from the architecture, and if the architecture never had it, neither does the switch.

Drawdown is the trigger you design for

Most kill switches are built to fire on drawdown: the account drops a set distance from its peak, and the system pulls out before the loss turns into something you can't come back from. So drawdown can't be an afterthought you bolt on. It has to be measured continuously, off state you actually trust, and fast enough to act before the threshold gets blown straight through.

And it has to read from the right place. A drawdown check pointed at stale or eventually-consistent state will fire late, or never, right when the market is moving fast enough to cause the drawdown in the first place. The trigger and the data feeding it aren't two problems. They're one.

Manual and automatic, both

A complete system gives you two ways to stop. The automatic path fires on a rule — drawdown, exposure, error rate — without waiting for anyone to notice. The manual path lets a human kill everything with a single action, no ambiguity, no five-step ritual, at three in the morning with their hands shaking. Both have to end up in the same clean stopped state. And neither can depend on the other still being alive, because the day you reach for one is often the day the other is the thing that broke.

A system you cannot stop is not under control. It is just working for now.

Being able to stop isn't a safety feature you tack on at the end. It's a property of a system that was built to be controllable in the first place — one whose state stays consistent enough that, on the ugliest day, you can pull it out of the market cleanly and know exactly where you stand once it's done. That's the line between a system you actually operate and one you're just hoping keeps behaving.

Ignacio Montoya is a systems architect specializing in algorithmic trading infrastructure, financial systems, and digital asset platforms. He designs trading systems that can be stopped cleanly — kill switches, drawdown controls, and the consistent state they depend on.