Feargal O’Sullivan and Jamie Hill of NYSE Technologies discuss OpenMAMA, the open source middleware Agnostic Messaging API they hope will expedite innovation in services, reduce vendor lock-in and minimize implementation time and cost.

Feargal O'Sullivan, NYSE TechnologiesSolving a Problem
Choosing a market data vendor because of their API alone is not sound practice. The issue of how to come up with a standard way of accessing market data that allows clients to select a vendor for any range of reasons – other than the API that the vendor happens to offer – has been a struggle for a long time. Something that should be low on any decision-making tree has unfortunately tended to be much more important. There are a number of different consolidated market vendors, including some obvious names like Thomson Reuters or Bloomberg and there is also a range of direct feeds or ticker plant vendors, where instead of going to a consolidator, feeds are accessed directly from an individual exchange.

In selecting a vendor, users must write all their code to suit that vendor’s particular way of accessing the data. Changing to a different vendor requires opening up the source code and altering everything to match how this other vendor wants to access the market data. With a consolidated feed for broad international access and a direct feed for low latency algo trading in US equities, for example, many users have to write according to two to four different APIs. This has been a significant problem for the industry and with OpenMAMA we are trying to drive the industry towards a standard.

User Base
This API is an eight-year-old standard that was initially developed by NYSE Technologies as the Middleware Agnostic Messaging API (MAMA), and it is quite heavily deployed in the financial services industry; close to 200 clients already use this API in their custom applications, so today it has an established installed base. We have opened that up and made it a standard by taking the source code for the APIs these firms are using today and provided it to The Linux Foundation, which will physically host the code as a neutral body.

During this process we worked with multiple parties that would not ordinarily use our API. Since the launch of OpenMAMA on 31 October 2011, one of the key factors to this being taken seriously as an open installation, was getting the right level of adoption. Before we launched, we approached a number of customers, other vendors and competitors, out of whom we established our launch partners J.P. Morgan, Bank of America Merrill Lynch, Exegy, Fixnetix and EMC. These launch partners, along with NYSE Technologies, formed a steering committee to drive the direction and the future of OpenMAMA.

From that point forth, each of those organizations who are part of that committee has a stake in Open MAMA. The API is open source under the LGPL 2.1 licence, so it is now owned by the open source community. With participation from Interactive Data, Dealing Object Technologies and TS-Associates as well, we now have a group ten strong and it is a global mix comprising different industries. Whereas before the API was driven largely by NYSE Technologies and our commercial use cases, now it is being driven forward as an industry standard. The more people we have to adopt and participate, the higher the likelihood of achieving that.

CME Group’s Fred Malabre and Don Mendelson chart the history of electronic commodities trading and discuss the recent improvements in FIX for commodities, including fractional pricing, trading listed strategies and faster market data. 

Fred Malabre, CME GroupAdoption of FIX for Commodity Trading
Products traded on CME Group exchanges have many underlying asset classes, including commodities, interest rate instruments, foreign exchange and equity indexes. Although the largest share of products traded today on our platforms are financial futures, the history of our markets began with agricultural and livestock commodities. The underlying physical commodities include the petroleum complex, agricultural products such as soybeans, wheat and corn, and metals such as gold and copper.
 
Listed contracts in all of our markets include futures and options on futures. The futures contracts can be physically settled, meaning that a seller has an obligation to physically deliver the commodity to the buyer when the contract expires at a delivery point specified by the contract, or cash settled, which are products that could not be settled to an index.

Back in 2001, we were at a crossroads. At this time, futures contracts were primarily traded via open outcry – brokers shouting and waving arms in trading pits. At that time, CME launched its first FIX compliant interface to electronically match orders for a wide range of asset classes ultimately including equity indexes, FX, interest rates, real estate, weather, economic events, energy, metals and agriculture. The question arose: how do we represent orders and execution reports and transmit them between firms and the exchange? We had earlier put out its own order routing API, but it had some drawbacks, including the high level of software developer support required. Firms were running several different computing platforms, for example.  

At that time, the FIX Protocol had begun well in the equities world. It was attractive because it was not an API, but rather a standard for message exchange. From the exchange’s perspective, this was an attractive proposition: we would develop our side of the conversation, and firms would develop theirs. From the firms’ perspective, their software developers could achieve high performance, only limited by their own imagination and skills.
 
It seemed that with a few adjustments, FIX could be adapted for futures and options trading. In version 4.2, fields were added to support derivatives, including expiration and strike price. We participated in working groups to standardize those changes, and later helped spawn FIX-based solutions for market data and FIXML for clearing.
 
An example of a problem with adapting an equities standard to commodities is fractional pricing. Traditionally, agricultural prices were stated in fractions. To this day, soybean futures are quoted in increments of ¼ of one cent per bushel. US equities made a leap from fractional to decimal pricing in 2001. Although trade pricing stuck with tradition, we decided to follow FIX conventions with decimal pricing in messages.
 
We added some custom indicators within our FIX interface to facilitate conversion to a fractional display. One indicator represents the main fraction and another represents the sub-fraction. For example, for a product ticking in ½ 64th, we would send the main fraction as 1/64 and the sub-fraction as ½. These indicators could then be used to convert a decimal price used over our FIX interface as 105.0390625 which would then be converted to a screen display as 105 2.5/64th. We found that the FIX Protocol is easy to extend to add custom features and can easily be extended for legacy needs with negligible impact to customers not using new tags such as the custom indicators talked about previously.

Few markets can boast the growth numbers seen in the South Africa trading community over the past five years. Technology provider, Peresys, has championed the development of electronic trading and FIX during this period. Ashley Mendelowitz, CEO of Peresys, looks at what other emerging markets can learn from the southerly nations experience.

The adoption of the FIX Protocol and concomitant growth in electronic trading in South Africa has been nothing short of prodigious. A little over five years ago the local trading environment had the characteristics of your typical turn of the century emerging market – comparatively low volumes, telephonic orders, paper based order management and error strewn post trade administration.

Half a decade later, and the picture has altered in dramatic fashion. The value of cash equities traded on the local exchange has sky-rocketed to US$34.6 billion in October 2008, from US$6.6 billion five years earlier, an impressive 424 percent increase. Offshore originated electronic trading accounts for up to 25 percent by value traded, while upward of 90 percent of local institutional orders are now routed electronically. Capping the meteoric growth, South Africa now has the largest single stock futures market in the world, by number of contracts.

None of this would have happened without the FIX Protocol.

The seeds were sown as far back as 1997 when the top two or three buy-side firms began to explore options in terms of taking their equity desks electronic. It quickly became clear that the barriers to automation were high and wide. These included:

  1. Non-existent order management systems on the buy-side and sell-side
  2. Telecommunications monopoly and exorbitant bandwidth costs
  3. Reluctance of traders on either side to change their work flow
  4. Lack of open application programming interface (API) to the exchange matching engine or broker trading systems
  5. Virgin territory insofar as a globally accepted messaging and session management protocol for pre-trade and trade messaging
  6. Lack of local or international vendor appetite to invest in building a workable solution that addressed all of the above barriers.

Breaking Down Barriers
It took some five years to gradually knock down or climb over the barriers above, through cash and resource investment, constant evangelising the benefits of electronic order routing by the converted (including our firm) and, critically, the buy-in and backing of a buy-side champion. The first buy side champion in South Africa not only committed its firm to the concept, but also made it clear to its sell-side counterparties that the telephone would be phased out within twelve months.

In 2003, the implementation of a first buy-side to ten brokers began, as well as the selection of a FIX engine provider flexible enough to price their product at ‘emerging market’ levels. Within three years, the first FIX hub had established a South African footprint spanning eight of the top ten buyside firms, the top thirty five broker members of the local exchange and a large chunk of local and international hedge funds trading SA equities.

Once Direct Market Access (DMA) was allowed on the SA equities exchange, the ability for brokers to receive orders via FIX played a key part in the exponential growth in DMA trading volumes originating from outside the country. Multinational investment banks and hedge funds could leverage their existing FIX infrastructure to trade into SA in a cost effective, reliable and high speed manner.

Today all the barriers to electronic trading have been removed:

  • Local and offshore vendors have successfully rolled out FIX compliant OMS products
  • Local telecom competition and the decision to connect the local Hub to any global FIX network based on demand has translated into cheap connectivity
  • Traders have seen the financial benefit of increased order flow through electronic messaging
  • The exchange implemented a comprehensive and well documented API
  • FIX has addressed all user concerns about a global standard for messaging formats, workflow and session management
  • Electronic trading pioneers paved the way for other buy-side/brokers/vendors to follow in offering products that exploit FIX, including hubs, order management systems, algorithmic trading and IOIs

Working on a Porsche analogy: To say that all Porsches are slow is, clearly, about as ridiculous as saying that FIX is slow! Kevin Houston explains.

All early Porsches have their roots in the design of the Volkswagen Beetle designed by Ferry Porsche’s father Ferdinand. The VW Beetle is only capable of about 80 mph and even that would be at the cost of a terrified driver. Early Porsches share a lot of their design elements with the Volkswagen, however that does not mean that Porsches’ are slow. Many of us will have been on track days where we have driven Porsches around a race track, hitting speeds of well over 80 mph, without inducing any great feelings of fear.

The early FIX engines, designed in an era of simply routing care orders between the buy-side and sales traders, are also slow and if used for modern high speed trading would result in traders nervously guessing whether each message would be one of the lucky ones that went through quickly or, more probably, one of the unlucky ones that took several seconds to arrive at its destination. Again some of us can testify that these early engine do not represent the state of the art; equally, however high velocity trading houses, today, are using FIX to trade in around 250 microseconds and a small number of FIX engine vendors are currently capable of consistently beating 10 microseconds for message processing, delivering throughput of around 100,000 messages per second.

To say that all Porsches are slow is, clearly, about as ridiculous as saying that FIX is slow. The remainder of this article examines the second myth in more detail.

First a bit of History
FIX started as a pilot between Salomon Brothers and Fidelity Investment to automate the placement of orders, the reports of executions and the distribution of advertisements and IOIs. Indeed many early FIX implementations did not even place the order electronically, but only reported the executions after order placement. At this time there was only one FIX engine on the market place and the price was extremely high, with the performance, by today’s standards, being extremely low. FIX adoption was driven by error reduction and the like. The arrival of the early commercial FIX engines did the community a great service by creating cheaper alternatives; but the performance bar was not very high. Often when people now refer to FIX as being slow, they are using the yard stick of early FIX engine performance as the measure. Since then and particularly over the last 5 to 10 years, increasing emphasis has been placed on the performance of FIX driven by a number of trends, and the FIX engine vendor community has responded. Some have accepted their current performance levels as adequate for order routing but not DMA and focused on that market; others, often new entrants, have engineered FIX engines from the ground up, to focus on future-proofing performance.

The drivers behind this need for speed are worth noting:
• Increased market data
• Increased order volume
• Exchange adoption of FIX
• Large percentage of trades going electronic
• Rise and rise of algorithmic trading

These drivers lead to two separate performance needs, high throughput and low latency. Whilst these are related needs there are optimisations that can be made that favour either. For example, FIX communicates over TCP/IP, typically a FIX message uses a few hundred bytes, but an IP packet has space for around 1,400 bytes of information. A setting on the IP communication layer allows you to select whether packets should be held back to wait for additional information that can be sent in the same packet.

This obviously improves throughput as the receiving application has to process fewer packets, but it has the potential drawback that it increases latency for at least the first message by it having to wait for subsequent messages. So, whether you allow this hold-back or not depends on your performance needs, or profile. This process was first introduced by John Nagel and is named after him; see http://en.wikipedia.org/wiki/Nagle’s_algorithm for more details. OK, so FIX can be fast but a lot of the implementations out there are dated and therefore can be slow; so, are there other things FPL is working on that will help with performance?

Where are we today, how long does it take?
Let’s take a look at some of the time costs in sending a FIX message. Obviously this is a very rough estimate and there are a lot of variables, but here are some general timing that are worth covering. Firstly, there is constructing the message, which typically takes something like 10 microseconds, saving a copy before sending, 50 microseconds; sending it to the wire, typically 10 microseconds; transmission time, a function of distance but easily worked out as distance divided by 2/3 the speed of light; switching time, a function of the number of routers and switches and their ilk, via the operating system into the user space, say 10 microseconds; and finally parsing in user space 10 microseconds. There are a number of ways you can improve these such as saving the copy of the message asynchronously, etc., but that still leaves a lot of time spent building the FIX message and it’s tag = value syntax.

An increasing number of exchanges and clearinghouses are adopting FIXML, an XML version of the FIX Protocol, for communicating post-trade data. Now it is time for clearing firms and vendors to weigh in. If the clearing members want to encourage the adoption of a global standard for post-trade messages to eliminate managing multiple interfaces, then 2010 is an important year. Eurex, NASDAQ OMX, MEFF and LCH.Clearnet are asking for user input on the initiatives they have underway.

FIXML is being implemented in various stages at exchanges in the U.S. and Europe. Major U.S. clearinghouses have implemented FIXML for all post-trade data and are offering additional functionality via FIXML. Certain European clearinghouses are testing the water by offering specific post-trade data via FIXML alongside their proprietary interfaces. If clearing member response is positive, they will make additional messages available via FIXML.

The widespread adoption of a post-trade standard interface will have significant benefits for clearing members. Managing proprietary interfaces with more than 60 exchanges that trade futures and options is time consuming and costly. The events of the last two years have driven more attention to costs and controls, says Conor Sherrard, Executive Director and Business Manager for Europe, Middle Eastern and African futures and options for J.P. Morgan. “The technology exists to deliver even greater straight through processing and cost reduction but without the adoption of an international protocol, firms are faced with having to maintain multiple systems to replicate essentially the same functions across the range of exchanges and clearinghouses they access,” he explains.

Legacy interfaces can sometimes limit the functionality available to clearing members. “By adopting this initiative we would lay the foundation to achieve critical improvements around risk management, more accurate trade commissioning and even greater automation across operations in areas such as close-outs,” says Sherrard.

FIXML provides a flexible method of formatting and describing data so that it can be recognized by other systems. Data values can get as large as needed because there are fewer limits imposed by the format of the message. The number of data fields contained within a transaction record is limited only by the message definition. Contract and account information may be added as necessary without size or format restrictions. For numeric values containing decimal points, XML allows flexible decimal place positioning, eliminating price alignment inconsistencies. On the exchange side, new products can be brought to market faster and more efficiently. The standard supports complex and non-vanilla products more easily and offers fewer barriers to entry for new exchanges.

The emergence of FIXML as a global standard began in 2000, when the Futures Industry Association launched an initiative to create a standard interface for clearing organizations to communicate with their members. The Chicago clearinghouses recognized that their ability to offer new products and new post-trade functionality was limited by their reliance on TREX, the messaging standard developed in the early 1990s for Chicago Mercantile Exchange and Chicago Board of Trade to communicate with members. CME, CBOT, Options Clearing Corporation, New York Mercantile Exchange, and New York Board of Trade participated in a working group that considered several formats before settling on FIX, which was widely used on the front-end.

The clearinghouses did not want to be limited by a fixed number of characters in the message so they agreed that XML (eXtensible Markup Language) should be the basis for the post-trade format. They approached the FIX Protocol Organization about creating an XML version of the FIX Protocol.

While firms agree that a common interface globally would be more cost efficient, it was the threat of regulatory intervention that prompted the U.S. and European exchanges to work together on a common standard for the listed derivatives industry. In 2003, the Giovannini Group, a quasi-governmental body established by the European Union to identify the principal barriers to cross-border clearing settlement, directed European exchanges to agree a common messaging protocol for European exchanges. U.S. exchanges had already begun adopting FIXML as a standard and the futures industry wanted to avoid one standard for the U.S., another for Europe and perhaps a third for Asia. FIA approached the European exchanges about agreeing a global standard.

The FIA and the U.K. based Futures and Options Association established a cross-border post-trade working group (PTWG) in 2006 which included CME, Eurex, New York Mercantile Exchange, New York Board of Trade, LCH.Clearnet, MEFF, OCC, and OM. Recent additions to the group include Intercontinental Exchange, and NYSE Liffe.

OLMA Investment Company’s Alena Melnikova and Valerian Zamolotskikh assess the Russian exchanges and comment on DMA and algorithmic trading.

Are algorithms widely used by Russian trading firms, and what asset classes are they used for (options, futures, ForEx, bonds, commodities)?

Algorithmic trading on the Russian market is relatively well developed. According to average estimates, about 60% of trading volume in our market is created by algorithmic trading systems. We use strategies similar to those used in Western markets: market making, arbitrage, pair trading, stochastic methods. However, algorithms for minimizing impact costs are not very popular, because there are few participants who can sufficiently affect prices. Algorithms to minimize market impact will be more popular with the advent of large participants and new funds. Trading firms widely use market making and arbitrage strategies, while stochastic methods are widespread amongst common traders.

Algorithmic trading in general and stochastic methods in particular are widespread amongst traders because the share of traders with strong mathematic skills is relatively high. These traders use stochastic methods for developing strategies and program algorithms for them. On the other hand, brokers meet traders’ requirements and develop trading platforms for the opportunity to connect traders’ applications with their platforms by API, internal programming language and so on. Algorithms are mostly used for futures, and slightly less for options, but the most liquid instruments in Russia are futures on the index RTS; the majority of algorithms use this asset class. 

Do you see an increase in DMA to Russian markets, and if so, will it come through equities, derivatives, ETF’s or other products?

It is difficult to say if DMA is developing in some specific products. Often, it depends on the exchange that provides the DMA. DMA is developing in equities on MICEX and in derivatives on RTS through the RTS Standard (equities T+4). DMA will develop proportionally alongside current liquidity. Futures on the RTS Index and Sberbank shares (on MICEX) remain the most interesting for algorithmic traders. As for ETFs, they are a new product on our market and are not very popular at this time, although we do expect development of DMA in this asset class.

How will data centers and increased connectivity, within Russia and out to London and international exchanges, affect high frequency and algorithmic traders?

We think data centers and increased connectivity will have a positive impact on our financial system generally, and on HFT in particular. First of all we expect increasing liquidity in commodity, currency and index futures. Second, narrowing spreads will result in an increase in trading volume and more arbitrage strategies, for example ADRs-equities. Third, with the advent of foreign HF traders, local traders have to improve their technologies, equipment and strategies, all of which certainly will have a positive effect.

Are Russian exchanges’ trading architectures ‘fast enough’ and what do RTS or MICEX need to do to meet Russian traders’ demands?

From our point of view, the Russian exchanges’ trading architectures are considered fast enough. An average round trip is 10-20 microseconds for both RTS and MICEX. What is more, RTS makes continual efforts to improve the trading environment. Last year RTS launched a new protocol Plaza II, which aims to improve and accelerate trading conditions. RTS is much more mobile, determined and creative, fast to meet investors’ requirements and ready to discuss improvements to their current work. Technical failures, however, can happen on RTS. MICEX is stable, but tends to develop slowly, which limits its appeal for HFT clients. HF traders seem to choose RTS, which offers halved fees for intraday trading and allows them to place their equipment in RTS’ data center on more attractive terms.

What is your impression of Moscow’s future as a financial center?

I would have to say that much remains to be done. However, in recent years, market professionals with the state’s support have made important steps in this direction. For example, the taxation of derivatives adopted last year. Of course, it is difficult to compare Moscow with other financial centers now, but the prospects are very encouraging.

The Vienna and Ljubljana Stock Exchanges comprehensive FIX upgrades reinforce the continued global trend for reliance on FIX over an alternate proprietary technology. Annie Walsh, Chief Marketing Officer for CameronTec, examines a case for FIX.

2010 was a pivotal year that saw many local exchanges fending off new, unfamiliar competition in what for many regions have traditionally been non-competitive market places. With competition continuing to intensify and once cozy monopolies progressively being dismantled, the stakes have rarely been higher. If regional consolidation was 2010’s buzz, then 2011 will be characterized by structural reform, increased central clearing and the emergence of a host of new players that will be ushered in as a result of Dodd-Frank and EU legislative equivalents.

The paradigm shift has been good for FIX. Looking back it was the emerging new trading venues that first demonstrated considerable appetite for FIX. Their motivation was driven by an acknowledgement that FIX could provide ease of entry into markets and a competitive edge for attracting liquidity away from the traditional exchanges. Exchanges can no longer operate in isolation within segregated vertical markets. Their consolidation due to mergers and the emergence of alternative trading venues has escalated the importance of technology around the trading lifecycle. Latest figures indicate just how much liquidity the new marketplaces are attracting. Volume for BATS, Chi-X, Pure Trading and Alpha ATS, to name a few, show significant levels of liquidity shared by a broad number of different venues.

Field-leveling regulations such as MiFID and Reg NMS have also put the spotlight on technology with a growing focus on reducing latency that has implicitly changed the exchange business model. Competition for exchanges is about performance and cost, with the highest performing and lowest cost marketplaces attracting the most liquidity. Now, more than ever, the need for a more uniform API has become a critical consideration, and this is one area where investments in technology are being made. Exchanges today recognise the considerable benefits of an exchange compliant FIX interface on a number of fronts.

The FIX Protocol is increasingly providing the level playing field for many market  participants, while encouraging exchange market differentiation across more value added service areas, such as Straight Through Processing (STP), latency, trading platforms
and strategies, corporate services and increased data offerings. FIX enables exchanges to take advantage of economies of scale and provide broader access as well as generate the additional revenues the business requires.

The Vienna and Ljubljana exchanges are two marketplaces within the CEE Stock Exchange Group (CEESEG), now using a cutting edge FIX API for trading access, order routing and market data. CEESEG’s decision to offer this to members is in response to participant support for the protocol over any proprietary alternative. On the business side, leveraging FIX across CEESEG’s exchange members provides a more flexible and cost efficient solution.

The appetite for the fastest possible interface will always be present and FPL’s continuous, collaborative work with the exchange community, evidenced with a number of working groups, has resulted in improved latency, making FIX messages more suitable for high speed trading. Through FIX 5.0, for example, exchange clients will find it easier to implement a more flexible, faster connection to the exchange. Exchanges are increasingly taking advantage of the latest advancements in FIX and using it to establish points-of-presence in major liquidity venues worldwide — thereby providing local connectivity for local customers, which in itself significantly reduces cross-regional connectivity costs.

The cost of defining a new protocol is considerable and these costs continue for the lifetime of the product. Every new software release must include additional regression tests based on very demanding performance tests. This will ensure performance gained is real and constant. Benefits are intrinsically about the additional flow bringing revenue that the exchange attracts, either from competitors as a result of the speed offered or from new flow that is created due to this speed. This cost calculation for customers is also important. The customer will be looking for measureable benefits and/or lower costs. If the binary interface uses FIX the cost of developing and using the interface may be lower. If the data types are common with FIX, the integration with existing OMS systems may be easier.

Bob Caisley, CIO of the Singapore Stock Exchange (SGX), recounts the reasons why SGX is adopting FIX 5.0

In June 2010, SGX unveiled a plan to launch the next generation of exchange trading in Asia through its SGX REACH initiative. Positioned as providing the fastest access to Asia, the SGX REACH initiative begins in the first quarter 2011 with the roll-out of co-location services at a Singapore Tier-4 compliant data centre. By the third quarter of 2011, SGX will implement a new trading engine (REACH ST) for the securities market. This will be delivered through NASDAQ OMX’s Genium INET platform providing an average order response time of 90 microseconds door-to-door using the native trading API. The last part of the REACH initiative is to establish points of presence in major liquidity venues around the world including New York, Chicago, London and Tokyo, thus enabling local connectivity for global customers and radically lowering cross-border connectivity costs.

Connectivity over FIX 5.0 is an integral part of the REACH initiative. Since March 2001, SGX has successfully offered FIX 4.2 connectivity to our securities market. However, like many older FIX gateways, SGX gateways are layered over an external trading engine API gateway. Such architecture is not ideal and introduces translation delays that can be more than a millisecond on top of the door-to-door latency of the trading engine. Unfortunately, in today’s context, an additional millisecond is one thousand microseconds too many.

With the new trading engine, SGX will deliver a faster FIX connectivity through NASDAQ OMX’s Genium INET FIX that is integrated directly to the internal message stream of the trading engine removing the need for additional translation. This new architecture and superior solution enables FIX connectivity to give performance very close to that of the native API. The choice of FIX 5.0 rather than continuing with FIX 4.2 or a higher version was taken because we wish to provide a rich FIX interface, delivering both order entry and market data feeds. Analysis of the differences between FIX 4.2 and FIX 5.0 for order entry has shown marginal differences and we believe the move to FIX 5.0 will be a simple step for our current and new FIX customers.