The Need For Sanity Checks in Software

Thursday’s massive drop in the Dow Jones Industrial Average may have been caused by what some are calling a “glitch” or problem in a software system. The evidence is still trickling in, and key questions around whether the event was completely automated, was completely user-driven, or a bit of both, have yet to be answered. Whether or not automation in some form is responsible for the market drop, it is a good time to revisit the idea of “sanity checks” in software systems.

There have been “fat finger” problems in financial markets in the past. An incident involving the inadvertent sale of French government bonds in 1998 was caused by someone inadvertently leaning on their keyboard. A “fat finger” problem in May 2007 pummelled the London FTSE 100 when a trader typed “£300m” instead of “£30m”, selling 10x more share value than expected. A Mizuho trader “fat fingered” his order, selling 610,000 shares at 1 yen, instead of 1 share at 610,000 yen. Occasional typos in symbols on some pink-sheet and penny stocks on NASDAQ have caused runs on largely inactive shares. Even the possibility of inadvertently connecting a test system to live data needs to be considered (as humorously described at

These types of errors are alternately blamed on the software and on the user. The software developers will often take the stand that the person at the keyboard is responsible for their actions. The users, on the other hand, will ask why the software didn’t prevent such an obviously incorrect or nonsense action. While I can see the merit in both, I think it ultimately makes some sense to have the software “do the right thing” and ask the user if they are really, really sure before going ahead with an action that could be determined to be off the wall. I’ve worked on trading systems in the past where we built in checks and warnings. Many of our customers were in regions where markets could be very volatile, and they wanted to prevent problems like buying or selling “too far” off of the current price, or entering volumes far outside what was “normal”. The key is to make it configurable. What is “normal” in one market is “insane” in another.

The issue you can run up against, though, is the users themselves. Most want limits for everyone but themselves. I’ve met a lot of traders in a lot of different places around the world, and there is a common thread: the guy you talk to figures he knows better, but the rest of his compatriots need to be watched, because they will screw up. Of course, you politely agree with them, and then listen to their boss, who invariably expects all of them to make mistakes, particularly in the heat of an active market. In the case of these previous trading systems, we ultimately deferred to the people who actually ran the exchange, and they set the rules and limits on this type of thing.

I think that, for any type of order management or algorithmic trading system, there needs to be logic to either confirm or simply reject an attempt to place an order either far off the current price, or with dramatically more volume than is “typical”. For many symbols, there is plenty of history to know what the normal trading volume is for any given day, and what the normal variance is. For example, a system should seriously question an order to buy 100,00 shares of a stock that normally only trades 1m shares a day. It’s possible the trader meant 10,000 or even 1,000, but fat-fingered the volume. It could very well be a legitimate order, but making sure means avoiding potential problems.

For automated systems, the rules and logic needs to include something to prevent automated orders outside of certain limits. Those limits need to be flexible and configurable, and should be based on historical data. For example, there’s no point in building a rules that says “don’t vary from the last trade by $1” when the stock only trades at $0.20. My preference would be to configure the ranges as percentages, not necessarily as hard numbers. The rules, though, for a completely automated systems should be much tighter. Letting a piece of software run rampant, with no oversight, with the potential to seriously harm the economy is not a good thing. We don’t allow it for life-sensistive systems like avionics. We shouldn’t allow it for financial systems either. They need to have limits, those limits need to be reviewed and revisited on a regular basis, and having outside review from time to time wouldn’t hurt either.

Now, all this being said, at some point the person at the keyboard does have to take some responsibility. Software systems can have errors, and it isn’t always possible to predict every possible scenario in advance. The software should do as much as it can. There is a time, though, when the system can warn and ask, and it is still up to the user to ultimately decide “yes, I mean it” or “no, don’t bother”. Building smarter systems to allow the user that decision, and not just following instructions blindly, is still important.


One thought on “The Need For Sanity Checks in Software

  1. Pingback: Tweets that mention Yesterday's events on the markets got me thinking about sanity checks, and how they are important. --

Comments are closed.