DOM, MBO, and Icebergs: Know What Your Order-Flow Feed Reveals

Icebergs separate displayed and total size

An iceberg or reserve order displays only part of its total quantity. As the visible portion executes, another portion may become visible under the venue's rules. A synthetic iceberg can be implemented by a participant submitting separate child orders rather than using an exchange-native reserve feature.

These mechanisms can leave different observable signatures. A persistent order identifier through a native refresh may support one kind of inference, while repeated new identifiers support a weaker pattern-based hypothesis. Exact rules are venue-specific. A “detected iceberg” label should say whether it reflects direct message evidence or a probabilistic pattern.

Suppose 100 contracts remain displayed while 1,000 trade at a price over several seconds. That suggests replenishment or multiple arriving orders, but it does not prove a single original hidden order of exactly 1,000. Some activity may belong to independent participants, and the original total could be larger or smaller than a naive cumulative count.

Queue position needs matching rules

Price-time priority is not the only matching method used across futures products. Some use pro-rata or hybrid allocation. A display's apparent order sequence cannot determine your fill without the applicable rules, order attributes, and event history.

CME's explanation of its central limit order book describes MBP, MBO, and different allocation approaches in its agricultural markets. The broader lesson is to check the exact product specification instead of importing assumptions from another contract.

For research, distinguish “the market traded at my limit price” from “my order would have filled.” A touch-based simulator can produce optimistic results when substantial quantity is ahead, orders receive different priority, or the market trades too little size to reach the hypothetical position in queue.

Completeness is an operational requirement

Order-book reconstruction needs an initial state and correctly ordered updates. Gaps, duplicate messages, resets, or missing snapshots can corrupt the book. A chart that resumes showing fresh prices after a disconnect has not necessarily reconstructed the full queue correctly.

Ask whether historical data contains actual depth events or only sampled snapshots. Snapshots can show broad liquidity changes but miss short-lived additions and cancellations. Claims about exact replenishment or queue behavior require data with the relevant granularity and continuity.

Also check timestamp semantics. Exchange event time, receive time, and display time answer different questions. A useful analysis preserves those distinctions rather than attaching a single “live” label to all of them.

Use the detail for a defined question

Start with a narrow objective, such as observing whether offers replenish at a premarked reference. Record the visible sequence, executed quantity, subsequent price behavior, and uncertainty. Avoid trying to identify a particular institution from anonymous activity.

Compare that observation with a simpler footprint view. If order-level detail does not change the research decision, the additional complexity may not be necessary. The right feed is the one that supports your actual question with clear limits.

Read liquidity heatmaps and footprint interpretation. Explore OrderMap as read-only analytics, verifying the specific data types, provider coverage, and entitlements available before relying on MBO, depth history, or inferred iceberg features.

Ask the vendor a concrete data question

Instead of asking whether a platform has professional order flow, ask whether the selected subscription supplies individual order identifiers, the full supported depth range, exchange timestamps, and chronological historical updates for your exact contract. Ask how resets and missing intervals appear. Those answers establish whether a proposed queue or replenishment study is possible.

Then inspect one short sample. Verify that you can distinguish an add, a cancellation, and an execution under the documented message rules. If the available output is only periodic snapshots, adapt the research objective to broad depth behavior rather than claiming exact event reconstruction.

Finally, separate the upstream feed's capabilities from the platform's implemented display. A provider may offer MBO while a particular integration uses only aggregated depth. Conversely, a useful MBP view need not pretend to expose individual orders. The relevant capability is the one actually delivered to the workflow you are using.

Explore OrderMap plans