After you have been in a field for while you start to see classic problems and painful lessons reoccur. After I wrote my post on the 'Flash Crash' a few months ago I have been watching on and off for more detailed information about happened on May 6th.
A few friends that had read my first post sent me various articles about the SEC/CFTC report that came out last Friday. I took some time to read the report which is pretty underwhelming but a few things jumped off the page at me. The first was the use 'Stub Quotes'. I don't think Stub Quotes caused the problem (maybe it did), but rather aggravated it once it was rolling.
Stub Quotes are based on an age old bad software technique that most software engineers learn to avoid very early on, the temptation of overloading the meaning of data in the system. Formally this is known as the Semipredicate problem.
Here's a simple unrelated example of the problems of overloading a variable meaning..
Say you're building a weather station that consists of hardware and software. You realize well into the project that you need to represent that the temperature sensor is sometimes deactivated. In other words, sometimes for one reason or another temperature is not available to your software. Ideally, you would have another variable in your code that is set from another signal that states, "no temperature is currently available". But, due to various other factors, you don't have that available to you. So to get around the problem you 'agree' with your fellow system designers that -20 degrees 'means' there is no temperature. It's a convenient value to use as your intended design calls for the weather station to only be deployed in tropical areas. So, in other words -20 degrees will never be a true temperature, but will rather be your signal for 'we don't know the temperature'. Then, of course one day it's used in Canada and the system shuts down every time the temperature hits -20 degrees.
Stub Quotes are exactly like the weather station example. When an exchange decides that it wants to suspend transactions in a stock, it tells potential buyers that the ask is now $100,000 share and it tells sellers that the bid is $.01. This, under normal conditions keeps a trade from happening, using the data channel (the quote) as the communication system. In other words it assumed no one will sell for $.01 a share and no one would buy for $100,000 share.
Amazingly, this is a common mechanism in exchanges. Problem is, on May 6th, our stock market turned into the equivalent our weather station getting installed in Canada. As prices crashed and stop loss orders turned into market orders, computers started to require trades outside of the norm. Stub Quotes, turned into real transactions. Wow.
A lot of these trades appear to be the 'erroneous' trades that got reversed on May 6th. Fascinating and it stems from the requirement of the SEC for exchanges to always provide a two sided transaction. There simply isn't a way for them to step back from the table and choose NOT to do the transaction or signal in another way that it's not going to happen right now.
I'm sure I have simplified this too much and the reality is much more complex but it's always interesting to me when the same kinds of lessons reoccur. Flash Crash is a super interesting subject and I can't help but think the worst is to come with all the automated trading that's happening. For now the SEC is looking at eliminating Stub Quotes, but with a system as old as the stock market there are literally thousands of these kinds of things lurking in that system.
I find it interesting that SEC goes out if way to make companies comply to the ideal the 'simplest investor' needs to understand your company and its metrics. The burden as a public company is on you to communicate clearly and simply. That's all fine, but there is no such requirement for exchanges to explain how they interact with each other, how fast they can execute a trade, etc. In 1987 the NYSE would process about 600M trades a day. Today that number is something like 12B. As these trades get faster and faster the systems that interconnect the exchanges play and larger and larger role in the economics of the transaction. How does the individual investor 'understand' this?
There's an old saying, "you never eat at the restaurant you work at". Having spent my entire career around real-time and pseudo real-time systems with speed demands or volume demands, I get more and more concerned that there is a day of wrecking coming with the stock market and no one will see it coming..