Crossed Book
A crossed book happens when the normal bid and ask relationship inside an order book is broken. In a healthy limit order book, buyers place bids below the lowest available seller offer, so the best bid should be lower than the best ask. If the best bid is 100.05 and the best ask is 100.00, the reconstructed book is crossed because the buy side appears to overlap the sell side. This is especially important in crypto market data because many systems build local books from snapshots and incremental updates rather than receiving a fully trusted book state after every event. A crossed book is often a sign that messages were applied out of order, a delta was missed, a snapshot was stale, or an update was processed under the wrong symbol or side. It can also happen when duplicate events are not handled safely and the local state keeps liquidity that should have been removed. In order-by-order data, the issue may come from incorrectly tracking order lifecycle events such as add, modify, trade, cancel, or trigger. For Level 4 order book data, reconstruction logic may also need to distinguish active executable orders from parent orders, child orders, conditional instructions, and other non-active records. A crossed state does not automatically prove that the exchange itself traded incorrectly, because the problem may be inside the consumer pipeline. It does mean the reconstructed state should be treated carefully until sequence continuity, snapshot alignment, and state-machine rules are checked. Good market data systems treat crossed-book detection as a validation rule that helps identify when the local book may no longer be reliable.
Why It Matters
Crossed books matter because they can make liquidity, spread, and executable depth calculations wrong. If a trading, analytics, or backtesting system trusts a crossed reconstructed book, it may assume that impossible or stale prices are available. For L2, L3, and L4 workflows, crossed-book checks help teams detect reconstruction failures before invalid book state reaches downstream users.
What causes a crossed book in reconstructed market data?
A crossed book often starts with an ordering problem in the feed handling process. For example, a cancel message may arrive but not be applied before a later add or trade event changes the opposite side of the book. A missing snapshot or a gap in incremental updates can leave stale prices in place, so the best bid or best ask no longer reflects current venue state. Incorrect parsing can also create the problem, such as reading an ask as a bid, using the wrong price precision, or applying an update to the wrong trading pair. In WebSocket workflows, reconnects can introduce overlapping or duplicated messages if the consumer does not apply idempotent rules. The practical cause is usually not one field by itself, but a break in the full reconstruction chain from raw message to validated book state.
How should validation logic detect a crossed book?
Validation logic should compare the best bid and best ask after each accepted snapshot or incremental update. If the best bid is greater than or equal to the best ask, the system should flag the state as crossed or locked according to its internal rules. The check should happen after the state machine has applied message semantics, not before, because raw messages may contain updates that only make sense in sequence. For aggregated L2 books, this means checking the top price levels after quantities have been updated and empty levels removed. For L3 and L4 books, this means checking only orders that are active and executable, then aggregating them into bid and ask depth. The validation result should include enough context to debug the issue, such as symbol, venue, sequence, timestamp, last snapshot reference, and the raw messages around the transition.
What should a system do after finding a crossed book?
A crossed-book event should usually be treated as a warning or validation failure, not as clean executable market depth. The system should log the raw messages that produced the state, preserve the previous valid state if needed, and check whether sequence continuity was broken. It should compare the local book against the latest available snapshot and determine whether a resynchronization is required. If duplicate or repeated lifecycle events contributed to the issue, idempotent update rules should be reviewed and tested. If the problem appears after a reconnect, the consumer should confirm whether the sequence values are scoped only to the current connection. Crossed-book detection is useful, but it is not a replacement for correct sequencing, snapshot handling, and state-machine design.
Real-World Example
A crypto market data consumer reconstructs an order book and sees a best bid of 100.05 with a best ask of 100.00. Because the highest bid is above the lowest ask, the local state is crossed. The application should not treat both sides as clean executable depth without checking how the book was built. A safer response is to flag the symbol, inspect the most recent snapshot and deltas, verify sequence continuity, and resynchronize if the local state cannot be trusted.
Crossed Book and Market Data API
CoinAPI Market Data API is relevant to crossed-book detection because teams use it to consume crypto order book data, snapshots, and high-frequency market updates across exchanges. Developers building reconstruction workflows can use normalized market data as the input to validation checks that monitor spread logic, top-of-book consistency, and executable depth. This is especially useful when comparing historical replay, real-time WebSocket consumption, and venue-specific order book behavior.