Architektur eines algorithmischen Handelssystems

Ein algorithmisches Handelssystem wirkt oft wie eine Sammlung einzelner Module: Datenaufnahme, Strategie, Backtest, Ausführung, Risikomanagement, Logs, Monitoring. Im echten Betrieb ist aber nicht die Liste der Komponenten entscheidend, sondern die Grenzen zwischen ihnen. Genau an diesen Grenzen bricht die Verbindung zwischen überzeugender Forschung und realem Markt am häufigsten.

Dieselbe Idee durchläuft mehrere Umgebungen: Research, Backtest, Paper Trading und Production. Wenn in jeder Umgebung andere Daten, andere Ausführungsregeln und andere Risikoprüfungen verwendet werden, testet das System eine Strategie und handelt eine andere. Architektur ist nicht wegen des Diagramms wichtig, sondern wegen der Reproduzierbarkeit: Signal, Positionsgröße, Limitprüfung und Orderversand müssen vom Hypothese-Test bis zum Live-Kapital dieselbe Bedeutung behalten.

Eine gute Handelsarchitektur sieht deshalb weniger wie ein "smartes Modell" aus, sondern eher wie ein technischer Kontrollkreis mit klaren Verträgen. Daten müssen in einem prüfbaren Format ankommen. Die Strategie sollte eine Entscheidung erzeugen, nicht direkt mit der Börse sprechen. Der Backtest muss die Einschränkungen realer Ausführung modellieren. Die Execution Engine muss den Orderstatus kennen, nicht nur HTTP-Requests senden. Risk Management muss vor dem Trade, nach dem Trade und über dem gesamten System stehen.

Data ingestion: die Eingangsschicht des Marktes

Data ingestion bedeutet nicht "Kerzen herunterladen". Es ist die Schicht, die den externen Markt in einen internen Strom von Ereignissen übersetzt: Trades, Orderbuch-Updates, Candles, Funding, Instrumentenstatus, Gebühren, Handelsbeschränkungen und bei Bedarf Nachrichten oder Unternehmensereignisse.

Die Hauptaufgabe dieser Schicht besteht darin, die Bedeutung der Daten bei der Normalisierung nicht zu verlieren. Börsen unterscheiden sich bei Symbolen, Preis- und Mengengenauigkeit, Zeitstempeln, Ordertypen, Anfrage-Limits und Aggregationsregeln. Selbst eine einfache Kerze kann andere Intervallgrenzen, eine andere Behandlung leerer Bars und eine andere Politik für verspätete Korrekturen haben. Wenn diese Unterschiede zu früh versteckt werden, erhält die Strategie eine saubere Tabelle, die nicht mehr zu einem konkreten Venue passt.

Deshalb ist es sinnvoll, raw layer und normalized layer zu trennen. Der raw layer speichert ursprüngliche Nachrichten oder eine Darstellung, die ihnen möglichst nahekommt: was angekommen ist, wann es angekommen ist, aus welcher Quelle, mit welcher sequence number oder update id. Der normalized layer überführt Daten in das interne Modell: einheitliche symbol ids, timestamps, Ereignistypen, Preise, Volumina und Qualitätsstatus.

Bei Streaming-Daten sind gaps und die Reihenfolge der Ereignisse besonders wichtig. Die Coinbase-Dokumentation weist ausdrücklich darauf hin, dass sequence numbers auf ausgelassene oder nicht in der richtigen Reihenfolge eingetroffene Nachrichten hinweisen können und dass der Consumer den korrekten Zustand wiederherstellen können muss. 6 Binance beschreibt für ein lokales Orderbuch ein eigenes Verfahren: zuerst WebSocket, dann REST-Snapshot, dann Anwendung der gepufferten depth events nach update id. 5 Das ist keine technische Kleinigkeit, sondern Teil des Handelsmodells: Wenn das Orderbuch falsch aufgebaut ist, werden Execution und Slippage auf imaginärer Liquidität berechnet.

Datenbank und Speicherung

In einem Handelssystem gibt es normalerweise nicht die eine "Datenbank für alles". Es gibt mehrere unterschiedliche Speicherklassen, und sie zu vermischen ist gefährlich.

Die erste Klasse ist der market data store. Er wird für historische Kurse, Trades, Orderbuchdaten, Funding, Instrumentenstammdaten und alle Daten gebraucht, auf denen Research und Backtest aufbauen. Wichtig sind hier append-only Logik, Versionierung, Gap-Kontrolle, die Möglichkeit, Kerzen aus einer niedrigeren Datenebene neu zu erzeugen, und die Frage, auf welcher Version der Historie ein bestimmtes Ergebnis entstanden ist.

Die zweite Klasse ist operational state. Dazu gehören Orders, Ausführungen, Positionen, Salden, cash movements, Gebühren, API-Fehler, Zustand von Risikolimits und interne Systemereignisse. Diese Daten werden nicht nur für Reports benötigt, sondern auch für Reconciliation: Stimmt die Sicht des Systems mit dem überein, was die Börse oder der Broker sieht?

Die dritte Klasse sind research artifacts: Strategieparameter, Optimierungsergebnisse, Walk-forward-Fenster, Metrikberichte und Experimentsets. Sie sollten nicht als namenlose CSV-Dateien wie "final_v3" gespeichert werden. Wenn ein Backtest-Ergebnis nicht mit Datenversion, Strategiecode, Parametern und Kostenmodell verbunden werden kann, ist es nicht reproduzierbar. Und wenn es nicht reproduzierbar ist, sollte es nicht in Production gelangen.

Strategy engine

Die Strategy Engine verwandelt Daten und Zustand in Handelsabsicht. In einer guten Architektur sendet die Strategie keine Order direkt an die Börse. Sie sagt: Bei diesem Markt-, Portfolio- und Risikozustand möchte ich diese Exposure, diese Zielposition oder diesen Satz von Orders.

Diese Trennung wirkt formal, schützt das System aber vor einer zentralen Verwechslung: Signal und Ausführung sind verschiedene Aufgaben. Das Signal beantwortet "was möchte ich tun". Execution beantwortet "wie lässt sich das auf einem konkreten Venue sicher und realistisch tun". Wenn die Strategie selbst die Börsen-API kennt, Limits berechnet und partial fills verarbeitet, lässt sie sich kaum noch ehrlich vom Backtest in Live übertragen.

Die Strategy Engine sollte möglichst als deterministische Schicht entworfen werden. Derselbe Input sollte dieselbe Entscheidung erzeugen. Wenn es Zufall gibt, muss er explizit über Seed, Modellversion oder Zustand fixiert sein. Werden ML-Modelle verwendet, gehören dazu Feature-Version, Modellversion, Trainingszeitpunkt und ein Verbot von Daten, die zum Entscheidungszeitpunkt noch nicht verfügbar gewesen wären.

Der praktische Vertrag ist einfach: Die Strategie erhält nur Daten, die zu diesem Zeitpunkt verfügbar gewesen wären, und sie weiß nicht, ob ihre Entscheidung im Backtest, Paper Trading oder Production ausgeführt wird. Dann kann dieselbe Strategy Engine in verschiedenen Umgebungen geprüft werden, ohne die Logik selbst umzuschreiben.

Backtesting engine

Die Backtesting Engine ist nicht dazu da, eine schöne Equity Curve zu zeigen. Sie soll eine Hypothese unter Bedingungen prüfen, die der späteren Ausführung möglichst nahekommen. Je mehr Annahmen im Backtest versteckt sind, desto größer ist das Risiko, dass das System auf den Simulator optimiert wird statt auf den Markt.

Die erste Anforderung ist das Fehlen von look-ahead bias. Die Strategie darf keinen zukünftigen Close sehen, keine verspäteten Datenkorrekturen, keine Universe-Zusammensetzung, die erst heute bekannt ist, und keine Corporate Actions, die so angewendet werden, als seien sie vorher bekannt gewesen. Die zweite Anforderung ist ein ehrliches Kostenmodell: Gebühren, Spread, Slippage, Funding, Borrow Cost, Market Impact und Liquiditätsgrenzen. Die dritte ist die richtige Ereignisreihenfolge: Signal, Limitprüfung, Orderplatzierung, Ausführung, Positionsupdate, Ergebnisaufzeichnung.

Ein vectorized Backtest ist bequem für Research, modelliert aber die Ereigniswarteschlange oft schlecht. Ein event-driven Backtest ist langsamer, dafür näher an Production: Er zwingt die Strategie, in derselben Ereignisreihenfolge zu leben, in der sie später handelt. Für mittelfristige Strategien kann der vectorized Ansatz ausreichen. Für Intraday-, Orderbuch- und execution-sensitive Systeme bekommt man ohne Ereignismodell jedoch leicht ein Ergebnis, das den ersten Start an einer echten Börse nicht überlebt.

Überoptimierung ist ein eigenes Problem. Bailey, Borwein, López de Prado und Zhu beschreiben backtest overfitting als Situation, in der eine Strategie anhand historischer Simulation ausgewählt wird und außerhalb der Stichprobe anschließend degradiert; sie schlagen vor, die Wahrscheinlichkeit von Overfitting über spezielle Cross-Validation-Verfahren für Investment-Backtests zu schätzen. 7 Der architektonische Schluss ist einfach: Die Backtesting Engine sollte nicht nur das "beste Ergebnis" speichern, sondern auch die Spur der Experimente, damit sichtbar bleibt, wie viele Varianten vor der schönen Kurve ausprobiert wurden.

Execution engine

Die Execution Engine ist die Schicht, die Handelsabsicht in reale Orders verwandelt. Sie arbeitet in einer deutlich schmutzigeren Welt als die Strategy Engine: Latenzen, wiederholte Anfragen, Teilausführungen, Stornos, Rejects, Rate Limits, Positionsdesynchronisation, verschiedene Ordertypen und verschiedene Zustände derselben Order auf Börsenseite.

Eine minimale Execution Engine muss den Order-Lebenszyklus führen können: created, submitted, acknowledged, partially filled, filled, cancelled, rejected, expired. Sie braucht Idempotenz: Eine wiederholte Anfrage nach einem Timeout darf nicht versehentlich eine doppelte Position eröffnen. Sie braucht Reconciliation: Wenn das System glaubt, eine Order sei storniert, die Börse aber einen Fill zeigt, muss die externe Quelle der Wahrheit Vorrang haben.

Für institutionelle Märkte ist FIX häufig die Standardgrenze. FIX Trading Community beschreibt das FIX Protocol als globalen offenen Standard für den Austausch von Handelsinformationen: Orders, Ausführungen und Marktdaten, unabhängig von einem konkreten Transport. 3 In der Krypto-Infrastruktur sind REST- und WebSocket-APIs einzelner Venues häufiger, aber die technische Aufgabe ist dieselbe: das interne Ordermodell vom externen Protokoll trennen.

Eine gute Praxis ist, Execution über Adapter zu bauen. Innerhalb des Systems gibt es ein einheitliches OrderIntent, OrderState, Fill und Position. Außerhalb gibt es Binance, Coinbase, ein Broker-FIX-Gateway oder eine Sandbox. Dann müssen Strategie und Risikoschicht nicht für jedes Venue umgeschrieben werden, und Venue-spezifische Unterschiede bleiben im Execution Adapter.

Börsen-APIs als externe Grenze

Eine Börsen-API ist nicht nur Transport. Sie ist die externe Grenze des Systems, an der authentication, rate limits, Grenzen für WebSocket-Subscriptions, Heartbeat-Regeln, Latenzen, Wartungsfenster, unterschiedliche Fehlerformate und plötzliche Verhaltensänderungen auftreten.

Die Binance-Dokumentation trennt zum Beispiel REST market data endpoints und WebSocket streams, nennt Limits für eingehende Nachrichten, ping/pong-Logik und das Verfahren zur Wiederherstellung eines lokalen Orderbuchs. 4 Coinbase beschreibt separat production und sandbox endpoints, Subscription-Kanäle, heartbeat, sequence numbers und die Notwendigkeit, gaps zu behandeln. 6 Diese Details beeinflussen die Architektur direkt: Ingestion muss sich erholen können, Execution muss reject und timeout unterscheiden, und Monitoring muss den Verlust eines heartbeat sehen, bevor die Strategie Entscheidungen auf veralteten Daten trifft.

Fragmentierung ist in Krypto besonders sichtbar. Dasselbe Paar kann auf verschiedenen Venues unterschiedliche Gebühren, Tiefe, tick size, min order size, Aktualisierungsgeschwindigkeit und Handelsunterbrechungen haben. Deshalb sollte die API-Schicht nicht in die Strategie lecken. Die Strategie kann wissen, dass sie mit einem Instrument und verfügbarer Liquidität arbeitet; konkrete LOT_SIZE-Regeln, Request-Signaturen oder das Format einer cancel response gehören nach unten.

Risk management als durchgehender Kontrollkreis

Risk Management darf nicht das letzte Modul am Ende der Pipeline sein. In einem Handelssystem muss Risiko ein durchgehender Kontrollkreis sein: vor dem Trade, während der Ausführung, nach dem Trade und auf Ebene des gesamten Systems.

Pre-trade risk checks beantworten Fragen wie: Überschreitet die Order das Größenlimit, verletzt sie max position, reichen Balance oder Margin, ist das tägliche Verlustlimit erreicht, ist das Instrument deaktiviert, sind die Daten veraltet, ist die Verbindung zur Börse verloren? Post-trade checks prüfen tatsächliche Position, PnL, Gebühren, Exposure, Konzentration und Abweichung vom erwarteten Zustand.

Regulatorische Praxis hat solche Anforderungen längst formalisiert. ESMA fordert in ihren Guidelines zu automated trading von Investment Firms wirksame Systeme und Kontrollen, darunter pre-trade und post-trade controls, Algorithmustests, Zugriffsverwaltung und Verfahren für Störungen. 1 SEC Rule 15c3-5 verlangt von Broker-Dealers mit market access ein System von Risk Controls und Supervisory Procedures, um finanzielle und regulatorische Risiken des market access zu begrenzen. 2

Für eine Anwendung wie ai-trader liegt der praktische Schluss nicht darin, ein Regulierungsdokument nachzuahmen, sondern die Risikoschicht zu einem obligatorischen Teil des Orderpfads zu machen: Ein Signal wird erst zur Order, wenn es die Limits passiert hat, und eine Drawdown-Überschreitung, Positionsabweichung oder der Verlust von Market Data muss den Handel ohne menschliches Eingreifen stoppen können.

Logging

Logging in einem Handelssystem ist kein Strom von Meldungen nach dem Motto "etwas ist passiert". Es ist ein Audit Trail, mit dem sich rekonstruieren lässt, warum das System eine Entscheidung getroffen hat, welchen Input es gesehen hat, welchen Risk Check die Order bestanden hat, was an die Börse gesendet wurde und welche Antwort zurückkam.

Logs sollten Ereignisse über durchgehende Kennungen verbinden: signal id, decision id, order id, exchange order id, fill id, strategy version, data version. Ohne diese Verbindung wird die Untersuchung zur manuellen Suche nach Zeitpunkten, und Zeit ist in Handelssystemen oft nicht perfekt: Verschiedene Services können unterschiedliche clocks haben, und Ereignisse können in einer anderen Reihenfolge eintreffen, als sie erzeugt wurden.

Wichtig ist, nicht nur Fehler zu loggen. Erfolgreiche Entscheidungen werden ebenfalls gebraucht: warum die Strategie nicht eingestiegen ist, warum die Risikoschicht eine Order abgelehnt hat, warum Execution eine Limit Order statt einer Market Order gewählt hat, warum die Position reduziert wurde. Das Ausbleiben eines Trades ist manchmal wichtiger als der Trade selbst, besonders beim Vergleich von Live-Ergebnis und Backtest.

Gleichzeitig darf Logging nicht zu einer neuen Risikoquelle werden. API-Secrets, private Schlüssel und vollständige authentication payloads gehören nicht in Logs. Für Production braucht es Log-Level, Maskierung sensibler Felder, separate Speicherung von Audit-Ereignissen und eine klare Retention Policy.

Monitoring

Monitoring beantwortet nicht die Frage "was ist in den Logs passiert", sondern "arbeitet das System gerade in einem zulässigen Zustand". Das ist der Unterschied zwischen historischer Untersuchung und operativer Steuerung.

In der SRE-Praxis wird Monitoring um Symptome herum gebaut, die der Nutzer oder das System sieht, nicht nur um interne Ursachen; das Google SRE Book betont gesondert Metriken, Alerts und Signale, die den tatsächlichen Zustand eines Services widerspiegeln. 8 Für ein Handelssystem sind solche Symptome freshness market data, latency ingestion-to-signal, latency signal-to-order, Reject-Quote, Abweichung zwischen lokaler und börsenseitiger Position, Reconciliation-Fehler, stale orders, heartbeat, drawdown, exposure und live-vs-backtest drift.

Schlechtes Monitoring meldet "die API hat einen Fehler zurückgegeben". Gutes Monitoring meldet "die Strategie trifft weiter Entscheidungen, aber Market Data für dieses Instrument wurden seit 40 Sekunden nicht aktualisiert" oder "die lokale Position unterscheidet sich nach dem letzten Fill von der Börsenposition". Das erste ist nur ein Ereignis. Das zweite ist ein Zustand, in dem das System degradieren, stoppen oder in safe mode wechseln sollte.

Besonders wichtig sind Alerts auf Stille. Wenn ein Service laut ausfällt, ist er leichter zu bemerken. Wenn ein WebSocket keine Updates mehr sendet, der Prozess aber lebt und die Strategie weiter alten State liest, sieht der Fehler wie normaler Betrieb aus. Monitoring muss deshalb nicht nur exceptions beobachten, sondern auch Datenfrische, Ereignisrate und Zustandsinvarianten.

Paper trading und production: ein Codepfad, unterschiedliche Konturen

Paper Trading ist nur dann nützlich, wenn es denselben Pfad prüft, der später in Production läuft. Wenn die Paper-Umgebung eine separate vereinfachte Implementierung ist, in der Orders sofort zum letzten Preis "ausgeführt" werden, prüft sie eher das Interface als das Handelssystem.

Sinnvoller ist ein einziger Signalpfad: data ingestion, strategy engine, risk checks, order intent, execution adapter, order state, fills, positions, logs, monitoring. Der Unterschied zwischen Paper und Production sollte im Execution Adapter und in der Quelle der Bestätigungen liegen. Im Paper Adapter wird der Fill nach einem definierten Modell simuliert. Im Production Adapter kommt der Fill von Börse oder Broker. Der Rest des Systems sollte dieselben Ereignistypen sehen.

Dieser Ansatz ermöglicht staged rollout. Zuerst durchläuft die Strategie historical backtest. Danach prüft Paper Trading auf live data Datenfrische, Ereignisreihenfolge, Risikolimits und operational behavior. Anschließend lassen sich minimale Positionsgröße, begrenztes Universe, strengere Limits und verstärktes Monitoring einschalten. Production Trading ist kein großer Schalter, sondern ein schrittweises Entfernen von Begrenzungen, während das System zeigt, dass sein Live-Verhalten dem erwarteten Verhalten ähnelt.

Auch dann ist Paper Trading kein Nachweis von Profitabilität. Es reproduziert nicht die vollständige Orderwarteschlange, market impact und Liquiditätsstress. Seine Aufgabe ist bescheidener und nützlicher: zu prüfen, dass der Handelskreislauf nicht von der Realität abweicht, bevor ein Fehler Geld kostet.

Fazit

Die Architektur eines algorithmischen Handelssystems beginnt nicht mit der Wahl eines Frameworks und nicht mit dem Signalmodell. Sie beginnt mit der Frage: Kann dieselbe Logik den Weg von Daten zur Order gehen, ohne ihre Bedeutung zu verändern?

Data ingestion sorgt dafür, dass der Markt ehrlich dargestellt wird. Speicherung sorgt für Reproduzierbarkeit. Die Strategy Engine trennt Idee und Ausführung. Die Backtesting Engine prüft die Hypothese unter realen Einschränkungen. Die Execution Engine führt den Order-Lebenszyklus. Exchange Adapters isolieren das Chaos externer APIs. Risk Management begrenzt Schaden, bevor er irreversibel wird. Logging gibt dem System Gedächtnis, Monitoring operatives Sehvermögen. Paper Trading verbindet Research und Production ohne blinden Sprung.

Ein starkes System muss nicht komplex sein. Aber es braucht klare Grenzen, überprüfbare Invarianten und einen einzigen Entscheidungsweg. Sonst kann eine Strategie im Research funktional aussehen, während sie in Wirklichkeit nicht den Markt handelt, sondern eine Sammlung architektonischer Annahmen.