Iceberg order detection: replenishment signals and data limits
An iceberg order displays only part of its total quantity and refreshes displayed size as executions occur. Detection looks for replenishment at a price level. Whether that refresh can be linked to one order depends on the exchange feed and on whether the iceberg is native to the exchange or managed synthetically outside it.
- Native clue
- Stable exchange OrderID across refreshes
- Synthetic clue
- Repeated new orders may be the only trace
- Main limit
- Replenishment is not unique to one iceberg
Key Takeaways
- Iceberg orders separate displayed quantity from hidden remaining quantity.
- CME MBO documents stable OrderIDs for native iceberg refreshes.
- Synthetic icebergs may refresh with new OrderIDs and are harder to link.
- Market by Price aggregates orders and cannot prove individual identity.
Native and synthetic icebergs
A native iceberg is held by the exchange and publishes only the display quantity. An off-exchange system can simulate the behavior by submitting new child orders. The two forms can produce similar visible depth but different order-event records.
| Type | Possible clue | What remains unknown |
|---|---|---|
| Exchange-native | Same OrderID refreshes after displayed quantity trades | Owner identity and full hidden balance |
| Synthetic | New orders repeatedly appear at the same price | Whether events share one parent order |
| Market by Price only | Aggregate size replenishes at a level | Individual order linkage and queue position |
A candidate-event rule
A transparent detector can look for executions that reduce displayed size followed by a refresh at the same price within a stated time window. With MBO, it may also test OrderID continuity. The result should be labeled a native candidate, synthetic candidate, or unexplained replenishment.
Candidate logic
if executedAtLevel and sizeRefreshesWithinWindow:
if sameOrderId: nativeIcebergCandidate
else: replenishmentCandidateFalse positives and missed cases
Independent traders can submit the same lot size at the same price. Market makers can replace quotes. Order modifications, batching, feed loss, and timestamp resolution can alter the sequence. A hidden order may also execute without repeated visible refreshes. Detection rates cannot be claimed without labeled venue-specific data.
Platform and Pineify boundary
A NinjaScript study can process the order events made available by the user's NinjaTrader connection. Pineify can generate the study code but does not supply CME MBO, exchange entitlements, a labeled dataset, or a universal detector. The code must fail closed when the required event fields are absent.
Generate a feed-aware NinjaScript study
List the available order-event fields, native and synthetic classifications, refresh window, minimum executions, and missing-data behavior. Pineify can generate editable NinjaScript, while NinjaTrader and the data provider remain responsible for the event feed.
Sources and verification
This page is educational and does not provide investment advice. The methods described are diagnostics or estimates, not trading signals. Results depend on data quality, sampling, market structure, and model assumptions.