5
$\begingroup$

We're developing an HFT strategy for highly liquid futures traded at Eurex. We are planning to colocate our server and to use data feed of QuantHouse and execution API of ObjectTrading. Backtesting is performed on tick data bought from QuantHouse, where timestamps have millisecond resolution (BTW, trades and quotes are sorted separately, so if trades and quotes have a same timestamp, they are not sorted). My question is about latency we should use for backtesting. I define latency as: data feed latency + internal processing time (several microseconds) + execution latency. We simulate this by adding X ms to the feed time (T) of the tick that triggered the trade, then if the last tick with the feed time not later than T + X was a quote we use its book for execution, otherwise (if the last tick with the feed time not later than T + X was a trade) we wait for an incoming quote and its book is used for execution. So my questions are:

  1. Is our execution model reasonable?
  2. What X should be used for our setup?
  3. Could you suggest other (not too expensive) setup in order to reduce any kind of latency?
$\endgroup$
  • $\begingroup$ The value of X is heavily dependent on your set-up. No one here will be able to answer that for you; you'll have to determine it empirically. $\endgroup$ – chrisaycock Jun 4 '12 at 11:19
  • 1
    $\begingroup$ Cross-posted on NP. $\endgroup$ – Joshua Ulrich Jun 4 '12 at 12:27
  • $\begingroup$ Q:Is our execution model reasonable? It looks reasonable, but are you keeping the liquidity and order quantities in the mix? Its easier to ignore the Qty of a quote available on book, but it may hurt you later in case you are using huge quantities and the market liquidity is not enough for it. Q:What X should be used for our setup? What kind of a network connection is being used? What speed? Copper or fibre? After this information is available to you, you should be able to make an educated guess. But it is always best to run your own tests to find the network time X. $\endgroup$ – Aziz Jun 5 '12 at 5:47
  • $\begingroup$ Thank you. Colocation in Equinix, fibre line. We're still developing a strategy, so currently we cannot find X empirically. $\endgroup$ – l.m Jun 6 '12 at 8:15
4
$\begingroup$

First the kind of strategy you plan to implement is of importance:

If it is scaling (arbitraging spread crosses: buy at one ask one one venue that is cheaper than one bid in another venue), the kind of approach you plan to use is rational. Nevertheless you should take into account:

  • the fact that the latency is somehow not deterministic, use a Poisson process for the duration between two messages,
  • the latency is not the same at any time during the day, more or less proportional to the activity (U shaped in the US, with an increase when NY is open in Europe).

If it is a stat arb based strategy, your PnL should not be too sensitive tonthe ordering of the messages. Instead of adding latency, you should backtest with local perturbations on the order of the messages (with for instance a radius of 1 to 10 messages).

$\endgroup$
  • $\begingroup$ Thank you. Our strategy is a stat arbitrage strategy. Does "bid-ask crossing" mean that we are liquidity takers? We are going to take liquidity. We thought about random perturbation of quotes, but only with a same timestamp (ms resolution, once again). $\endgroup$ – l.m Jun 6 '12 at 8:10
  • $\begingroup$ I mean: to arbitrage bid-ask crosses between two trading destinations. $\endgroup$ – lehalle Jun 6 '12 at 14:29
  • $\begingroup$ Could you please explain why stat arb PnL should not be sensitive to the ordering of the messages? $\endgroup$ – user2763361 Oct 6 '13 at 11:44
0
$\begingroup$

I would say the average latency for most data providers ( level 1 CTA feed ) is between 100ms-450ms.

This also varies when there are spikes in trade volume, eg: Market Open/Close.

$\endgroup$
0
$\begingroup$

To make it properly you should have:

  • historical data streams per instrument and
  • backtest engine is synchronizing those into one GlobalMarket object (instant quote representation after each tick). Synchronization happens by reading timestamp of each tick and then pushing it into GlobalMarket

If you have this setup, then latency can be added as a shift to timestamp of delayed ticks before synchronization. Shift can be fixed or random following some distribution of latency. Even collocated trade-boxes have random latency following very narrow distribution.

However, be aware of the following.

  • The data you store might have physical (actual) latency already. So, do not add latency to those. Or at least, subtract expected latency (which is random) and only add the wanted one
  • It makes sense to add latency only if you use data stored by exchanges from their matching engine. But even then, there is a chance that exchange clocks (used for timestamps) are misaligned, likely by fixed value. They should use some atomic clock synchronized between them to make perfect match of their timestamps.

There might be more caveats in it. The above might help you to identify them.

New contributor
Nikolai Zaitsev is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.