Why did you start Communicating Ltd?
I had been working in IT at Bear Stearns, but when I left in 1995 I decided that I did not want another job at an investment bank and so started my own firm. I had virtually no contacts in the City and started pretty much from scratch. The only product the company had to sell was me, so I took on IT consulting projects while assembling the team one by one. We spent the first five years doing all sorts of jobs, from configuring networks to building disaster recovery sites; you name it, we did it.
How did the Aquarius matching engine come about?
In late 1999, LIFFE (London International Financial Futures Exchange) went electronic and asked us among others to become an ISV for its new trading platform. At that time, the deal was that the ISV bore the brunt of the development costs in return for future revenues in terms of licences from LIFFE users. But there were too many ISVs competing in a finite market so we very quickly opted out and started looking more closely at the technology that ran the exchange itself. We basically analysed the performance of LIFFE and other electronic exchanges that existed at the time and decided to make something that was quicker, much quicker. We ended up designing our own matching engine.
At around that time (1999-2000), I met my business partner Richard Lane, who had previously been an options market maker and one of the biggest 'locals' on the floor. We named the system Aquarius because we are both Aquarians, born on the same day. We met because we both helped design the first mobile trading system for the futures market based on Windows CE and using GSM for connectivity. Richard saw that technology would play a greater part in the future of trading and wanted to be part of it.
So the original plan was to sell the matching system to an exchange?
In 2000, we showed Eurex a matching engine that was capable of trading, say, 20,000 times a second. And they said, "Not interested. Who needs it? Not possible."
You could say we were deluded in thinking that if you show something better, faster, cheaper, somebody would snap it up. Not so. We offered it to everybody we could at that time and they all said, "Who needs it?" So eventually we said, "If we can't sell it, we'll use it." We inverted the matching system, added a front-end to it and decided that we would treat the exchange's clients as our clients by matching the orders that the exchange is too slow and inefficient to match. We created an automated trading tool based on our matching engine which basically subscribes to the entire pool of liquidity on the exchange and looks for arbitrage opportunities.
How did you turn Communicating from a tech shop to a trading operation?
Before Richard joined us, we had a trading tool but we couldn't trade ourselves. Richard decided that he no longer wanted to trade options on LIFFE, because handing options to brokers was not a business he wanted to be in. Richard came along and said, "I have a seat on LIFFE, I'm a member and can trade futures, let's see what we can do together." From day one, we connected directly to LIFFE, almost certainly as the first automated trading system to write to the exchange's API. We started by trading only LIFFE products, often extremely large volumes; euribor and sterling futures were our playground, as well as many commodities contracts and we even traded options for a while. Gradually we expanded across all the other exchanges. In the meantime, we were still trying to sell the system, but always met the same rebuff, "If it's so good, why haven't you sold it already?" So we said, "To hell with this, let's trade."
What's the scale of your trading activities now?
We trade in 76 contracts across six exchanges and will be adding more soon. We use the same fully automated trading system to do vertical, horizontal and cross-contract arbitrage. The trading staff are really just here to monitor the systems in case we get 'legged', i.e. the system doesn't manage to complete all legs of a trade and so we are left with a net position. We trade flat so human intervention is required if an order is only partially filled or if it misses completely because the volume has gone before the exchange accepts our order or because the exchange market control staff subsequently busts one leg of our sequence of trades. Otherwise, almost everything is done by the machines.
What daily volumes does Communicating trade currently?
It really depends on market volatility. We do reactive trading; we don't have a view on the market. Volume varies vastly. Some days we trade 25-30,000 contracts on ICE (Intercontinental Exchange) alone, and we have traded well over a quarter of a million lots a month on ICE for the last couple of months. Depending on market conditions, we might trade as many as 100,000 contracts in a day on the Chicago Mercantile Exchange alone. But currently the yield curve is flat; virtually all market movements can be predicted and there's really not a lot of volatility in the straight 'financial' products. We're currently concentrating on a wide range of active commodity and energy contracts to take advantage of volatile market conditions as and when they occur. For example, between January and March, corn, wheat and soya were particularly volatile; there were days when our trading represented as much as a third of all screen-based trading in those futures contracts.
Because most open interest is rolled into the next expiry period, we tend to have even larger trading volume at roll-over. If volatility is exaggerated for any reason during roll-over, our trading volumes can be huge.
The Communicating Team
How are roles split up between members ofthe team?
Half of the team is basically development, the other half management and trading. We have some extremely specialised developers who we do not trouble with day-to-day activities. Trading is mostly handled these days by me, Richard and George Ferrari. People ask how can two or three guys handle 76 contracts. But the answer is that we don't, the machines do. We just monitor the machines. We run the trading software on desktop computers, one per exchange. The trading risk control parameter profile is set individually for each exchange and contract, and modified in the light of experience of an exchange's technical characteristics, such as market update lag time, the allocation algorithm and contract and expiry characteristics, such as typical market depth. Once a machine is profiled for a particular exchange and all trading parameters are set for each commodity (i.e. trade if…), then it's just a matter of loading these set parameters at the opening of each trading day. On most days, there's no more involved than that, but of course we can tune the parameters during the day to respond to changing market conditions. Famously, Aquarius fits on a floppy disk. What principles do you follow to ensure your trading software is as lean and efficient as possible? It's a matter of engineering. We only use C++ language in development. But it's also a matter of discipline. Sometimes you need to do things the hard way in order to preserve speed. Take for example default memory allocation routines, which basically dictate how quickly and efficiently a machine can allocate memory in the system, or to a particular application or process. The simplest thing would be to take what's there and use it. Alternatively, you look at what it does to the system, how it behaves on the processor and how many process exceptions it incurs. Then you see if you can write a more efficient routine.
We've chosen the latter route. We tried to use industry standard components, but they were not efficient enough, so we've spent a lot of time developing our own technology, including frontend displays. The display is often one of the slowest components of any trading system because most commercially available GUIs are horrendously inefficient and that gets in the way of trading. So we've spent a lot of time developing our own technology or rewriting something that we've bought as a source code library to achieve the performance we need.
What procedures and technologies (hardware, applications, networking) are required to ensure your machines run as efficiently as possible?
There are many ways of talking to the network. If you're not fast enough to the exchange's network, then all bets are off. We do have some trade secrets on how we communicate with exchanges, but we also try to apply common sense wherever possible. For example, don't watch porn or send emails on the same machine you use for trading! I've seen so many people sending emails while trading at the same time as watching a football match - and they still expect the machine to perform.
We only run processes on our machines that are absolutely necessary to trading. Most of our trading machines are stripped naked in terms of services and functionality; they run one process and it's called trading. That advice is free to anyone; you can increase performance simply by removing all the crap from your desktop.
Secondly, be very careful who you select as your front-end provider. These goodlooking, all-singing, alldancing front-ends look beautiful but are painfully slow. Do you want to look at something pretty or do you want to hit the price? Our philosophy has always been: never mind the beauty, focus on the functionality. When we built Aquarius, our entire focus was on functionality, speed and execution.
What are your connectivity arrangements with exchanges to support your trading strategies?
We use dedicated direct connectivity wherever possible, rather than local lines to exchange-provided hubs. Where the exchange does not mandate the use of its own gateway, we mostly trade via Internet VPN circuits over our resilient 10/100Mb links to a level 3 ISP, i.e. high bandwidth internet-based connectivity - but it's really a question of whatever it takes to connect directly. What we've found, with very few exceptions, is that connectivity arrangements can vary enormously between exchanges and this can make life difficult for firmsthat want to connect directly.
For example, some exchanges give a technical advantage to firms trading locally to the point where, just to compete on level terms, you have to co-locate your trading engine in the same building as the exchange's primary trading backbone - in a different continent - and operate it remotely.
How can latency between trading firms and exchanges be further reduced?
Arbitrage trading is critically dependent on trading off valid prices and getting the orders in as fast as possible without overwhelming the exchange gateway and so latency on the market data stream and order entry gateway capacity is a big issue. A lot depends on the sophistication of the technology and the protocols used by the exchanges. These days, everybody's looking to connect with FIX, but personally I'm not yet convinced that the FIX protocol can cope with future trading volume growth. In my experience, it can be heavy, cumbersome and slow to the point where it introduces unacceptable latency in market update streams. A number of exchanges are adopting FIX and when they hit the wall volume-wise the response is to start compressing the FIX message files. But once you compress FIX you actually get a binary packet, so it's a paradox in itself. Why not start with an efficient binary protocol in the first place?
I'd like a more uniform approach to connectivity across exchanges, but I really don't think FIX is the answer for transmission protocols. We try to use native protocols where there is a choice but we have to put up with what the exchanges offer.
How well equipped are most exchanges for high-volume automated trading?
I think there are a lot of serious challenges ahead. A lot of exchanges take the approach of financing the real estate, i.e. coping with growth through sheer CPU power. That works up to a certain point but then it can start working against you. Exchanges are currently making decisions that could very easily backfire in the long term. The worst thing that can happen is for an exchange to become the victim of its own success. It's one thing to sign up 25 market makers, but it's very different when you end up defeated by those very market makers because you can't handle the volume.
The reason that these potential problems have not yet come to light is that there has been an exceptional period over the last five years in which we really haven't had consecutive days of exaggerated volatility. Financial products have remained stable on the whole, but who is to say that's going to be the case for the next 10 years? It may change tomorrow. Give me seven days of proper volatility of the like we sawregularly in the market prior to 9/11, and quite a few of the exchanges we now consider as rock solid might not look quite as stable. In my opinion, they should be redesigning, not just adding capacity.
What processes do you go through when considering expansion into new markets?
Primarily, we're looking for liquid contracts where there is some element of volatility. In essence, we are volatility traders; the only contracts that don't suit us are the ones that don't move. We also need contracts with some degree of complexity and sophistication, with lots of spread strategies. When you have a contract that consists of bid and offer there's nothing to arbitrage - they're only really of interest to firms that do statistical arbitrage. That's not us; we do real-time arbitrage.
Identifying price volatility is often just a question of eyeballing the intraday price charts, and checking the depth is equally a matter of observation. Exchanges have sometimes come to us with volatility statistics to encourage us to add liquidity to their markets.
At present, we are mostly concentrating on contracts in the commodities markets, and oil in particular, where we're trading almost every futures contract in the market. We're also currently looking to expand into the cash FX market starting with perhaps 30 currency pairs. To do this, all we'll need to do is to write to the APIs of the various FX trading platforms we wish to trade on because we will use exactly the same trading tool across all exchanges and exactly the same front-end.
What are your internal risk management processes and how does your clearer monitor risk?
To a certain extent, risk management is built into the trading algorithm itself. We trade on a completely riskless basis because we're flat after each trade. Each trade is basically in and out so we almost never have a position. Sometimes we will have a spread or two outstanding at close, but that is the most we will carry overnight. But we never leave positions open overnight if there is a way of getting out of it; 99 times out of a 100 there is an opportunity for us to close out the position. The only real exception is when the missed leg is in a very illiquid part of the curve.
What is the next stage of growth for automated trading in the futures market?
We firmly believe that automated trading is still in its infancy. We're not just looking one year down the line, we're asking ourselves what's going to be happening in five or even ten years' time. What happens when China, India and other developing economies start joining the futures market? There's a lot of talent out there that can be harnessed in this market.
How many futures traders are there in the world right now?
Maybe 50,000-100,000 if we add up all the firms that dabble in the market. In a world population of 7 billion, it is not inconceivable that there could be a million futures traders in five years' time. Clearly, liquidity would increase dramatically. Our plan for the future of Communicating is really about expansion and adding more contracts, putting more exchanges and more products on the screen. But from a broader market perspective, what we see now is perhaps only 20 per cent of the market's size in five or ten years' time. I don't have a crystal ball; the only thing I know is that more liquidity and more products traded electronically will mean only one thing for us and that's more profit.
How much can artificial intelligence be used to support automated trading in the futures market?
For the time being - and for the kind of trading that we do - there is simply not a large enough playing field for artificial intelligence to make a viable impact on the performance of our automated trading systems. There is not enough liquidity and not enough choice on the markets. But I can certainly see scope for the application of artificial intelligence and we have already developed several generations of AI engines intended for trading options. A single option trader or market maker can really only trade one or two contracts well. The challenge is to develop an AI machine that can recognise the opportunities across multiple strikes and volatilities - while also handling positional management across several contracts - as well as or better than a qualified option trader. Unfortunately trading options using AI-based automated trading systems is only a dream while options trading remains a telephone market dominated by the brokers. Hopefully one day there will be an adequate options market from an automated trading perspective, and then we will see AI engines in use for trading.
In what circumstances can an AI engine make most difference to trading operations?
In the futures market it's too early to say. I think we're only on the verge of getting useful answers from our AI machines. But AI algorithms are getting more sophisticated by the day. AI can do a lot but you need to formulate the question correctly. It can do things that mathematically you cannot otherwise prove. If you qualify your question adequately, AI can get results. But AI is typically most valuable when used on very large sets of data and that implies having a vast pool of liquidity with considerable complexity. Without this, you don't really need AI. Already today you can use AI for trend analysis and statistical arbitrage, but at the moment I don't believe it is strictly necessary. In five years, hopefully, the market will have developed enough in size, complexity and diversity of products to justify the use of AI.