Für wen dieser Artikel gedacht ist — Für alle, die eine gegenüber verfügbarer Liquidität erhebliche Menge ausführen und professionelle Gegenparteisuche vom Versand an den scheinbar besten Quote unterscheiden wollen.
Liquidity Seeking ist ein Ausführungsziel und eine Strategiefamilie: Die Order sucht Gegenparteien, indem sie je nach Policy Menge, Zeit, Aggressivität und Ziele verteilt. Es ist kein standardisierter Ordertyp und funktioniert bei Broker, Bank, Algorithmus und Assetklasse nicht identisch.
Die Strategie kann Spread, Tiefe, jüngste Fills, Fillwahrscheinlichkeit, Venue-Kosten und Dringlichkeit beobachten. Danach sendet sie passive, aggressive oder konditionale Child Orders, wartet, storniert oder verschiebt Restmenge. Günstige Liquidität ist womöglich nicht rechtzeitig verfügbar; sofortige Liquidität verlangt eventuell Spreadüberquerung oder erzeugt Market Impact.
Einfach gesagt — „Liquidity Seeking“ heißt nicht „findet immer den besten Preis“. Es ist eine Regel, wo, wann und wie dringend Fills versucht und auch Nichtfills gemessen werden.
Liquidität ist keine einzelne Zahl
Liquidität umfasst sofortige Kosten, verfügbare Menge, Ausführungsgeschwindigkeit und Book-Erholung. Das Top of Book zeigt nur beste sichtbare Quotes zu einem Zeitpunkt. Iceberg-Reserven, nicht sichtbares Interesse, andere Venues, Internalisierung und künftig eintreffende oder gelöschte Orders fehlen womöglich.
Ein aggregiertes Book, direkter Venue-Feed und Brokerquote sind nicht austauschbar. Der nominell beste Preis kann nur für kleine Menge gelten, andere Gebühren tragen oder aufgrund der eigenen Queue-Position geringe Fillchance bieten. Jede Policy muss daher ihren Daten- und Venue-Perimeter offenlegen.
Unterschied zum Smart Order Router
Ein Smart Order Router wählt automatisiert ein oder mehrere Ziele. Liquidity Seeking kann ihn verwenden, geht aber häufig weiter: Es zerlegt Parent-Menge, ändert Timing, Größe, Preis oder Aggressivität und verwaltet Rest nach Versand.
MiFID II Artikel 4(1)(39) schließt Systeme von „algorithmic trading“ aus, die ausschließlich routen, ohne Parameter zu bestimmen. Entscheidet ein System automatisch Timing, Preis, Menge oder spätere Behandlung, kann es je nach Perimeter unter die Definition fallen.
Das ESMA Briefing 2026 betont automatische Parameter, Governance, Tests, Outsourcing und Pre-Trade-Kontrollen. Auch ein Drittanbieter-Algorithmus muss mit seinen Einstellungen, Grenzen und Verantwortlichkeiten verstanden werden.
Bausteine einer Policy
Die Parent Order legt Menge, Limit, Horizont und Einschränkungen fest. Das Venue-Universum bestimmt erreichbare Märkte und Gegenparteien. Die Dringlichkeitsregel wägt Warten gegen sofortigen Fill ab. Child-Regeln legen Size, Preis, TIF und passive oder aggressive Modi fest. Datenregeln prüfen, ob der Feed wirklich erreichbare Liquidität beschreibt. Kontrollen begrenzen Duplikate, anomale Preise, zu große Size und Nachrichtenfrequenz. Schließlich definiert die Messung Benchmark, Filldaten, Rest und Kosten.
„Passiv zuerst“ ist nicht universell optimal. Die Queue kann Spreadkosten vermeiden, aber Nichtausführung und adverse Selektion erhöhen. Dringlichkeit folgt dem Ziel der Parent Order, nicht einem abstrakten Ideal.
Zentrale Trade-offs
Impact und Information Leakage: Verteilung über Zeit und Venues kann konzentrierten Druck reduzieren, doch wiederholte Muster können das Interesse erkennbar machen. Häufige Cancels und Re-Routing erhöhen zudem Nachrichten- und Operationsrisiko.
Opportunitätskosten: Warten auf bessere Gegenpartei lässt Menge offen, während der Markt weglaufen kann. Diese Kosten stehen nicht als Fee in der Abrechnung.
Adverse Selection: Ein passiver Fill ist nicht automatisch günstig. Die Gegenseite kann gerade handeln, weil neue Information eine Bewegung gegen den ruhenden Quote erwarten lässt.
Routingkonflikte: Gebühren, Rebates, Payment for Order Flow, Datenzugang und Vereinbarungen können Ziele beeinflussen. SEC-Rule-606-Informationen zeigen im US-NMS-Perimeter, warum Preis allein nicht genügt.
Keine Garantie von Best Price oder Completion
Ein Algorithmus kennt künftige Liquidität, Löschungen, Queues und verborgenes Interesse nicht sicher. Er garantiert weder besten Preis auf jedem möglichen Markt, Vollfill innerhalb der Dauer, fehlende Slippage, Impact oder Leakage, Zugang zu allen Venues noch automatische Erfüllung von Best Execution. Letzteres ist ein rechtlich-organisatorischer Prozess; Liquidity Seeking ist eine Technik, die dazu beitragen kann.
Beispiel: Eine Parent Order soll 80.000 Aktien bis zum Sitzungsende verkaufen. Die Policy beginnt passiv und wird mit kürzerer Restzeit aggressiver. Eine Venue zeigt einen besseren Preis, aber eine lange Queue; eine andere weist einen breiteren Spread auf, liefert jedoch einen Teilfill. In fallendem Markt sparen weitere passive Versuche Fees, erhöhen aber Opportunitätskosten. Die Review vergleicht Arrival Price, Fillquote, gewichteten Preis, Spread, Fee, geschätzten Impact, Rest und Post-Fill-Bewegung — sie erklärt nicht einfach eine Venue zum „Gewinner“.
Typischer Fehler — Algorithmen nur nach dem Durchschnitt der Fills zu vergleichen. Ein scheinbar besserer Preis kann daraus entstehen, dass wenig Menge gehandelt und das gesamte Restrisiko beim Kunden belassen wurde.
Professionelle Kontrolle
Benchmark, Horizont, Limit und Dringlichkeit werden vorab festgelegt. Erlaubte Venues, Ausschlüsse, Feeds, Gebühren und Konflikte werden dokumentiert. Pre-Trade-Limits schützen Preis, Menge, Wert und Nachrichtenrate. Tests decken Fallback, Kill Switch und degradierte Daten ab. Parent-, Child-, Cancel- und Fill-IDs bleiben über Zeitstempel verbunden. Die Auswertung umfasst explizite Kosten, Impact, adverse Selektion und Opportunitätskosten.
Quellen
- EUR-Lex — Richtlinie 2014/65/EU, Artikel 4(1)(39)
- ESMA — Supervisory Briefing on Algorithmic Trading in the EU
- U.S. SEC — Responses to Frequently Asked Questions Concerning Rule 606 of Regulation NMS
- U.S. SEC — Disclosure of Order Execution and Order Routing Information