HLT, as in “High Latency Trading”

Some weeks ago I was interviewed by two Dutch journalists from VPRO about high-frequency trading. They wanted to talk about the microwave networks between London and Frankfurt and what they call “latency arbitrage”. The first part of the program is here (Dutch only), the second one there (with videos and English subtitles). The later focuses on “latency arbitrage” from a case I I had never heard of: a study made by a Dutch broker named DeGiro discussing a Dutch smart order routing system named TOM which is supposed to provide “best execution”.

The DeGiro findings were published in a fierce report, and one of the TOM co-owners, Binck (a DeGiro competitor as a broker), responded to the report, and then DeGiro responded to the Binck answer, and then the affair was featured in Dutch newspapers, amsterdamtrader.com wrote “DeGiro trashes TOM”, the case was probably much discussed in the Dutch milieu (Amsterdam firms Optiver and IMC have shares in TOM), and finally the VPRO journalists asked me about the case. When they came I didn’t had the time to read it quietly but the second part of the radio program is mostly about it, with comments by Dutch academic Albert Menkveld, Nanex’s Eric Hunsader, IEX CEO Brad Katsuyama and other people from the Dutch industry. In the end I decided to have a look to the documents and I realized there is something odd with the timestamps published by DeGiro. I don’t want to participate in the debate, but geography and information transmission are always interesting issues.

Let’s keep it simple: DeGiro acts as a broker; a broker sends orders to various exchanges (exchanges may be Euronext, Chi-X or one of the multilateral trading facilities [MTF] who popped up in Europe after the MIFID regulations in 2007) and those orders have to be filled at the best price available at one (or more) exchange(s). The exchanges are geographically disseminated, and sometimes the orders are for a same product available on different exchanges (shares of Solvay, in the DeGiro study), so the broker needs good connectivity to find the best price of the product at the right location, at the right time. Here, DeGiro decided to send their orders to the TOM smart order router (SOR), so they could to test the way the router can find the best prices here or there. A smart order router is a system designed to deploy orders on several venues and is now a crucial part of the market microstructure technology. In the new HFT ecosystem, order books (and transactions, de facto) are information for the different traders, that’s why a SOR needs to be “smart” – it has to be efficient and to find the best price without leaking information while being as fast as possible. Here is a chart from the DeGiro research (slightly simplified and modified by me, with locations added):


Thanks to this chart we can see that TOM is not only a router but also a MTF – an exchange. That means the TOM router probably tries to match orders at the TOM MTF before routing them elsewhere. Before discussing the DeGiro findings, let’s start with geography. The DeGiro research suggests they send their orders to the TOM routing system from Amsterdam (two Dutch newspapers were invited to look at the tests), probably from their office (Rembrandt Tower, Amstelplein 1, 1096 HA Amsterdam). Note in the map below that DeGiro is a neighbor of the TOM Holding offices.


But if TOM is said to be “located” in Amsterdam, the MTF (and probably the router) is not in Amsterdam: the TOM “Connectivity Guidelines” released in 2014 tell us TOM is in two locations in London, the “primary site” being in Slough. That makes sense as the LD4 Equinix data center in Slough is hosting other exchanges (like Chi-X). This was confirmed by people from the industry: TOM is in London, not in Amsterdam. As you can see on the map below, at the other end of the London metropolitan area you have the NYSE/Euronext data center, in Basildon (if you want to know more about the geography of the exchanges in Europe, check out my previous posts about how HFTs invaded my backyard):


So… DeGiro sent orders from Amsterdam to the TOM router in Slough; then the TOM router tries to fill them at the TOM MTF (in Slough), or at the Chi-X MTF (in Slough too, same data center), or at the Euronext exchange (in Basildon), etc., depending on the best price (and the volume) available here or there. DeGiro (in Amsterdam) needs technology to send the orders to TOM (in Slough). They may use pigeons (but it’s outdated), couriers (but they would have to take boats to cross the North Sea – too slow) or the last technology available: microwave. But as far as I know there is no microwave network between Amsterdam and London. The only technology available to send messages from Amsterdam to Slough is fiber – the good old cables. I asked people working in the industry about the fastest  fiber cables for the Amsterdam-London path, and it seems the fastest to cross the North Sea is the Circe North cable (owned by VTLWavenet/Viatel and euNetworks). This cable seems to be used by Zayo (a network provider who offers “low latency routes for finance”), and Zayo built additional proprietary cables to link different venues where trading firms or exchanges are. Here is a map with the Zayo proprietary cables in Amsterdam (in blue) joining other cables the firm leases (in red) –  kmz files are publicly available. One of the Zayo fibers, in Amsterdam, is probably used by TOM, Optiver and IMC:


Here is another map showing how Zayo has built a fiber (in blue) from a cable they lease (in red) to Basildon in order to beat another existing (but longer) fiber (in pink):


Of course, Zayo also has a lot of different fiber connections between Slough and Basildon (but now good HFT firms have new kind of networks – with millimeter waves the round-trip time between the two locations is 0,167 millisecond, that is far less than 1 millisecond):


I don’t know if DeGiro and/or the TOM router are clients of Zayo, but anyway – we can see there are a lot of fibers available, and I suppose they offer good latencies. Here is a global map of the case:


Now let’s have a look to the timestamps of DeGiro study (read the reasearch to know more about the tests they have made, I don’t go into the details here):


As TOM is both a router and a MTF, the study is sometimes confusing – when the report says “the order is sent to TOM at 978 ms” we should understand “the order is sent by the TOM router to the TOM MTF at 978 ms”. At the beginning I thought the TOM router was in Amsterdam (as it is said here), that’s why I tried to find data about fibers and latency around Amsterdam-London. But the TOM router can’t be in Amsterdam as the fastest fiber offers a ± 5.4 millisecond round-trip time – so that’s impossible to have a 3 millisecond round-trip time (978 -> 981) between Amsterdam and Slough. According to the DeGiro study, “the exact timestamps are given by TOM’s Smart Order Router”, meaning that the TOM router is definitively in Slough (and that would be logical).

At 974 all the DeGiro orders were in Slough, and then they were split;  at 978 the TOM router send an order to the TOM MTF, resulting in a transaction at 979.5, notified at 981. Both the router and the MTF being in the same data center in Slough, they are probably co-located (or at least not so far apart from each other), so 3 millisecond is quite long, no? (Depending on the technology, the orders may be matched in less than 1 millisecond.) Most surprising, however, is the time needed by TOM (the router) to send an order from Slough to Basildon (Euronext). Here the timestamps show that the round-trip time between Slough (974) and Basildon (991) is 17 milliseconds. Is this a joke?

When I visited the Basildon data center two years ago, I left with a document about the connectivity between Basildon and London downtown, where there is (among others) a data center named Interxion LON1 (by the way, this is the second site of TOM the MTF, “acting as a standby site, where systems and processes can be promoted to run as primary”); according to my document, at least in 2013, the round-trip time between Basildon and Interxion was 534 microseconds; Interxion being in the middle of the Basildon-Slough path, we may estimate that a round-trip time between Slough and Basildon would be a little more than 1 millisecond with fiber. Now, thanks to millimeter waves, it’s possible to have a 0,67-millisecond round-trip time – i.e. 670 microseconds. So the 17-millisecond round-trip time offered by TOM the router is 25 times higher than the best latency available, and twice the round-trip time between London and Frankfurt with fiber. We don’t talk anymore about high-frequency trading here. “To be able to guarantee best execution of client orders, TOM developed a search engine [The Tom router] which compares prices, faster than a blink of an eye, between markets” says the Tom website. Well, a 17-millisecond round-trip between two areas around London is faster than a blink of an eye, but in a world where every microsecond counts now, the TOM router really has a very poor connectivity.

That’s because those 17 milliseconds are so high that I thought TOM the router was in Amsterdam – but we saw that the router can’t be in Amsterdam as it’s impossible to have a 3-millisecond round-trip time between TOM the MTF located in Slough and Amsterdam. DeGiro published the study in order to prove that the TOM router was intentionally designed to offer “latency arbitrage” possibilities to the fastest traders. This is the purpose of the chart below: according to DeGiro, the trade at TOM (in Slough) at 979.5 was used as an information (thanks to the ITCH feeds) by a fast trader who initiated a “flash trade” at Euronext (in Basildon), “stealing” the best price/execution TOM the router was supposed to give to the DeGiro orders (some speculated to guess who was this bad predatory HF trader). That’s the story of the IEX flash boys, who designed a router named Thor when they worked at the Royal Bank of Canada – and that’s why Brad Katsuyama was interviewed by the VPRO journalists about the TOM affair. Assuming that most of the HF traders now use millimeter waves to carry data from Slough to Basildon (and vice versa), and given that the best latency here is 0.335 microseconds (one way), that means various HF traders had the opportunity to “steal” the price at 979.835 in Basildon, 2.665 milliseconds before the DeGiro order arrived there, thanks to the poor connectivity of TOM the router. Welcome in the High Latency Trading world.


  1. Congratulations on the detailed report! Though, in connecting this to the possibility of ‘high latency trading’ , there is an important nuance to add to this discussion. The modus (most common) size of a retail order in the TOM SOR is Euro 2,000,= . In principal in this case, latency arbitrage will only take place if an order on one exchange will create a price movement on an exchange where someone with a fast(er) connection to another exchange can react on earlier than others. A typical retail order sent to TOM SOR will be filled easily by the first bid or offer in the market on one of the connected exchanges and won’t move the market. The order sent as a “test”- trade in your analysis is more than a factor 100 compared to a normal retail trade in a very illiquid stock and therefor is not very representative to the retail space in the Netherlands. Although we closely monitor performance and also latencies in our systems and make adjustments accordingly if necessary, we feel that the order flow from retail sent to the SOR, is not negatively affected by latency arbitrage because of the nature of the flow.

    • Thank you for your comment. I get the difference between the “normal” retail orders and the (big) ones sent by DeGiro. I got to go but I may have other questions – they will come later… Thanks again.


Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s