Who this is for — Readers who want to understand why the quantity shown in an order book may be smaller than the quantity actually available, and traders who need to work an order without displaying its full size at once.
An iceberg order, also called a reserve order or display quantity order in some systems, is usually a limit order for which the market sees only a displayed amount. The undisplayed portion is the reserve. When the displayed slice is filled, the system may release another slice until the total quantity is filled, expires or is canceled.
Iceberg does not universally mean “invisible order.” The displayed portion participates in the book. The reserve, its release conditions, disseminated data and priority after replenishment all depend on the rules of the individual venue and product.
In plain terms — A 1,000-unit order might display 50 units. After those 50 trade, another 50 may appear. Knowing that replenishment exists does not reveal either the remaining quantity or its queue priority.
Instruction, quantity and replenishment
| Element | Function |
|---|---|
| Parent order | Defines the side, limit price and total quantity |
| Display quantity | Sets the maximum amount shown at a given time |
| Reserve quantity | Portion not yet displayed in the public book |
| Replenishment | Release of another slice after a fill or another specified condition |
| Child order | New order sent by an external system in a synthetic iceberg |
Terminology is not uniform. Under Commission Delegated Regulation (EU) 2017/583, RTS 2 for non-equity instruments, Article 4 describes a reserve order as a limit order made up of a disclosed portion and an undisclosed remainder. The undisclosed quantity can execute only after it has been released to the order book as a new disclosed order. This is a regulatory definition for that particular scope, not a technical specification for every exchange, broker or crypto venue.
“Display quantity” may likewise be an order qualifier rather than a standalone order type. CME, for example, documents a displayed amount that replenishes as it is filled. Users should therefore read the product documentation before using the feature instead of inferring its mechanics from the label shown in an interface.
Native and synthetic icebergs
A native iceberg is managed by the matching engine or other venue infrastructure. The venue receives the total quantity and controls display and replenishment. A synthetic iceberg is managed by a broker, independent software vendor or external algorithm: the venue may see only a succession of child orders without knowing the parent size.
The distinction changes both operational risk and the traces left in market data:
- a native order depends on the venue's availability and rules;
- a synthetic order also depends on the network, gateway, latency and continuity of the system submitting the children;
- a native order may keep the same order identifier as it replenishes, while synthetic children may receive new identifiers;
- order identity and queue priority are not the same thing.
CME's Market by Order documentation, for example, explains that a native
iceberg retains the same OrderID when its displayed quantity refreshes, while
its PriorityID may change. A synthetic iceberg managed outside the venue
submits new orders instead. The example shows why a priority rule from one
market cannot be carried automatically into another.
Priority and fill probability
The limit price remains a price constraint, not a promise of execution. The displayed slice competes under the applicable matching algorithm; a later slice may receive new priority or different treatment. Price-time, pro-rata and hybrid rules can produce different outcomes.
Hiding quantity may reduce initial information exposure, but it does not make the order immune to:
- partial fills or no fill;
- the market moving away from the limit;
- adverse selection when other participants trade against the quote;
- venue-specific fees and access rules;
- loss of priority on replenishment;
- the feature being unavailable for a particular instrument.
The effect on market impact is not guaranteed. Displaying less size can limit the information revealed immediately, but repeated replenishment may itself disclose interest and change how other participants behave.
Can an iceberg be detected in the book?
Only by inference. Many trades at one price accompanied by a displayed quantity that repeatedly reappears are consistent with an iceberg; they do not prove one exists. Independent new orders, multiple participants, aggregated feeds, cancellations and data latency can produce a similar sequence.
A Market by Price feed aggregates quantity by price level. A Market by Order
feed can provide more granular order and queue-position data, but it remains
anonymous and does not necessarily disclose the total reserve. Even a
persistent OrderID does not identify the owner.
Common mistake — Turning a possible refresh into certainty about a “whale,” directional intent or remaining quantity. The observation may support a microstructure hypothesis; it does not reveal the sender's identity or future behavior.
Controlled example
A sell limit for 10,000 shares displays 500. The first 500 execute and the venue shows another slice. An aggressive trader can see that new quantity has arrived at the price, but cannot know whether 500 or 9,500 shares remain, whether the refresh lost priority, or whether part of the sequence came from separate orders. Evaluating the execution requires logs, venue specifications and data consistent with the feed being used.
Pre-use checklist
- Establish whether the implementation is native or synthetic.
- Read the display rules, minimum quantities and eligible products.
- Check initial priority, replenishment priority and amendment rules.
- Separate total, displayed, executed, canceled and remaining quantity.
- Measure fills, cost and impact against a declared benchmark.
- Determine what happens if an external system or connection fails.
The wider framework is covered by the Orders, execution and market microstructure hub. See order-priority-and-partial-fills for queue rules and order-splitting for working a larger quantity in pieces.
Sources
- CME Group, Market by Order (MBO) — FAQ — MBO versus MBP feeds, native and synthetic icebergs,
OrderIDandPriorityID. - CME Group, Display Quantity Order Overview — displayed quantity, fills and replenishment within the CME framework.
- CME Group, Enter Orders — operational description of the Display Quantity field.
- EUR-Lex, Commission Delegated Regulation (EU) 2017/583, Article 4 — reserve-order definition within RTS 2.