Pre-Trade-Risk-Checks im Order-Pfad

Eine Order trifft am Gateway ein. Bevor sie zum Venue hinausgeht, muss etwas entscheiden, ob das Konto sie senden darf. Diese Entscheidung läuft bei jeder Order, auch bei der überwältigenden Mehrheit, die völlig in Ordnung ist, also zahlt der gesamte normale Verkehr ihre Kosten und nicht nur die Rejects.

Das ist die Randbedingung, die zuerst zu nennen ist. Ein Risk-Check im Order-Pfad ist eine Steuer auf den Order-Eingang. Die technische Frage ist nicht, wie man den Check clever macht, sondern wie man ihn klein genug macht, dass Trader ihn nicht spüren, und ehrlich genug, dass er die Orders trotzdem ablehnt, die er ablehnen muss.

Was tatsächlich in den Order-Pfad gehört

Der Hot Path beantwortet genau eine Frage: Darf diese Order jetzt gesendet werden, angesichts dessen, was wir aktuell über dieses Konto wissen. Checks, die diese Frage beantworten, bleiben drin. Checks, die eine andere Frage beantworten, ziehen aus.

• Positions- und Exposure-Limits - die resultierende Position im Instrument, in der Gruppe und im Konto, verglichen mit konfigurierten Grenzen
• Margin oder Kaufkraft - ob das Konto unter dem aktuellen Margin-Modell noch Raum für die Order hat
• Fat-Finger-Grenzen - Ordergröße, Nominalwert und Preisabstand zu einer Referenz, die den Tippfehler vor dem Venue abfangen
• Instrument- und Kontozustand - Handel ausgesetzt, Konto eingeschränkt, nur Schließen erlaubt, Produkt für dieses Konto nicht freigegeben
• Kill-Switch-Zustand - ein einzelnes Flag, das alles darüber überstimmt
• Duplikat- und Self-Trade-Schutz dort, wo das Venue ihn nicht bietet

Alles andere läuft neben dem Pfad, auf demselben Zustand, ohne die Order aufzuhalten. Es speist die Limits, die der Hot Path durchsetzt, aber es sitzt nicht zwischen Trader und Venue.

• Portfolio-Risikoanalytik - Szenariorechnungen, Stresstests, korrelierte Exposure über Konten hinweg
• Neubewertung des Margin-Modells bei Parameteränderungen und jede Neuberechnung, die das ganze Buch berührt
• Überwachung und Mustererkennung, die Historie braucht, die der Hot Path bewusst nicht mitführt
• Reporting, Abgleich und alles, was mit einer Datenbank oder einem externen Dienst spricht
• Kredit- und Kontrahentenprüfung, die naturgemäß auf einer langsameren Uhr läuft

Wo der Positionszustand lebt und warum die Datenbank nicht im Pfad liegt

Der Zustand, den ein Pre-Trade-Check braucht - aktuelle Positionen, offene Orders, genutzte und verfügbare Margin, Limit-Konfiguration -, liegt im Speicher des Prozesses, der die Entscheidung trifft. Nicht in einem Cache vor einer Datenbank, nicht hinter einem Netzwerkaufruf. Im Prozess.

Der Grund ist nicht nur Geschwindigkeit, obwohl eine Query um Größenordnungen teurer ist als ein Lookup in einem lokalen Array. Der Grund ist Korrektheit. Eine Datenbank hält die Position so, wie sie geschrieben wurde. Der Risk-Check braucht die Position einschließlich der eben gesendeten Orders, die noch nicht ausgeführt, bestätigt oder persistiert sind. Liest man aus dem Speicher, prüft man gegen eine Vergangenheit, die der eigene Flow bereits überholt hat.

Praktisch prägt das den Prozess so, wie jede latenzarme Komponente geprägt wird:

• Ein Writer pro Konto. Konten werden über Risk-Instanzen geshardet, sodass der Zustand eines Kontos nie umkämpft ist und auf dem Order-Pfad kein Lock genommen wird
• Flache, vorab allokierte Strukturen - Arrays fester Größe, indiziert nach Konto- und Instrument-ID, zu Sessionbeginn aufgelöst, statt Hash-Lookups auf pro Order gebauten Strings
• Keine Allokation, kein I/O und kein Logging, das auf dem Entscheidungspfad blockiert; der Audit-Eintrag wird über eine Queue an einen anderen Thread übergeben
• Konfiguration, die sich ohne Neustart ändert, wird als ganzer unveränderlicher Snapshot eingetauscht, damit der Check nie ein halb aktualisiertes Limit liest

In der Datenbank wird die Position festgehalten. Sie ist nicht der Ort, an dem die Position bekannt ist.

Inkrementelle Neuberechnung, kein vollständiger Durchlauf

Eine vollständige Neuberechnung von Exposure und Margin eines Kontos läuft über jede Position und jede offene Order. Diese Kosten wachsen mit der Größe des Buchs, womit der Risk-Check ausgerechnet für die Kunden langsamer würde, die am meisten handeln. Deshalb rechnet der Hot Path nicht neu. Er wendet ein Delta an.

Das Konto führt laufende Aggregate - Netto- und Brutto-Exposure je Instrument und je Gruppe, genutzte Margin, Nominalwert in Flight. Eine eingehende Order erzeugt eine kleine Änderung dieser Aggregate, die geänderten Werte werden gegen die Limits verglichen, und die Order wird angenommen oder abgelehnt. Der Aufwand ist proportional zur Order, nicht zum Portfolio.

• Beim Senden wird der Worst-Case-Effekt der Order gegen die Aggregate reserviert, damit zwei Orders in Flight nicht beide in denselben verbleibenden Spielraum passen
• Bei Reject, Cancel oder Verfall wird die Reservierung freigegeben; bei Ausführung wird sie durch die realisierte Positionsänderung ersetzt
• Teilausführungen passen beide Seiten davon in einem Schritt an, und genau dort stecken die meisten Bugs in dieser Art von Engine
• Netting- und Gruppierungsregeln werden beim Laden des Instruments aufgelöst, nicht pro Order, sodass das Delta eine Handvoll arithmetischer Operationen ist

Die vollständige Neuberechnung findet weiterhin statt - nach Zeitplan, bei Änderung der Margin-Parameter und als periodische Selbstprüfung gegen das inkrementelle Ergebnis. Sie läuft neben dem Pfad, auf einer Kopie, und ihr Ergebnis wird entweder eingetauscht oder als Diskrepanz gemeldet. Inkrementeller Zustand, der still vom wahren Zustand abdriftet, ist schlimmer als gar kein Check, deshalb ist der Vergleich nicht optional.

Der Kill Switch ist ein eigener Pfad

Ein Kill Switch wird genau dann eingesetzt, wenn bereits etwas nicht stimmt. Das schließt aus, ihn auf der Maschinerie aufzubauen, die selbst das Problem sein könnte. Er ist ein eigener Pfad mit eigenen Regeln.

• Er ist ein einzelnes atomares Flag, das ganz oben im Check gelesen wird, bevor Positionszustand, Margin oder Instrumentdaten angefasst werden - so wirkt er auch, wenn diese veraltet, fehlend oder kaputt sind
• Er wird von mehreren unabhängigen Auslösern gesetzt: einer Operator-Aktion, einer automatisierten Bedingung, dem Verlust des Marktdaten- oder Fill-Feeds, von dem der Risikozustand abhängt
• Er fällt geschlossen aus. Kann der Risk-Prozess nicht feststellen, dass er gültigen Zustand hat, verhält sich das Gateway, als wäre der Switch aktiv
• Er hat Geltungsbereiche - die ganze Firma, ein Desk, ein Konto, eine Strategie -, denn ein Switch, der nur alles stoppen kann, wird zu spät benutzt
• Ihn zu aktivieren ist eine Aktion und eine Bestätigung, kein Konfigurations-Deploy; ihn zu deaktivieren ist bewusst und wird immer protokolliert

Neue Orders zu stoppen ist die leichte Hälfte. Die schwerere Hälfte ist, was der Switch mit Orders macht, die bereits am Venue ruhen: Quotes zu ziehen und offene Orders zu stornieren muss möglich sein, während der Sendepfad deaktiviert ist. Dieser Cancel-Pfad verdient eigene Tests, denn er wird am schlimmsten Tag geübt und nicht an einem normalen.

Neustart, und wie der Zustand zurückkommt

Der In-Memory-Zustand ist eine abgeleitete Sicht auf einen dauerhaften Datensatz. Genau das macht einen Neustart überlebbar. Jedes Event, das den Risikozustand ändert - eine angenommene Order, eine freigegebene Reservierung, ein angewandter Fill, ein geändertes Limit, der aktivierte Switch -, wird auf der lokalen Maschine an ein Journal angehängt, bevor es stromabwärts wirkt.

• Beim Start spielt der Prozess das Journal wieder ein, um die Aggregate aufzubauen, und gleicht danach Positionen und offene Orders gegen Venue und Clearing-Drop-Copy ab
• Bis der Abgleich abgeschlossen ist, ist das Konto nicht für den Handel geöffnet. Eine Risk Engine, die Orders annimmt, während sie die Position noch ermittelt, ist keine Risk Engine
• Eine Abweichung zwischen dem wiedergespielten Zustand und der Sicht des Venue stoppt dieses Konto und löst einen Alert aus; sie wird nie dadurch gelöst, dass stillschweigend eine Seite bevorzugt wird
• Ein Hot Standby folgt demselben Journal, sodass ein Failover einen warmen Zustand wiederherstellt statt eines kalten Replays, und der Standby wird regelmäßig durch Promotion überprüft statt nur in der Theorie

Die Wiederherstellungszeit hängt dann von der Journallänge und der Verfügbarkeit der Drop Copy ab, nicht von der Größe des Buchs, und der Fehlermodus jeder Unbekannten ist derselbe: den Handel für das Konto verweigern.

Was dieses Design nicht leistet

Die ehrlichen Grenzen sollte man klar benennen, denn sie entscheiden, ob diese Architektur überhaupt passt:

• Der Check ist nur so korrekt wie der Fill-Feed. Hinken Drop Copy oder Ausführungsberichte hinterher, ist die Exposure zu niedrig ausgewiesen, und die richtige Reaktion ist, auf konservative Limits herunterzugehen oder den Switch zu aktivieren, statt auf veraltetem Zustand weiterzuhandeln
• Portfolio-Margin-Modelle, die wirklich nicht additiv sind, widersetzen sich einer inkrementellen Auswertung. Was funktioniert, ist eine konservative inkrementelle Schranke auf dem Pfad plus das volle Modell neben dem Pfad; der Preis ist, dass einige Orders abgelehnt werden, die ein volles Modell erlaubt hätte
• Der Switch schützt vor dem eigenen Flow, nicht vor dem Markt. Er kann weder ein Gap noch Slippage auf bereits gehaltenen Positionen verhindern
• Zustand im Prozess bedeutet, dass Risk Engine und Order Gateway ein gemeinsames Schicksal haben. Das bringt Latenz und kostet die Möglichkeit, beide unabhängig zu skalieren
• Single-Writer-Sharding nach Konto erschwert kontenübergreifende Limits, und firmenweite Checks brauchen eine langsamere Aggregationsschicht mit eigener Veraltung
• Es ist mehr Betriebsaufwand als ein datenbankgestützter Check: Journale, Abgleich, Übungen zur Standby-Promotion. Ist der Order-Eingang nicht latenzkritisch, lohnt sich diese Komplexität nicht

amBrain baut solche Pre-Trade-Risk-Pfade für Broker und Prop-Firmen, mit Hot Paths in Rust. Das Team arbeitet seit 2019 von Jerewan, Armenien aus an Trading-Infrastruktur.