Ryan Gagne, Sales, North America, Divisa UK Ltd.
This guest article was written by Divisa Capital’s Ryan Gagne, an FX market veteran, with over 15 years of experience working with some of the market leaders in FX such as State Street Global Link, Hotspot FXi, FX Bridge, Alpari, and currently with Divisa Capital. His experience has positioned him on the front line of e-FX trading consultation to global banks, institutional money managers, and leveraged hedge funds as well as proprietary, corporate and retail trading firms.
Foreign exchange trading is a global beast by nature and before the age of electronic trading, business was conducted point to point via a telephone and location was not a significant factor in the process. Well times have surely changed. With the birth of centralized matching engines (CME) and global limit order book (GLOB) exchange style trading systems, location has become a factor. Let me explain:
A CME or GLOB is a single point of presence, a physical location where a server connects all trading parties (i.e. banks, brokers, trading parties, etc. regardless of where each individual firm is), globally. Simply put; it is one place for the whole world to come together to trade. Much like a physical stock or futures exchange, NYSE, CME, CBOT, LSE, etc.
So what is the problem?
It sounds good, looks efficient until you factor in one thing, latency. The latency I am focusing on is the delay from input into a system to receiving the outcome. In this case, it is the time from when the trade is initiated to when it reaches the trading 'exchange'. The latency in the actual matching process can be put on a shelf and saved for another discussion, we shall focus on the time it takes to get from point A to point B and back to point A.
No matter the quality of the line, the types of connections or the hardware in place between locations; latency will always exist. Reason being, data transmission can only move so fast and in data’s case, no faster than the speed of light. Sounds fast and in certain situations, it is….Well except when it comes to trading. The speed of light as we know it moves at about 186,000 miles per second and data takes about 50ms (milliseconds) when employing the best of the best technology to get from London to New York.
For many of these exchanges, the eastern seaboard of the United States is their only location. A single location for their matching engine forces a call to action for non-US firms.
Wrench or a hammer, what will fix this?
So how do many firms try to eliminate this inherent latency, simply by moving closer to the exchange. Each exchange is located in a centralized data center where other firms can rent rack space and make direct connections to any exchange of their desire, although at a price; a price that questions if there is a need to reduce the latency in the trading process. For some firms, that cost pales in comparison to the profits they aim to generate in a low latency environment.
For other firms, the cost can eliminate a large portion of their potential profits, making the idea impossible. So what can they do?
Think smarter, work harder
Well, it’s not what the trader can do to get to an exchange; it is what an exchange can do to get to the trader. Regional server locations are the solution for many firms globally. By co-locating matching engines in major regional data centers, i.e. London, New York, Tokyo, Sydney, Munich, local trading firms that are not co-located aside of these machines can still have a robust and cost effective trading process.
Some may ask “But why all this work if latency is not a major factor?” The fact is, latency in a lot of cases for trading firms is a major ingredient in their overall trading performance. Retail brokerage firms monitor their client trade execution performance in several ways; rejected trades and repriced trades are two contributing factors to lower trade execution performance. Repriced and rejected trades are also two outcomes where latency is a factor. Let me explain:
A retail brokerage hosts a Non-Dealing or Straight Through Process “STP” retail Trading Platform whereas they receive and repost price quotes and executions from a centralized FX exchange type platform. The client of the brokerage trades from his home outside of London, the brokerage hosts their server within their office in downtown London and they connect to the exchange style platform located in New York.
Consequently, the time it takes from when the end client clicks on the 'buy' or 'sell' button to when the trade is committed on the matching engine is somewhere around, 100 to 150ms in an optimal scenario. Inside those precious couple hundred milliseconds, another client of that same centralized exchange sends in an order to trade, this client though co-located their server a couple racks down from the centralized exchange style platform. The problem is it is the exact same trade as that retail client sitting over in London.
Hence, the race is on and in this case, that retail client will never win, and because of this a couple things may happen. In most cases, that retail client would either have his trade rejected or repriced and potentially at a rate worse than what they expected. If this happens once maybe the client won’t notice, but if this is a regular occurrence, over time at client level and overall at a firm level the retail broker will suffer a tarnished reputation and loss of business.
Band Aids and Duct Tape
In some cases, a retail broker may realize they need to do something to try to improve their clients’ experiences and one idea that is often tried is a low cost co-location hosted solution with a non-financial provider. This type of provider might be good to host a web server for some type of service where latency is not a material factor in their process and a 'low cost' solution turns out to be a long term cost.
With Slippage , server downtime and slow feeds due to latency, these 'band aid' solutions end up costing retail brokers thousands in lost revenue opportunities and dismal execution performance for clients trying to trade through a latent exchange platform thousands of miles away. Cheaper is never better…
Ah, this makes sense
Pointing out the obvious, by using a regionally based server, whether it be in London, Sydney, Tokyo, New York, Munich, Johannesburg, etc. a great deal of these risks can be reduced.
Is there a 'Solves All Problems' solution? Sadly, no there is not. No firm could fathom locating servers in every place so that every single client’s experience is perfect but creating a more efficient trading process is possible.
