Swedish Stock Exchange Hit By Programming Snafu 136
New submitter whizzter writes "I was reading the Swedish national news today and an image in a stock exchange related article struck my eye. An order had been placed for 4 294 967 290 futures (0xfffffffa or -6 if treated as a 32-bit signed integer), each valued at approximately 16,000 USD, giving a neat total of almost 69 trillion USD. The order apparently started to affect valuations and was later annulled, however it is said to have caused residual effects in the system and trading was halted for several hours."
SNAFU..... (Score:4, Insightful)
Speed at the cost of accuracy (Score:1, Insightful)
This is what happens when you want million transactions a second. You have to forgo input validation on your trading systems. Do these people ever learn?
Stop annulling these trades. (Score:5, Insightful)
The way to prevent this kind of mistaken (or even malicious) trade is to stop protecting the trader by canceling the trade as soon as the mistake is realized. If you issue a trade order, you should be liable for paying for it. If you can't, normal bankruptcy laws should apply.
Re:Good Point Here (Score:5, Insightful)
A linked list of digits? Seems a little much given that there's data types meant to handle really big numbers.
At a minimum someone should be bounds/sanity checking their inputs before it goes anywhere past the user interface -- you have to assume your users will type all sorts of random stuff into your fields.
Then again, I am often surprised when testing new software that when I do something completely random I often see issues.
I remember a developer saying to me once "but nobody is ever going to do that" -- the reality is, unless you actively prevent it, sooner or later they will; and in the case of many users, it's more like within the first 5 minutes. They don't know or care what you think is 'normal' inputs -- they're going to do what they do no matter what.
Re:SNAFU..... (Score:3, Insightful)
Mismatched types in caller/callee: Re:SNAFU..... (Score:4, Insightful)
That seems like the perfect description of what happened, either in terms of bad coding without type checking or input validation or in terms of the stock exchanges so frequently doing stupid things these days.
.
I think most likely it's a case of mismatched types between the calling function and how the function itself defines the calling variables. Errors that occured (possibly) (is there a link to the description/report that shows how this really happened?):
.
1 -- No Sanity Checking at Broker's end of transaction request: no validation of input at the customer or broker's computer, thus allowing a negative number entry for amount of shares to sell by the broker. aka Trusting the user to not input stupid values into a field.
2 -- Poor division of actionsactually not spliiting BUY and SELL into two different transaction categories and letting the sign of the number be the indicator as to the intent to buy or sell
3 -- Allowing wild extrema and outliers to affect trading: it's crazy to allow BID/buy orders at (average sale price)\dividedby(large positive integer) or to allow ASK/sell orders at (average sale price)\times(large positive integer). It's crazy for algorithms or humans to interpret any buy or sell price requests that are more than 50% deviated from the current running average price to be considered as anything other than either an anomaly or a deliberate attempt to fuck things up.
4 -- No sanity checking at the Stock Exchange board computer:no bounds checking on the board computer that accepts the buy/sell from the brokers. seriously, shouldn't there have been at least two places this poor interpretation could have been caught?
5 -- Unit Error / Representation Error: like letting a spacecraft go lost or kablooey by thinking the units are Imperial instead of Metric/Systeme_Internationale, maybe the order entry system represents the number X as signed long integer value, and the order-taker system (who knows what it's really called?) at the exchange interprets the number X as unsigned long integer value.
Now that number (5) error seems likely to me, as I have been learning C programmng and note that since it does not do type checking, it's possible to call a function with a variable that is holding a signed long integer, but the program is written with a
unsigned int functionname(unsigned long c1) {
\\... code goes here
}
\\... more intervening stuff
signed long int yabbadabbadoo = -6;
signed long int resultinganswer = 0;
resultinganswer=functionname(yabbadabbadoo);
so the same bit-representation is seen as two things. Akin to using the same words to mean two different things.
Re:oopsie... (Score:2, Insightful)
If I was writing an exchange system, I'd use something like Ada, where there are well tested add-ons that let you prove the accuracy and integrity of the algorithms.
In C, I almost never use signed integers. It's rare that I ever need negative values. If I'm subtracting, in the vast, vast majority of situations I expect to end up with a positive number. If the result would prove negative, something is broken. Using unsigned integers with modulo arithmetic I at least get a value in the correct domain. I only ever have to check for sane upper bounds, not upper _and_ lower bounds. It's half as much work, and half as much to go wrong.