610,000 JPY
When Dentsu Inc started trading on the Tokyo Stock Exchange in December 2001, financial analysts watched the stock price with great expectations. Dentsu was one of Japan’s largest advertising companies, and the event was one of the biggest initial public offerings that year. In the early hours of trading, the stock value surprised everyone by falling through the floor. A single trader in Tokyo, working for UBS, caused the crash by mistake. Instead of offering to sell 16 Dentsu shares at 610,000 yen (roughly US$5000 at that moment), the trader offered 610,000 Dentsu shares at 16 yen each. The Wall Street Journal reported that, upon noticing the error, ‘UBS’s trading floor in central Tokyo went into a panic, with a cacophony of yelling and screaming.’ The mistake was rolled back after just two minutes, but ended up costing UBS almost US$100 million.
Not to be outdone, a trader at Mizuho Securities caused even bigger chaos in 2005 with a touch of, as the financial news broadcasters all over the world named it, a ‘fat finger’. Instead of offering to sell one share of the recruitment company J-Com at the price of – imagine the coincidence – 610,000 yen, the trader offered 610,000 shares to the market at a price of 1 yen each. Needless to say, the bargain was quickly picked up by anyone with a pair of eyes. Other investment banks made a killing, but the biggest individual winner that day was Takashi Kotegawa, 27 and unemployed. He made a profit of 2 billion yen, roughly US$15 million at the time. Mizuho Securities tried to recall the offer after spotting the error, but a bug in the Tokyo Stock Exchange systems prevented that from happening. Takuo Tsurushima, president of the Exchange, resigned over the issue. Mizuho ended up picking up the bill for the whole episode, to the total of 40 billion yen.
Fat-finger errors are a human mistake and happen all the time, all over the world. But the ones that make news all, as a rule, happen in Japan. In 2009, UBS placed an order for bonds issued by the game-maker Capcom worth 3 trillion yen (US$31 billion), 100,000 times more than it intended. Luckily, the order was placed through an off-hours trading system, and UBS was able to reverse it before it caused an impact on the market. In 2014, a tsunami of 67.78 trillion yen (US$617 billion) of fat-finger orders hit the Tokyo Stock Exchange, but this time they were cancelled in time. Bloomberg reported that the value of the error was greater than that of Sweden’s economy.
Fair enough, people in the Land of the Rising Sun wake up before everyone else, so sleepiness might be causing fat-finger more errors than in other places. But there’s actually a good reason why it’s always Japanese trades that are so error prone. ISO standard 4217, controlling the display of currency information, requires that amounts in yen use just integers without decimal places. This makes it easy to confuse currency amounts and other numbers, such as how many bonds you want to sell. My UK bank, for example, tries to prevent careless fat-finger errors by requiring that all currency amounts have two digits. If I want to pay £50 to someone, the bank will only let me enter it as 50.00. That’s how it prevents people entering the payment reference into the amount field, or the other way around. With Japanese yen, that kind of validation just isn’t possible. Even worse, third-party software might mysteriously complain if you do try to supply decimals with yen amounts. That’s why the popular Q&A site Stack Overflow is full of questions relating to incorrectly formatted item errors when using yen with PayPal.
The humble yen is a lovely edge case, even for developers not working in Japan. In fact, it’s the people in the West who are most at risk of making daft mistakes. Floating-point numbers aren’t precise, so they aren’t suitable for financial calculations. That means that financial amounts often get represented by integers or special-purpose database types that record numbers to a fixed number of decimal points. Because most developers live in countries where two-digit amounts are taken for granted, it’s quite common to see code where amounts are multiplied by 100 before saving. In fact, to prevent rounding errors, many payment APIs require amounts as integers. That works the same for euro, British pounds or most other popular currencies. But not for yen. A payment request for 2000 using a popular payment gateway Stripe might only ask for US$20, but it will ask for 2000 yen. That’s why there’s a special warning about yen amounts in the Stripe payment documentation. For an even weirder edge case, consider Kuwaiti dinar (ISO code KWD), which should use exactly three decimal places.
In plain English, the correct way to record financial amounts is to use an integer in the smallest currency-amount units. A US dollar consists of 100 cents, so the smallest unit is a cent. But the smallest currency unit in Japan is 1 yen, so all kinds of wrong assumptions about always multiplying by 100 or adding two decimal places cause weird and wonderful bugs. Yen is not the only zero-digit currency in use, but it’s by far the most popular one. Very few developers ever had to deal with payments in Rwandan francs, but Japan is a huge market so it’s quite likely that people working even for mid-size US or European companies need to deal with yen payments at some point.