# Iceberg orders: detecting the hidden size defending the level - Source: https://orderflowfutures.com/en/blog/how-to-detect-iceberg-orders - Site: OrderFlowFutures (https://orderflowfutures.com) - Author: Tom, Trader & founder of OrderFlowFutures (https://orderflowfutures.com/a-propos#auteur) - Published: 2026-08-24 - Updated: 2026-08-24 - Reuse: free to quote and cite, with attribution to OrderFlowFutures and a link to the source URL. > An iceberg displays one slice of its real size and reloads on every fill: displayed size is an intention, executed volume is a fact. The three proofs that give it away on screen, the difference between native and synthetic, and why order-by-order data is the entry fee. You are watching the NQ DOM at yesterday's support. The bid shows 12 contracts. A burst of market sells eats them. They come back. A second burst, bigger. They come back again, same price, same size. Ten minutes later the footprint shows more than 400 contracts executed at that level, and the book never displayed anything but 12. You have not found a bug in your platform. You have just watched an iceberg at work. **An iceberg order is a large limit order of which only a small slice is visible in the book. Each time the slice is filled, it reloads at the same price, until the total quantity is exhausted. On screen, all you see is a small order that refuses to disappear. Detection rests on three proofs: executed volume at the level far above the displayed size, a systematic reload after every fill, and a price that fails to advance. On level-aggregated data these proofs are invisible: you need order-by-order data (MBO).** --- ## 1. Why hide your size (and why it concerns you) Start with the other side's problem, because everything follows from it. An institution that needs to buy 800 contracts has a problem you do not have: its own size. Display 800 on the bid and the market moves before a single contract is bought. Algos spot the mass, sellers back away, impatient buyers step in front, and the average price degrades as the intention becomes public. In the order book, **information has a price, and size is information.** The iceberg is the exchanges' answer to that problem: show 10, execute 800. The term is official, and so is the tool. It is neither a trick nor a grey area: it is a documented order type, offered by the venues themselves, precisely so that large size can execute without being picked apart. Why it concerns you: because **the levels that hold almost never hold thanks to what is displayed.** The raw DOM does not lie to you, but it lies by omission. If your read stops at visible size, you are judging the strength of a level from the one number serious participants have deliberately made meaningless. Hence the rule that structures this whole site, and this article in particular: **displayed size is a revocable intention, executed volume is a paid fact.** A 500-contract limit can cancel in one click and costs nothing. An iceberg slice consumed then reloaded has cost real money at every fill. That is why the iceberg is the most honest presence in the book: it does not want to be seen, but it cannot lie. --- ## 2. Native or synthetic: two species, two signatures Everyone says "iceberg" as if there were only one. There are two, and they are not detected the same way at all. ### The native iceberg: managed by the exchange On CME Globex the order is called *display quantity* (or *max show*): you submit 300 contracts and display 10. **The exchange's matching engine** handles the rest. When the visible slice is consumed, the exchange reloads the next one by **modifying the same order: the order ID is preserved for the iceberg's entire life.** The one concession to fairness: the reloaded slice goes to the back of the queue at its price level, behind everyone. The consequence for detection is enormous: on the order-by-order feed, a native iceberg has a **deterministic signature**. An order that gets filled, modifies, gets filled, modifies, all under the same ID, is not ambiguous. And it leaves a second footprint: a trade can print a volume larger than the resting size at the level, because the aggression cut through the visible slice and bit into the hidden quantity. ### The synthetic iceberg: managed by an algo The second kind does not exist inside the exchange's servers. The **execution software** (the broker's, the prop desk's or the platform vendor's) slices the parent order and submits the tranches one by one. Each tranche is an ordinary limit order with a fresh ID, **indistinguishable one by one from any other order in the book.** Its detection is therefore statistical, never certain: you look for a fresh order appearing at the same price within a very short window after the previous fill. The reference study on the subject uses a 0.3 second window, and observes that most tranches follow the previous one in under a second. It is a body of evidence, not a proof: two independent orders can chain by coincidence, and **every synthetic iceberg detector accepts false positives.** ### The Eurex case, and it is counterintuitive On Eurex derivatives, the FDAX first among them, **the native iceberg order does not exist**: the T7 platform reserves that order type for its cash markets such as Xetra. In other words, on the most "institutional" of the European index futures, all hidden size is synthetic, managed by execution algos. That is not a footnote. It means no detector on the FDAX can lean on the native's deterministic signature: everything goes through a fine read of the order-by-order flow, which Eurex distributes through its EOBI interface. That is exactly the [Eurex feed](/eurex) discussed all over this site, and one of the reasons it costs what it costs. | | Native iceberg | Synthetic iceberg | |---|---|---| | Managed by | The exchange's matching engine | An external execution algo | | Order ID | Preserved through every reload | New for every tranche | | Queue priority | Back of the queue at the level | Back of the queue, like any new order | | Detection on MBO | Deterministic | Statistical, with false positives | | On CME (NQ, ES) | Yes | Yes | | On Eurex derivatives (FDAX) | No, cash markets only | Yes, the only form possible | --- ## 3. How much volume actually hides The best public data on the subject comes from a [Devexperts study](https://arxiv.org/abs/1909.09495) (the company behind dxFeed) run on the complete order-by-order flow of the ES over a week of June 2019. The numbers have aged, the mechanics have not, and to my knowledge nobody has published better since. What it measures: - Native icebergs accounted for **0.06% of orders, but 4% of traded volume.** Rare, and heavy. - Synthetic icebergs added **3.3 to 14.3% of volume** depending on how strict the detection threshold is. - On the sample, the algorithm flagged on the order of **1,600 native icebergs against 60,000 synthetic ones**: most modern hidden size is synthetic. - **87% of native icebergs ran their full quantity to completion**, against less than half of the synthetics, of which more than one in two was cancelled along the way. Add it up: depending on the threshold, **between 7 and 18% of ES volume executed against size the book never displayed.** Roughly one contract in ten. That figure alone justifies this article: if your book reading ignores icebergs, it ignores a participant that outweighs most visible queues. The last number deserves a pause. A native almost always runs to completion: it is a commitment lodged with the exchange, proof of firm intent. A synthetic cancels one time out of two: the algo keeps control and can vanish at the first sign of trouble. **The hierarchy of trust is therefore: an executed reload from a native, then an executed reload from a synthetic, then displayed size, far behind.** --- ## 4. The three proofs, on screen Now the practical part. You do not need to rebuild the study's algorithm: you need three converging proofs, in this order. ### Proof number one: executed volume dwarfs displayed size This is the master proof, and it reads by crossing two tools you already have: the DOM shows 12, the [footprint](/lexique/footprint) shows 400 executed at the same price. A ratio above thirty to one has no innocent explanation. Small independent orders relaying each other at exactly the same price for ten minutes exist in theory; in practice, at that ratio, someone is working size. ![Displayed size treads water while executed volume climbs: the accounting signature of an iceberg at work.](/uploads/blog/ice-01-affiche-vs-execute-en.png) *The displayed slice oscillates between 0 and 12 while cumulative executed volume climbs step by step: that contradiction is what gives the hidden size away.* ### Proof number two: the reload at the same price The second proof is dynamic: after every fill, the size comes back, **at the same price and at a comparable size.** Not one tick away, not five minutes later: right there, right away. Beware of a classic confusion that even good traders maintain: a **visible reload** and an iceberg are not the same proof. A reload, the kind [Deep Reload](/deepcharts/deep-reload) flags, is displayed liquidity that gets pulled then reposted: it shows on the book side, among intentions. An iceberg reveals itself on the execution side, in the fills. Both signal a defended level, both often happen together, but the iceberg is the stronger proof of the two: its slices are not reposted intentions, they are paid contracts. ### Proof number three: price fails to advance The third proof is the result: despite repeated aggression, the level does not give way. That is the very definition of [absorption](/lexique/absorption), and it is the bridge to the [Punch to the Wall](/blog/punch-to-the-wall-order-flow-pattern) pattern: record volume, extreme delta, zero progress. The iceberg is very often the concrete mechanism hiding behind that wall. One proof is a curiosity. Two proofs, a hypothesis. **All three together, an identified participant, with a precise price level and a readable intention.** It is rare, and that is exactly why it is worth something. ![Native versus synthetic: two reload mechanisms, two signatures in the order-by-order flow.](/uploads/blog/ice-02-natif-synthetique-en.png) *The native reloads by modifying the same order at the exchange; the synthetic reposts a fresh order in under a second. The first is proven, the second is inferred.* --- ## 5. The life and death of an iceberg Knowing an iceberg is there is half the read. The other half is knowing where it stands in its life, because the trading signal flips entirely. **While it reloads, the level is defended.** A participant is committing real money there, fill after fill. Price has good odds of being rejected, and if you fade in its direction your invalidation is crystal clear: price trading through the level and the reloading stopping. **The most dangerous moment is not the wall, it is its disappearance.** An iceberg is not a floor: it is a reservoir. When the reloads space out and then stop, two things happen at once: the liquidity that was blocking price disappears, and everyone who was leaning on it, you included, finds themselves on the wrong side. Price then breaks in one move, precisely because nothing holds it back any more and the unwinds feed the move. An exhausted iceberg is not the end of the signal: it is the second signal. **And it can simply walk away.** Remember the number: more than one synthetic in two is cancelled before completion. The algo managing the size can decide the level is no longer worth it and evaporate without a single further slice being consumed. That is the difference between a defense defeated and a defense lifted, and the book rings no bell to warn you. Hence the rule: **you never trade the iceberg, you trade its latest proof.** A reload twenty minutes old is an anecdote, not a level. ![The life of an iceberg in three acts: the reloading defense, the exhaustion, then the break fueled by its disappearance.](/uploads/blog/ice-03-vie-et-mort-en.png) *Three acts: the level holds while reloads keep coming, the reloads stop, and the break accelerates exactly where the defense vanished.* --- ## 6. The regime above: an iceberg does not cancel gamma A word of context, because the best iceberg read in the world can lose against the background flow. In a negative gamma regime, dealer hedging pushes in the direction of the move, and it does not stop because a level is defended: nobody in that flow has an opinion about your level. A perfectly real iceberg can therefore get run over by aggression that refuels itself mechanically, tick after tick. That is the trap described in detail in [GEX: why the SPX drives your ES](/blog/gex-spx-drives-your-es), and the field test there is the same as here: **the question is never "is there an iceberg", it is "is it still reloading".** A defense soaking up pressure in positive gamma and the same defense under a seller hedging flow are not the same trade, even if the picture in the book is identical. --- ## 7. Why aggregated data is not enough Let us be honest about the entry price of this read: it depends on the data your platform receives. The data most platforms display is aggregated by level (*market by price*): you see the total size at each price, and that is all. When it drops from 60 to 48, you cannot tell whether an order was pulled, whether twelve contracts traded, or whether three orders left and two came back. **Every proof in this article is built from events that aggregation destroys.** Order-by-order data (*market by order*) is a different animal: every order in the book carries an anonymous ID, with its position in the queue. The [CME has distributed it for all of its futures since 2017](https://www.cmegroup.com/articles/faqs/market-by-order-mbo.html); on the Eurex side the equivalent is called [EOBI](https://www.mds.deutsche-boerse.com/mds-en/real-time-data/derivatives-markets/Eurex-Order-by-Order-Futures-1340236), the un-netted feed the FDAX requires. That granularity is what lets you watch one ID modify itself fill after fill (the native) or fresh orders chain at the same price in under a second (the synthetic). The practical conclusion fits in one sentence: **iceberg detection is a data problem before it is an indicator problem.** An "iceberg detector" plugged into aggregated data detects nothing: it guesses. --- ## 8. Concretely, what to watch this with Rebuilding all of this by hand is a fine afternoon project for learning, not a six hour a day trading workflow. In practice you need a platform that receives the order-by-order feed and extracts the three proofs for you. That is [DeepCharts](/deepcharts)' home turf, working on MBO data for CME as well as Eurex. The full chain of this article reads through four building blocks: - **[Iceberg Detector](/deepcharts/iceberg-detector)**: the proof through executions. It spots the reload pattern, a slice consumed then reposted at the same price, and shows you the defense while it happens, then its end. - **[Deep Reload](/deepcharts/deep-reload)**: the proof on the book side. It marks the zones where significant liquidity returns after a pull, with adjustable thresholds for volume and pull size. - **[Deep Wall](/deepcharts/deep-wall)**: the extreme case on the ES. It only flags passive walls that cleanly reject aggression, a few times a week or month, and that repeated refusal very often gives away an iceberg. - **The [liquidity heatmap](/deepcharts/heatmap-liquidite)**: the context. Built on order-by-order data, it tracks each order individually, which is exactly what lets it tell a genuine wall from a reloading iceberg. And for training, Deep Replay lets you replay entire sessions: you can spend an evening hunting nothing but icebergs on yesterday's levels, check which ones held, and calibrate your eye on dozens of real cases before risking a euro on it. **[Activate DeepCharts with code OFF →](/go/deepcharts)**: the discount applies to the platform licence. --- ## What to remember The book displays intentions, the iceberg executes facts. A participant reloading slice after slice at the same price hands you the most expensive information in the market: where real size has decided to fight, and until when. Demand the three proofs: executed volume out of all proportion with displayed size, the immediate reload at the same price, the price that fails to advance. Separate the native, a deterministic commitment lodged with the exchange, from the synthetic, a statistical inference that can cancel at any moment. And remember the signal has two faces: defense while it reloads, breakout when it stops. The rest is a data question. Without the order-by-order feed, everything this article describes is invisible, and a "defended" level remains an act of faith. --- ## Frequently asked questions **What is an iceberg order?** It is a large limit order of which only a fraction, the visible slice, is displayed in the book. Each time the slice is filled, a new one reloads at the same price, until the total quantity is exhausted. The goal is to execute large size without revealing the intention to the market. On screen, an iceberg looks like a small order that refuses to disappear. **How do you detect an iceberg order?** Through three converging proofs: executed volume at a price level far above the size that was displayed there, a systematic reload of the size at the same price after every fill, and a price that fails to progress despite the aggression. These proofs are only readable on order-by-order (MBO) data: level-aggregated data destroys the events they are made of. **What is the difference between a native and a synthetic iceberg?** A native iceberg is managed by the exchange: on CME Globex the reload modifies the same order, whose ID is preserved, and the fresh slice goes to the back of the queue. Its detection is deterministic. A synthetic iceberg is managed by external execution software: each tranche is an ordinary order with a fresh ID, and its detection is statistical, typically an order reposted at the same price within a second of the previous fill. **Are iceberg orders legal?** Yes. The iceberg is an official order type, documented and offered by the exchanges themselves, precisely to let large size execute without being picked apart. It must not be confused with spoofing, which is illegal: a spoofer displays orders they have no intention of executing, an iceberg hides orders it firmly intends to execute. One lies about its intention, the other only about its size. **Is an iceberg a buy or a sell signal?** Neither by itself: it is an absorption signal, proof that a participant is defending a level with more size than displayed. Direction comes from how price reacts and from the iceberg's state: while it reloads, the level is defended and rejection is the dominant scenario; once the reloads stop, the blocking liquidity is gone and the break becomes the signal. **What share of volume comes from iceberg orders?** The best public study, run by Devexperts on the complete order-by-order flow of the ES in June 2019, measures 4% of volume for native icebergs (only 0.06% of orders) and 3.3 to 14.3% for synthetics depending on the detection threshold, a total on the order of 7 to 18% of traded volume. The figures are dated, but the order of magnitude remains the only published reference. **Why is MBO data required to see icebergs?** Because every iceberg signature is an event at the level of the individual order: an ID preserved through modifications for the native, a chain of fresh orders at the same price for the synthetic, a trade volume larger than the resting size. Level-aggregated data only exposes totals: it shows that size changed, never why. The CME distributes MBO for all its futures since 2017, Eurex through its EOBI feed.