Skip to main content

Iceberg Orders

This reference covers iceberg order mechanics, detection algorithms, and the broader concept of absorption. Every concept is structured as a discrete unit with explicit mechanics, detection logic, and trading implications.

Prerequisite: Market Mechanics (concepts like MBO, MBP, FIFO matching, order queues are assumed known).

1. What Is an Iceberg Order?​

An iceberg order is a limit order with a visibility constraint. The exchange only shows a fraction of the total size to other participants via market data.

Parameters​

ParameterSame as Limit Order?Description
Side (Buy/Sell)YesDirection
Limit PriceYesWorst acceptable execution price
Time in ForceYesHow long the order remains valid
Total SizeYesThe full quantity the trader wants to execute
Maximum Displayed SizeNo — unique to icebergsThe "tip" — the most the exchange will show at any time

The Math​

Hidden Size = Total Size − Maximum Displayed Size

Example:
  Total Size = 500 contracts
  Max Displayed Size = 25 contracts
  Hidden Size = 475 contracts (invisible to all market participants)

Key insight: When you see "iceberg" in any context, the core concept is always the same: only a small slice is visible, the rest is managed by the exchange internally. The displayed size is typically much smaller than the total — otherwise there's no point using the iceberg feature.

2. Who Uses Icebergs and Why​

The Users​

Institutional traders and large individual traders who need to execute quantities that are significant relative to available liquidity.

The Problem They Solve​

Orders reveal intentions. The logic chain is:

  1. Large traders are assumed to be more informed than average (they wouldn't have accumulated that capital otherwise).
  2. If other participants see a large order in the book, they infer the large trader's directional view.
  3. Other participants front-run — they trade ahead of the large order to profit from the anticipated price impact.
  4. This front-running makes the large trader's remaining fills significantly worse.

The Solution​

By only showing 25 of 500 contracts, the iceberg trader:

  • Appears to be a small participant (no alarm bells for other traders).
  • Gets early fills at favorable prices before the market moves against them.
  • Continuously refills the visible portion as it gets executed, maintaining a persistent but small-looking presence.

Key insight: Iceberg detection is valuable because it reveals informed institutional intent that the trader is actively trying to hide. Detecting an iceberg is like finding a large player's footprint — the direction they're positioned in likely has informational value.

3. How Iceberg Matching Works (FIFO Context)​

This is the mechanical process inside the matching engine. Understanding it is critical for detection logic.

Step-by-Step Lifecycle​

Setup: Iceberg Sell order at 2777.00, Total Size = 150, Max Displayed Size = 20.

STEP 1: Order enters the exchange
  ┌────────────────────┬──────────────────────────────┐
  │ Hidden: 130        │ Queue at 2777.00:            │
  │ (invisible)        │ [Other25] [Other10] [ICE:20] │
  │                    │ ← Displayed part joins END   │
  └────────────────────┴──────────────────────────────┘
  Market data shows: Total size at 2777.00 = 55 (25+10+20)
  The iceberg's displayed 20 is indistinguishable from a regular order.

STEP 2: Displayed part advances in queue (as other orders fill/cancel)
  Queue at 2777.00: [Other10] [ICE:20] [NewOrder5]
  The displayed part advances like any normal order.

STEP 3: Displayed part reaches front and gets fully executed
  An aggressive Buy 100 arrives and starts sweeping the ask.
  The 20-unit displayed part fills completely.

STEP 4: Exchange internally refills from hidden reserve
  Hidden: 130 → 110 (gave 20 to refill the display)
  A NEW 20-unit order appears at the END of the queue at 2777.00.
  
  Market data shows: A "new" sell order of size 20 at 2777.00.
  
STEP 5: Cycle repeats
  The new 20-unit displayed portion advances, fills, refills...
  Until Hidden Size is exhausted.

STEP 6: Final partial
  When Hidden < Max Displayed, the last refill is smaller.
  Example: Hidden = 10 remaining → refill shows 10 instead of 20.
  This final smaller refill can be a detection signal.

Critical Queue Mechanic​

Each refill goes to the END of the queue — just like a brand new order. The iceberg does NOT get priority. It must wait its turn again after every refill cycle.

This is why icebergs are slower to execute than a single large visible order (which would have queue priority for its entire size). The tradeoff: slower execution in exchange for concealment.

Key insight: The refill-to-end-of-queue mechanic means that during active sweeps, you'll see a pattern of "order fills → new order instantly appears at same price at same size → fills again → repeat." This repetitive, machine-like refill pattern is the primary detection signal.

4. Pros and Cons of Iceberg Orders​

Pros (From the Iceberg User's Perspective)​

  • Hides total size: Other participants cannot see the full order.
  • Placement/cancellation invisible: No one can detect when the iceberg was originally placed or when it was cancelled (without MBO data).
  • Only displayed size is detectable, and only after it gets executed (not before).

Cons (Vulnerabilities)​

  • Detection upon first execution: Once the displayed portion fills and refills, the pattern becomes detectable.
  • MBO data exposes more: With MBO, trackers can see the Order ID and track the refill cycle precisely.
  • High-quality data is available to sophisticated participants: The traders most likely to exploit iceberg detection (other institutions, HFT firms) are exactly the ones with access to high-quality MBO feeds.

Key insight: Icebergs are NOT invisible — they are merely delayed visibility. Before first execution: undetectable. After first execution: increasingly transparent to anyone with good data and detection algorithms.

5. Detection — Theoretical Limits​

Before discussing algorithms, the agent must understand what is and isn't possible to detect, regardless of algorithm quality:

What You Want to KnowCan It Be Detected?Conditions
Hidden size (total remaining)No — neverFundamentally unknowable from market data
Presence before first executionNo — neverIceberg is invisible until the displayed part fills
Presence after first executionYes — estimatedRequires tracking refill patterns
Displayed size (max display parameter)Yes — estimatedFrom the consistent refill size
Original placement timePartially — MBO onlyCan be inferred from Order ID once detected
Full exhaustion (iceberg done)Yes — MBO instantly, MBP delayedMBO: order ID disappears. MBP: next execution at price fails to trigger refill
CancellationMBO onlyMust have been detected at least once first

Key insight: Any iceberg tracker is an estimation. The hidden size is fundamentally unknowable. Never present iceberg detection as exact — always frame it as "detected iceberg activity with estimated displayed size of X."

6. Detection Algorithms in Bookmap​

Bookmap offers three detection algorithms, each suited to different data quality levels.

6.1 Underflow Algorithm (Expired/Unreliable)​

How it worked: When a trade executes at a price level and the trade size exceeds the visible book size at that level, the excess is attributed to a potential iceberg.

Example:
  Visible ask at 2777.00 = 55 contracts
  A buy executes for 100 contracts at 2777.00
  Underflow: 100 − 55 = 45 contracts attributed to iceberg

  MBP data would show:
    Execution: Buy 20 @2777.00
    Execution: Buy 10 @2777.00
    Execution: Buy 25 @2777.00
    Execution: Buy 45 @2777.00  ← This exceeds remaining visible (0)
    Set Ask Size = 0 @2777.00
    Set Bid Size = 20 @2777.00

Why it's expired: CME and other exchanges changed the sequence of events in their market data, breaking the assumption that trade sizes would visibly exceed book sizes in a detectable way.

Key insight: If a user mentions "underflow detection" — note that this method is no longer reliable on modern data feeds. Recommend Native or Resistance instead.

6.2 Native Algorithm (Ideal — Requires MBO)​

Data requirement: MBO data with untouched event sequence (no vendor reordering or channel splitting).

Core detection logic: During the atomic processing of a single aggressive order, new limit orders appear from the opposite side interleaved with executions at the same price level. This is impossible in normal matching — the only explanation is an iceberg refilling.

WITHOUT Iceberg (normal matching of Buy 100 @2777.00):
  MBO events:
    Executed Sell 20 @2777.00
    Executed Sell 10 @2777.00
    Executed Sell 25 @2777.00
    → Price level cleared, aggressive order moves to next level
    New Buy Order: 45 @2777.00 (unfilled remainder becomes bid)

WITH Iceberg Sell 20 (displayed) at 2777.00:
  MBO events:
    Executed Sell 20 @2777.00
    New Sell Order: 20 @2777.00  ← IMPOSSIBLE without iceberg!
    Executed Sell 10 @2777.00
    Executed Sell 25 @2777.00
    Executed Sell 20 @2777.00    ← The refilled iceberg portion
    New Sell Order: 20 @2777.00  ← Another refill!
    Executed Sell 20 @2777.00
    New Sell Order: 20 @2777.00  ← And again
    Executed Sell 5 @2777.00     ← Partial fill of last refill

The smoking gun: A "new" sell order appearing at the same price during the atomic processing of an aggressive buy order. In normal operation, no new sell orders would arrive during a buy sweep — the matching engine is processing one aggressive order atomically. The only source of these interleaved new orders is the exchange's internal iceberg refill mechanism.

What it detects:

  • Presence of iceberg: Yes
  • Displayed size parameter: Yes (the consistent size of each "new" order)
  • Order ID tracking: Yes (MBO provides order IDs, so you can track the iceberg across refill cycles)

Key insight: The Native algorithm is the gold standard. It exploits the fundamental constraint that matching is atomic — during one aggressive order's processing, no external orders can arrive. Any "new" orders appearing on the opposite side during this window MUST be internal iceberg refills.

6.3 Resistance Algorithm (Works with MBP)​

Data requirement: MBP data with preserved event sequence (can work without MBO, but sequence must not be scrambled by vendor).

Core principle: Same concept as Native, but without order IDs. Looks for new limit orders appearing "instantly" on the opposite side in response to executions at a price level.

Configurable parameters:

  • Delay (ms): How quickly must the new order appear after execution to count as "instant"? Default: 50ms. Shorter = fewer false positives but may miss icebergs. Longer = catches more but may include HFT-mimicked icebergs.
  • Min size: Minimum size of the refill order to be counted. Default: 1. Higher values reduce false positives from small noise.

Accuracy: Bookmap's testing found that if MBO data is accurately converted to MBP while preserving event sequence, the Resistance algorithm's accuracy is nearly indistinguishable from the Native algorithm.

Key insight: For users on Rithmic MBO data feeds (like the ES via CME), recommend the Native algorithm. For users on MBP-only feeds, the Resistance algorithm is the next best option. The Underflow algorithm should not be recommended.

7. The Iceberg → HFT-Mimicked Iceberg → Absorption Spectrum​

This is a conceptually important generalization. Icebergs exist on a continuum:

Level 1: Exchange-Native Iceberg Order​

  • Managed entirely by the exchange's matching engine.
  • Refill is instantaneous (zero latency — it's internal to the engine).
  • Displayed size is perfectly consistent.
  • Detectable via Native algorithm.

Level 2: HFT-Mimicked Iceberg​

  • A co-located HFT firm sends regular limit orders that behave like an iceberg.
  • After each fill, the HFT sends a new order to replace it.
  • Refill latency: sub-millisecond (RTT of co-located connection).
  • Advantages over real iceberg: Can stop at any time; can vary the displayed size and refill timing to evade detection.
  • Disadvantage: The sub-millisecond gap means multiple market events can occur between fill and refill during activity bursts.

Level 3: Institutional "Manual" Absorption​

  • A human trader or slower algorithm repeatedly adds liquidity at a price level as it gets consumed.
  • Refill latency: seconds to minutes.
  • Not technically an iceberg, but the market impact is identical: price stops moving despite aggressive orders hitting the level.

The Unifying Concept: Absorption​

All three levels produce the same observable phenomenon — Absorption: aggressive orders hitting a price level are being "absorbed" by continuously replenishing liquidity on the opposite side. The price stalls or reverses despite persistent aggressive flow.

Absorption Spectrum:

Exchange Iceberg ←→ HFT Mimicked ←→ Manual Replenishment
     |                    |                    |
 0 latency          <1ms latency         seconds/minutes
 Perfect pattern    Near-perfect          Irregular
 Native detects     Resistance detects    Visual/heuristic only
     |                    |                    |
     └────────── ALL = Absorption ─────────────┘

Key insight: When analyzing absorption signals on Bookmap, the agent should recognize that what Bookmap's absorption indicator detects is the generalized version of this spectrum — not just literal exchange iceberg orders, but any behavior pattern where liquidity is being replenished at a level to absorb aggressive flow. This is why absorption signals are one of the most important confluence factors in order flow analysis.

8. Iceberg Orders vs. Regular Large Limit Orders​

Both can produce similar market effects but differ in visibility:

PropertyIceberg OrderRegular Large Limit Order
Acts as absorptionYesYes
Attracts large traders seeking liquidityYesYes
Number of orders visibleVery few (just the tip)All visible in market depth
Presence is visibleOnly after first executionImmediately upon placement
Total size is visibleNeverYes
Full execution is visibleNot until all orders at that price clearYes, at the moment of execution
Cancellation is visibleNo (MBO-only, and only if previously detected)Yes, immediately
Used for manipulation (spoofing)Probably not (why hide a fake order?)Yes, frequently

Dual Market Impact​

Both icebergs and large visible orders create two possible outcomes:

Outcome A — Absorption succeeds: The large order absorbs all aggressive flow at that price. Aggressive traders exhaust themselves. Price reverses. The iceberg/large order holder wins.

Outcome B — Absorption fails: An even larger opposing force (another institution seeking the liquidity, or a cascade of stops) overwhelms the iceberg/large order. It fills completely, and price blows through the level. The collision between the two forces determines the post-event direction.

Key insight: Detection of an iceberg or large resting order is NOT automatically a trading signal. The critical question is: Will the absorption hold or fail? This requires assessing the comparative size of the absorbing force versus the aggressive flow — which is where CVD, delta analysis, and the broader confluence scoring system become essential.

9. Data Quality Sensitivity​

Why Event Sequence Matters​

A static snapshot of the order book cannot detect icebergs. Detection requires tracking the dynamics — the sequence of events over time. The detection algorithms all depend on the assumption that matching is atomic (one aggressive order is fully processed before the next action).

What Breaks Detection​

Data Quality IssueImpact on Detection
Vendor splits data into async channels (T&S, BBO, depth)Destroys event sequence — detection becomes unreliable or impossible
Vendor aggregates/throttles updatesLoses granularity — refill events may be merged into single updates
Vendor reorders eventsAtomic processing assumption breaks — false positives and negatives increase
MBO converted to MBP with preserved sequenceNearly no accuracy loss (per Bookmap testing)
Raw MBO from exchangeOptimal — full accuracy

Practical Recommendation by Data Source​

Data SourceBest AlgorithmExpected Accuracy
Rithmic MBO (CME)NativeHighest
CQG MBP (preserved sequence)ResistanceVery high
Generic MBP (vendor-processed)Resistance (tuned delay)Moderate
Split-channel data (separate T&S + depth)UnreliableLow — may not be worth using

Key insight: Always assess the user's data quality before recommending an iceberg detection approach. Rithmic MBO users (like the primary user of this system) have access to the highest quality data and should use the Native algorithm exclusively.

10. Key Principles Summary​

  1. Icebergs hide institutional intent. Detection reveals informed large-player positioning that the trader is actively concealing.

  2. Detection is always estimation. The hidden size is fundamentally unknowable. Never claim exact iceberg sizes.

  3. The detection signal is the refill pattern. New orders appearing on the opposite side during atomic processing of an aggressive order = iceberg refill.

  4. Native algorithm > Resistance > Underflow. Use the best algorithm your data quality supports.

  5. Icebergs are a special case of absorption. The generalized concept — liquidity being replenished to absorb aggressive flow — is the truly important trading signal.

  6. Iceberg detection is not a standalone trading signal. It must be combined with flow direction, delta, and broader confluence analysis to determine if absorption will hold or fail.

  7. HFT firms mimic icebergs with regular orders. The Resistance algorithm catches both real icebergs and HFT-mimicked ones, which is arguably more useful than catching only exchange-native icebergs.

  8. Large visible orders can be spoofing; icebergs probably aren't. If you're going to hide an order, it's probably real. This makes iceberg detection a higher-confidence signal of genuine intent than large visible resting orders.

  9. Data quality determines detection quality. Preserved event sequence is the single most important factor. MBO vs MBP matters less than whether the sequence is intact.

  10. Absorption is fractal. The same pattern (liquidity replenishment absorbing aggressive flow) occurs at every timescale — from microsecond iceberg refills to minutes-scale institutional accumulation. This is why it's one of the most robust order flow signals.

11. Glossary​

Extends the Market Mechanics Glossary.

TermDefinition
AbsorptionThe generalized phenomenon where aggressive orders at a price level are neutralized by continuously replenishing passive liquidity. Icebergs are the most granular form.
Displayed sizeThe maximum quantity an iceberg order shows in market data at any time. Also called "the tip."
Front-runningTrading ahead of a detected large order to profit from its anticipated price impact. The primary reason large traders use icebergs.
Hidden sizeTotal size minus displayed size. Fundamentally undetectable from market data.
Native algorithmBookmap's MBO-based iceberg detection that exploits the atomic processing constraint to identify refill events. Gold standard.
RefillWhen an iceberg's displayed portion is fully executed, the exchange internally replenishes it from the hidden reserve. Appears in market data as a "new" order.
Resistance algorithmBookmap's MBP-compatible iceberg detection that looks for rapid opposite-side order placement following executions. Works with lower-quality data.
Underflow algorithmDeprecated detection method based on trade sizes exceeding visible book size. No longer reliable on modern data feeds.

See Also​