On 1 August 2012 Knight Capital's trading system sent millions of erroneous orders and lost about $440M in 45 minutes. Automated warnings had been emailed before the market opened and were not treated as critical. What is the communication failure here, and what mechanism fixes it?

The trigger

A deployment left one of eight servers running old code, and a configuration flag that had been repurposed activated logic that should have been long dead. Orders flooded out at market open. The SEC's 2013 settlement order records that Knight's systems had generated 97 automated emails before the open flagging errors, which were not designed to be treated as system-critical notifications, and that the firm had no written procedures for when to shut the system down.

Why it propagated

Two separate communication defects, and only one of them is about people.

• A warning delivered on a channel with no severity is a warning that will be read after the event. Email to a group is not an alert: it has no acknowledgement, no escalation on silence, and no distinction from the dozens of other messages arriving in the same inbox. A signal without a response contract is documentation, not an alert.
• Nobody had the explicit authority to stop trading while the cause was unknown. The response during those 45 minutes was directed at diagnosing and repairing, and the losses accumulated at roughly $10M a minute while diagnosis proceeded. The question "who may halt this system without agreement on the cause?" had no pre-agreed answer.

The structural fix versus the tempting local fix

The tempting fix is better alerting on this specific condition, which is worth doing and fixes this failure only.

The structural fixes are about decision rights, and they are cheap:

1. A named stop authority, exercisable without consensus. One role, any time, no justification required in the moment. The cost of a wrong stop must be explicitly declared acceptable in advance, or nobody will use it.
2. A severity contract for every automated signal. Each one names its expected response and its escalation path on silence. A signal that nobody must act on is deleted, because its presence teaches people to ignore the channel.
3. A documented kill mechanism that has been tested. Knowing you are allowed to stop is useless if stopping requires a deploy or a call to a vendor.
4. Separate the decision to stop from the decision about the cause. These are frequently conflated in incidents: the group will not stop because it cannot agree on what is wrong. Stopping is a risk decision available with zero diagnosis.

The general lesson

Disagreement under pressure resolves in favour of inaction unless someone has been given the authority to act alone. In a system whose loss rate is measured per minute, the default of "discuss until we agree" is itself a decision, and an expensive one.

Common weak answers

• "They should have had better monitoring." They had the signal. The failure was that the signal had no response contract and no owner, which is an organisational design problem wearing a technical costume.
• "Roll back faster." The deployment was part of the trigger, and in this case rolling back the one inconsistent server would have spread the defective behaviour further. Stop first, diagnose second is the ordering the incident argues for.