When did you first suspect that automated trading was going to be important for ICE?
I believe it was probably late 2004 or early 2005. At the time we were planning to close the floor at the International Petroleum Exchange and move all the associated energy contracts onto our electronic platform. We were in the process of entirely re-architecting our platform, in terms of capacity and performance. It was as we were doing this that we began to appreciate how automated trading was really beginning to take off.
From our perspective this was convenient timing, because we could incorporate this into the design for the platform; we had an early heads-up on the sort of capacity requirements we were likely to encounter going forward.
How much contact did you have with automated traders at that stage?
We contacted the automated and algorithmic trading fraternity for
their assistance in terms of requirements that we could feed
through into the design; that process evolved into a very
collaborative relationship. They were very helpful, not just in
terms of feedback, but also in terms of reviewing requirements
and designs for what we were building.
That input helped to shape the core development of the new platform. That project ran from around early 2005 until the end of 2007 and involved a complete rebuilding process ranging across messaging infrastructure, APIs, trading engines and networking.
How much of your business does automated trading account for?
Automated trading certainly accounts for the majority of our message volume; that is obviously part of its nature. I cannot say exactly what percentage of traded volume it accounts for, but I think you could safely assume that it is a very significant amount.
Have you been surprised by the volume growth driven by automated trading?
Yes; we anticipated substantial volume growth, but have nevertheless been amazed at the pace of change in data volumes. Even now, with the world economy slowing down, you still see rising message volumes. For example, we have seen growth of around 30% just since last September.
How do you account for that?
I'm sure the addition of the Russell contracts to our platform
accounts for some of the growth.
However, another very important factor has been how traders react to any improvements we make in terms of capacity increase and latency reduction. We track the relationship between message volumes and traded volumes versus latency. If you look back to 2005, we were averaging about 250 to 300 milliseconds for a round trip with relatively small volumes. Today we average around 3 milliseconds or less for a round trip and the increase in message/trade volumes over the intervening period has been exponential. I think the logical explanation is that each performance improvement begets new trade opportunities in the market microstructure, which in turn stimulates trading activity.
Do you feel that the latency discussion has shifted from the network to the application?
I think there have been a lot of significant improvements in network latency generally over the past few years. I would say that it's certainly a subject that comes up far less frequently these days in discussion with customers than it did once. Having said that, I don't think it's something that you can ever let up on, it is always going to be important.
Do you have a sense that the era of 'latency trading' is coming to an end and that speed alone is no longer enough?
Yes, I think that's certainly true. In the early days of automated trading it was possible to have an edge and capture revenues simply by being faster; it was just a latency race. However, I think today you can see that competition between automated traders is much more about the quality of their models' business logic. You now have to be smart and not just fast to be competitive. Incidentally, we've seen a similar evolution among manual electronic traders. Originally they held a speed advantage but when automated trading emerged they had to adapt in order to survive.
Have you noticed much change over time in the ratio between message volumes and contracts traded?
That ratio varies considerably from contract to contract and in
our experience is a function of a contract's maturity. As a
contract matures, the ratio typically tightens up and becomes
more efficient. In general, newer contracts tend to have a
greater amount of message volume per traded contract.
A number of Automated Trader readers have remarked on falling trading volumes in ICE's WTI crude futures; any particular reason for that?
I think there have been some commercial changes in the US that may have been a factor. The WTI contract has certainly lost some ground against Brent crude futures where volumes have continued to rise.
We've also had a lot of Automated Trader readers asking about ICE's plans for options; anything you can tell us about those?
We've spent the last few years redesigning our trading platform with the focus mostly on futures and some of our over-the-counter cleared products. More recently we have started to look at using some similar techniques to develop our option platform. Our existing options capability is not as we would like it and so we have been working on this for the past year and new option functionality is scheduled for our next major release this spring, probably in April/May. There will be changes to our matching/trading engines as well as our network infrastructure specifically designed to accommodate options. We don't feel that electronic options market as they currently exist have achieved their full potential and our hope is that the new platform will assist in this process.
Is the intention to make more exotic derivative products exchange-tradable on ICE?
I think it's a little early to say whether we will definitely be expanding into the more exotic areas, but we do see the growth opportunity is there. Initially we will focus on the more vanilla products, but we are exploring some more complex capabilities in our matching engine, as well as the possibilities for user-defined products.
At present, our more complex derivatives are available via a company called YellowJacket that ICE acquired about a year ago. The YellowJacket product allows you to trade these more exotic products via an instant messaging system, which effectively acts as a peer to peer network, with all trades being cleared via the ICE clearinghouse.
Have you always adopted a policy of building rather than buying technology?
Over the development period I referred to earlier, we actually
spent quite a lot of time considering whether we were better off
buying or building, in
terms of time to market. We eventually decided to build, because we felt there were competitive advantages in doing so, such as the ability to respond to changes faster. For example, one of the reasons we launched our own clearinghouse in Europe was that using our own technology base meant that we could add products faster as required.
What are your technology preferences?
For the most part we are Java-based, but some of our most recent work has been written in C and C++. We are not technologically dogmatic, so tend to pick and choose the most appropriate technology for our immediate needs. To that end we are always looking for technologies based upon open standards that may be of advantage to us in our development program.
It's unusual to talk to somebody who has been using Java then switching to C or C++, we usually hear that story in reverse; what prompted that?
We are perfectly happy using Java, but in certain areas where we feel we need the absolute minimum latency and highest performance we will use C or C++. It is not that it wouldn't be possible to accomplish these in Java, but you have to be much more focused on reducing things like garbage collection. There are trade-offs in the other direction too; with Java you have far easier maintainability and faster time to market than you do with C or C++. Ultimately the quality of your code is also a factor; you can write fantastically fast efficient Java and you can also write incredibly inefficient and slow C or C++.
What is your take on C#?
We haven't used it much, but from what I have seen it complements Java very well. One area where we have seen some .NET development activity has been in YellowJacket's front end where the GUI is written in .NET.
What are your preferences as regards hardware platform and operating system?
We have tried a number of different things over the years, but for our larger servers (such as those running matching engines) we have recently standardised on AIX running on pSeries IBM servers. For our mid tier servers we've been very comfortable running Solaris 10 on a mixture of Intel and AMD boxes.
How is your infrastructure distributed?
Last year we moved our matching engines and primary data centre to Equinix Chicago. (Until about a year ago we were running our primary data centre out of Atlanta.) We now run the disaster recovery (DR) centre in Atlanta and are also preparing to build a new DR site there.
You offer a co-location service; how have you found that business has evolved?
Obviously this is being driven by the automated trading community and we saw a great deal of quick growth when we launched the service. While mature isn't perhaps the right word, I would say it is now a pretty well developed market from our perspective.
Finally, what keeps you awake at night?
I sleep better now than I did a couple of years ago! In this industry there is always another challenge; always the need to keep delivering something that is better and faster with more capacity and lower latency.