How do you handle crossed states and latent matching loops in NSE Equity Order Book?

Algos, strategies, code
1

Hi everyone,

I am currently developing a local order book builder using the tick-by-tick (TBT) / Level 2 data feed for the Indian Equity market (NSE).

While processing the order book packets, I occasionally encounter a crossed market state, where the best ask price becomes lower than or equal to the best bid price (Ask <= Bid).

In most high-liquidity cases, this crossed state is resolved almost instantly by a rapid succession of trade execution messages. However, during certain volatile periods or when disclosed quantity orders (hidden liquidity) are involved, I notice that the order book remains in this crossed state for an extended period—sometimes up to ~3ms—before the exchange finally clears it and the book unlocks.

This introduces a synchronization lag between my local order book simulator and the actual exchange matching engine state. For those who are running live algo-trading or HFT setups on NSE:

  1. How do you handle these 3ms crossed state windows? Do you freeze your execution logic and passively wait for the exchange to emit the official trade/cancel logs to correct the book?
  2. Is there a more efficient, proactive method or heuristic to predict how the hidden/disclosed quantities will match, or do you just rely strictly on price-time priority rules to simulate the queue internally while the cross is active?
  3. Does treating the book as “locked” during this brief window cause significant slippage or missed execution opportunities in your experience?

Would love to hear how the community approaches this edge case. Thanks!

2 Likes
2

Which data feed are you talking about? I have never encountered a crossed state in the L2 feed, its not possible there.

3

You’re right, my mistake. I mixed up the terminology. I meant the MTBT multicast feed (order-by-order), not Level 2 MBP.