MBP and MBO, two ways to describe the same book

Every order book can be described in two ways. Market by price, or MBP, adds up all the orders at each price and sends one number per level. Market by order, or MBO, sends every order separately with its own ID. The book is the same in both cases. What changes is how much of it your software can see.

The same level, described twice

Take an invented bid at 4,980.00 in the E-mini S&P 500 future.

An MBP feed describes it as one line. Bid, 4,980.00, 120 contracts.

An MBO feed describes the same level as a queue of separate orders, in the order they arrived.

The total is still 120. MBO also tells you the level holds seven orders, that one order accounts for 50 of the 120 contracts, and which order fills first.

What changes when the book moves

Suppose 30 contracts sell into the bid. On CME futures most contracts fill resting orders first in, first out, so order 7731 fills 30 of its 50.

The MBP feed sends one update. Bid, 4,980.00, 90 contracts.

The MBO feed sends an update for order 7731, which now shows 20 contracts left, plus the trade.

Now suppose order 7802 cancels. MBP shows 120 dropping to 100 and cannot tell you whether that was a fill or a cancel without checking the trades. MBO shows which order was cancelled and that no trade happened.

Depth limits

The two formats also differ in depth. CME's MBP book for most futures carries ten price levels on each side. CME's MBO data carries every resting order at every price. If you care about large orders twenty ticks away, MBP cannot show them and MBO can.

Your platform's view also depends on your data provider. Some providers pass full MBO data through, some pass MBP only, and some pass a reduced version. The glossary explains depth and entitlements, and the cost guide lists data charges by platform.

Why iceberg detection needs MBO

An iceberg order shows only part of its size. When the visible part fills, the exchange displays a new slice at the same price. On an MBP feed this looks like a level that gets hit and then refills. A refill might be an iceberg, or it might be several new traders joining the bid, and MBP gives no way to tell them apart.

On an MBO feed the pattern is clearer. A slice fills completely, and a new order of the same size appears at the back of the queue at the same price straight away. That repeats several times. The order IDs, sizes and timing give software something concrete to test.

Here is the same bid in Liquivue. On an MBP connection, the 4,980.00 level shows as a band that dims and brightens again while trade bubbles keep printing beside it. Suppose the bubbles add up to 600 contracts while the band never shows more than 120. You can see that more traded than was displayed, but not why. With live CME MBO data, Liquivue can also mark the level as a possible iceberg, because the software can match each refill to a new order at the back of the queue.

This is why Liquivue ties its native iceberg detection to live CME order-level data. The feature is experimental, and it depends on your connection passing MBO data through. Liquivue's heatmap, trade bubbles, volume and delta profiles, CVD and VWAP do not need MBO, and they work from the data your Rithmic or NinjaTrader bridge connection supplies.

Which one do you need

For a first heatmap or DOM, MBP data covers most of what a new reader looks at. You see where size is resting and how it changes near price. MBO data starts to matter when you want queue position for your own limit orders, order counts per level, or evidence of iceberg orders. The earlier note on what the DOM shows and hides lists the gaps MBP leaves.

Before paying for order-level data, check three things with your data provider and platform. Confirm the exchange and contracts covered. Confirm whether the provider sends full MBO or a reduced feed. Confirm that your platform reads the MBO fields and does not only aggregate them back into MBP. If any answer is unclear, ask for the provider's documentation before you subscribe.