By Iceberg Order Explained: Hidden Liquidity
Iceberg order na limit order with displayed size and hidden reserve. See how each refresh loses queue priority and wetin the pattern looks like on tape.
An iceberg order na one limit order wey dey wait for execution inside exchange book, with two quantities attached: displayed size wey the whole market fit see for quote, plus hidden reserve wey dey behind am. Matching engine dey release the reserve automatically as the displayed slice dey fill. The name describe the shape: small tip above water, while most of the mass dey below. Hiding get cost, and na queue position you dey pay with: every refreshed slice dey post with new timestamp, behind everything wey don already dey wait for that price.
Wetin be iceberg order?
Suppose fund wan buy 50,000 shares and e ready pay up to $50.00. If e enter am as ordinary limit order, the book go show 50,000 shares of demand for that price for everybody to see. If e enter am as iceberg with display size of 500, the book go show 500. When those 500 trade, matching engine go take another 500 from the reserve, post am, and repeat until reserve finish or dem cancel the order.
Two things remain true throughout. Na one order for one price on one venue, and exchange don hold the full quantity since the moment dem enter am.
The description wey you go hear most often—trader dey cut large order into pieces and feed dem in over hours or days—na different technique. That one na execution schedule, run by algorithm wey dey send many separate child orders across several venues and measure dem against benchmark like VWAP. Iceberg na venue order attribute. The slicing dey happen inside matching engine, within microseconds, for one book.
Vocabulary dey vary by venue. The visible part fit be display quantity or tip. The remaining part na reserve or non-displayed portion. Nasdaq rulebook call the attribute Reserve Size.
How small fit the displayed slice be?
Venues dey set minimum for the displayed portion, and dem express am in round lots instead of fixed share count. Nasdaq require reserve order display size to be one or more normal units of trading when person enter am. If lot mix, dem round am down to nearest round lot. Cboe BZX book dey replenish displayed quantity once e don fall below one round lot. Wording dey differ by venue and dem fit amend am, so read rulebook of the venue wey you route to. No just trust number wey person quote second hand.
Round lot no be flat 100 shares again. Under amended Regulation NMS definition, wey dey effective since November 3, 2025, e dey scale with price: 100 shares for $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 dey reassign each stock two times every year, based on average closing price over March or September evaluation period. Nasdaq's vendor alert on the change list the tiers and dates. For stock wey dey trade around four figures, the smallest permitted tip na ten shares.
Iceberg orders dey lose queue priority?
Yes, and na this part most explanations dey skip. US equity books rank resting orders first by price, then by time. If you arrive earlier at the same price, you go trade earlier.
Iceberg displayed slice join queue when e post. Once the slice fill and engine replenish am from reserve, the replenishment enter as new displayed order with fresh timestamp, for back of the line at that price. Nasdaq rule state the difference clearly:
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 one na Nasdaq Equity 4, Rule 4703(h), quoted from the SEC order approving the reserve order rule change of February 18, 2021. The reserve keep its original position, while visible tip reset every time e refresh. A 50,000-share order wey show 500 at a time fit refresh up to a hundred times. Every refresh start again behind all displayed orders wey dey rest for that price. Na that be the real cost of hiding.
Many venues add another cost. Displayed interest rank ahead of non-displayed interest at the same price. So reserve go yield to any displayed order there, even if the reserve arrive first.
Iceberg order vs hidden order vs dark pool
- Iceberg dey rest on lit exchange and e put displayed slice inside public quote, where that slice fit set the national best bid or offer. The reserve behind am no dey appear for quote.
- Fully hidden order no dey display anything. E dey rest on same lit exchange, execute at its limit price, and show for public data only after e trade. Venues generally rank am behind displayed orders at the same price.
- A dark pool na separate venue wey no get public quote at all. The print reach the tape through trade reporting facility after the trade happen.
- A block trade move the whole quantity in one negotiated print. Maximum size, minimum duration—the opposite approach to dripping am out.
All of dem dey move quantity without advertising am ahead of time. The difference na where the order dey rest and how much of am public quote ever carry. Hidden interest fit sit for prices wey quote never show, so visible book always be only part of available liquidity. Keep that in mind alongside locked and crossed markets.
How much of the tape prints dey come in small size?
Before you fit read iceberg footprint, you need understand the normal texture of the tape. The panel below divide each month's share volume by that month's trade count for two well-known companies wey no get stock splits during the period.
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_startFor Jan 2019, average Microsoft execution carry 137.4 shares. By Jun 2026, average don reach 39.5 shares, while Coca Cola record 47.7 for the same month. Institutional orders no shrink. Na the prints shrink. One parent order now reach the tape as hundreds or thousands of small executions, whether e hide, follow schedule, or do both.
If you zoom into one session, you go see the same texture. The next panel group 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 below 100 shares make up 88.99% of executions that day, while dem carry 22.84% of the shares. For the other end, 5000 and up bucket account for 0.02% of prints and 48.77% of volume. A 500-share print no strange for this distribution. Na the first reason iceberg detection hard.
How you fit spot iceberg order for the tape?
Consolidated tape carry price, size, time and venue for every execution. E no carry order IDs, display quantities or reserves. Wetin e fit show na footprint: one size dey print again and again for one price, across period wey one displayed order of that size rarely fit survive. The panel below pair each price with each print size for the same session and count 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 pairing wey repeat pass na 300 shares at $300.54. E print 67 times between 09:34 and 09:58 ET, across 0.4 hours. Follow that pairing through the session in half-hour buckets to see whether the repeats spread across the day or gather inside one period.
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_timeDem gather. The trace return as one half-hour bucket, the one wey start at 09:30 ET. That bucket carry 67 prints and bring the session running count to 67. Thirty minutes of repetition at one price na burst, no be all-day activity. Footprint wey short like that provide weaker evidence than the first pattern suggest. Displayed order of that size, for that price, in stock wey dey active like that, normally go finish within seconds. Something continue to put am back.
Why iceberg detection no reliable
“Something continue to put am back” na the honest limit of wetin tape support. Same footprint get ordinary explanations wey no involve reserve order:
- Execution algorithm dey slice parent order into equal child orders and send dem one after another from broker's own server.
- Unconnected participants dey choose the same round quantity at the same round price, because round numbers dey attract that behavior.
- Market maker dey requote the same size repeatedly at level wey e dey willing to hold.
- Print counts and order counts no dey match, because one resting order fit fill through sweep wey report as several prints.
Another quiet case dey. Iceberg wey never trade no leave any footprint, and tape dey record executions only. Any measure of hidden liquidity wey come from prints dey measure only the part wey trade, never the part wey wait. Treat the pattern as hypothesis wey you need check against venue mix and quote, not as fact about one specific order.
FAQ
Wetin be iceberg order for trading?
Na limit order with two quantities: small displayed size wey dey appear for public quote, plus larger hidden reserve wey exchange dey release automatically each time displayed slice fill. E dey sit for one price on one venue as one order.
Iceberg orders dey lose their place for queue?
The displayed slice dey lose am. Every replenishment post as new displayed order with new timestamp, behind everything wey don already rest for that price. Under Nasdaq rule, non-displayed reserve keep its original timestamp.
You fit see iceberg orders for Level 2?
No. Depth of book display show only displayed slice, and e look like ordinary small limit order. Reserve remain invisible until e trade, and e never appear as its own line.
Iceberg order be the same as dark pool order?
No. Iceberg dey rest on lit exchange and publish part of itself for public quote. Dark pool order dey rest on venue wey no get public quote, and trade appear for public data only when e print.
Iceberg orders legal?
Yes. Reserve orders na documented order attributes for exchange rulebooks wey dem file with SEC. Member firms and their customers fit access dem. Hiding part of order size na disclosed feature of the order type.
Every panel for here come with the SQL wey produce am, so you fit see how dem count each number. If you wan run repeated print scan for ticker and date wey you choose, ask for am in plain English on Strasmore terminal.