Fixed-Latency Models

Suppose you want to backtest a latency-sensitive strategy using historical market data. Given an event you receive at time t, you need to know the state of the order book at time t+Δt when your order reaches the matching engine. For the sake of this article, it is assumed that you want to use a constant latency Δt.

What one typically sees is that the median optimal Δt is much smaller than the value during "interesting" events. Hence, latency models that base the value on all market data are usually overly optimistic. There is no harm in using a value only based on observations from competitive events as the latency does not matter much during non-competitive periods.

But even before picking a value for Δt, we need to define what we want to model. There are several levels of sophistications:

(1) You do not have the exact time when you received the data. The only timestamp you have is the one contained in the market data. Using EOBI as an example, let's assume you use the matching-engine-in timestamp, t5 (but the choice does not matter in this mode). You need to estimate the round-trip latency from t5 of the triggering event to t5 of your order arriving.

(2) You do have the receive timestamp (t11) and only need to estimate the one-way latency to the matching engine.

(3) Same as (2) but instead of using the matching-engine-in timestamp, you model the lower-variance, earlier gateway-in-timestamp t3n. This is possible because the sequence of events is already determined at this point.

The resulting quality of the latency model is depicted in Fig. 1 below. It is only based on competitive events in the Bund Future (FGBL) for a day, i.e., only looking at brief intervals (1 ms) following trades. The results do not vary much across instruments and dates. It is assumed that the internal latency (wire-to-wire, between receiving the trigger and sending the order) is 10 μs.

The horizontal axis denotes the choice of Δt. The vertical axis and color coding represent the composition of the error. "Error" here is by how many book updates off our estimated arrival time from the actual arrival time of our order is. Shades of blue are cases where your latency model is too optimistic, greys are cases where it is too pessimistic.

The top panel represents scenario (1) where the horizontal axis is the round-trip latency. We see that no matter the choice of latency, our model is rarely correct (narrow green area). We are often off by tens or even hundreds of book updates.

Switching to the one-way latency, but still based on matching-engine-in timestamp makes virtually no difference (center panel).

The bottom panel suggests that one can use a fixed-latency model when using t11 (receive timestamp) and t3n (gateway-in-timestamp) as reference timestamps. There is now a narrow range of latencies where one is correct >90% of the time. Note, however, that

• Your internal latency (t11→t1) is known and a constant. Participants operating in the 10 μs reaction time range usually have the CPU, feed handler, and model calculation in the critical path. This assumption, hence, is probably wrong. And it is wrong the most when it matters the most.
• For participants operating in the nanosecond regime, t3n still has too much variance. Plus, even being off by a single book update is the difference between a hit and a miss.

Still, assuming you use a fixed-latency model and have a high-quality (and synchronized to the exchange clock) receive timestamp, please use the gateway-in-timestamp as exchange timestamp for your backtests. It is much lower variance than any subsequent timestamp and it is available in the public, real-time EOBI market data.

Obviously, the "correct" approach is to use the even earlier and even lower-variance ETI capture timestamp (t3a) from the HPT files. This then allows one to model latency differences in the nanosecond range.

#latency #trading #backtesting #marketdata #stocktrading #derivativestrdaing #eurex #xetra