Iceberg Orders Tracker

From Bookmap
Jump to: navigation, search
Iceberg.jpg

Iceberg orders are a sub-type of Limit orders where only part of the order can be visible to other market participants via market data. Iceberg orders extend regular Limit orders by having an additional property:

  • Side (Buy or Sell)
  • Limit price
  • Time in force (Until when the order is valid)
  • Size (or Quantity)
  • Maximum displayed size (The tip of the iceberg)

This parameter instructs the exchange not to display in the market data more then specified of the order size. Naturally, the maximum displayed size must be less than the total size of the order (typically significantly less to justify the use of Iceberg), and the difference between them is called the Hidden size.

This article provides detailed explanation of Iceberg orders mechanics, the motivation behind using them, detecting them, the methods of detection in general, with Bookmap in particular, and even Icebergs generalization and relation to the market phenomenon called Absorption.

Who uses iceberg orders and why[edit]

Most exchanges offer traders the ability to send iceberg orders due to demand for it from institutional traders or in general traders who trade large amounts. Such traders want to hide their orders because orders in general reflect the intentions of their owner. Large traders are considered more informed and more influential than the average trader (they probably wouldn't be large otherwise). Therefore if the intention of a large trader becomes transparent to other market participants, they may decide to front-run the large order, making it more difficult to execute at a desired price.


Iceberg detection.png


When traders need to execute significantly large amount (compared to the available liquidity), they wish to make at least the first transactions without significantly affecting the price. Otherwise the next transactions will be at a significantly worse price.


The mechanics of iceberg orders[edit]

Market mechanics is a required background for this topic.The basic principle of how, for instance, Buy Iceberg orders operate is this:

Iceberg principle.png

Matching of Iceberg orders[edit]

The mechanics of Iceberg orders matching is quite similar except that only its displayed size can advance in the order queue.

Matching of Iceberg order.png

Pros and Cons of using iceberg orders[edit]

Large traders have multiple alternatives to choose from to execute large amounts effectively, and each has its own pros and cons.

Pros:

  • Allows to hide the hidden size of the order.
  • Other market participants cannot detect the moment of placement or cancellation of the Iceberg order.
  • Only the displayed size of the Iceberg order can be detected, but not before it gets executed.

Cons:

  • The presence of an Iceberg order may be detected when its displayed size gets executed.
  • In recent years more and more exchanges offer detailed MBO (market-by-order) full market depth.
  • High quality data (which other large traders typically have access to) allows to detect Iceberg orders with high accuracy.

Why traders want to detect iceberg orders[edit]

Titanic.gif

Orders in general disclose the intentions of their owners. And since large traders are considered to be more informed on average (they wouldn't be large otherwise), it's reasonable to follow them or even better -- to trade in front of them. Also, large orders are by definition more influential on the price because price is determined by orders actions.

From the other hand, other large traders may look for Iceberg orders to execute against them because they seek higher liquidity for the same reasons as the owners of Iceberg orders.

Detection Methods and Algorithms[edit]

It's essential to understand that exchanges do not report Iceberg orders via market data. As demonstrated above, even with highest quality of market data, untouched by data vendors in between, there are limits of what can be detected even in theory:

  • The size of the hidden part of the Iceberg order cannot be detected.
  • The presence of an Iceberg order and its displayed size cannot be detected before it gets executed.
  • The moment of placement of an Iceberg order cannot be detected in advance, however given the MBO data, it may become known based on its Order ID once the Iceberg gets detected for the first time.
  • The moment of Iceberg order full execution can be detected instantly with MBO data, or after the next execution at the same price with MBP data.
  • The moment of Iceberg order cancellation can be detected only with MBO data given that it was executed at least once and detected.

Regardless of market data quality, any Iceberg tracker is an estimation. Its accuracy depends on the quality of market data and on the tracking algorithm of course.

Bookmap offers 3 different Iceberg tracking algorithms:

Bookmap Iceberg tracking algorithms.png

Sensitivity to market data quality[edit]

A snapshot or instant state of the market depth doesn't allow to detect Iceberg orders regardless of market data quality. The only way to detect Iceberg orders is by tracking the dynamics of market data. The key for successful Iceberg detection is finding the differences in the sequence of events, comparing it when a regular limit order gets executed vs those when an Iceberg order gets executed.


In addition, most Iceberg detection algorithms are based on the knowledge that Matching Engines process orders in an atomic-operation manner. This means that even if two orders arrived to the exchange in the same nanosecond, there is still the earlier one, and later one will not be processed until the complete processing of the first order. In practice exchanges may perform a smarter approach which allows parallel processing in certain cases, but this doesn't affect the outcome. This assumption becomes very weak when market data vendors split the raw market data into channels such as Times&Sales, BBO, Level 1, Level 2, and transmit them via different servers. This makes restoring the original sequence of events very challenging and in most cases impossible without adding latency by buffering the data events.


Ideally, market data should be MBO and its updates should arrive in exactly the same order as was sent by the exchange.

Underflow algorithm (expired)[edit]

Until recently, exchanges (and CME in particular) when an Iceberg got executed, market data contained trade size that exceeds the available size in the order book. This allowed to spot such events and to mark the excess of the trade size as an execution of potential Iceberg order as shown in the diagram:

Iceberg detection with Underflow algorithm.png

The markers on Bookmap chart showed how much of the potential Iceberg order was executed. However, this algorithm isn't reliable anymore because the sequence of events in market data has changed.

Ideal or Native detection algorithm[edit]

This algorithm requires MBO data with untouched sequence of events. It should be noted that unlike MBP, MBO data doesn't need to provide trades explicitly. For instance, when an aggressive Buy order gets matched, MBO can report only the execution of Sell orders. And because any trade always require two sides, the arrival of the aggressive Buy order can be assumed, i.e. it's reported implicitly.

Iceberg detection with Native algorithm.png


Here is a more detailed demonstration of this process:


Iceberg detection details with Native algorithm.png


Here is an example of native algorithm in action:


Native algorithm in action.png

Adjustments for lower quality data[edit]

The basic principle of the above native Iceberg detection algorithm is this: New limit orders being added instantly from the opposite side as a response to executions at that price level. Same principle can be applied to lower quality, non-MBO market data. In a sense, these limit orders act as resistance to the aggressive order and its absorption. Hence, the name of this algorithm is Resistance. Since the definition of instantly added may vary depends on the market data, users can configure it. Also, users can set higher than default=1 threshold for size to reduce the chance of false positive detection.

Resistance panel.png


The data inside exchanges have always been MBO, and most modern exchanges provide the MBO data. That includes CME, NASDAQ, BATS, and almost all Digital / Crypto exchanges. The quality of typically being lost during post-processing it by data vendors who may split it into different asynchronous channels, or aggregate and throttle it. However, based on experiments conducted by Bookmap team, if the MBO data was accurately converted into MBP while keeping the exact sequence of events, the accuracy of Resistance detection algorithm is hardly distinguishable from the Native algorithm.

Generalization of Iceberg indicator[edit]

It's easy to imagine that some high frequency traders (HFT) would decide to mimic the behavior of Iceberg order using regular Limit orders, i.e. implement it locally. They would send a relatively small order (similar to the Displayed size of Iceberg order), and then another one each time the previous order gets executed.

In both cases the small orders start from the end of the queue, therefore the only disadvantage of it is latency: although typical HFT in exchange colocated facilities have sub-millisecond round-trip-time (RTT), during short peaks of market activity many events can occur during such short time interval.

However, the advantages of this method are the abilities to:

  • Stop the execution of the "Hidden" size at any moment.
  • Obfuscate the process, making it more difficult detect it. For instance, by
    • Sending different sizes of smaller, "displayed" orders
    • Adding different latency prior to sending another order, and so on.

The impact of such manually managed Iceberg order on the price is very similar to the impact of equal Iceberg order.

Iceberg orders vs Absorption[edit]

Extrapolating the analogy between actual Iceberg order and the Iceberg order mimicked by an HFT, it becomes apparent that the impact of such orders is quite similar even for large time intervals between execution and placing of a new order on the opposite side (which also demonstrates the fractal nature of trading).


It also becomes apparent that Iceberg orders and all of their higher-scale analogies act as Absorption of aggressive orders.

Iceberg orders vs regular limit orders[edit]

Recall the basic principle of Iceberg orders behavior, for instance, of Buy orders:

Iceberg principle.png

Just like Iceberg orders, regular Limit orders may also behave this way: responding to market actions by adding more liquidity on the opposite side. The only difference between them is visibility. Therefore it's reasonable to compare between them.

Iceberg orders Regular Limit orders
Act as absorption Yes Yes
May attract large traders who seek liquidity Yes Yes
Number of orders Very few All of the market depth
The presence is visible Only when it gets executed for the first time At the moment of order placement and at any price level
Total order size is visible No Yes
Full execution is visible Not until the execution of all orders at the price level Yes, at the moment of execution
Cancellation is visible No Yes, at the moment of cancellation and at any price level
Being used for manipulations Probably not... Yes, frequently


Both Iceberg orders and large regular Limit orders can affect the market in two opposite ways:

  • By absorbing the aggressive orders and reverting the price trend
  • By attracting other large traders who seek higher liquidity. The resulting price movement after the collision depends on the comparative size between the two forces.