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.


  • Rail_thumb_ted

    What happens when our computers get smarter than we are?

    Artificial intelligence is getting smarter by leaps and bounds — within this century, research suggests, a computer AI could be as "smart" as a human being. And then, says Nick Bostrom, it will ...
  • Rail_thumb_aesthetic

    Avoiding Algo Disaster

    As the markets have grown increasingly complex, so too have the algorithms designed to navigate them. And capital markets firms increasingly are challenged to manage the risks associated with this algo ...
  • Rail_thumb_leap-second

    Forget Leap Year. What's a Leap Second?

    The leap second happens every few years when the standard time around the world is adjusted by one second to account for a slight mismatch between clocks and the earth’s rotation. And it has some exchanges and ...

More Video | Podcasts


03 August 2012

Time to Revisit Design and QA of Mission-Critical Systems

In today’s competitive markets, the urgency to "get it out" has superseded the rationale to "get it right."

Recent high-profile market disruptions illustrate the need for design reviews and quality assurance reviews of mission-critical trading systems. In today’s competitive markets, the urgency to “get it out” has superseded the rationale to “get it right.”

Lack of proper attention to detail/oversight, making production changes on the fly, etc. can lead to operational risk or reputational risk. Both can be costly as we have seen in the last few months and can lead to significant realized losses.

As markets have become more fragmented, inter-linked and reliant on high velocity data, the complexities of systems design and interrelationship of these “moving parts” may not be fully understood by technologists or business staff.

This becomes exacerbated when something goes wrong, and the law of unintended consequences comes into play. These hit the media as “software run amok,” “rogue software” or “tech glitches.”

In the last five to seven years, algorithmic trading has permeated global markets – equities, options, futures, and, as electronic market making has taken off, so has the phenomenon of proximity hosting (aka co-location).

Competition, market structure changes, smart order routing and shrinking margins have driven the need for speed and smart technologists discovered ways to gain an edge via low-latency hardware, software and network technologies. This arms race has escalated the speed at which trades are executed at and the overall market velocity.

Business analysts and trading systems software designers need to have sanity checks – both in systems design review by humans – and in the logic of the system code. An order or trade that moves the market and creates a new high or new low outside the primary market – may not be the intent of the trading strategy or the system’s design.

Trading systems should have logic in the code or circuit breakers that stop run-away algorithms or slow down order flow, so that humans can intervene and determine what the underlying problem might be. Once an abnormal or unrealistic market condition is detected, the system should have separate logic on how/when to handle it. This could be as simple as stopping or slowing the order flow and presenting it to an experience trader for review/release.

The Knight problem may have been as simple as a trader that missed a setting for a TWAP algo (e.g., set the order to execute in five minutes versus five days), or as egregious as an inadequately tested software release.

The technology disruptions at BATS, NASDAQ and now Knight Capital that roiled the market could have been avoided if those firms invested the time and effort to do a proper code review and extensive testing of the system.

The types of problems are difficult to totally prevent and cannot be solved via regulation.

We believe they can be mitigated by:

  • Conducting software walk-throughs with both software engineers and subject matter experts:
  • How should the system react  under conditions of normal  market irregularities
  • How should the system react under conditions of abnormal behavior
  • Regression test the system over periods of low and high volatility
  • Back-testing for highly irregular trading (high water mark days) (e.g., Oct. 19, 1987, May 6, 2010)

 Conducting QA reviews for defects in application design logic; stress and regression testing.

Add a Comment

You must log in to comment.