dxFeed Solution for Iceberg Orders Detection and Prediction

Solutions

Index Management

Iceberg Detection Solution

Blockchain Oracle Solutions SEC Rule 6c-11 Solution for ETF Vendors Machine Learning Virtual and Augmented Reality Chainlink Node

Iceberg Orders

On financial exchanges, an iceberg order is a limit order where only a fraction of the total order size is shown in the limit order book (LOB) at any one time (the peak), with the remainder of volume hidden. When the currently resting (outstanding) peak is executed, the next part of the iceberg’s hidden volume (tranche or refill) gets displayed in the LOB. This process is repeated until the initial order is fully traded or cancelled.

dxFeed Solution for Iceberg Orders Detection

For iceberg detection and prediction on Chicago Mercantile Exchange, dxFeed uses its proprietary algorithm*:

CME supports two types of iceberg orders: native and synthetic.

Native icebergs are managed by the exchange itself. All new tranches are submitted as modifications of the initial order; this means that the original order ID is preserved throughout the whole lifetime of the iceberg.
Synthetic icebergs are submitted by independent software vendors (ISV), whose infrastructure is physically separated from the exchange. ISVs split the initial iceberg order, submit new tranches and track their execution. These tranches are indistinguishable from regular limit orders submitted by other participants.

The processing of both order types is supported by the algorithm. Synthetic icebergs are identical to non-iceberg orders in how they are processed by the exchange, so they can only be detected heuristically and relying on a set of assumptions. An unambiguous detection of native icebergs is possible.

Below you can see the distributions of peak volumes and number of tranches on one trading day (as inferred by the algorithm):

Once an iceberg is detected, a prediction of its total size can be made.

dxFeed API

dxFeed market data feeds (real-time, delayed or historical) allow to reconstruct analytic order books. dxFeed Java API provides the OrderBookModel class which builds a high quality analytic order book from a set of market events. Iceberg orders are represented by the AnalyticOrder class, which extends the base Order class with the following notable attributes:

icebergPeakSize: the size of the peak
icebergHiddenSize: the prediction of current hidden size of the iceberg, as inferred by the model
icebergExecutedSize: the executed size of the iceberg order

Examples

Native Iceberg

We trace an order with ID 645752022466. 11 units of (visible) volume are placed at 2890.25, and then executed.

ask LIMIT 11 @ 2890.25
bid TRADE 3 @ 2890.25 (against 645752022495)
bid TRADE 4 @ 2890.25 (against 645752022505)
bid TRADE 4 @ 2890.25 (against 645752022508)

The second tranche of volume 11 enters the book. At this point, we conclude that the order is indeed an iceberg, give an estimate of its total volume (equivalently, current hidden volume) and disseminate an AnalyticOrder instance.

ask MODIFY 11 @ 2890.25
AnalyticOrder(icebergPeakSize = 11, icebergHiddenSize = 33, icebergExecutedSize = 11)
bid TRADE 2 @ 2890.25 (against 645752022518)
bid TRADE 9 @ 2890.25 (against 645752022532)

More tranches then follow, each potentially having a different size. A more precise prediction is made upon detecting a new tranche. When the last tranche is executed, the order is removed from the book.

ask MODIFY 11 @ 2890.25
AnalyticOrder(icebergPeakSize = 11, icebergHiddenSize = 22, icebergExecutedSize = 22)
bid TRADE 6 @ 2890.25 (against 645752022593)
bid TRADE 3 @ 2890.25 (against 645752022594)
bid TRADE 4 @ 2890.25 (against 645752022602)
(...)
ask MODIFY 1 @ 2890.25
AnalyticOrder(icebergPeakSize = 1, icebergHiddenSize = 3, icebergExecutedSize = 46)
bid TRADE 1 @ 2890.25 (against 645752022639)
ask DELETE 1 @ 2890.25

In this example, the iceberg order had 5 tranches, the peak volume was 11 and the total volume was 47.

Synthetic Iceberg

Synthetic iceberg tranches are regular limit orders. Briefly, an incoming order is considered a tranche if it is placed within a small time frame after a previous order of the same size and price level had been executed. Hence there are the following notable differences with the native icebegs:

Since more than one order is eligible for being a parent tranche, the iceberg is best viewed as a network graph of orders, see Fig. 1. Then icebergExecutedSize is an aggregate quantity of the executed volume of each tranche chain (which altogether form the graph).
Since the detection process is inherently speculative, there is a chance that regular orders are classified as iceberg tranches. A minimum tranche chain length parameter specifies the number of tranches sufficient to declare the chain an iceberg (the larger the value, the higher the precision and the lower the recall).

The dissemination model for synthetic icebergs is the same as for native ones.

A synthetic iceberg graph. Node labels are order IDs; edge labels are time in seconds between subsequent tranches:

Visuals

* CME Iceberg Order Detection and Prediction article is distributed under license CC BY-NC-SA 4.0 and is also available at https://arxiv.org/abs/1909.09495).