In the previous section, we looked at the importance of understanding and modeling latencies in an algorithmic trading setup correctly when backtesting trading strategies. If after carefully understanding, accounting for, and modeling latency variances in the algorithmic trading setup in historical simulations and redeploying the algorithmic trading strategy to live markets, we are still noticing simulation dislocations that are causing a deviation in strategy performance in live markets from what is expected, we can look into further backtesting sophistication.

Modern electronic exchangers provide a lot of information about every aspect of the matching process, beyond just providing accurate timestamps. There are a lot of transactions that take place during a matching event which, if not accounted for in a backtester, can cause a lot of simulation dislocations because they participate in matching events and can fundamentally change when a strategy can expect its orders to get executed. Non-conforming transactions such as self-match-prevention cancellations, stop-order releases during matching events, iceberg orders with hidden liquidity that over-execute or are replenished after being fully executed, matches during auction events, and implied/pro-rata matching considerations, can cause simulation dislocations if not correctly detected and accounted for in the simulator.

Different asset classes come with their own set of matching rules and complications. Dark pools, hidden liquidity, price improvements, hidden counter parties, and a lot of other factors can end up creating simulation dislocations and ultimately cause an algorithmic trading strategy to fail. Understanding all these rules, implementing them in software, and building accurate simulations on top of that is a very difficult problem to solve, but can often be the difference between success and failure in the algorithmic trading business.