Knight Capital $440M Runaway Trading Loss
Dormant algorithmic trading feature reactivated by configuration flag error, executing millions of unintended orders and causing about $440 million in losses within 45 minutes.
What happened
On August 1, 2012, Knight Capital deployed new order-routing software to seven of its eight production servers. The eighth server did not receive the new code and still ran a legacy internal function called Power Peg, an order-routing and market-making test function used to verify the behavior of other proprietary trading algorithms, which Knight had decommissioned around 2003. A configuration flag that had previously triggered Power Peg was reused for the new code, so on the one server missing the update the flag inadvertently reactivated the old Power Peg logic. That server fired millions of unintended orders into the market over approximately 45 minutes. The automated trading system operated with no human approval gates, no notional ceilings on order sizes, and no kill switch to halt the execution stream once initiated.
What the agent did
The automated trading system continuously placed millions of equity orders into the market based on the reactivated legacy Power Peg trading logic, with no circuit breaker or human intervention to stop the stream.
The irreversible effect
About $440 million in irreversible market losses over 45 minutes (Knight's announced figure; the SEC cites over $460 million); Knight Capital paid an SEC-imposed $12 million penalty for violating Rule 15c3-5 (the Market Access Rule).
Root cause
Lack of segregation of duties between deployment and market access, absence of approval gates on order placement, no per-order amount limits, configuration management failure that allowed dormant code to be reactivated, and critically, no per-session invocation cap or circuit breaker to halt a runaway order stream before catastrophic losses occurred.
How a maker-checker control would have refused it
MakerChecker would refuse execution via: (1) deny-by-default refusal ("skill_not_granted") if the routing actor lacked an explicit send grant, preventing direct market access, or (2) enforcement of per-invocation amount limits ("limit_violation") that would block oversized orders, or (3) per-session invocation caps ("limit_violation") that would halt the stream after a configurable number of trades, providing the kill switch this incident lacked.
Runnable reproduction
This incident ships as a runnable scenario in the open-source repository. Point the enforcement engine at the policy and watch the action get refused, with the refusal written to a signed audit record.
examples/knight-capital-440m-runaway-trading
Accuracy and corrections
This entry describes a publicly reported incident and is compiled from the primary sources listed above. Where an account is a legal allegation rather than an established finding, the entry labels it as such. Summaries can still contain errors. If you can document a correction, email hello@makerchecker.ai and we will review and correct it, with the change noted, within 14 days.
See it for yourself
Reading is one thing. Watch it block an agent.
One command starts the demo: an agent stopped from signing off its own work, and the signed evidence file an inspector can check for themselves.
Designed against the rules your auditors already enforce.