Slashdot Mirror


How To Lose $172,222 a Second For 45 Minutes

An anonymous reader writes "Investment firm Knight Capital made headlines in 2012 for losing over $400 million on the New York Stock Exchange because of problems with their algorithmic trading software. Now, the owner of a Python programming blog noticed the release of a detailed SEC report into exactly what went wrong (PDF). It shows how a botched update rollout combined with useless or nonexistent process guidelines cost the company over $172,000 a second for over 45 minutes. From the report: 'When Knight used the Power Peg code previously, as child orders were executed, a cumulative quantity function counted the number of shares of the parent order that had been executed. This feature instructed the code to stop routing child orders after the parent order had been filled completely. In 2003, Knight ceased using the Power Peg functionality. In 2005, Knight moved the tracking of cumulative shares function in the Power Peg code to an earlier point in the SMARS code sequence. Knight did not retest the Power Peg code after moving the cumulative quantity function to determine whether Power Peg would still function correctly if called. ... 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.'"

8 of 327 comments (clear)

  1. There should be a mandatory one second delay. by Anonymous Coward · · Score: 5, Insightful

    This level of trading does not do the market any good, and puts individual investors at a severe disadvantage against firms like this.

    It can be stopped. And it should be stopped. And the only reason it is not being stopped is because too many rich and powerful people make too much money on it.

  2. IT Debt by Anonymous Coward · · Score: 5, Insightful

    They had some code that processed orders in a special way. There was a flag on the order they could set that would trigger that code. We will call this Power Peg. They later moved away from that functionality but it still existed in the system. It sat there for years untested and unused. 9 years later they added new functionality and decided to reuse that same flag. The new code also disabled Power Peg.

    When they pushed the new code into production, they missed a server. That missed server still had Power Peg looking for that flag. Orders started setting that flag and it was processed correctly on all but one server. But that last server was placing orders incorrectly. The logic that Power Peg used was not valid anymore. In a panic they rolled back the code on the servers. Not knowing that Power Peg was the issue, they now had all the servers running Power Peg again.

  3. Re:The efficiency of capitalism by TsuruchiBrian · · Score: 5, Insightful

    The wealth that the money represented was not "lost", but rather redistributed. Efficient redistribution of wealth is a strength of the private sector not a weakness. The private sector is good at redistributing money where it needs to go for economic growth. This company was not exercising an appropriate level of caution and it's money was redistributed elsewhere.

  4. This is what I like best about /. by rsilvergun · · Score: 5, Insightful

    In the same thread where I can find 1000 people going on about how efficient capitalism is I can find another (sometimes the same) 1000 people complaining all the dumb things their companies do. Well, which one is it? It doesn't work both ways people. Could it be that people are people, no matter what banner they're organized under?

    --
    Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
    1. Re:This is what I like best about /. by Anonymous Coward · · Score: 5, Insightful

      Capitalism produces large corporations that are very efficient at doing dumb things.

    2. Re:This is what I like best about /. by Anonymous Coward · · Score: 5, Insightful

      The money wasn't destroyed, it went to other traders. Maybe they will donate it to children with cancer?

    3. Re:This is what I like best about /. by Tablizer · · Score: 5, Insightful

      The public and private sector do different things better. While the private sector is more efficient in terms of service or widgets per hour, there's also heavy pressure to trick, mislead, and rip off consumers and customers.

      Such "trick" pressure is noticeably lower in the public sector. There is relatively little pressure for a line worker and middle manager to rip off or trick customers because they don't have to compete with other cut-throat competition and are not sweating over narrow margins. They generally don't want the drama of customers sending or phoning complaints and so do an adequate job, even if a bit slow at it.

      Certain kinds of services are better under one versus the other. If it's a service where it's easy to fool customers, especially over longer-term features, then it's probably best done by or heavily regulated by the gov't. If it's something that's relatively easy for a consumer to verify the quality of, then it's probably best done by the private sector.

  5. Re:Garden Variety Upgrade SNAFU by Alan+Shutko · · Score: 5, Insightful

    There were a number of errors made here.

    1. They failed to deploy to one of eight servers
    2. They failed to automate the deployment to the servers such that it would be impossible to deploy to all servers without knowing.
    3. They didn't have a step between code deployment and production activation where they could validate all 8 servers. For instance, in our company, we deploy the prod code to the prod servers but leave them in a "stage" environment, where the production load balancer doesn't hit those instances. Once we've validated, we then switch the load balancers to point to the correct instance.
    4. They failed to quickly back out a change when they realized it was having problems. In fact, they backed out the part on seven servers but not the flag that was being sent to the servers, which made things worse.
    5. They failed to have a risk-mitigation backstop in place which would have prevented these orders from being submitted once they hit a certain amount, and which was required by SEC Rule 15c3-5(c)(1)(i).

    There were a lot of places that you could put in a control to prevent or limit the effect of these kinds of errors, and that's the lesson people need to learn. Yes, mistakes happen! But try to make it hard to make a mistake, easy to recover from a mistake, and really easy to NOTICE a mistake.