Aussie AI

Chapter 8. Iceberg Orders

Book Excerpt from "C++ Ultra-Low Latency: Multithreading and Low-Level Optimizations"

by David Spuler, Ph.D.

Chapter 8. Iceberg Orders

What are Iceberg Orders?

Iceberg orders are large orders where most of the quantity is hidden, in the same way that most of an iceberg is hidden under the water. Exchanges offer support for iceberg orders in terms of auto-replenishment of these orders with more of the hidden quantity when the displayed quantity gets traded. The replenished quantity is added as a new order with a different ID, so it’s not obvious that it’s a replenishment of an iceberg.

The reason that some traders would want to use iceberg orders is that a large quantity can be traded without making it obvious. Hopefully, this avoids price slippage that might otherwise occur.

The effect of icebergs is different for exchanges versus other traders because of the information asymmetry. At a high level, the management iceberg orders has aspects including:

Display quantity is visible to other traders, but a larger total quantity is hidden.
The exchange knows it’s an iceberg, and has automatic support for this.
Other traders don’t know which orders are icebergs (in theory).

Many exchanges allow the placement of iceberg orders as a special type of bid or ask. For example, a hedge fund or institutional investor might wish to make a large trade. Even HFT traders may use their own icebergs, although they may also like to find icebergs to trade against, because it means there’s a lot of hidden liquidity at a price level.

Exchanges have explicit support for icebergs as an order type. When you place an iceberg order with an exchange, you specify:

Side (buy or sell)
Price
Display quantity
Total quantity (hidden)
Replenishment (increment)

The initial quantity is displayed and is the first order. When this order is consumed in a trade, a new order is created with the replenishment quantity. The amount of replenishment doesn’t need to be the same as the initial quantity.

This is a simple type of iceberg order with a fixed replenishment quantity and zero delay. Some exchanges offer more advanced handling of iceberg orders, such as dynamic adjustment of the replenishment size, or auto-delays for when the new order appears. These more advanced features can help iceberg orders remain hidden and get the best execution prices.

Iceberg Replenishment Scenarios

When an iceberg is triggered on the side of an executed trade, the exchange automatically “replenishes” the quantity in a new order. In other words, once the display quantity is absorbed in a trade, another new order is automatically placed.

Conceptually, the new order has its own ID and is added to the end of the queue, like any other type of order. However, behind the scenes, the exchange may have shortcut this cycle with some code optimizations.

An interesting scenario arises where an aggressive order matches an iceberg order at the best price, and one or more orders at a second-best price that is also crossed and could be executed. Naively, we would say that the price level has only the single iceberg order at the displayed quantity according to the FIFO queue of orders at that price level. The replenishment orders are not yet on that queue. Hence, the matched iceberg order’s initial display quantity should be used, and there being no further liquidity at that price levels, the second-best price orders should be executed to fill any remaining capacity.

But when is the iceberg replenished? Is it before or after switching to a second-best price level?

The naive scenario is not very good, because a better price was on offer by replenishing the iceberg and trading with it again, before reverting to the second-best priced orders only after the iceberg order was exhausted. This is a better algorithm for the exchange, and there’s nothing really conceptually wrong with this. It’s just doing the replenishments after scanning a single price level, before moving to a second-best price level.

Iceberg Algorithm Optimizations for Exchanges

There are two types of code optimizations in relation to the processing of iceberg orders:

1. Exchanges optimizing trade executions that trigger many replenishments.

2. Other traders trying to figure out which orders are icebergs.

On the exchange side, some of the situations that can be considered for algorithmic optimizations include:

Repeated replenishment — iceberg orders getting replenished many times in a single trade execution with lots of new orders getting created and then executed.
Two icebergs colliding — the aggressive order that triggered the trade was itself an iceberg, which matched with one (or more) icebergs on the other side of the trade.

Let’s look at what sort of code optimizations are possible.

The first point is that the exchange knows which orders are iceberg orders. Hence, when it’s scanning the list of orders to match at a price level, it can fill the non-iceberg orders, and the displayed amount of an iceberg order. Note that this is only considering a “fair” FIFO filling method, and not more complex variants such as “pro rata” algorithms where larger orders get more fill.

After the first scan of the order list for a price level, the exchange knows it has seen some iceberg orders at that price level. Hence, the exchange’s matching engine knows that once the list is finished this first scan of the price level, there will be new replenishments of one or more iceberg orders at that price level. In fact, after this first scan of the best price level, if there’s still quantity to be traded, then:

There’s only icebergs left!

According to a naive implementation, the one or more icebergs at that price level should be repeatedly:

1. Creating a new order with a replenished quantity, and

2. Executing a trade with the new quantity.

This could happen many times. Possibly an entire iceberg order is used up, or it may have quantity left. Partial fills are also possible at the edge cases.

In practice, an exchange’s matching engine may use some optimizations here, rather than repeatedly doing the same steps. After all, you can calculate how much of the available quantity should be consumed by each iceberg based on:

(a) your active order’s available quantity,

(b) the iceberg’s hidden remaining quantity, and

You can do the arithmetic first, and then create new orders with new IDs. One optimization is to do a bulk-insert of all these new orders into the order book. A better optimization is not to put them into the order book at all, because they’re already been traded out of the order book (before they even went in). However, the exchange still needs to emit the various new order and trade execution messages for all of these iceberg replenishment orders, so as to try to hide everything.

Finally, note that these optimizations won’t apply in all situations for an exchange. For example, these optimizations are assuming that the client’s iceberg orders are immediately replenishable with zero delay, which is not true of all iceberg orders.

Trader Detection of Hidden Icebergs

Other trading participants would love to find out which orders are icebergs. In theory, there’s nothing to see. But HFT coders and algorithmic traders are nothing if not innovative.

Generally, the strategy for finding icebergs is to watch the market’s sequence of events, via the market data feed. Anywhere that the sequence differs from what you would normally expect for a non-iceberg order, that’s when you have identified a likely candidate. The main idea is:

Spot icebergs when they execute!

There’s not much you can do when an iceberg is sitting passively in the order book. Similarly, a non-aggressive new iceberg order won’t be easy to spot. The differences occur in the executions.

To see what can be done to detect market sequence differences, think about the process whereby an order will trigger an immediate auto-replenishment by the exchange. Some new orders have appeared and been executed in the blink of an eye. The IDs of these new replenished orders were not in the order book before, but they appear as a sequence of aggressive orders at the same price point. Some of the main things to see is:

(a) Suddenly created orders immediately executed, and/or

(b) New orders created with the same quantity.

So, this analysis of the timing of executions and new orders gives some hints about the presence of an iceberg order at a price point. Note that this is assuming basic icebergs with replenishment of a fixed size that processes instantaneously with zero delay. However, exchanges also offer more advanced types of icebergs with dynamic replenishment quantities, time delays, and triggers based on market conditions.

Some other types of indicators that an iceberg may be present include:

Price levels sustained despite low apparent available liquidity.
Volume spikes at that price level.
Recurring market maker indicators in repeated orders (not the individual traders, which is secret, but the financial institution through which they’re trading, which isn’t).

Probing Strategies

And finally, there’s also the idea of issuing your own trades that attempt to find out if an order is an iceberg, This is called a “probing strategy” and aims to find hidden liquidity in the market. Some of the ideas include:

Ping orders — submit small orders watching for replenishments.
Layered orders — several orders at multiple price levels.
Flash orders — short-duration orders to see if they get swallowed.

The overall idea is to issue these “probes” and then watch the reaction in the market data feed for what trades occur, and how quickly, and whether new orders get created.

If you think you’ve found an iceberg, there are two basic ways to play for an edge:

(a) Now — repeatedly trade against the iceberg or others using this extra knowledge, and/or

(b) Later — trade for price changes that will occur after the iceberg is finished.

Many of these probing methods are commonly used by algo traders. These attempts to find icebergs can have false positives, whereby it’s not an iceberg, but some other algorithmic trader that’s responding with new orders. Furthermore, such methods can be expensive if you fail, may change the market unintentionally, and some types of probing may be considered “market manipulation” in some jurisdictions. Hence, if you think you can spot icebergs, maybe think about the Titanic.

Extensions

Examine or code up the matching engine logic for processing trades when an iceberg order is matching.
Examine the algorithm for optimizing iceberg matches where multiple icebergs match, and the active quantity is large enough for many replenishments.
Can you calculate how much each iceberg will consume of an order’s quantity using only arithmetic and conditional tests? Try to avoid simulating it with a loop. Start with the case of one iceberg, then generalize.
Examine probing methods to detect advanced iceberg orders with delayed replenishment and non-fixed quantities.

• Online: Table of Contents

• PDF: Free PDF book download

• Buy: C++ Ultra-Low Latency