Ausführungslatenz: Pfad, Zeitstempel und Messung

Einfach gesagt — Zwischen Entscheidung und Fillbericht liegen Plattform, Netzwerk, Broker, Kontrollen, Router und Venue. Ein einziger „Click-to-Fill“-Wert mischt Technik und Warten auf Gegenpartei. Zur Diagnose braucht jedes Teilstück einen definierten Timestamp.

Ausführungslatenz ist die verstrichene Zeit über eine oder mehrere Phasen des Order-Lebenszyklus. Es gibt keinen universellen Start- und Endpunkt. Messbar sind etwa Signal bis Versand, Client bis Broker, internes Routing, Eingang an der Venue, Acknowledgement, Match und Rückweg des Reports.

„Ausführung“ kann verschiedene Ereignisse meinen. Ein Acknowledgement bestätigt meist Empfang oder Annahme, nicht den Fill. Eine Order kann mehrere Teilfills erhalten. Eine passive Limit-Order kann minutenlang in der Queue warten, obwohl die Infrastruktur in Millisekunden durchlaufen wurde. Diese Liquiditätswartezeit ist nicht automatisch technische Latenz.

Jedes Segment hat eigenen Messpunkt und Verantwortungsbereich. Zeitstempel nicht synchronisierter Uhren dürfen nicht einfach voneinander abgezogen werden.

Segmente des Ausführungspfads

Marktdatenlatenz reicht vom Ereignis an der Venue bis zum empfangenen Feed und umfasst Konsolidierung, Netzwerk und Parsing. Entscheidungslatenz reicht vom Marktdatenereignis oder Signal bis zur Ordergenerierung. Client/Broker misst Versand bis Empfang; intern folgen Validierung, Risiko, Throttling und Routing. Danach kommen Broker/Venue-Netz, Eingangskontrollen und Matching sowie der Rückweg des Reports.

Welcher End-to-End-Pfad zählt, hängt von der Frage ab. Eine automatische Strategie kann von den empfangenen Marktdaten bis zum Fillbericht messen. Ein Broker-Audit beginnt bei dessen erstem Empfang. Eine Venue sieht nur ihren eigenen Perimeter.

Rule 605 definiert im US-Anwendungsbereich Order Receipt als den Zeitpunkt, an dem das automatisierte System des Empfängers den Auftrag erstmals erfasst. Diese Definition unterstützt vergleichbare Statistiken; sie ist weder zwingend der Kundenclick noch der Eingang in die Matching Engine.

Uhren, Zeitstempel und Sequenz

Ein Timestamp ist nur nützlich, wenn Quelle, genauer Setzpunkt, Zeitzone, Granularität, Genauigkeit, Driftkorrektur und Umgang mit gleichen Zeitwerten bekannt sind. Innerhalb eines Rechners eignet sich für Intervalle eine monotone Uhr, die nicht durch zivile Zeitsprünge verändert wird. Zwischen Systemen ist eine gemeinsame, nachvollziehbare Zeitbasis nötig.

Die Delegierte Verordnung (EU) 2025/1155 verlangt für die von ihrem MiFIR-Anwendungsbereich erfassten Stellen die Synchronisierung von Geschäftsuhren mit UTC und je nach Aktivität unterschiedliche Genauigkeit. Die Artikel 11 bis 16 gelten seit dem 2. März 2026. Das beweist nicht, dass jeder kommerzielle Timestamp perfekt synchronisiert ist.

Zieht man einen Venue-Zeitstempel von einem Client-Zeitstempel ab, ohne deren Offset zu kennen, kann sogar negative Latenz entstehen. Eine Round-Trip-Messung auf demselben Client vermeidet zwei Uhren, enthält aber Hinweg, Verarbeitung und Rückweg. Durch zwei zu teilen liefert nicht zwingend One-way-Latenz, weil die Wege asymmetrisch sein können.

Beispiel einer korrekten Lesart

Auf der monotonen Client-Uhr entsteht ein Signal bei 0 ms, die Order wird bei 2 ms gesendet, das Ack bei 24 ms empfangen und der erste Fillbericht bei 80 ms. Sicher messbar sind 2 ms lokale Entscheidung, 22 ms Send-to-Ack und 78 ms Send-to-Report.

Diese Daten zeigen nicht, wo die 22 ms lagen, und der Match muss nicht bei 80 ms stattgefunden haben. Der Report kann später eintreffen. Die 56 ms zwischen Ack und Report können Queue-Wartezeit, fehlende Gegenpartei, Matching und Nachrichtenrückweg enthalten. Bei einer passiven Limit-Order ist dies eher Time-to-first-fill als reine Netzlatenz.

Zur Lokalisierung braucht es weitere Broker- und Venue-Zeitstempel mit dokumentierter Herkunft und Synchronisierung oder kontrollierte Messungen je Segment.

Geeignete Metriken

Ein Mittelwert verdeckt Ausreißer. Sinnvoll sind Median, p95, p99 und Maximum je Segment; Verteilungen nach Venue, Instrument und Uhrzeit; getrennte Time-to-Ack, Time-to-first-fill und Time-to-completion; Timeout-, Reject- und Retry-Raten; Out-of-sequence-Meldungen sowie Differenz zwischen Event- und Empfangstimestamp.

Rule-605-Statistiken berücksichtigen Geschwindigkeit und ausgeführte Menge als Dimensionen der Execution Quality. Geschwindigkeit bleibt mit Preis, Fillrate und Ordertyp zu lesen: Eine sofortige Ablehnung entspricht nicht einer vollständigen Ausführung, und ein schneller Fill zu schlechterem Preis ist nicht automatisch besser.

Latenz, Slippage und Qualität

Latenz und Slippage können zusammenhängen, wenn Quotes schnell wechseln. Sie sind keine Synonyme, und Korrelation beweist keine Ursache. Während einer Verzögerung kann der Markt günstig, ungünstig oder gar nicht laufen. Slippage hängt außerdem von Spread, Tiefe, Menge, Ordertyp und Market Impact ab.

Niedrigere Latenz vermindert bestimmte Zeitrisiken, garantiert aber keinen Bestpreis, keinen Vollfill, kein korrektes Routing, keinen Schutz vor adverser Selektion und keine wirtschaftlich vorteilhafte Infrastruktur. In MiFID II Artikel 27 ist Geschwindigkeit neben Preis, Kosten, Ausführungswahrscheinlichkeit, Settlement, Größe und Art nur ein Faktor.

Reproduzierbare Kontrollen

Vor Logauswertung müssen Ereignisse definiert sein. „Send“ kann Klick, API- Aufruf oder Gateway-Ausgang bedeuten; „Fill“ kann Match an der Venue, Brokerbericht oder UI-Update meinen. Unterschiedliche Definitionen machen Systemvergleiche ungültig.

Benötigt werden eindeutige IDs für Order, Ack, Änderungen und Fills, Sequenzen bei zu grober Timestamp-Auflösung, vollständige Reject-, Cancel- und Restmengendaten, regelmäßige Driftkontrolle sowie Segmentierung nach Ordertyp und Marktregime. Marktdaten-, Entscheidungs- und Infrastrukturlatenz bleiben getrennte Kategorien.

Typischer Fehler — Lokalen Klick-Timestamp und Venue-Zeit wie dieselbe Uhr zu behandeln oder die gesamte Fillzeit dem Netzwerk zuzuschreiben. Ohne Messpunkte und Clock-Dokumentation lokalisiert der Wert keine Ursache.