How to keep critical systems running in capital markets

Erroneous software sometimes play havoc in Capital markets. In 2012, the NASDAQ and other global stock exchanges were affected due to erroneous software not once, but thrice within a period of just three months!

In May, Facebook’s IPO, one of the biggest IPO in technology, was plagued by a series of problems that originated from NASDAQ’s IPO Cross, a pre-IPO auction process that allows traders to place orders and agree on an IPO price before the stock is officially launched.

This software application, however, couldn’t handle the trading demand - the processing of Facebook share trades was delayed by 30 minutes. This delay caused a loss, estimated to be $300+ million, for a number of brokerages. NASDAQ is currently working on a compensation plan for these brokerages.

In August a gush of faulty trades were placed by an automated trading software of a major US trading firm Knight Capital on 1st August. The firm was unable to stop it for the greater part of an hour. This resulted in a reported loss of $400+ million. Knight Capital is now working with other firms involved to unwind the faulty trades.

Again in the same month, NASDAQ cancelled certain trades in Peet’s Coffee and Tea shares after some erroneous orders were found to have caused a steep rise ($73.89  $77.47 in the opening two minutes) in the share price in a matter of seconds due to erroneous trades triggered by software applications of some trading firms.

In a similar situation the Financial Services Authority, Britain’s Regulator of Financial Services providers sought from several of the largest banks and building societies in UK details of their IT contingency plans to prevent software glitches. This action was triggered by an incident earlier this year when many millions of RBS customers were unable to access their accounts for several weeks due to technical issues in a software update.

The Securities and Exchange Commission (SEC) is holding meetings to discuss concerns over software glitches and other trading errors. SEC may also order NASDAQ to revamp its processes from development to implementation of the Codes used.

The above incidents have raised many questions about the reliability of automated trading applications. There is a need for higher degree of Quality Assurance (QA) in these situations. The problem needs to addressed at the root (i.e., from the development stage of these software applications).

Some major reasons commonly attributed to erroneous software include unclear or incomplete requirements specifications, miscommunication, unrealistic schedules and inadequate testing.

CAN SUCH ISSUES BE ADDRESSED?
Good Project Management practices would address issues associated with requirements, communication and schedules. It is also essential that good coding and testing practices are in place to complete the safety net.

Coding: Good codes should be simple, readable, maintainable and well documented. The design should make provisions for flexibility and scalability. Flexibility makes the application more adaptable to future changes in business requirements. Scalability makes the application more adaptable to higher anticipated volumes of business transactions.

Testing: Good testing practices for data and transaction-intensive applications should include the following testing:

Black Box Testing: This Test is based on requirements and functionality and is not based on any knowledge of internal design or code.

White Box Testing: This is based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths, conditions.

Unit Testing: This micro level testing is used to test particular functions or code modules.

Incremental Integration Testing: This includes testing of applications on continuous basis as new functionalities are added to check for the performance of respective functions with the system in incomplete status.

Integration Testing: This includes testing of combined elements of applications to determine if they function cohesively together. These 'elements' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.

Regression Testing: This is the re-testing of applications after fixes or modifications of the software or its environment.

Load Testing: This involves testing of applications under heavy loads, such as testing of a web site under a range of loads to determine at what point the system's response time degrades or fails. This is also known as Stress testing or Performance testing.

Automated testing tools offer good help with regression testing and load testing.

In simple words, software applications should not surprise users and should definitely not err without warning! Needless to say, the key is ‘good team work with good practices’ to produce good code.

And good code makes a great difference especially for applications used in Capital markets.