Proximity Hosting: Plug’n’Trade or Pay’n’Wait?
First 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
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.
