Fat Finger Trades

Image courtesy of amanky (Flickr)

I know the title might not sound that appealing but this is quite an interesting and widely documented phenomenon in the world of financial trading.

Millions of dollars have been lost and entire markets brought down a few points due to a fat finger trade (FFT).

What is a FFT then?  A FFT is an error that occurs when the user attempting to buy or sell shares accidentally hits additional keys to those they are targeting.  The Hindu Business Line provides a nice lists of examples of these errors.  The error normally results in trades being made for 10 or 100 times as much as intended.  As you will find out, context is everything for this type of error.  No big deal if you are working on your home computer and are able to correct the mistake but when dealing with amounts in the millions, this can have a huge impact upon the companies involved, and as listed above, an entire market.

The problems don't end there.  Occasionally a FFT can have even worse consequences for the company involved.  In December 2005 the Times reports an instance of a FFT occuring at the Japanese company Mizuho Securities.  Instead of selling 1 share at 610,000 Yen, the employee typing this in accidentally sold 610,000 shares for 1 Yen each.  Not only did the error result in huge monetary discrepancies but the company actually sold far more shares than they had, in fact it represented "more than 40 times the total number issued by the company".  Yikes.

How easy is it to place checks and guards into trading software to ensure that trades aren't made for 40 times the company's worth?  The task seems a trivial one so why has it not been implemented?   It could be that in the dynamic and changing world of financial trading the task would involve a fair amount of computation.  But these are just the type of calculations that most pieces of financial trading software are made to deal with.  We could explain the lack of safe guards on poor User Centred Design.  The companies commissioning the trading software will focus on the efficiency and speed at which their employees are able to trade at.  In the fast moving world of stocks and shares speed is key to buying lowest and selling highest (fact generated by me based on films I have seen).  There is no incentive for the software to be designed to do anything else any better.

Well it seems like feedback from these errors is reaching those in charge of designs.  This article in the Sunday Morning Herald of Australia suggests that the FFT is being weaned out due to increased checking in the trading software - fantastic.  Turns out it wasn't an impossible problem.  The article speculates that perhaps the recent dip in the Dow index was not down to a FFT but rather some error resulting from the program itself.  At this point it isn't human error, I say hooray and leave the analysis of the computer program to someone more interested in analysing the code of financial trading systems than myself.

One last thought on the FFT example from Mizuho Securities - is this a FFT at all?  It seems like the issue here wasn't pressing additional keys by accident but rather confusing the two numbers and entering them into the wrong locations in the interface.  This could have been caused by a confusing interface or a lack of experience or simply mixing the numbers up in the employee's head.  It seems that the term "Fat Finger Trade", in the media at least, is being appropriated for all types of error that occur in the financial market.  How important is this generalisation?  Well if we just want to read about traders doing stupid things, it's a pretty useful search term.  But, as a student researching types of number entry error, I really think this generalisation hides the more interesting information.  If we break the generic FFT error down into more accurate descriptions of what's going on, we can begin to look at causes (were they distracted? keyboard too small? numbers too hard to read? numbers too similar? confusing interface? no training?), and the myriad of possible cures.

So newspapers, you can have your buzz words but when you the reader see it, think about what's really going on - it's far more interesting.

UX Errors

Courtesy of mrlerone (Flickr)

UX Errors is a highly entertaining set of photos on Flickr, all representing some brilliantly flawed UX design.

They're not strictly all numerical nuisances but I think a little UCD ideas belong here too.

HCI Matters

The blog HCI Matters is written by another HCI enthusiast and friend, Anna BD.  I know that she’ll be writing some very informative and interesting posts about the wider topics in HCI.  Enjoy!

The price of electricity is on the rise

Image courtesy of Holeymoon (Flickr)

Tony Leventhal received a shock in 2007 when his credit card company called to ask him about a rather large payment to the electricity company. It turns out a reasonable £170 bill had turned into one for a massive£17,000. Source BBC News. Full story.

How might this have come about? Well we’ll put this one down to human error. There are a few scenarios I can see that may have caused this error. Firstly, let’s look at the mistakes that could have occurred whilst reading the number to be entered. So the operator who was typing in the amount (at whatever stage in the process) is fairly new at this job and is working on transcribing bill amounts into the system. He’s a little distracted thinking about lunch whilst working. He sees the amount £170.00 and does one of two things. He might misread the number, by ignoring the decimal (making it £17000) or he reads the decimal point as a comma, albeit misplaced (reading it as£170,00). Both of these instances result in him inputting an amount 100 times larger than intended. How can we solve this issue? Well it all comes down to how this information was presented to the operator. Was it printed neatly? Was it scribbled down on some paper from a customer’s home meter reading when their electronic gadget went wrong? Who knows, but there are a few conventions we can take from the medical domain to help people read decimal numbers more accurately. One of which is to make the decimal point large. Don’t hide it at the bottom of the text, we don’t need things to look pretty, we need them to look readable. Another convention that works in conjunction with the large decimal is writing the decimal portion of the number in smaller numbers (see the Design for Patient Safety page). With these simple additions, reading and transcribing numbers can be easier and a lot more accurate.

Now let’s think about the possible slips whilst typing. In the following cases the operator has correctly read and knows the right number he is to enter. An error occurs however, due to the keyboard or display, and the operator is not aware when he makes a slip. I don’t actually know what the input layout is like on screen but let’s take a quick look at two possible form layouts and the associated error causes.

The first layout theory is simple and probably what you’d expect:

In this situation the operator may have aimed to type in £170.00 and accidentally missed the decimal key for whatever reason (he was distracted by something, the keyboard was still sticking from that time he spilt coffee on it etc.) Without the all important decimal place, the operator inputs the huge amount of £17000. As far as the operator knows, there’s no reason the decimal point hasn’t been inputted, he thinks he typed it and so does not double check the number. How could we prevent or protect against this error? One way would be to assume and check that every number typed into the system has a decimal point, even if the amount only comprises of pounds and not pennies. With this check in place the operator, upon entering the erroneous number with no decimal point, will be presented with an alert requesting they add a decimal point to the number. At this point hopefully the operator will look at the number they entered, the one they thought they typed a decimal place in, realise and correct their mistake.

Another way of fixing this problem might be to separate the pound and penny fields. This layout looks a little silly but who knows, this might be how it works! I’ve seen crazier input systems.

So this layout ensures that pounds and pennies are split. The operator doesn’t have to worry about decimal points! Hooray, hurrah! But really this doesn’t actually solve the problem. Now the operator has the option of accidentally not pressing an entirely different key, this time the tab key. Now our operator goes to type in the amount but doesn’t press the tab key, again for the same reasons, resulting in the first field being filled with 17000. And again, this problem is solved by having the system check the second field is filled with some value.

In both possible input systems, the small check to ensure that there is a decimal portion of the number would prevent the error we see above. It seems like this system could add a bit of time to the number entry process with operators having to type in the penny amount even if there are none. But only one in every hundred bills will be a round pound amount. If the operator is used to typing in the pennies then typing the two trailing zeros will mimic their usual typing pattern (type the pounds the ‘decimal/tab’, ‘digit’, ‘digit’).

I can’t say for sure that this error did occur by human error but I think the evidence and suggested scenarios are compelling and plausible. Let me know if you have any other suggestions for what happened and ways to prevent it. Or if you have any inside information about how this process actually works!