The Gateway to Algorithmic and Automated Trading

A Singular Vision

Published in Automated Trader Magazine Issue 08 Q1 2008

Its recent merger with the CBOT saw CME Group expand further the range of asset classes available on its Globex platform. Deputy CIO Kevin Kometer looks at the diverse challenges ahead.

What does the CME-CBOT merger mean for algorithmic and automated traders?

All the futures and options contracts previously available on the Chicago Board of Trade's e-cbot platform have now been fully migrated and are now available on the CME Globex® electronic trading platform. All the e-cbot agricultural products and equity index products went live on January 13, followed by interest rate products on January 27. In each case, there was a day's mock trading on the Saturday preceding migration on the Sunday to give traders a chance to connect to CME Globex and get comfortable and we're now running all those contracts on a single platform.

One platform should provide a more consistent and efficient trading experience for customers that trade multiple asset classes. An algo trader can now leverage a single gateway to trade multiple products and take advantage of the speed and reliability of the CME Globex platform.

What difficulties had to be overcome?

The migration involves more than just running markets on a new matching engine; a lot of other system migrations have to take place beforehand. For example, we had to migrate and consolidate the different membership and fee systems, as well as systems that generate product information. Because we couldn't really start work on those until the merger with CBOT closed in July, we really didn't have much time to put those systems in place in preparation for the migration of the e-cbot products to CME Globex. In addition, we have to ensure customers have sufficient time to make their system changes, then test them against our certification environment and ultimately in the mock trading sessions, six of which were conducted across December 2007 and January 2008. The biggest challenge was for firms not already connected to CME Globex, because they would typically need a new release from their ISV or undertake in-house development work if using proprietary systems.

How will CME Globex handle both CBOT-related and ongoing volume growth?

CME Globex is very flexible, capacity-wise, because we run multiple matching engines. To cope with the migration, we've added four new engines specific to e-cbot products, i.e. one for agriculture products and equity futures and one for interest rate futures as well as two new engines for options on these futures. The e-cbot products had a combined average daily volume of 3.2 million in 2007, so that's a lot of trades to add to Globex's own 5.3 million contracts per day. So now CME Globex totals six futures engines and six options engines, not including our disaster recovery capabilities. We've also scaled up our order entry and market data systems to accommodate additional connections from users, either new customers or existing ones that want to increase the scale of their CME Globex connectivity. Since July 2007, we've been investing in hardware and the necessary configuration to handle increasing volumes.

"One platform should provide a more consistent and efficient trading experience for customers that trade multiple asset classes."

What hardware/network changes have you made to CME Globex to support greater message, data and deal volumes?

The current infrastructure is very sustainable and scalable so we can continually expand capacity if we see higher volume increases than expected. Peak transaction volumes on CME Globex - for orders, rather than contracts traded - are almost 20 times the average, on a message per second basis. This means we have to build additional capacity to handle extreme peaks. On an ongoing basis, we look to take advantage of the new hardware releases offered by vendors, such as faster CPUs (central processing units) for our futures engines, which run on Tandem Non-Stop, and options engines, which run on Linux.

We continue to monitor performance and make software changes as necessary, to tweak and tune databases. For example, we're expecting that software and configuration changes to streamline outbound order traffic will result in up to a 50 per cent reduction in round trip times for our futures engines in Q1 2008. On a daily average basis, round trip times for futures transactions are between 25-30 milliseconds, plus perhaps another couple of milliseconds of network latency if the customer's located in Chicago or around 10 milliseconds if they're elsewhere. We're looking at a reduction from around 30 milliseconds today, to perhaps 15-17 milliseconds for certain products by the end of Q1. These are average figures, so clients will find round trip times increase a little at peak times, but are better than average in off hours. In the past, we've changed hardware and added faster CPUs and experienced a 20 per cent improvement in performance, but the latest changes are all down to software improvements.

We're already below 10 milliseconds, for round trip times on our options engines, not including network latency. Part of the reason for the difference between futures and options is the different market dynamics, i.e. the mass quoting going on in the options market.

"Peak order volumes on CME Globex are almost 20 times the average, on a message per second basis. This means we have to build additional capacity …"

Are you approaching the physical limits to improvements in round trip times?

There's always more we can do. The most important thing we can do is make sure systems are scalable so that you can sustain performance in the future. Scalability can be either horizontal or vertical, i.e. adding more servers or adding more capacity to existing servers. We run specific product groups on a specific matching engine and can scale out horizontally when that product group adds new contracts. We also are able to take advantage of vertical scaling methods such as adding faster CPUs, which tends to take place every 18 months. At some time in the future, there will be a point at which the impact of changes will be less significant, but there's still currently plenty of scope for taking advantage of

advances in hardware to improve performance. But performance isn't everything: while investing in new hardware, or looking at developments such as grid computing for example, we have to consider whether it's right for our environment because reliability is as much a concern as performance for us.

How important are industry standards such as FIX FAST to handling higher volumes?

We're very active in promoting industry standards. We use FIX protocols on all of our major interfaces, i.e. FIX for order entry, FIXML for post-trade and FIX FAST for market data. The value of these industry standards is that they make it easier for the customers. A wide range of exchanges use them and vendors are creating solutions incorporating them so that users can buy packages off the shelf rather than building interfaces in-house. FIX FAST creates a standard where there simply wasn't one in market data and the key value there is in the reduction in bandwidth. With the ever-increasing number of market data messages, our strategy has been to enable customers to select the contracts they want to see market data for. As we continue to add products and see volumes increase, this will help minimise customers' bandwidth needs thereby slowing their spending on bandwidth.

We've had a very positive response so far to our migration to FIX FAST, but implementation to date has been slowed by the CBOT migration; there's only so much change customers can handle at one time. Compared to our current market data solution, we believe clients will see a 70 per cent reduction in bandwidth requirement.

How much of a long-term solution can be offered by data compression techniques such as those employed in FIX FAST?

There's only so much you can do with compression. Right now, FIX FAST is a key part of our market data strategy and, while there'll be enhancements over time, I don't think you'll squeeze much more out of compression. So everyone's going to have to continue to monitor the ever-increasing growth in market data and come up with innovative approaches. As I said earlier, we're offering customers a choice in the market data they receive, which may mean we supply multiple pipes of feeds to customers that want to limit their growth of bandwidth use. This might result in higher costs for the exchange, but that's an area for consultation with the customer base. Because of the sheer number of market-makers and quotes in the options market, for example, firms that take options feeds will see larger bandwidth requirements than those just looking at the futures.

If they want to continue seeing all product groups, they're going to have to address the bandwidth issue.

"… everyone's going to have to continue to monitor the ever-increasing growth in market data and come up with innovative approaches."

How is CME addressing the risk management issues raised by high-frequency traders executing trades via DMA?

We're looking at making available to customers a number of features that have been rolled out already on FXMarketSpace, our foreign exchange platform developed with Reuters. One of these is the drop copy capability, which sends a 'copy' of a transaction to a trader's risk management interface simultaneous to execution.

We're currently talking to customers about the kinds of credit controls they want and which make sense for us to implement on the order entry side. One of the key considerations is how do clients want to see positions aggregated, i.e. by account level, session level, or company wide etc. Again, we are looking at extending a credit control solution implemented as part of FXMarketSpace to the larger customer base. In doing so, we have to be careful to balance the level of control needed, from a risk management perspective, with platform performance.

How is the CME looking to compete for global market share?

The 'big four' exchanges face similar challenges in terms of performance, reliability and handling greater market data volumes. We continue to focus on distribution and making sure we have the network connectivity to allow customers to connect to CME Globex easily. We have six hubs globally and will continue to grow those with a new one planned for Seoul. Although there's perhaps 30 minutes of downtime each day per asset class, Globex is now pretty much a 24/7 operation, serving clients in more than 83 countries and territories. As well as ensuring CME Globex is available to clients across the world, distribution agreements play a big part in our global strategy. Products such as the KOSPI 200 futures contract are scheduled to trade on CME Globex and we have an electronic order-routing agreement in place with the Brazilian Mercantile & Futures Exchange.

How is CME responding to the growth in multi-asset trading?

From a technology point of view, we're going to see perhaps more requests for spreading across different products. Now that we've completed the migration of the e-cbot products to CME Globex we'll see higher demand for that. Of course the increase in demand for cross-asset trading brings new risk management questions. This is one of the reasons why we're talking to customers about credit controls and aggregating positions at the moment. We don't know the answer right now but it's an area we're actively pursuing.

Do you expect a convergence between the exchange-traded and OTC markets?

I think you'll see exchanges getting more into the OTC space. We're actively engaging those markets to try to determine their needs. Of course, OTC contracts don't necessarily trade like our typical futures and options instruments, so the interfaces needed for those products are different from what we have within CME Globex right now. As such, we're looking to establish the right solution to enable market participants to post OTC trades with the CME. Other benefits that an exchange can bring to the OTC market are the credit efficiencies and virtual elimination of counterparty risk that stem from a central counterparty model. Our challenge is to determine what's easiest for them and what's going to make their life easier.