Iceberg Orders: Display Size, Hidden Quantity and Fills

Compare the owner’s quantities with the public price level, then advance through the incoming buys. The A/B queue is an educational view of a known scenario; an ordinary public book does not identify the hidden reserve or tell you who owns each order. After changing the settings, apply them to build a new example. The step sequence is fixed, so a larger custom order may remain partly unfilled.

Iceberg or reserve orders let a trader specify a displayed portion of a larger order. Interfaces may call this Display Size, peak quantity or visible quantity. Distinguish the setting from the amount currently resting in the book:

For an order with no cancellation: total = executed + remaining, and remaining = displayed + hidden. Replenishment moves quantity from hidden to displayed; it does not add to the original order. The display cap can stay unchanged while the displayed remainder falls after a partial fill.

The starting example is a sell order for 25 units at a limit price of 100, displaying up to 10 and holding 15 in reserve. A separate sell order B for 5 units sits behind its first slice at the same price. These are invented units and prices, with no other price levels, orders or cancellations.

An incoming buy for 4 takes the iceberg’s displayed quantity from 10 to 6. Its hidden reserve stays at 15 and its executed quantity becomes 4. The public level now shows 11: the iceberg’s 6 plus B’s 5. An incoming buy for another 6 exhausts the first slice. The model displays a fresh 10, leaving 5 hidden; this is a refill, not a new 10-unit addition to the total.

The refreshed slice goes behind B, so the next buy for 5 fills B and leaves the iceberg’s executed quantity unchanged. Later, when only 5 iceberg units remain, the last displayed slice is 5 even though the cap is 10. The full event log is available in the component.

This queue rule follows the published Kraken trading rules: replenished quantity moves to the back of its price queue. It is a chosen model, not a rule for every exchange. The “one incoming buy” scenario also shows that a single sufficiently large opposing order can consume multiple refreshed slices. CME’s fill-message documentation describes multiple refreshes within one matching event; a refill need not mean a new buyer or a separate execution report.

“Synthetic” does not necessarily mean the logic runs on your own computer. It may run on a broker’s server. Closing a local terminal therefore does not have the same consequence for every implementation; establish where the parent order is managed.

CME Market by Order distinguishes native and synthetic implementations. A native CME iceberg retains its OrderID when replenished, but its PriorityID may change. A persistent identifier is therefore not proof that the refreshed quantity keeps its earlier place. Apply the actual product’s matching rules rather than assuming one universal FIFO queue.

Some settings can be combined when the venue permits it; they are not interchangeable order names. A stop condition concerns activation, whereas an iceberg concerns displayed quantity. The Buy Stop vs Buy Limit guide explains the trigger and limit-price distinction.

An aggregated order book shows displayed quantity at a price. It can combine several orders, as the demonstration’s level combines the iceberg and B. Order-level feeds can provide more detail, but the available fields and identifiers depend on the feed. The component exposes both sides for teaching; it does not recover private quantities from market data.

Repeated executions followed by replenishment may suggest hidden liquidity. They do not, by themselves, reveal the exact original quantity, remaining reserve or owner. New independent orders can also arrive at that price. Treat an inferred iceberg as a hypothesis whose evidence depends on the feed, not a confirmed map of another trader’s intentions.

Displaying only a slice limits how much size is advertised at once. It can be useful when a trader wants to work a larger order without publishing all its remaining quantity. It does not make executions invisible, guarantee lower market impact or ensure that the market keeps supplying willing counterparties.

• A price limit protects the acceptable execution price; the unfilled remainder can still wait or never trade.
• Replenishment can change queue priority. A smaller displayed slice is not automatically a faster way to complete an order.
• Other participants can react to visible executions and order-book changes even when the full reserve is concealed.

Keep price protection separate from execution quality against another benchmark. The slippage guide explains differences between reference and execution prices; an iceberg setting alone does not remove those comparisons.

• Confirm that this instrument, exchange and routing choice support the order, and identify whether it is native or synthetic.
• Check minimum quantity, quantity increments, allowed display size and time-in-force in the current specifications.
• Read the replenishment, priority, modification and cancellation rules, including how synthetic child orders are handled.
• Check the actual fills and remaining parent quantity in the order report, and use the applicable fee schedule.

Kraken’s order guide illustrates venue-specific display requirements; its exact limits do not apply to every venue. This demonstration uses whole units and a fixed display cap to make the mechanics inspectable. It is not a venue eligibility checker or a live order router.

Does an iceberg always pay maker fees?

No. “Iceberg” describes displayed quantity, not the liquidity role of every execution. Whether it can match immediately, which combinations of flags are allowed and what fee applies depend on the implementation and execution. Check the venue’s maker/taker rules. The trading-cost guide also explains why quoted spreads and commissions should be assessed together.

Can I place one from MT4 or MT5?

A depth-of-market window alone does not establish iceberg support. Your broker must offer a suitable order route or an external implementation for that instrument. Check its documentation and a test environment; a synthetic tool may have different connection and cancellation requirements from a native exchange order.

Should I always choose the smallest display size?

There is no universally best display size. Smaller slices disclose less at one time but may require more replenishments, with the queue treatment specified by the venue. Quantity minima and increments also constrain the choice. The demonstration explains these mechanics; it does not optimise a live execution strategy.