Problem Setup

We assume the FX market participant (FXMP hereafter, client of Tradefeedr) is trading with several liquidity providers (LP) via FX aggregator setup (see Definitions). FXMP is a price taker. He observes FX quotes in real time from all LPs and selects the best quote to trade (highest bid to sell, lowest offer to buy). We assume for now that his trade size is smaller than the size attached to the quotes. So he does not have to hit several LP at once (so-called sweep). FXMP can be filled, partially filled or rejected as a results of his order.

FXMP is looking for a way to identify latency in his stack and the costs associated with it.

The study assume the FXMP market data and trade messages (order, fills, rejects) are loaded in the Tradefeedr Platform

The prices and quantities observed by FXMP can be schematically demonstrated on Figure 1

Figure 1: Liquidity Stack

Latency

Latency is the time difference between two events. Latency is extremely important to measure as there can be significant costs associated with latency.

Tradefeedr platform supports a number of fields corresponding to the life cycle of the trade execution. The following 3 below a typically looked at when analyzing latency:

  • TradeTime. Time when the trade was filled. This can be the time when the Execution Report via FIX is received. Execution time is that of the LP. For Voice trades can be just whenever the trade is entered into a booking system. Obviously for Voice trades the statistical analysis would have to be very different.
  • SentTime or Arrival Time. It is the time at which the order was sent out to LP. The difference between Trade Time and Arrival Time is Round Trip Time (RTT) – the time it takes you to know the outcome of the trade quest (filled, rejected, accepted as limit in order book). The RTT generally characterizes the latency unless LP artificially delays the execution (Last Look). The terminology here can be somewhat confusing. Arrival time terminology is rooted motivated by Buy Side/execution desk language (as it is the time trade order arrives to execution desk from portfolio management system.  We prefer to keep both name of the same time as Arrival Time is very common in the Implementation Shortfall literature. As the the risk on confusing matters more, this time can also be called QuoteActionTime. This is because in FX the orders are normally sent against received Quote.  
  • Quote Time. The time of the quote as labelled by Liquidity Provider. Quote time should generally be before the Arrival Time (as you need to receive a quote before deciding to trade on it). However Arrival time is generally recorded by the trader while Quote and Trade Time by LP so it is useful to have both to identify time sync problems and problems with late quotes from ECN.

     

The sequence of times is show on Figure 1 below.

Figure 1: Different Times in Trade Execution Cycle

 

Type of Analysis

Quote time is generally measured as a conditioning variable to optimize routing. For example is a reasonable to believe that older quotes have higher chances of being rejected by LP when acted upon.

However, market participants mainly pay attention to the time period difference between TradeTime and SentTime. During this waiting time window two outcomes are possible (for standard trade on quote trading style): fill (may be partial) and reject. Fills would have to be marked against the prevailing market mid to capture the cost of execution (Spread Paid). Rejects would have to be marked against the mid-price move between SentTime and TradeTime (more like RejectTime in this case) to capture the opportunity costs.

The difference between mid-price moves in fills and reject scenarios is what constitutes symmetric or asymmetric last look.  If LP accepts trades which go in his favor and reject trades which go again him, there will be asymmetry. There are many definition of this asymmetry which are considered in a separate note.

Measurement and Interpretation

As follows from the above definitions, latency is a characteristic of bilateral connection between the trader and his LP. Same LP may have latency variation due to general line noise and business of the LP order system. So the most natural first step in any analysis is to consider the distribution of latency per LP.

Typical comparative latency is shown on Figure 2. This is a screen Tradefeedr use would use to get the first view of latency. With latency charts the log scale is normally required as “tail” can be quite large. We can make a number of observations from the chart below.

First average LP latency varies quite a bit. The smaller is the LP latency the more like the physical factors (connect like) and our order management system delays are going to proportionally affect it. This is because 1ms added on top the average latency is 3ms is more visible than 1ms added on top of the average latency of 200ms. If LP latency is large and reasonably constant it is likely to be arterially inflated. This might not a problem in itself but longer waiting time definitely have a potential of non-trivial cost.

As latency tail is big, more of the cost might be there. Therefore, 99% latency is the popular measure

Figure 2: Tradefeedr Analysis of Latency Distributions Across LPs

 

As latency normally classifies the connection there is no reason to for an LP to give different latency across different currencies or order types. This is unless some business logic is involved. A simple visualization is presented on Figure 3. In the picture below we would expect slow LPs to remain slow across all currencies and fast LPs to remain fast. Most of the time it is the case.

Figure 3: Latency Map Across Currencies

 

Latency also should not change over time. This is unless LPs order management system slows down in busy periods. Or unless LP uses latency to “risk manage” orders during busy periods. In both scenarios this is not good news for the trader. Simple visualization can uncover potential problems early.

Finally latency should be reasonably constant over time and sharp move would indicate a significant changes in LP infrastructure. Figure 4 shows how to track LP latency over longer time periods (top panel) as well as intraday (bottom panel)

Figure 4: Latency Over time (trend) and Intraday

 

 

Cost of Waiting

Apart from generic inconvenience and indirect costs like having to wait for the outcome of your order, costs of latency can be evaluated directly. It can be quantifies as simple an average mid-price move during the latency window (from the time the order is sent to the trade time when the execution report received)

Figure 5 shows a typical costs of latency over time. There are normally positive (ie if there was no latency this cost would have been a additional profit traded P&L). More often than not cost of rejects is higher than costs of fills.

Figure 5. Costs of Latency

 

 

 

Conclusion

Latency can be costly. Latency is also a complex interplay between network connectivity, LP order management system and trader order managements system. Therefore tracking cost of latency over time is extremely important. Especially measuring it across LPs, ccy and time of the day can give clues on when it increases (and its costs can potentially increase). If latency increase during busy period it may be just the LP system are overloaded. If it increases during rejects chances are the LP is using your order a signaling variable. In any case, it should be tracked. It is impossible to claim best execution without tracking latency