Lösung für die Erkennung von Iceberg-Orders

Iceberg-Orders

Als Iceberg-Order bezeichnet die Finanzwelt eine Limit-Order, bei der nur ein Bruchteil des gesamten Auftragsvolumens
im Limit-Order-Buch (LOB) angezeigt wird (die Spitze bzw. der Peak). Der Rest des Volumens bleibt verborgen. Erst
wenn der noch ruhende (ausstehende) Peak ausgeführt wird, zeigt sich der nächste verborgene Teil des
Iceberg-Volumens (Tranche oder Auffüllung) im LOB. Dieser Vorgang wird so lange wiederholt, bis die ursprüngliche
Order vollständig gehandelt oder storniert ist.

Lösung von dxFeed zur Erkennung von Iceberg-Orders

Für die Erkennung und Vorhersage von Iceberg-Orders an der Chicago Mercantile Exchange (CME) verwendet dxFeed einen proprietären
Algorithmus*:

Die CME unterstützt zwei Arten von Iceberg-Orders, Native und Synthetic.

• Native Icebergs verarbeitet die Börse selbst: Alle neuen Tranchen werden als Änderungen der
  ursprünglichen Order eingereicht. Somit bleibt die ursprüngliche Order-ID während der gesamten Lebensdauer des
  Iceberg erhalten.
• Synthetic Icebergs werden von unabhängigen Softwareanbietern (ISV) eingereicht, deren
  Infrastruktur räumlich von der Börse getrennt ist. ISVs teilen die ursprüngliche Iceberg-Order auf, reichen neue
  Tranchen ein und verfolgen deren Ausführung. Diese Tranchen sind von normalen Limit-Orders, die von anderen
  Marktteilnehmern eingereicht werden, nicht zu unterscheiden.

Der Algorithmus unterstützt die Verarbeitung beider Order-Arten. Synthetic Icebergs werden von der Börse auf
identische Art und Weise wie andere Orders verarbeitet. Daher lassen sie sich nur heuristisch und aufgrund einer
Reihe von Annahmen erkennen. Bei Native Icebergs hingegen ist ein eindeutiger Nachweis möglich.

Nachstehend sind die Verteilungen der Peak-Volumen und die Anzahl der Tranchen an einem Handelstag (gemäß
Algorithmus) abgebildet:

Sobald ein Iceberg entdeckt wird, lässt sich seine Gesamtgröße vorhersagen.

API von dxFeed

Die Marktdaten-Feeds von dxFeed (in Echtzeit, verzögert oder historisch) ermöglichen die Rekonstruktion von
analytischen Orderbüchern. Dazu bietet die Java-API von dxFeed die Klasse OrderBookModel, die anhand einer Reihe von
Marktereignissen ein qualitativ hochwertiges analytisches Orderbuch erstellt. Iceberg-Orders werden durch die Klasse
AnalyticOrder dargestellt, die die zugrunde liegende Order-Klasse um die folgenden nützlichen Attribute erweitert:

• icebergPeakSize: die Größe des Peaks
• icebergHiddenSize: die vorhergesagte, noch verborgene Größe des Iceberg, abgeleitet aus dem Modell
• icebergExecutedSize: die ausgeführte Größe der Iceberg-Order

Beispiele

Native Iceberg

Wir verfolgen eine Order mit der ID **********2466. Es werden 11 Einheiten (sichtbares) Volumen bei 2890,25 platziert
und dann ausgeführt.

ask LIMIT 11 @ 2890.25
bid TRADE 3 @ 2890.25 (against ********2495)
bid TRADE 4 @ 2890.25 (against ********2505)
bid TRADE 4 @ 2890.25 (against ********2508)

Die zweite Tranche mit dem Volumen 11 wird ins Orderbuch aufgenommen. An diesem Punkt erkennen wir, dass es sich um
eine Iceberg-Order handelt. Wir liefern eine Schätzung des Gesamtvolumens (und des entsprechenden verborgenen
Volumens) und verbreiten eine AnalyticOrder-Instanz.

ask MODIFY 11 @ 2890.25
AnalyticOrder(icebergPeakSize = 11, icebergHiddenSize = 33, icebergExecutedSize = 11)
bid TRADE 2 @ 2890.25 (against ********2518)
bid TRADE 9 @ 2890.25 (against ********2532)

Danach folgen weitere Tranchen, wobei jede eine andere Größe haben kann. Wenn eine neue Tranche erkannt wird, wird
die Vorhersage präzisiert. Sobald die letzte Tranche ausgeführt ist, wird die Order aus dem Buch entfernt.

ask MODIFY 11 @ 2890.25 
AnalyticOrder(icebergPeakSize = 11, icebergHiddenSize = 22, icebergExecutedSize = 22)
bid TRADE 6 @ 2890.25 (against ********2593)
bid TRADE 3 @ 2890.25 (against ********2594) 
bid TRADE 2 @ 2890.25 (against ********2602) 
ask MODIFY 11 @ 2890.25 
AnalyticOrder(icebergPeakSize = 11, icebergHiddenSize = 22, icebergExecutedSize = 33) 
(...) 
ask MODIFY 3 @ 2890.25 
AnalyticOrder(icebergPeakSize = 3, icebergHiddenSize = 0, icebergExecutedSize = 44) 
bid TRADE 3 @ 2890.25 (against ********2639) 
ask DELETE 3 @ 2890.25

In diesem Beispiel hat die Iceberg-Order 5 Tranchen, das Peak-Volumen beträgt 11 (die letzte Tranche hat einen
restlichen Peak mit dem Volumen 3) und das Gesamtvolumen beträgt 47.

Synthetic Iceberg

Die Tranchen von Synthetic Icebergs sind normale Limit-Orders. Eine eingehende Order gilt dann als Tranche, wenn sie
innerhalb eines kurzen Zeitrahmens platziert wird, nachdem eine vorhergehende Order derselben Größe zum selben Kurs
ausgeführt wurde. Daraus ergeben sich die folgenden deutlichen Unterschiede zu Native Icebergs:

• Da mehr als eine Order als übergeordnete Tranche in Frage kommt, lässt sich der Iceberg am besten als ein
  Netzwerkdiagramm von Orders darstellen (vgl. Abb. 1). Dann ist icebergExecutedSize eine aggregierte Menge des
  ausgeführten Volumens jeder Tranchenkette (gemeinsam als Kurve abgebildet).
• Da der Erkennungsprozess als solcher spekulativ ist, können unter Umständen auch normale Orders als
  Iceberg-Tranchen eingeordnet werden. Ein Parameter für die Mindestlänge der Tranchenketten gibt die Anzahl der
  Tranchen an, ab der eine Kette als Iceberg-Order gilt: je größer der Wert, desto höher die Genauigkeit und desto
  geringer die Zahl der Rückrufe.

Das Verbreitungsmodell für Synthetic Icebergs ist dasselbe wie für Native Icebergs.

Im nachstehenden Diagramm für einen Synthetic Iceberg sind die Knoten mit den Order-IDs bezeichnet; die Beschriftung
der Pfeile entspricht der Zeit in Sekunden zwischen aufeinanderfolgenden Tranchen:

Visuelle Darstellungen

* Der Artikel CME Iceberg Order
Detection and Prediction wird unter der Lizenz CC BY-NC-SA 4.0 publiziert und steht auch unter https://arxiv.org/abs/1909.09495 zur Verfügung.