While market participants cannot directly trace the relationships between iceberg components, the exchange maintains complete visibility through internal systems:
PARENT_ORDERS Table
-------------------
ParentOrderID : Primary key, internal reference (not exposed to market)
TotalQuantity : Complete size of the order
DisplayQuantity : Size of visible portion
RemainingQuantity : Unfilled quantity
Price : Order price
Symbol : Order instrument
ParticipantID : Owner of the order
OrderType : "Iceberg"
TimeInForce : GTC, GTD, Day, etc.
EntryTime : When order was submitted
Status : Active, Filled, Canceled
CHILD_ORDERS Table
-----------------
ChildOrderID : ID visible to market (e.g., 100000000005)
ParentOrderID : Foreign key to PARENT_ORDERS
DisplayQuantity : Visible quantity
IsVisible : Boolean - is this the displayed portion
ExecutedQuantity : Amount filled so far
SequenceNumber : Order of child creation
Status : Active, Filled, Canceled
EXECUTIONS Table
--------------
ExecutionID : Unique identifier (exposed in market data)
ChildOrderID : Order that executed
ContraOrderID : Matching order
ParentOrderID : Link to parent order (internal only)
Quantity : Size of execution
Price : Execution price
Timestamp : When execution occurred
IsVisible : Was this against visible portion
The exchange performs these transformations when publishing market data:
-
For visible portion executions:
- Internal message contains both ChildOrderID and ParentOrderID
- PITCH message only includes ChildOrderID
-
For hidden portion executions:
- Internal message links to original ParentOrderID
- PITCH message uses a different obfuscated OrderID
- Relationship to original order is intentionally broken
-
For replenishments:
- Internal systems generate a new ChildOrderID
- PITCH shows this as completely new Add Order
- No reference to original order is included
This transformation layer maintains complete order history within the exchange while providing only the legally required transparency to the market.# Understanding Iceberg Orders in CBOE Market Data
| Field Name | Length | Type | Description | Iceberg Relevance |
|---|---|---|---|---|
| Length | 1 | Binary | Total message length | Standard header |
| Message Type | 1 | 0x37 | Identifies message as Add Order | Indicates new visible order |
| Timestamp | 8 | Binary UTC | Nanoseconds since epoch | Event timing |
| Order Id | 8 | Binary | Day-specific identifier | Key identifier for tracking order |
| Side Indicator | 1 | Alpha | B = Buy, S = Sell | Order direction |
| Quantity | 4 | Binary | Visible size of order | For icebergs: Only shows display quantity, not total |
| Symbol | 6 | ASCII | Security identifier | Order instrument |
| Price | 8 | Binary | Limit price | Order price level |
| PID | 4 | Alpha | Participant ID | Order owner identifier |
| Reserved | 1 | Binary | Reserved field | N/A |
| Field Name | Length | Type | Description | Iceberg Relevance |
|---|---|---|---|---|
| Length | 1 | Binary | Total message length | Standard header |
| Message Type | 1 | 0x38 | Identifies message as Order Executed | Indicates visible execution |
| Timestamp | 8 | Binary UTC | Nanoseconds since epoch | Event timing |
| Order Id | 8 | Binary | Order being executed | References original visible order |
| Executed Quantity | 4 | Binary | Number of shares executed | Size of this execution |
| Execution Id | 8 | Binary | Unique execution identifier | Links related execution messages |
| Contra Order Id | 8 | Binary | Matching order identifier | Other side of the trade |
| Contra PID | 4 | Alpha | Counter-party ID | Other participant in trade |
| Reserved | 1 | Binary | Reserved field | N/A |
| Field Name | Length | Type | Description | Iceberg Relevance |
|---|---|---|---|---|
| Length | 1 | Binary | Total message length | Standard header |
| Message Type | 1 | 0x3D | Identifies message as Trade | For icebergs: Used for hidden executions |
| Timestamp | 8 | Binary UTC | Nanoseconds since epoch | Event timing |
| Symbol | 6 | ASCII | Security identifier | Order instrument |
| Quantity | 4 | Binary | Number of shares executed | Size of hidden execution |
| Price | 8 | Binary | Execution price | Trade price |
| Execution Id | 8 | Binary | Unique execution identifier | Links related execution messages |
| Order Id | 8 | Binary | Order identifier | For icebergs: Obfuscated ID for hidden portion |
| Contra Order Id | 8 | Binary | Matching order identifier | Other side of the trade |
| PID | 4 | Alpha | Participant ID | Order owner identifier |
| Contra PID | 4 | Alpha | Counter-party ID | Other participant in trade |
| Trade Type | 1 | Alpha | Trade classification | Matching type, N = normal |
| Trade Designation | 1 | Alpha | Order type | Order classification (C=Limit, P=Mid-Point, etc.) |
| Trade Report Type | 1 | Alpha | Report classification | Only for off-exchange trades |
| Trade Transaction Time | 8 | Binary UTC | Original trade time | Only for off-exchange trades |
| Flags | 1 | Bit Field | Additional trade flags | Reserved for specific trade conditions |
| Field Name | Length | Type | Description | Iceberg Relevance |
|---|---|---|---|---|
| Length | 1 | Binary | Total message length | Standard header |
| Message Type | 1 | 0x3C | Identifies message as Delete Order | Visible portion removal |
| Timestamp | 8 | Binary UTC | Nanoseconds since epoch | Event timing |
| Order Id | 8 | Binary | Order being removed | References visible order |
| Field Name | Length | Type | Description | Iceberg Relevance |
|---|---|---|---|---|
| Length | 1 | Binary | Total message length | Standard header |
| Message Type | 1 | 0x3A | Identifies message as Modify Order | Order amendment |
| Timestamp | 8 | Binary UTC | Nanoseconds since epoch | Event timing |
| Order Id | 8 | Binary | Order being modified | References original order |
| Quantity | 4 | Binary | New visible quantity | Updated display size |
| Price | 8 | Binary | New price | Updated price level |
| Reserved | 1 | Binary | Reserved field | N/A |
An iceberg order is a type of order that displays only a portion of its total quantity to the market, with the remainder hidden from view. Like an actual iceberg where only the tip is visible above water, these orders show just a small portion of their total size.
- Display Quantity: The visible portion shown on the order book
- Total Quantity: The complete size of the order (visible + hidden)
- Price: The limit price for the entire order
- Replenishment: When the visible portion is executed, it automatically refills from the hidden reserve
When an iceberg order is submitted to the exchange:
- An Add Order message appears in the market data feed
- This message shows only the display quantity, not the full order size
- The hidden portion is not mentioned in any market data message
Example:
Add Order
- OrderID: 100000000005
- Side: Buy
- Price: $10.00
- Symbol: ZVZT
- Quantity: 50 (only the display quantity!)
- PID: "1234"
The hidden portion (additional 50 shares in our example) is completely invisible to market participants.
When someone trades against the visible portion of an iceberg order:
- An Order Executed message is sent
- The message references the original Order ID
- The remaining visible quantity is reduced
Example:
Order Executed
- OrderID: 100000000005
- Executed Quantity: 20
- Execution ID: 01000000C
- Contra Order ID: 100000000006
- Contra PID: "5678"
When the visible portion is completely filled:
- A final Order Executed message shows the last visible shares being taken
- At this point, participants would normally remove the order from their books
- But the hidden portion still exists!
Example:
Order Executed
- OrderID: 100000000005
- Executed Quantity: 30 (remaining visible quantity)
- Execution ID: 01000000D
- Contra Order ID: 100000000007
- Contra PID: "9123"
Hidden Portion Execution
When trading continues against the hidden portion:
- A Trade message is sent (not an Order Executed message)
- This message uses a different, obfuscated Order ID
- No connection to the original Order ID is provided in the message
Example:
Trade
- OrderID: 100000000008 (different from original!)
- Quantity: 50
- Price: $10.00
- Execution ID: 01000000E
- Contra Order ID: 100000000007
- PID: "1234"
- Contra PID: "9123"
- Trade Type: N (Normal)
When the visible portion is executed but hidden quantity remains, the iceberg replenishes:
- A new Add Order message appears
- This message has a new Order ID different from the original
- The price, symbol, and participant ID remain the same
- The quantity will be either the original display size or the remaining quantity (whichever is smaller)
Example:
Add Order
- OrderID: 10000000000B (new ID!)
- Side: Buy
- Price: $10.00
- Symbol: ZVZT
- Quantity: 25 (remaining quantity)
- PID: "1234"
The CBOE PITCH protocol intentionally obscures the relationship between:
- The original iceberg order
- The hidden portion executions
- The replenished visible portions
This design protects the anonymity of large orders and prevents other participants from easily detecting and exploiting this information.
Market participants can use these clues to potentially identify iceberg orders:
- Timing Pattern: Observe when visible orders are exhausted and immediately followed by Trade messages or new Add Orders
- Identical Attributes: Look for matching price, symbol, and participant ID
- Size Patterns: Watch for consistent display sizes and decreasing total sizes
- Execution Sequence: Notice the pattern of visible execution followed by hidden execution
To detect iceberg order relationships, monitor these message sequences:
-
Initial Phase:
ADD ORDER (Type 0x37) → OrderID: 100000000005 → Visible Quantity: 50 -
Visible Execution Phase:
ORDER EXECUTED (Type 0x38) → OrderID: 100000000005 → Executed Quantity: 20 → Execution ID: 01000000C → Contra Order ID: 100000000006 ORDER EXECUTED (Type 0x38) → OrderID: 100000000005 → Executed Quantity: 30 → Execution ID: 01000000D → Contra Order ID: 100000000007 -
Hidden Execution Phase:
TRADE (Type 0x3D) → OrderID: 100000000008 (obfuscated) → Quantity: 50 → Execution ID: 01000000E → Same symbol/price/PID as original -
Replenishment Phase (if applicable):
ADD ORDER (Type 0x37) → OrderID: 10000000000B (new ID) → Quantity: 25 → Same symbol/price/PID as original
The key insight is recognizing that the Trade message (0x3D) with an obfuscated OrderID appearing immediately after the visible portion is exhausted indicates execution against the hidden portion of the same iceberg order.
ICEBERG ORDER LIFECYCLE
-----------------------
SUBMISSION
│
▼
┌───────────────────────┐
│ ADD ORDER MESSAGE │
│ OrderID: 10000000005 │
│ Quantity: 50 (Visible)│
│ [Hidden: 50] │
└───────────────────────┘
│
▼
┌───────────────────────┐
│ ORDER BOOK STATE │
│ Buy ZVZT @ $10.00 │
│ ┌────────┬─────────┐ │
│ │VISIBLE │ HIDDEN │ │
│ │ 50 │ 50 │ │
│ └────────┴─────────┘ │
└───────────────────────┘
│
▼
PARTIAL EXECUTION (20 shares)
│
▼
┌───────────────────────┐
│ ORDER EXECUTED │
│ OrderID: 10000000005 │
│ Quantity: 20 │
└───────────────────────┘
│
▼
┌───────────────────────┐
│ REMAINING ON BOOK │
│ ┌────────┬─────────┐ │
│ │VISIBLE │ HIDDEN │ │
│ │ 30 │ 50 │ │
│ └────────┴─────────┘ │
└───────────────────────┘
│
▼
VISIBLE PORTION EXHAUSTED
│
▼
┌───────────────────────┐
│ ORDER EXECUTED │
│ OrderID: 10000000005 │
│ Quantity: 30 │
└───────────────────────┘
│
▼
┌───────────────────────┐
│ NO VISIBLE QUANTITY │
│ ┌────────┬─────────┐ │
│ │VISIBLE │ HIDDEN │ │
│ │ 0 │ 50 │ │
│ └────────┴─────────┘ │
└───────────────────────┘
│
▼
HIDDEN PORTION EXECUTION
│
▼
┌───────────────────────┐
│ TRADE MESSAGE │
│ OrderID: 10000000008 │
│ (Different ID!) │
│ Quantity: 50 │
└───────────────────────┘
│
▼
┌───────────────────────┐
│ ORDER COMPLETELY FILLED│
└───────────────────────┘
ICEBERG REPLENISHMENT
---------------------
ORIGINAL ORDER (Total: 75 shares)
│
▼
┌───────────────────────┐
│ ADD ORDER MESSAGE │
│ OrderID: 10000000009 │
│ Quantity: 50 (Visible)│
│ [Hidden: 25] │
└───────────────────────┘
│
▼
VISIBLE PORTION EXHAUSTED
│
▼
┌───────────────────────┐
│ ORDER EXECUTED │
│ OrderID: 10000000009 │
│ Quantity: 50 │
└───────────────────────┘
│
▼
REPLENISHMENT
│
▼
┌───────────────────────┐
│ ADD ORDER (NEW!) │
│ OrderID: 1000000000B │
│ Quantity: 25 │
│ Same price/symbol/PID │
└───────────────────────┘
- No Direct Link: The CBOE PITCH protocol provides no direct field linking the original order ID to the replenished order ID or hidden executions
- Intentional Design: This missing connection is by design to protect large orders from detection
- Exchange Systems: While market participants can't see these connections, the exchange's internal systems maintain full parent-child relationships
- Market Impact: Iceberg orders help large traders minimize market impact while still providing some transparency to the market
Iceberg orders are a powerful tool for executing large orders while minimizing market impact. The CBOE PITCH protocol deliberately makes these orders difficult to track from the market data feed alone, requiring market participants to use pattern recognition and inference to identify potential iceberg behavior.
Understanding how these orders are represented in market data is crucial for developing effective trading strategies and accurately interpreting market activity.