In an algorithmic trading setup, there are many hops between when the market data first reaches the trading server and when the order flow in response to the new data reaches the trading exchange. First, the market data feed handler reads it and decodes it, the trading strategy then receives the normalized market data, and then the strategy itself updates the trading signals based on the new market data and sends new orders or modifications to existing orders. This order flow then gets picked up by the order gateway, converted to an exchange-order-entry protocol, and written to the TCP connection with the exchange.

The order finally gets to the exchange after incurring latency equal to the transmission latency from the trading server to the matching engine at the electronic trading exchange. Each one of these latencies needs to be accounted for in backtesting trading strategies, but it can often be a complicated problem. These latencies are most likely not static latency values, but vary depending on a lot of factors, such as trading signal and trading strategy software implementation, market conditions, and peak network traffic, and if these latencies are not properly modeled and accounted for in historical simulations, then live trading strategy performance can be quite different from expected historical simulation results, causing simulation dislocations, unexpected losses in live trading, and impaired trading strategy profitability, possibly to the point where the strategies cannot be run profitably.