By Matt Connor
Iceberg Orders Explained: Hidden Liquidity
What is an iceberg order? How the displayed slice and hidden reserve work, why each refresh loses queue priority, and what the pattern looks like on the tape.
An iceberg order is a single limit order resting on an exchange book with two quantities attached: a displayed size the whole market can see in the quote, and a hidden reserve behind it that the matching engine releases automatically as the displayed slice fills. The name describes the shape, a small tip above the waterline with most of the mass below. Hiding has a price, and it is paid in queue position: every refreshed slice is posted with a new timestamp, behind everything already waiting at that price.
What is an iceberg order?
Suppose a fund wants 50,000 shares and will pay up to $50.00. Entered as an ordinary limit order, the book shows 50,000 shares of demand at that price for everyone to see. Entered as an iceberg with a display size of 500, the book shows 500. When those 500 trade, the matching engine pulls another 500 from the reserve, posts it, and repeats until the reserve is exhausted or the order is cancelled.
Two things stay true throughout. It is one order at one price on one venue, and the exchange has held the full quantity since the moment it was entered.
The description you will meet most often, a trader chopping a large order into pieces and feeding them in over hours or days, is a different technique. That one is an execution schedule, run by an algorithm sending many separate child orders across several venues and measured against a benchmark such as VWAP. An iceberg is a venue order attribute. The slicing happens inside the matching engine, in microseconds, on one book.
Vocabulary varies by venue. The visible part is the display quantity or the tip, the rest is the reserve or the non-displayed portion, and Nasdaq's rulebook calls the attribute Reserve Size.
How small can the displayed slice be?
Venues put a floor under the displayed portion and express it in round lots rather than a fixed share count. Nasdaq requires the displayed size of a reserve order to be one or more normal units of trading at entry, and rounds a mixed lot down to the nearest round lot. Cboe's BZX book replenishes the displayed quantity once it has been depleted below one round lot. Wording differs by venue and gets amended, so read the rulebook of the venue you route to rather than trusting a number quoted second hand.
A round lot is no longer a flat 100 shares either. Under the amended Regulation NMS definition, in effect since November 3, 2025, it scales with price: 100 shares at $250.00 and below, 40 shares from $250.01 to $1,000.00, 10 shares from $1,000.01 to $10,000.00, and one share above that. Exchanges reassign each stock twice a year from its average closing price over a March or September evaluation period. Nasdaq's vendor alert on the change lists the tiers and the dates. On a four figure stock, the smallest permitted tip is ten shares.
Do iceberg orders lose queue priority?
They do, and this is the part most explanations skip. US equity books rank resting orders by price first and then by time. Arrive earlier at the same price and you trade earlier.
An iceberg's displayed slice joins that queue when it posts. Once the slice fills and the engine replenishes it from reserve, the replenishment enters as a new displayed order with a fresh timestamp, at the back of the line for that price. Nasdaq's rule states the asymmetry plainly:
When a Reserve Order is posted, if there is an execution against the displayed order that causes its size to decrease below a normal unit of trading, a new displayed order will be entered and receive a new timestamp, while the size of the non-displayed order will be reduced by the same amount and will not receive a new timestamp.
That is Nasdaq Equity 4, Rule 4703(h), quoted from the SEC order approving the reserve order rule change of February 18, 2021. The reserve keeps its original standing while the visible tip resets on every refresh. A 50,000 share order shown 500 at a time refreshes up to a hundred times, and each refresh starts again behind every displayed order already resting at that price. That is the real cost of hiding.
Many venues add a second cost. Displayed interest ranks ahead of non-displayed interest at the same price, so a reserve yields to any displayed order there even when the reserve arrived first.
Iceberg order vs hidden order vs dark pool
- An iceberg rests on a lit exchange and puts its displayed slice into the public quote, where that slice can set the national best bid or offer. The reserve behind it never appears in the quote.
- A fully hidden order displays nothing at all. It rests on the same lit exchange, executes at its limit price, and shows up in public data only after it trades. Venues generally rank it behind displayed orders at the same price.
- A dark pool is a separate venue with no public quote whatsoever. The print reaches the tape through a trade reporting facility after the fact.
- A block trade moves the whole quantity in one negotiated print. Maximum size, minimum duration, the opposite approach to dripping it out.
Each of these moves quantity without advertising it in advance. What separates them is where the order rests and how much of it the public quote ever carries. Hidden interest can sit at prices the quote never shows, so the visible book is always a partial picture of available liquidity, which is worth keeping in mind alongside locked and crossed markets.
How much of the tape prints in small size?
Before you can read an iceberg's footprint you need a feel for the ordinary texture of the tape. The panel below divides each month's share volume by that month's trade count for two household names with no stock splits in the window.
The exact SQL behind every number
SELECT
toString(month_start) AS month,
formatDateTime(month_start, '%b %Y') AS month_label,
round(sumIf(volume, ticker = 'MSFT') / sumIf(transactions, ticker = 'MSFT'), 1) AS msft_shares_per_print,
round(sumIf(volume, ticker = 'KO') / sumIf(transactions, ticker = 'KO'), 1) AS ko_shares_per_print
FROM
(
SELECT
toStartOfMonth(toDate(toTimeZone(window_start, 'America/New_York'))) AS month_start,
ticker,
volume,
transactions
FROM global_markets.delayed_stocks_minute_aggs
WHERE ticker IN ('MSFT', 'KO')
AND window_start >= toDateTime('2019-01-01 00:00:00', 'UTC')
AND window_start < toDateTime('2026-07-01 00:00:00', 'UTC')
)
GROUP BY month_start
HAVING sumIf(transactions, ticker = 'MSFT') > 0
AND sumIf(transactions, ticker = 'KO') > 0
ORDER BY month_startIn Jan 2019 an average Microsoft execution carried 137.4 shares. By Jun 2026 the average was 39.5 shares, alongside 47.7 for Coca Cola over the same month. Institutional orders have not shrunk. The prints have. One parent order now reaches the tape as hundreds or thousands of small executions, whether it hides, schedules, or does both.
Zoom into a single session and the same texture appears. The next panel groups every AAPL print on June 17, 2026 by size.
The exact SQL behind every number
WITH tape AS
(
SELECT size
FROM global_markets.stocks_trades
WHERE ticker = 'AAPL'
AND sip_timestamp >= toDateTime('2026-06-17 04:00:00', 'UTC')
AND sip_timestamp < toDateTime('2026-06-18 04:00:00', 'UTC')
)
SELECT
multiIf(size < 100, 'under 100',
size < 200, '100 to 199',
size < 500, '200 to 499',
size < 1000, '500 to 999',
size < 5000, '1000 to 4999',
'5000 and up') AS print_size_bucket,
count() AS prints,
round(100 * count() / sum(count()) OVER (), 2) AS pct_of_prints,
round(100 * sum(size) / sum(sum(size)) OVER (), 2) AS pct_of_shares
FROM tape
GROUP BY print_size_bucket
ORDER BY min(size)Prints of fewer than 100 shares made up 88.99% of executions that day while carrying 22.84% of the shares. At the other end, the 5000 and up bucket accounted for 0.02% of prints and 48.77% of the volume. A 500 share print is unremarkable in this distribution, which is the first reason iceberg detection is hard.
How do you spot an iceberg order on the tape?
The consolidated tape carries price, size, time, and venue for every execution. It carries no order IDs, no display quantities, and no reserves. What it can show is a footprint: one size printing over and over at one price, across a stretch of time that a single displayed order of that size would rarely survive. The panel below pairs each price with each print size for the same session and counts the repeats.
The exact SQL behind every number
SELECT
concat(toString(size), ' shares at $', toString(round(toFloat64(price), 2))) AS level_and_size,
count() AS prints,
formatDateTime(toTimeZone(min(sip_timestamp), 'America/New_York'), '%H:%i') AS first_et,
formatDateTime(toTimeZone(max(sip_timestamp), 'America/New_York'), '%H:%i') AS last_et,
round(dateDiff('minute', min(sip_timestamp), max(sip_timestamp)) / 60.0, 1) AS hours_spanned
FROM global_markets.stocks_trades
WHERE ticker = 'AAPL'
AND sip_timestamp >= toDateTime('2026-06-17 04:00:00', 'UTC')
AND sip_timestamp < toDateTime('2026-06-18 04:00:00', 'UTC')
AND size >= 200
GROUP BY price, size
ORDER BY prints DESC
LIMIT 12The most repeated pairing was 300 shares at $300.54, printing 67 times between 09:34 and 09:58 ET, a span of 0.4 hours. Follow that pairing through the session in half hour buckets to see whether the repeats spread across the day or bunch into one stretch.
The exact SQL behind every number
WITH top_level AS
(
SELECT
price,
size
FROM global_markets.stocks_trades
WHERE ticker = 'AAPL'
AND sip_timestamp >= toDateTime('2026-06-17 04:00:00', 'UTC')
AND sip_timestamp < toDateTime('2026-06-18 04:00:00', 'UTC')
AND size >= 200
GROUP BY price, size
ORDER BY count() DESC, size DESC, price DESC
LIMIT 1
)
SELECT
formatDateTime(toStartOfInterval(toTimeZone(sip_timestamp, 'America/New_York'), INTERVAL 30 MINUTE), '%H:%i') AS et_time,
count() AS prints,
sum(count()) OVER (ORDER BY et_time) AS cum_prints
FROM global_markets.stocks_trades
WHERE ticker = 'AAPL'
AND sip_timestamp >= toDateTime('2026-06-17 04:00:00', 'UTC')
AND sip_timestamp < toDateTime('2026-06-18 04:00:00', 'UTC')
AND (price, size) IN (SELECT price, size FROM top_level)
GROUP BY et_time
ORDER BY et_timeThey bunch. The trace comes back as a single half hour bucket, the one beginning 09:30 ET, which carried 67 prints and ends the session's running count at 67. Thirty minutes of repetition at one price is a burst, not a day long vigil, and a footprint that short is thinner evidence than the pattern first suggests. A displayed order of that size, at that price, in a name that active, would ordinarily be consumed in seconds. Something kept putting it back.
Why iceberg detection is unreliable
Something kept putting it back is the honest limit of what the tape supports. The same footprint has ordinary explanations that involve no reserve order at all:
- An execution algorithm slicing a parent order into equal child orders and sending them one at a time from a broker's own server.
- Unrelated participants defaulting to the same round quantity at the same round price, which round numbers invite.
- A market maker requoting the same size repeatedly at a level it is content to hold.
- Print counts and order counts diverging, since one resting order can be filled by a sweep that reports as several prints.
There is also a silent case. An iceberg that never trades leaves no footprint whatsoever, and the tape records executions only. Any measure of hidden liquidity built from prints is measuring the part that traded, never the part that waited. Read the pattern as a hypothesis worth checking against the venue mix and the quote, never as a fact about a specific order.
FAQ
What is an iceberg order in trading?
A limit order with two quantities: a small displayed size that appears in the public quote, and a larger hidden reserve the exchange releases automatically each time the displayed slice fills. It sits at one price on one venue as a single order.
Do iceberg orders lose their place in the queue?
The displayed slice does. Each replenishment posts as a new displayed order with a new timestamp, behind everything already resting at that price. Under Nasdaq's rule the non-displayed reserve keeps its original timestamp.
Can you see iceberg orders on Level 2?
No. A depth of book display shows the displayed slice only, which looks like an ordinary small limit order. The reserve stays invisible until it trades and never appears as its own line.
Is an iceberg order the same as a dark pool order?
No. An iceberg rests on a lit exchange and publishes part of itself in the public quote. A dark pool order rests on a venue with no public quote, and the trade appears in public data only when it prints.
Are iceberg orders legal?
Yes. Reserve orders are documented order attributes in exchange rulebooks filed with the SEC and available to member firms and their customers. Hiding part of an order's size is a disclosed feature of the order type.
Every panel here ships with the SQL that produced it, so you can see how each number was counted. To run the repeated print scan on a ticker and date of your own choosing, ask for it in plain English on the Strasmore terminal.