Iceberg Orders on CME: How They Work and What the NQ Heatmap Shows of Them

Twenty contracts show on the offer at one price. Over the next minute three hundred trade there, and the offer still shows twenty. Somebody is selling far more than they're displaying, a slice at a time. That's an iceberg order: a large limit order that shows only part of its size in the order book and refills the visible part as it trades.

On NQ, the E-mini Nasdaq-100 future, icebergs are a native order type of the exchange. The contract itself is covered in NQ vs MNQ tick value and point value, and the basics of reading trades against the book in order flow trading explained.

How CME handles them

CME Globex lets a futures order carry a display quantity: the order rests with only that many contracts visible, and the rest stays hidden from every market data feed. When the visible slice has fully traded, the exchange puts up the next slice, the same size or whatever is left, at the same price, at the back of the queue. NQ is matched first in, first out (FIFO): at each price, the order that arrived first fills first. So every refill gives up its place, and a slice can wait behind orders that joined the level after the iceberg did. That's the price of hiding size.

There are two kinds of iceberg, and the difference matters for spotting them. A native iceberg is held by CME itself, and each refill keeps the same order ID. A synthetic iceberg is built by a trading platform or an execution algorithm that sends small orders one after another, and each slice arrives as a new order with a new ID. To the exchange the second is just a series of ordinary orders.

What you can see of one

On aggregated depth, an iceberg looks the same as many traders rejoining a level that keeps trading, so the signal is the pattern, not proof: trades keep hitting the price and the size doesn't shrink. Market-by-order data is more specific. Every resting order carries an anonymous ID, so a native iceberg shows up as one order refilling, and CME itself notes that a stable order ID makes icebergs easier to detect. Either way, an iceberg is only visible after it trades. Until the first slice fills, it's an ordinary order of twenty.

Bookmap's Stops & Icebergs add-on automates the MBO version, marking icebergs as they trade, are fully executed or are canceled. It needs CME MBO data, which at the time of writing means a Rithmic connection with quote aggregation turned off or Bookmap's own CME data; through NinjaTrader's connection Bookmap gets depth without order IDs. The heatmap itself is set up in Bookmap for NQ.

How traders read one

An iceberg says that someone was willing to trade a lot of size at one price without showing it. What it means for the next move is a hypothesis, and traders read it three ways.

The level holds. Aggressive buyers keep lifting the offer, the iceberg keeps refilling, price doesn't go through. This is what order flow traders call absorption: in cumulative volume delta it shows up as strong buying with no progress in price. Some traders read it as a reason to fade the buyers once they give up.

The iceberg runs out. If buyers eventually take the whole order, the price that held is gone and the last obstacle with it, and the move through the level can be fast.

It disappears. The order is canceled before it's filled, and the level stops meaning anything.

None of the three is a signal on its own, because the order's purpose is unknown. A fund rebalancing an index position, a hedge on an options book and a market maker managing inventory all use icebergs, and none of them is betting on the next ten points.

NinjaTrader 8 doesn't offer an iceberg order type of its own; a trader who wants one can slice orders in NinjaScript, which makes a synthetic iceberg with a new ID for each slice. At micro and retail size there's rarely a reason to. The heatmap I keep next to NinjaTrader for NQ is Bookmap.