Home » Story
You have been granted access to this page through First Click Free. Subsequent use of TabbFORUM will require logging in. If you don't have an account, registration is free.

Videos

  • Rail_thumb_adam_honore_david_etue-finqloud-safenet-cloud_security_in_financial_services

    Debunking the Cloud Security Myth

    The idea that the cloud is not secure is a misperception, says David Etue, SafeNet. While the cost and agility gains that come with moving to the cloud also come with a loss of some...
     
  • Rail_thumb_steve_phillips-nasdaq_omx-latam

    Latin America's Quest for Liquidity

    Brazil no longer is the only game in town when it comes to trading in Latin America. According to Steve Phillips, senior managing director, Latin America and Caribbean, NASDAQ OMX...
     
  • Rail_thumb_adam_will_screen_shot

    What Will Nasdaq Do With eSpeed?

    Following several failed cross-border exchange mergers, Nasdaq’s acquisition of the electronic fixed income trading platform eSpeed provides the exchange with a way to diversify...
     
 

More Video | Podcasts

Advertisement
Spotlight-blackInnovations in Trading and Technology (more stories)

14 December 2010

What Does the Flash Crash Mean for Financial Software Engineering?

In all the conversation about the flash crash and high-frequency trading, the real historic change is going unmentioned.

Every time someone finds out I work with high frequency traders, they want to talk about the May 6 Flash Crash even though it happened seven months ago. The recent Securities and Exchange Commission report has reinvigorated debate. Everyone with an opinion or agenda regarding high frequency trading, algorithmic execution and market microstructure is using the report to back up their arguments.

In all the conversation about the crash, the real historic change is going unmentioned. In the very last paragraph of the Lessons Learned section of the report, the authors note: “another area of focus going forward should be on the integrity and reliability of market centers’ data processes, especially those that involve the publication of trades and quotes to the consolidated market data feeds.”

This is a key insight – late in coming – that will expand over time. Traditionally the SEC has focused on regulating the behavior of market participants, identifying deliberately malicious behavior or patterns of behavior. But now they are beginning to realize that data processing, integrity, and reliability can be just as important. The efficient functioning of markets is in just as much danger from software system failures as it is from malicious traders.

These system failures don’t result from market manipulation. In highly liquid markets covered by HFT firms, attempts at market manipulation are easily noticed or even unprofitable. Other HFT firms are always ready to profit from inaccurate prices, and the open nature of modern markets prevents the formation of cartels. Market manipulation alone is not sufficient to bring about a flash crash.

Similarly, the “algorithms gone wild” that Professor Bernard Donefer described earlier this year in the Journal of Trading, will not precipitate a market failure. When United dropped 12% in 2008 in reaction to faulty news data, a lot of people were impacted. But the market infrastructure continued functioning properly and the issue was quickly pinpointed. Confidence in the broader financial system was not at risk. Donefer’s suggestions for stricter monitoring and managements of algorithms are a good start, but they don’t get at the true problem, which is that modern markets are fertile ground for system accidents.

In a system accident, tightly coupled components of a complex system fail in a cascade. Their interdependent failures form a Rube Goldberg machine manufacturing disaster.

System accidents were first described by Charles Perrow in 1984, focusing on military and industrial accidents such as the Challenger shuttle or Union Carbide plant in Bhopal, India. While there may seem to be a single cause of a system accident, such as a faulty gasket or operator error, further investigation finds tightly coupled systems with many opportunities for failure and a history of partial failures.

The SEC has been content to set only vague regulations around electronic systems to date. The result has been a lot of innovation, but also a lot of fragile systems. And in an increasingly coupled market, fragile systems without checks and balances are a threat to market stability. To avoid the kind of complex failure that precipitated the flash crash, we need individual systems that are robust and redundant checks on those systems.

The best defense against system accidents is to avoid focusing on the assignment of blame and to investigate near misses. The FAA, for example, has a highly effective anonymous reporting scheme and highly trained investigators. According to research published by Nanex and personal conversations with other firms, delayed quotations similar to those during the flash crash occurred earlier this year. Had the SEC investigated these and other near misses, system reliability could have been improved before a full-scale system accident.

Luckily, good engineering practices are already well established in other industries. The field of software safety engineering is over 20 years old. Improving the reliability of our systems and the market as a whole can be undertaken methodically.

Market participants that develop custom software, from hedge funds to exchanges, will need to improve their engineering practices. At the same time, financial regulators can learn from the success of regulators in other technology-heavy industries, from online banking to space exploration.

By applying better software and systems engineering to the capital markets, we can make markets that are both efficient and reliable.

Spotlight-white-trans For more stories in the Innovations in Trading and Technology Spotlight Series click here.

Comments | Post a Comment

9 Comments to "What Does the Flash Crash Mean for Financial Software Engineering?":
  • Missing
    jeley

    14 December 2010

    Richard: Great post. This is an uncovered topic that is clearly important. It will be interesting to see what the rules look like

    Comments (8)

  • Comment_me
    colpclark

    14 December 2010

    Richard, are you implying that the flash crash was caused by different reasons than those highlighted in the SEC's report?

    Comments (20)

  • Missing
    donefer

    14 December 2010

    I agree with Richard completely. The flash crash was the result of a complex and fragile market structure and not an algo issue. Regardless, our algo and quant models need to be carefully engineered by people who understand the markets. I am pleased to see that the SEC is not acting based on this one event, but is looking at the entire financial eco-system.

    Comments (2)

  • Comment_me
    colpclark

    14 December 2010

    I've been saying, since the beginning, that HFT had nothing to do with the flash crash. It's in writing, on my blog. The question I'm asking, and that Richard seems to point out, is that he believes the crash was caused by slow quotes.

    Comments (20)

  • Comment_streambase_cto
    tibbetts

    14 December 2010

    Colin: I'm not taking a side in the question of cause and effect or blame. I believe that slow quotes probably made the problem worse, which I have heard from several trading firms. More importantly, slow quotes would be indicative of infrastructure problems that are important to resolve. Isolating the problem to a single "cause" and declaring victory over that cause is not an effective way to build reliable systems. We should be working hard to learn from everything that occurred during the crash, and from other anomalous behavior on non-crash days. By resolving problems before they cause systemic failures can avoid some of the future system failures.

    Comments (3)

  • Comment_me
    colpclark

    14 December 2010

    Richard: I agree with you - slow quotes in and of themselves may have actually been an effect, and not a cause. Or maybe both. Who knows? I think the important thing we all learned from the flash crash is that the 'market structure' is broken. And all we've seen from SEC is an attempt to build a 'database of all things' that will help us arrive at the same inconclusive end we find ourselves at today. I'm glad to not hear you say that CEP could have prevented the crash as many of the other CEP based product vendors were quick to incorrectly claim.

    Comments (20)

  • Comment_streambase_cto
    tibbetts

    15 December 2010

    Well, some of our customers used StreamBase CEP to clean own their market data well enough to not trade on bad data during the flash crash. So there is your shameless plug for StreamBase. CEP is a tool that can help build a better system, but there is a lot more to building a culture of good engineering than just using the right tools. Having a database of all things might help the SEC do investigations, but they need to be doing the right kind of investigations (preemptive, cooperative, constructive) if they are going to make the markets more reliable.

    Comments (3)

  • Missing
    davidcox

    16 December 2010

    Great blog. Ultimately it comes down to data. We need clean data to execute trades and manage risks. But there will always be part of the market that is not invested in transparency, and sees alpha in the opaque. BTW we have seriously over analyzed the Flash Crisis, and ignored the real story about how well the markets have recovered.

    Comments (12)

  • Missing
    rkozhikk

    17 December 2010

    Good point. System Safety has long been ignored by the mainstream software engineering community. In case you are interested, please look up work done by people like Nancy Leveson, Missy Cummings at MIT and other places. Yet, time and time again, we fail to learn the right lessons. Blaming technology is easy - fixing engineering methods, choosing the right tools and nurturing a safety culture, that's a lot tougher. (Obligatory disclosure: I am associated with TIBCO Software and MIT Engineering Systems Division)

    Comments (1)

You must log in to comment.