Prof. Jayanth R. Varma's Financial Markets Blog

Photograph About
Prof. Jayanth R. Varma's Financial Markets Blog, A Blog on Financial Markets and Their Regulation

© Prof. Jayanth R. Varma
jrvarma@iima.ac.in

Subscribe to a feed
RSS Feed
Atom Feed
RSS Feed (Comments)

Follow on:
twitter
Facebook
Wordpress

January
Sun Mon Tue Wed Thu Fri Sat
   
11
   
2013
Months
Jan
2012
Months

Powered by Blosxom

Fri, 11 Jan 2013

Why exchanges should be forced to use open source software

For more than a decade now, I have arguing for using open source software in critical parts of the financial system like stock exchanges (here and here) and depositories (here). At the risk of sounding like a broken record, I want to come back to this in the light of the following cryptic announcement from the BATS exchange in the US two days ago:

Please be advised that BATS has determined that upon an NBBO update on BATS’ BYX Exchange, Dividend Notifications BZX Exchange and BATS Options, there are certain cases where the Matching Engine will allow for a trade through or an execution of a short sale order at a price that is equal to or less than the NBB when a short sale circuit breaker is in effect under Regulation SHO. These cases result from the sequencing New Listings Short Sale Circuit Breakers of certain required events in the Matching Engine related to re-pricing and sliding orders in response to the NBBO update.

I found this almost impossible to understand as it is not clear whether the scenario “when a short sale circuit breaker is in effect” applies only to the second type of error (“execution of a short sale order at a price that is equal to or less than the NBB”) or also to the first type of error (“trade through” the NBBO). Focusing on the first type of error, we can make some headway by consulting the BATS exchange User Manual which describes the price sliding process with a numerical example:

Example of BATS Displayed Price Sliding:
NBBO:
10.00X10.01
BATS:
10.00X10.02
1) Buy BATS-Only Order at 10.03
2) Order is re-priced and ranked 10.01 and displayed down to 10.00 (10.01 would lock the NBBO)
3) NBBO goes to 10.00X10.02
4) Order is re-displayed at 10.01 using its existing priority
5) NBBO goes to 10.01X10.03
6) Order remains unchanged (it’s only allowed to unslide once after entry)
Note: Order will always execute at 10.01 regardless of its display price at the time

But even with this explanation, it is hard to understand the precise nature of the software bug. My first thought was that in the above example, if the NBBO moved to 9.99X10.00, the sliding order might execute at 10.01 if it were matched against an incoming order at the BATS exchange order. On second thought, I ruled that out because it is too simple not to have been thought about during the software design. Maybe, it is a more complex sequence of events, but the terse announcement from the exchange does not really tell us what happened. It is interesting that even when admitting to a serious error, the exchange does not consider it essential to be transparent about the error.

Over a period of time, exchanges have been designing more and more complex order types. In some ways, these complex order types are actually the limiting case of co-location – instead of executing on the trader’s computer located close to the exchange server, the algorithm is now executing on the exchange server itself, and that too in the core order matching engine itself. The same business logic that favours extensive co-location also favours ever increasing complexity in order types.

In this situation, it makes sense to mandate open source implementations of the core order matching engine. As I wrote six years ago:

It is also evident that in a complex trading system, the number of eventualities to be considered while testing the trading software is quite large. It is very likely that even a reasonable testing effort might not detect all bugs in the system.

Given the large externalities involved in bugs in such core systems, a better approach is needed. The open source model provides such an alternative. By exposing the source code to a large number of people, the chances of discovering any bugs increase significantly. Since there are many software developers building software that interacts with the exchange software, there would be a large developer community with the skill, incentive and knowledge required to analyse the trading software and verify its integrity. In my view, regulators and self regulatory organizations have not yet understood the full power of the open source methodology in furthering the key regulatory goals of market integrity.

But it is not just the exchanges. Regulators too write very complex regulations which too should ideally be written in the form of open source software. Instead, regulators all over the world write long winded regulations and circulars which are open to many different implementations and which do not function as expected when they are most needed.

Posted at 12:23 on Fri, 11 Jan 2013     View/Post Comments (0)     permanent link