The Gateway to Algorithmic and Automated Trading

Proximity Hosting: Plug'n'Trade or Pay'n'Wait?

Published in Automated Trader Magazine Issue 08 Q1 2008

Proximity and trading application hosting have been some of the fastest growing areas in the evolution of automated and algorithmic trading. Mark Thornberry, Managing Director at RTS Realtime Systems, London, discusses some of the main considerations for traders evaluating its various flavours.

Mark Thornberry, Managing Director at RTS Realtime Systems, London

Mark Thornberry, Managing Director at RTS Realtime Systems, London

Trading is a business that has never been renowned for its charity and in today's auto/algo trading environment that reputation has only hardened. With thousands of smart professionals chasing the same brief inefficiencies, the only position in the order race that matters is first. Little wonder therefore that proximity hosting of auto/algo trading strategies has become so popular. However, the selection of that hosting facility can be something of decision-making minefield.

Get me to the show on time

It is tempting to assume that data centres are purely about cutting latency through proximity. That is of course a major consideration, but facility is also critical. Particularly in the high-frequency trading spectrum, an individual model's ability to capture profitable inefficiencies has an ever-decreasing half life. Where once a model might remain viable for years, it is now increasingly common for performance to decay in a matter of days or even hours. The ferocious level of competition among the technologically well-armed means that slow deployment will leave a model attempting to capture inefficiencies that no longer exist.

In such an environment, implementation latency is a key factor. Every hour of delay in deploying a trading model in a new market spells lost opportunities and increases the risk that the model will arrive after the party is over. Therefore proximity and trading applicaion hosting providers have to be capable of implementation times measured in hours, not days or weeks.

'Bare bones', full service or somewhere in between?

Proximity and trading application hosting services typically consist of four broad options:

1. Rack space in a facility close to the trading venue;

2. Rack space plus service provider access to the trading venue's gateway;

3. Provider-maintained servers plus service provider access to the trading; venue's gateway; or

4. Provider-maintained servers and trading software, plus service provider access to the trading venue's gateway.

Individual circumstances will obviously dictate which option the trading business will choose, but each has its pros/cons.

• Rack space in a facility close to the trading venue

The 'bare bones' option offers considerable flexibility, but will typically only be appropriate for those less sensitive to implementation latency and with deeper pockets. Negotiating and connecting direct to trading venue gateways is non-trivial in terms of both cost and time. For the majority of trading businesses, the substantial charges levied by trading venues for this 'go direct' approach will be a major deterrent.

A further consideration with the 'bare bones' option is power. The explosion in demand for proximity and trading application hosting has created an unprecedented demand for power, so that in some facilities the amperage available to each rack unit is already inadequate. (Notwithstanding the fact that the introduction of more efficient CPUs has reduced power requirements per unit of rack space.) Therefore businesses considering this option need to ask potential providers searching questions about their power provision, both now and in the future.

• The 'fuller service' options

The other three options dispense with the cost/time hurdle of having to deal with the trading venue direct. A service provider that offers gateway access will be able to amortise the costs of venue connectivity across multiple clients to offer lower cost per client. (Note that this does not imply that multiple clients will be using one gateway.)

Options 2 and 3 are well suited to trading firms who have a legacy code base that they do not wish to rewrite in order to run on the provider's trading application, but who nevertheless require a fast, standardised API to connect to multiple markets. Those trading businesses considering Option 4 need to be sure that the provider can offer the necessary support for rapid porting of existing trading models to the provider's trading application.

A further consideration for fuller service options is the provider's testing capabilities. A production environment is one thing, knowing that trading models will run as expected within it is quite another. A testing environment that accurately simulates interaction both with trading gateways and (in the case of Option 4) also the trading application is essential. Furthermore, the transfer from testing to production environment should be trivial if implementation latency is to be avoided.

Global coverage

One of the strongest recent trends in proximity and trading application hosting has been the huge increase in demand for global footprint. This has been driven by two particular developments: traders looking to leverage existing models by deploying them in new markets; and multi-asset class trading.

An important distinction is that some providers claim to offer connectivity to multiple markets around the world, but only offer this from a extremely limited range of data centre locations - with obvious negative implications for latency. Therefore the number and proximity of the individual hosting locations is vital - as is the provider's long-term commitment to expanding these locations to ensure optimal performance per market in the future.

For those looking to trade multi-asset strategies across diverse physical locations, the provider has to be able to guarantee first-rate connectivity across all its hosting sites. If a model always trades the first leg of a trade in Chicago and subsequent legs in London and Frankfurt, then the connection quality across those locations must be impeccable. As part of this, connectivity must be optimised to minimise unnecessary hops, so the second and third legs of the trade can be sent straight to the London and Frankfurt trading venue gateways and not via servers in those locations.

Covering all the bases

For a trading organisation looking to trade rather than manage infrastructure, a provider that can offer Options 2, 3 and 4 is ideal. Apart from avoiding the technological headaches, such a provider also allows the organisation exceptional flexibility as regards its future business strategy. If the provider can also tick the boxes as regards implementation time, connectivity, location and testing environment then the trading organisation will be able to focus on its core business comfortable in the knowledge that everything else is in safe hands.

Realtime Systems Group