Knight Capital 2012: more than US$ 460 million lost in 45 minutes (SEC)

01 · CONTEXT

An order router and the rule that limits its risk

The case comes from the SEC administrative order on Knight Capital, from October 2013. On August 1, 2012, Knight suffered a significant error in SMARS, its automated stock order routing system. While processing 212 small retail orders from its customers, SMARS sent millions of orders into the market over 45 minutes. The SEC records that Knight lost more than US$ 460 million on the unwanted positions.

SMARS is an automated, algorithmic, high-speed router. One of its core functions is to receive parent orders from other components of Knight's trading platform and, depending on available liquidity, send one or more child orders to external markets for execution.

1. Customer orders go first through Knight's trading platform, whose interface, order management, and internal execution already had controls against erroneous orders.

2. The platform passes the parent orders to SMARS.

3. SMARS splits each parent order into child orders and sends them to external markets for execution.

The violation sanctioned is of a rule that requires brokers to have controls and procedures reasonably designed to limit the risks of market access, including those of automated systems. The order notes that the speed of these systems can turn a manageable error into an extreme event with broad impact.

02 · THE DEPLOY

New code over old code, on eight servers

To prepare for the NYSE's Retail Liquidity Program (RLP), Knight changed order-handling systems and code and deployed new code to SMARS. The new code was supposed to replace an unused section, formerly tied to a feature called Power Peg, which Knight had discontinued many years earlier. Despite being unused, Power Peg was still present and triggerable when the RLP was deployed. The new code also reused a flag that previously activated Power Peg, and the intent was to remove it so that, with the flag set to yes, the RLP would be triggered in its place.

In Power Peg, a cumulative quantity function counted the shares already executed for the parent order and told it to stop routing child orders once it was fully filled. In 2005, Knight moved the cumulative share tracking function to an earlier point in SMARS's code sequence and did not retest Power Peg to see whether it would still work correctly if called.

1. Knight deployed the new code in stages, to a limited number of SMARS servers, on successive days.

2. A technician did not copy the new code to one of the eight SMARS servers.

3. There was no second technician reviewing the deployment, and no one noticed that the eighth server was still running Power Peg without the new code.

03 · THE MORNING OF THE INCIDENT

Forty-five minutes without a brake

On August 1, Knight received orders from brokers whose customers were eligible for the RLP. The seven servers that had received the new code processed them correctly. The orders sent with the reused flag to the eighth server, however, triggered the defective Power Peg code that was still there.

1. On the servers with the new code, RLP-eligible orders were processed correctly.

2. On the eighth server, orders with the reused flag triggered the defective Power Peg.

3. With the cumulative quantity function moved, the server kept sending child orders continuously, regardless of the executions it had already received.

One part of Knight's order system recognized that the parent orders were already filled, but this information did not reach SMARS. For the 212 parent orders handled by the defective Power Peg, SMARS sent millions of child orders, with 4 million executions in 154 stocks and more than 397 million shares, in about 45 minutes. Knight inadvertently took on about US$ 3.5 billion in net long position in 80 stocks and about US$ 3.15 billion in net short position in 74 stocks.

04 · THE MISSING CONTROLS

No brake on the router's output or on the firm's exposure

Before SMARS there were controls, but within SMARS itself the SEC concluded there were no adequate controls against erroneous orders. Missing were a control to monitor the output, such as comparing the orders going out with those that came in, and procedures to stop SMARS in the face of its own anomalous activity. On the capital side, some groups' position limits did not account for the exposure of open orders, and there were no aggregate firm capital limits tied to automated controls that would prevent orders from being entered.

1. SMARS sent child orders to the market without a control comparing output with input and without a procedure to stop it.

2. The executions accumulated in an account that held several types of positions. The account had a gross position limit, but was not tied to any automatic control of the firm's overall exposure.

3. PMON, the main risk-monitoring tool, showed positions after executions and did not generate automatic exposure alerts.

4. At market open, senior staff saw a large volume of positions accumulating in the account, but PMON was not tied to order entry to stop it automatically.

5. Before the open, an internal Knight system sent a group of people automated emails that mentioned SMARS and the Power Peg disabled error. They were not designed as alerts, were generally not reviewed, and were not addressed before the open.

05 · THE RESPONSE AND THE OUTCOME

Fixing it live made the problem worse

Knight had no supervisory procedures to guide staff when significant problems arose. It depended mainly on the technology team to identify and handle the SMARS problem in a live trading environment, while the system kept sending millions of child orders.

1. While the team tried to find the source of the problem in a live trading environment, the system kept sending millions of child orders.

2. In one of the attempts, Knight uninstalled the new code from the seven servers where it was correct. This made the problem worse: new parent orders began to activate Power Peg on those servers too.