Orderbuch friert ein, wenn im Markt viel los ist? Wie Sie den Marktdaten-Feed reparieren und wer das kann

Wenn das Orderbuch auf Ihren Trading-Bildschirmen in einem hektischen Markt einfriert, springt oder unmögliche Preise zeigt, liegt der Fehler meist an einer von drei Stellen. Updates gehen dort verloren, wo der Börsen-Feed hereinkommt, das Orderbuch wird falsch zusammengesetzt, oder es erreicht Hunderte Bildschirme zu langsam. Messen Sie Ihre Spitzenstunde, bevor Sie jemanden beauftragen, und testen Sie dann jede Firma, die Sie in Betracht ziehen, mit einer Aufzeichnung dieses Tages.

Wie sieht ein gestörter Marktdaten-Feed auf dem Bildschirm aus?

Es zeigt sich in den hektischsten Momenten, etwa bei einer Ankündigung der Zentralbank oder zur Markteröffnung. Das Orderbuch auf dem Bildschirm bleibt ein, zwei Sekunden stehen und springt dann. Stornierte Orders bleiben sichtbar. Manchmal liegt der höchste Preis, den ein Käufer bietet, über dem niedrigsten Preis, den ein Verkäufer verlangt; das nennt man ein gekreuztes Orderbuch. An einer einzelnen Börse würden solche Orders außerhalb der Eröffnungs- und Schlussauktion sofort gegeneinander ausgeführt. Ein gekreuztes Orderbuch für eine einzelne Börse auf Ihrem Bildschirm bedeutet also, dass Ihre Kopie dieses Orderbuchs falsch ist.

Dann bekommt der Support Screenshots von zwei Tradern, die für dasselbe Instrument unterschiedliche Orderbücher sehen. Oder ein Trader bestreitet den Preis, zu dem eine Order ausgeführt wurde, weil der Bildschirm einen anderen gezeigt hat.

Warum gehen Updates verloren oder kommen in falscher Reihenfolge an?

Der Orderbuch-Feed einer Börse ist ein Strom kleiner Änderungen: Eine Order kommt hinzu, eine Order wird storniert, ein Trade findet statt. Ihr System startet mit einer vollständigen Kopie des Orderbuchs, einem sogenannten Snapshot, und wendet die Änderungen der Reihe nach an. Jede Änderung ist nummeriert, sodass sich eine fehlende erkennen lässt. In der Spezifikation von Nasdaq für den Feed TotalView-ITCH 5.0 heißt es, der Feed „besteht aus einer Reihe sequenzierter Nachrichten“, also aus fortlaufend nummerierten.

In einem hektischen Markt steigt der Strom der Änderungen stark an. Manche gehen unterwegs oder in Ihren eigenen Servern verloren, manche treffen in falscher Reihenfolge ein. Übersieht das System die Lücke, wendet es an, was gerade ankommt, und zeigt ein Orderbuch, das nicht mehr mit dem der Börse übereinstimmt. Bemerkt es die Lücke, braucht aber Sekunden, um sich zu erholen, steht der Bildschirm still.

Börsen rechnen damit, dass ihre Kunden Updates verlieren. In der Dokumentation der CME Group zu ihrem Feed MDP 3.0 heißt es, nach einer Lücke sei „davon auszugehen, dass alle im System des Kunden geführten Orderbücher möglicherweise nicht mehr den korrekten, aktuellen Stand haben“.

Wo im System versagt der Feed?

Es gibt drei Stellen, und jede braucht ihre eigene Lösung. Die dritte nennen Engineers Fan-out, weil sich ein einziger Strom von Updates fächerförmig auf viele Bildschirme verteilt. Der oben verlinkte technische Artikel behandelt alle drei im Detail.

Die erste Stelle ist der Eingang, an dem der Börsen-Feed ankommt. Manche Börsen bieten Wege, verlorene Daten zurückzubekommen. Eines der Übertragungsprotokolle von Nasdaq, MoldUDP64, ermöglicht es Empfängern, „verpasste Pakete zu erkennen und erneut anzufordern“. Die CME sendet ihren Stream doppelt, auf Leitungen namens A und B, und betreibt einen separaten Feed mit Snapshots, um Orderbücher auf den aktuellen Stand zu bringen. Nichts davon hilft, wenn Ihr System die Lücke nicht bemerkt.

Dann wird das Orderbuch zusammengesetzt, und hier besteht die Gefahr, dass eine Änderung doppelt, in falscher Reihenfolge oder auf den falschen Snapshot angewendet wird. Binance, eine Krypto-Börse, beschreibt in ihrem Leitfaden die genauen Schritte, mit denen ein Snapshot an den Live-Stream angeschlossen wird. Ein Orderbuch, das ohne sie aufgebaut wird, zeigt trotzdem Preise und sieht gut aus, aber die Preise sind falsch.

Zuletzt kommt der Fan-out, bei dem das Orderbuch an Hunderte Trader-Sessions geht, eine für jeden verbundenen Bildschirm. Ein Trader mit schwacher Mobilverbindung oder ein Terminal, das hängt, liest Updates langsam. Wartet der Server auf diese Session, warten alle anderen Sessions mit. Den Rückstau an Updates für diese Session unbegrenzt wachsen zu lassen, ist nicht besser, denn dann geht dem Server der Speicher aus, und er versagt für alle.

In einem gut gebauten System bringt der Server die Updates einmal in die richtige Reihenfolge und sendet dasselbe Ergebnis an jede Session. Eine Session, die zurückfällt, bekommt entweder das aktuelle Bild des Orderbuchs und überspringt die Zwischenschritte, oder der Server trennt sie unter Angabe eines Grundes, und der Bildschirm verbindet sich mit einer frischen Kopie neu. Ein Feed kann an mehr als einer Stelle gleichzeitig versagen.

Was sollten wir messen, bevor wir jemanden beauftragen?

Nehmen Sie die Stunde mit der höchsten Last im letzten Monat und erfassen Sie für sie diese Zahlen:

• Lücken: wie oft das System in jedem Börsen-Feed eine fehlende Update-Nummer gefunden hat. Wenn das System sie nicht zählt, ist das Ihr erster Befund
• Wiederherstellungszeit: wie lange jeder Neuaufbau gedauert hat und was die Trader in der Zwischenzeit gesehen haben
• Verzögerung: die Zeit vom Zeitstempel der Börse auf einer Nachricht bis zu dem Moment, in dem das Update Ihren Server in Richtung Trader verlässt, und auf einigen Testterminals bis zum Bildschirm. Erfassen Sie den Median und das 99. Perzentil, also die Zeit, die 99 von 100 Updates unterschreiten. Halten Sie die Uhren Ihrer Server mit einer genauen Zeitquelle synchron, sonst sind die Zahlen wertlos
• Sessions: wie viele zurückgefallen sind, um wie viel, und wie viele getrennt wurden, jeweils mit Grund

Zeichnen Sie dann den Roh-Feed eines Tages mit hoher Last genau so auf, wie er ankam, mit der Ankunftszeit jedes Pakets. Ein Replay dieser Aufzeichnung in Originalgeschwindigkeit und schneller ist der Test, den Sie jeder Firma auf Ihrer Liste stellen und nach jeder Reparatur wiederholen.

Den eigenen Handler reparieren, einen kaufen oder den Fan-out neu bauen?

Die Software, die einen Börsen-Feed aufnimmt und das Orderbuch führt, heißt Feed-Handler. Sie haben drei Wege, und Ihre Messungen sollten auf einen davon hindeuten. Die letzten beiden lassen sich kombinieren.

Wann ist es sinnvoll, den eigenen Feed-Handler zu reparieren?

Reparieren Sie Ihren vorhandenen Feed-Handler, wenn die Messungen auf einen klaren Fehler hindeuten, etwa unbemerkte Lücken oder einen langsamen Neuaufbau, und die Leute, die den Code kennen, noch da sind.

• Wann es passt: ein Fehler, den Sie benennen können, und ein Design, das ansonsten funktioniert
• Was Sie zahlen: Entwicklungszeit und einen Prüfstand, der Ihre Aufzeichnungen abspielt
• Wem der Code gehört: Ihnen
• Die Grenze: Eine Reparatur am Eingang hilft nicht, wenn das Problem darin liegt, das Orderbuch an die Bildschirme zu senden

Wann sollten wir einen Feed-Handler kaufen oder einen Managed Feed beziehen?

Ein fertiger Feed-Handler ist lizenzierte Software, die sich mit einer Börse verbindet, Lücken erkennt und Ihrem System ein korrektes, aktuelles Orderbuch übergibt. Ein Managed Feed geht weiter: Ein Marktdatenanbieter bindet die Börsen an, und Sie beziehen von ihm einen einzigen Stream in einem einheitlichen Format.

• Wann es passt: viele Börsen mit Standardformaten und kein Wunsch, jede Änderung zu verfolgen, die eine Börse an ihrem Feed vornimmt
• Was Sie zahlen: die Lizenz und die Arbeit, das Produkt an Ihr System anzubinden. Die eigenen Datengebühren und Lizenzbedingungen der Börsen gelten in der Regel weiterhin, ganz gleich, wer die Daten liefert
• Was Ihre Aufgabe bleibt: das Orderbuch auf Hunderte Trader-Bildschirme zu bringen und mit langsamen Sessions umzugehen
• Wem der Code gehört: Das Produkt gehört dem Anbieter. Ihnen gehören die Integration und alles, was danach kommt

Wann sollten wir ein Team beauftragen, den Fan-out neu zu bauen?

Bauen Sie die Schicht neu, die Daten an die Trader sendet, wenn der Eingang funktioniert, die Probleme aber bleiben. Trader sehen weiterhin unterschiedliche Orderbücher, eine langsame Session bremst die übrigen aus, oder Sie planen, deutlich mehr Sessions zu bedienen als heute.

• Wann es passt: Die Verzögerung wächst zwischen Ihren Servern und den Bildschirmen, nicht zwischen der Börse und Ihren Servern
• Was Sie zahlen: Entwicklungs- und Testzeit, danach die Leute, die das System nach dem Start betreiben
• Wem der Code gehört: Ihnen, wenn der Vertrag es so festlegt

Wie prüfen wir eine Firma, bevor wir sie beauftragen?

Unterziehen Sie jede Firma auf Ihrer Liste denselben fünf Tests:

• Ein Replay Ihrer Aufzeichnung, in Originalgeschwindigkeit und um ein Mehrfaches schneller, durch alles, was die Firma liefert oder vorführt. Vergleichen Sie Lücken, Neuaufbauten des Orderbuchs, Wiederherstellungszeiten und Verzögerungen mit denen Ihres heutigen Systems
• Wie es eine Lücke erkennt. Eine gute Antwort lautet: Das System wendet eine Änderung nur an, wenn ihre Nummer die nächste erwartete ist. Fehlt eine Nummer, wartet das System kurz und fordert die Änderung dann erneut an oder baut das Orderbuch neu auf. Bis dahin markiert es das Orderbuch als veraltet. Fragen Sie, was die Trader in der Zwischenzeit sehen
• Was mit einem einzelnen langsamen Trader passiert. Bitten Sie die Firma, während des Replays absichtlich eine Session zu verlangsamen. Die Verzögerungen der anderen Sessions sollten sich nicht ändern
• Wie es die Verzögerung misst: von welchem Zeitstempel bis zu welchem Punkt, bei welchem Perzentil, welcher Last und welcher Hardware und wie die Uhren synchron gehalten werden
• Wem der Code gehört und zu welchen Bedingungen Sie Teile nutzen, die die Firma als ihr Eigentum behält

Was sind die Warnsignale?

• „Wir stellen mehr Server dazu“ als erste Antwort, bevor überhaupt jemand Ihre Messungen gesehen hat
• „Wir nutzen eine zuverlässige Verbindung, also geht nichts verloren.“ Binance sendet ihre Updates über einen WebSocket, eine Verbindung, die unterwegs keine Daten verliert, und trotzdem erklärt ihr Leitfaden den Kunden, was zu tun ist, wenn Events übersprungen werden

Wo passt amBrain ins Bild?

amBrain baut Infrastruktur für den algorithmischen Handel: Orderausführung, Marktdaten und Pre-Trade-Risikokontrollen.

Eine Zeile auf der Website von amBrain lautet: „Entwicklung von Trading-Terminals, Order-Management-Systemen und FIX-Protokoll-Anbindung an Börsen.“

amBrain diagnostiziert langsame Trading- und AdTech-Systeme: Die laufende Plattform wird durchgängig vermessen, und der Bericht benennt, wohin die Zeit geht.

amBrain entwickelt seit 2019 Software. Sein Team beschreibt es in einer Zeile: „Ein Team von bis zu 40 Personen, davon etwa 75% Senior.“ Es arbeitet in drei Formaten: vollständige Umsetzung, ein dediziertes Team oder in Ihr Team eingebettete Entwickler. Der Kunde behält das volle Eigentum an Produkt und Code, ausgenommen die wiederverwendbaren Komponenten von amBrain.

Dieser Artikel ist keine Case Study und beschreibt keine Arbeit für Kunden. Er nennt keinen Latenzwert für irgendein System, das amBrain gebaut hat, und weder Preise noch Zeitpläne.

Wenn amBrain auf Ihrer Shortlist steht, stellen Sie ihm dieselben fünf Fragen wie jeder anderen Firma, und machen Sie Ihre Aufzeichnung zum Abnahmekriterium für jede Arbeit, die Sie vereinbaren.

Häufige Fragen

• Lösen mehr Server das Problem? Nicht für sich allein. Wendet das System Änderungen in falscher Reihenfolge an oder wartet es auf seine langsamste Session, wiederholen mehr Server denselben Fehler. Stellen Sie Server dazu, sobald die Messungen zeigen, dass den vorhandenen die Kapazität ausgeht
• Können wir Updates zusammenfassen und weniger davon senden? Für das Orderbuch ja. Engineers nennen das Conflation, und manche Börsen machen es selbst. Laut der Dokumentation von Binance liefert ihr Spot-Stream mit Orderbuch-Änderungen Updates im Takt von 1000 ms oder 100 ms. Sagen Sie den Tradern, dass der Stream das jeweils aktuelle Bild zeigt, nicht jeden Zwischenschritt. Fassen Sie keine Trades oder Orderbestätigungen zusammen, denn wenn eine davon wegfällt, stimmt die Handelshistorie nicht mehr
• Müssen wir es in Rust oder C++ neu schreiben? Nicht unbedingt. Übersehene Lücken und ein Server, der auf seine langsamste Session wartet, sind Designfehler, die eine neue Sprache nicht beseitigt. Rust und C++ haben keinen Garbage Collector, also keine automatische Speicherbereinigung, die ein Programm in einer Sprache wie Java oder Go anhalten kann. Das hilft in den Teilen des Systems, die jedes Update verarbeiten. Unabhängig von der Sprache: Fragen Sie nach der gemessenen Verzögerung bei Spitzenlast
• Wie lange dauert eine Reparatur? Das hängt davon ab, wo der Fehler liegt und wie viele Börsen und Sessions Sie haben. Bitten Sie jede Firma, eine erste Phase zu bepreisen und zu terminieren, die die Messungen und einen Testaufbau abdeckt, der Ihre Aufzeichnung abspielt. Nutzen Sie die fünf Tests oben als Abnahmekriterien