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 645752022495)
bid TRADE 4 @ 2890.25 (against 645752022505)
bid TRADE 4 @ 2890.25 (against 645752022508)

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 645752022518)
bid TRADE 9 @ 2890.25 (against 645752022532)

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 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 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.