On August 1st, 2012, high-frequency equities trader Knight Capital lost $US462 million after automated trading systems went haywire, a mess that has now been traced to a mistake by a single sysadmin.

The incident saw the company place orders for many more shares than its clients wanted to buy. Knight ended up holding the baby, to the tune of $462m in an event that came to be known as the “Knightmare”.

Knight Capital floundered in the aftermath of the error and has since merged with another company. It's also been slapped with a $12m fine, and the US Security Exchange Commission's order (PDF) explaining why offers a look at just what went wrong in the IT department on and before that fateful day.

An application called “SMARS” was the main culprit. One of SMARS' functions was to receive “parent” orders to buy equities, which it then turned into “child” orders that actually bought the equities. Helping things along was a feature called “Power Peg” that hadn't been used for years, but hadn't been removed from SMARS either.

During 2012, Knight Capital upgraded SMARS so it could interface with a new “Retail Liquidity Program (RLP)” offered by the New York Stock Exchange. That upgrade, the SEC says, “repurposed a flag that was formerly used to activate the Power Peg code”. The plan was for the new RLP code to supersede Power Peg.

When the new version of SMARS was introduced, “Knight deployed the new RLP code in SMARS in stages by placing it on a limited number of servers in SMARS on successive days.”

During that process, a staffer made the critical error, described by the SEC as follows:

“During the deployment of the new code, however, one of Knight’s technicians did not copy the new code to one of the eight SMARS computer servers. Knight did not have a second technician review this deployment and no one at Knight realized that the Power Peg code had not been removed from the eighth server, nor the new RLP code added. Knight had no written procedures that required such a review.”

Here's what happened when the server that missed the SMARS update went live:

“On August 1, Knight received orders from broker-dealers whose customers were eligible to participate in the RLP. The seven servers that received the new code processed these orders correctly. However, orders sent with the repurposed flag to the eighth server triggered the defective Power Peg code still present on that server.”

The un-patched server therefore kept making "child" orders for more shares than Knight or its customers wanted. So many orders, in fact, that some stock prices fluctuated wildly and Knight was left holding shares nobody wanted that it had acquired at prices nobody was willing to pay. By the time the market had moved on, it was left with $462m of losses.

The SEC's document scorches Knight Capital for its lax risk management practices and poor systems to detect dodgy-looking trades. It also lashes its poor software development and deployment process, as follows:

“Knight did not have written code development and deployment procedures for SMARS (although other groups at Knight had written procedures), and Knight did not require a second technician to review code deployment in SMARS. Knight also did not have a written protocol concerning the accessing of unused code on its production servers, such as a protocol requiring the testing of any such code after it had been accessed to ensure that the code still functioned properly.”

Elsewhere, the document suggests Knight Capital could have foreseen the problem. Previous disaster recovery tests found related problems, and the SEC points out that “a written procedure requiring a simple double-check of the deployment of the RLP code could have identified that a server had been missed and averted the events of August 1.”

The Reg feels for the sysadmin who conducted the server upgrade, because while they made a mistake the consequences that flowed from it can be attributed to the sloppy software development practice that left Power Peg in place years after anyone stopped using it. Knight's lack of risk management rigour left him or her horribly exposed.

Failures on this scale usually end up being used as examples of how not to do IT. How long do you think it will be before your boss issues a new policy manual about how you work and who checks your activities? Or have you asked them to do it already? ®