Iceberg Order erklärt: Reserve, Refill und Priorität

Für wen dieser Artikel gedacht ist — Für alle, die verstehen möchten, weshalb sichtbare Book-Menge kleiner als die insgesamt verfügbare Menge sein kann, oder eine große Order nicht vollständig zeigen wollen.

Eine Iceberg Order, auf manchen Systemen Reserve Order oder Display Quantity Order, ist gewöhnlich eine Limit Order, von der der Markt nur eine Teilmenge sieht. Der nicht angezeigte Teil ist die Reserve. Nach Ausführung der sichtbaren Tranche kann das System weitere Menge freigeben, bis Gesamtmenge, Gültigkeit oder Stornierung die Order beenden.

Einfach gesagt — Von 1.000 Einheiten können jeweils nur 50 im Book stehen. Nach einem Fill erscheinen womöglich weitere 50. Daraus lässt sich aber weder die verbleibende Gesamtmenge noch deren Queue-Platz sicher ablesen.

Nur die Display Quantity erscheint im öffentlichen Book. Freigabe und Priorität der Reserve folgen der konkreten Venue-Spezifikation.

Parent, Display Quantity und Refill

Die Parent Order enthält Seite, Limitpreis und Gesamtmenge. Display Quantity begrenzt die aktuell gezeigte Tranche; Reserve Quantity bleibt zunächst verborgen. Ein Refill gibt nach einem Fill oder einer anderen festgelegten Bedingung eine neue Tranche frei. Bei synthetischer Ausführung kann ein externes System dafür einzelne Child Orders senden.

Die Terminologie ist nicht einheitlich. Artikel 4 der Delegierten Verordnung (EU) 2017/583 beschreibt für Non-Equity-Instrumente eine Reserve Order als Limit Order aus offengelegtem und nicht offengelegtem Teil; die Reserve darf erst nach Freigabe als neue sichtbare Order ausgeführt werden. Das ist eine regulatorische Definition für diesen Bereich, keine technische Spezifikation für jede Börse, jeden Broker oder Krypto-Handelsplatz.

CME dokumentiert Display Quantity als Attribut, dessen sichtbare Menge nach Ausführung wieder aufgefüllt wird. Vor der Nutzung zählt daher das Produktregelwerk und nicht allein der Name im Interface.

Native und synthetische Icebergs

Ein nativer Iceberg wird von Matching Engine oder Infrastruktur der Venue verwaltet. Die Venue kennt die Gesamtmenge und steuert Anzeige und Refill. Ein synthetischer Iceberg wird vom Broker, einem ISV oder einem externen Algorithmus geführt; die Venue sieht womöglich nur nacheinander eintreffende Child Orders.

Diese Unterscheidung verändert die operative Spur. Der native Typ hängt von Venue-Verfügbarkeit und -Regeln ab. Der synthetische Typ trägt zusätzlich Netz-, Gateway-, Latenz- und Ausfallrisiko des Systems, das die Child Orders sendet. Ein nativer Iceberg kann dieselbe Order-ID behalten, ohne denselben Queue-Platz zu behalten; synthetische Kinder erhalten häufig neue IDs.

Die CME-MBO-Dokumentation erläutert beispielsweise, dass bei einem nativen Iceberg die OrderID nach dem Refill bestehen kann, während sich die PriorityID ändert. Ein extern verwalteter Iceberg sendet neue Orders. Dieses Beispiel darf nicht als universelle Regel auf andere Märkte übertragen werden.

Priorität und Fillwahrscheinlichkeit

Der Limitpreis bleibt nur eine Preisgrenze. Die sichtbare Tranche konkurriert nach dem Algorithmus des Produkts; eine später freigegebene Tranche kann neue Priorität erhalten. Preis-Zeit, Pro-rata und Hybride erzeugen unterschiedliche Ausgänge.

Verdeckte Menge kann die sofort sichtbare Information reduzieren. Sie schützt aber nicht vor Teilfill, ausbleibendem Fill, Marktbewegung weg vom Limit, adverser Selektion, Gebühren, fehlender Produktunterstützung oder Prioritätsverlust beim Refill. Auch ein geringerer Market Impact ist nicht garantiert. Wiederholte Refills können selbst Interesse signalisieren und andere Teilnehmer reagieren lassen.

Kann man einen Iceberg im Book erkennen?

Nur als Hypothese. Viele Trades auf derselben Stufe zusammen mit wiederkehrender sichtbarer Menge passen zu einem Iceberg. Neue unabhängige Orders, mehrere Teilnehmer, aggregierte Feeds, Löschungen und Latenz können jedoch dasselbe Muster erzeugen.

Market by Price fasst Menge je Stufe zusammen. Market by Order bietet mehr Granularität zu einzelnen Orders und Queue, bleibt aber anonym und zeigt nicht zwingend die Reserve. Selbst eine persistente Order-ID identifiziert nicht den Eigentümer.

Typischer Fehler — Aus einem möglichen Refill auf einen „Whale“, seine Absicht oder die verbleibende Größe zu schließen. Die Daten stützen höchstens eine Mikrostruktur-Hypothese.

Kontrolliertes Beispiel und Prüfung

Eine Sell Limit Order über insgesamt 10.000 Aktien zeigt 500. Die ersten 500 handeln, danach erscheint eine neue Tranche. Der aggressive Teilnehmer weiß nur, dass neue Menge auf die Stufe kam. Er weiß nicht, ob 500 oder 9.500 übrigbleiben, ob der Refill Priorität verlor oder ob unabhängige Orders an der Sequenz beteiligt sind.

Vor Einsatz sind native oder synthetische Implementierung, Display-Regeln, Mindestmenge, zugelassene Produkte, Anfangs- und Refill-Priorität sowie Wirkung von Änderungen zu prüfen. Im Log müssen Gesamt-, sichtbare, ausgeführte, gelöschte und verbleibende Menge getrennt bleiben. Fill, Kosten und Impact sollten gegen einen benannten Benchmark gemessen werden; beim synthetischen Typ braucht es zudem einen Plan für Verbindungs- oder Systemausfall.

Iceberg- und Reserve-Order: sichtbare Menge