The Typo That Cost A Quarter Of A Billion Dollars (At Least)
from the double-check-your-data dept
Earlier this year, we had a story about a Taiwanese stock trader who made a typo on on a new trading platform her company was using -- costing the firm $251 million. We were surprised that any kind of equities trading software wouldn't have controls to catch such trades, but apparently not. Now we have yet another example. Head up to Japan and you find a case where a trader who might not have had enough caffeine swapped the number of shares he was trying to sell with the price, so that instead of selling one share for 610,000 yen ($5,065), he tried to sell 610,000 shares (40 times the outstanding shares) for (yup) one yen. The system was smart enough not to let the sale go through for one yen, but it did sell many shares at a steep, steep discount. The company whose equity was at stake was having their IPO, so they couldn't have been particularly thrilled. The investment bank, Mizuho Securities, has been scrambling to buy back all the shares they sold -- at a huge premium. So far, the estimates are that the bank has lost $224 million for this little typo. So, with two examples in just a few months showing how little trading typos lead to quarter of a billion dollar losses, don't you think someone might look into making the software that traders use a bit... uh... smarter?
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Reader Comments
Subscribe: RSS
View by: Time | Thread
No Subject Given
[ link to this | view in thread ]
No Subject Given
[ link to this | view in thread ]
No Subject Given
[ link to this | view in thread ]
Re: No Subject Given
Didn't cost me a quarter of a billion, though. :) Thanks, it's fixed now.
[ link to this | view in thread ]
Re: No Subject Given
t's worth an extra prolly 50 or 100 bucks to know you'll be asked twice before you ever do anything. It may be annoying to some and you may even have to go as far as a company to make sure that it's not turn-off able. Either way you deal with the issue though the company screwed up bought faulty software without safeguards. An employee made a minor mistake that cost millions. It would have cost maybe 1/250,000th of that to be sure that there was and never would be any way a mistake like that can happen.
[ link to this | view in thread ]
Re: No Subject Given
Change it back!
[ link to this | view in thread ]
Re: No Subject Given
[ link to this | view in thread ]
More complicated design issue that it seems
Moreover, when any confirm gets in somebody's way, it'll be blamed for a loss - but when it prevents an error, there won't be any credit.
[ link to this | view in thread ]
Re: No Subject Given
[ link to this | view in thread ]
Re: More complicated design issue that it seems
How hard would it be to have the software check the last price of the security, and add a confirmation screen if the submitted limit price was too far out of whack?
The issue here is not to have an alert show up for every little operation you do... but rather, to identify unlikely operations, and ask for confirmation for these only.
Alan Cooper addresses this issue when discussing of possible vs. probable tasks in his "About Face" book, whereby for the average programmer all possible actions are equivalent and need to be granted equivalent interface complexity to pursue, on the ground of the fact that someone might need all of them sooner or later, while the smart programmer knows what's likely and what's not, and eases the interface for likely actions, to the expenses of unlikely ones.
In practice, in this case it would not be hard to implement a verification system that checked the likelyhood of the proposed transaction against a set of rules or previously approved operations, and asks for a confirmation when it goes out of the acceptable boundaries. BTW, it would make sense to add layers and layers of approval screens, and even the approval of a supervisor, as the proposed transaction becomes unlikelyer.
To sell for one yen (less than one USD cent) a share whose expected price is 5,000 USD, and to try to sell 610,000 shares, when the total amount of available share is 15,000, should have activated some serious confirmation screens indeed!
[ link to this | view in thread ]
Re: More complicated design issue that it seems
[ link to this | view in thread ]
Warn if the current bid is out of whack with the a
A better way might be to multiply the difference between the new price and the current trading price by the number of shares and warn if this anount is larger then some threshold, say $10,000. This would have few false positives but would stop all the big mistakes. This has the advantage of warning about the size of the dollar loss. i.e. Setting 10 share for 1 cent instead of a 43 is noise. But selling 10,000,000 share for $8.91 instread of $9.81 is a loss of over $1,000,000
[ link to this | view in thread ]
Re: No Subject Given
I misspelled Quarter as Quater. If I was going to intentionally do a typo, that one was fairly subtle. Oh well. Next time I'll make my typo better. :)
[ link to this | view in thread ]
Bangalored?
i have a good friend who works for an investment bank in London who does nothing but writes proceedures and checking mechanisims on the traders software to prevent this stuff happening. It's down to a fine art. I find it amazing that this kind of error is still happening - i'm willing to bet the the checking mechanisim was "Bangalored"!
[ link to this | view in thread ]