ARTIKEL 20
Monitoring von Handelssystemen: Was im Live-Betrieb überwacht werden muss
SEO-Titel: Monitoring von Handelssystemen im Live-Trading
Meta-Description: Welche Kennzahlen müssen automatische Handelssysteme überwachen? Datenfeeds, Orders, Positionen, Risiko, Performance, Infrastruktur und Modellabweichungen.
URL-Slug: /blog/handelssystem-monitoring/
Haupt-Suchbegriff: Handelssystem Monitoring
Weitere Suchbegriffe: Trading System Monitoring, algorithmisches Trading überwachen, Live Trading Monitoring, Quant Trading Infrastruktur
Warum Monitoring unverzichtbar ist
Mit dem Start des Live-Tradings endet die Arbeit an einem Handelssystem nicht.
Sie verändert sich.
Während Research und Backtesting fragen:
Sollte dieses Modell grundsätzlich funktionieren?
fragt Monitoring:
Funktioniert das System jetzt gerade so, wie es funktionieren soll?
Das betrifft mehrere Ebenen gleichzeitig:
Daten → Modell → Risiko → Orders → Broker → Infrastruktur → Performance
Ein Problem auf nur einer dieser Ebenen kann ausreichen, um ein ansonsten gutes Handelssystem zu gefährden.
Monitoring ist mehr als Performancekontrolle
Ein System sollte nicht ausschließlich danach überwacht werden, ob es gerade Gewinne oder Verluste produziert.
Eine profitable Strategie kann technisch defekt sein.
Eine korrekt funktionierende Strategie kann vorübergehend Verluste erzeugen.
Deshalb muss zwischen mindestens drei Kategorien unterschieden werden:
1. technische Systemgesundheit
2. Handels- und Risikozustand
3. Modell- und Performanceverhalten
1. Datenmonitoring
Ohne korrekte Daten können Signale nicht zuverlässig berechnet werden.
Überwacht werden sollten beispielsweise:
- Datenfeed aktiv?
- letzter Zeitstempel aktuell?
- fehlende Bars?
- ungewöhnliche Preissprünge?
- doppelte Datensätze?
- falsche Zeitzone?
Stale Data
Besonders gefährlich sind veraltete Daten.
Angenommen, ein Datenfeed stoppt um 14:30 Uhr.
Der Algorithmus läuft weiter und interpretiert den letzten bekannten Preis als aktuellen Preis.
Das kann falsche Entscheidungen erzeugen.
Eine einfache Kontrolle lautet:
Wie alt ist die letzte Beobachtung?
Überschreitet sie einen definierten Grenzwert, sollte das System warnen oder Trading blockieren.
Preisplausibilität
Daten können technisch ankommen und trotzdem falsch sein.
Beispielsweise:
Aktie gestern:
100
aktueller Feed:
1.000
Das kann real sein.
Es kann aber auch ein Datenfehler sein.
Plausibilitätsprüfungen können ungewöhnliche Sprünge markieren und gegebenenfalls neue Orders verhindern.
2. Prozessmonitoring
Automatisierte Systeme bestehen aus mehreren Prozessen.
Beispielsweise:
- Datenimport,
- Signalberechnung,
- Portfoliooptimierung,
- Ordererzeugung,
- Reporting.
Für jeden Prozess sollte bekannt sein:
- läuft er?
- wann lief er zuletzt?
- war er erfolgreich?
- wie lange dauerte er?
Heartbeats
Ein sogenannter Heartbeat zeigt regelmäßig:
Der Prozess lebt und arbeitet.
Bleibt der Heartbeat aus, kann automatisch ein Alarm ausgelöst werden.
Das ist besonders wichtig bei Systemen, die über Stunden oder Tage unbeaufsichtigt laufen.
3. Signalmonitoring
Auch die Signalerzeugung sollte überwacht werden.
Fragen:
- Wie viele Signale wurden erzeugt?
- Entspricht die Zahl ungefähr der Erwartung?
- Gibt es plötzlich gar keine Signale?
- Sind alle Signale identisch?
- Existieren extreme Signalwerte?
Ein Modell, das normalerweise 20 Positionen erzeugt und plötzlich 2.000 Kauforders signalisiert, benötigt Aufmerksamkeit.
Signal Drift
Die statistische Verteilung von Signalen kann sich verändern.
Beispielsweise:
historisch:
durchschnittliches Signal nahe 0
live:
alle Signale extrem positiv
Das kann auf veränderte Märkte hindeuten.
Es kann aber auch durch fehlerhafte Daten oder eine fehlerhafte Modellversion verursacht werden.
4. Positionsmonitoring
Das interne System sollte jederzeit wissen:
- welche Positionen vorhanden sind,
- welche Positionen geplant sind,
- welche Positionen beim Broker tatsächlich existieren.
Diese drei Zustände müssen regelmäßig verglichen werden.
Reconciliation
Reconciliation bezeichnet den Abgleich zwischen internem System und externem Brokerzustand.
Beispiel:
System:
AAPL +100
Broker:
AAPL +95
Diese Differenz darf nicht unbemerkt bleiben.
Mögliche Ursachen:
- Teilausführung,
- abgelehnte Order,
- manueller Trade,
- technischer Fehler.
5. Ordermonitoring
Für jede Order sollten Status und Lebenszyklus nachvollziehbar sein.
Mögliche Zustände:
- erstellt,
- gesendet,
- akzeptiert,
- teilweise ausgeführt,
- vollständig ausgeführt,
- storniert,
- abgelehnt.
Orders, die ungewöhnlich lange offen bleiben, sollten erkannt werden.
Ungewöhnliche Orderfrequenz
Ein Programmierfehler kann dazu führen, dass dieselbe Order immer wieder erzeugt wird.
Deshalb können Grenzwerte sinnvoll sein:
- maximale Orders pro Minute,
- maximale Orders pro Tag,
- maximale Positionsänderung.
Eine Überschreitung kann einen Alarm oder Kill Switch auslösen.
6. Execution-Monitoring
Ein Backtest modelliert Ausführungsqualität.
Der Live-Betrieb liefert reale Messwerte.
Überwacht werden können:
- Slippage,
- Spread,
- Fill Rate,
- Fill-Zeit,
- abgelehnte Orders,
- Teilausführungen.
Diese Daten zeigen, ob die ursprünglichen Backtestannahmen realistisch waren.
Erwartete versus tatsächliche Slippage
Beispiel:
Backtestannahme:
5 Basispunkte
Live:
durchschnittlich 18 Basispunkte
Dann ist die tatsächliche Strategieökonomie schlechter als modelliert.
Das muss nicht zwingend zur sofortigen Abschaltung führen.
Es erfordert aber Analyse.
7. Risikomonitoring
Risikolimits sollten möglichst in Echtzeit oder in angemessenen Intervallen geprüft werden.
Dazu können gehören:
- Gross Exposure,
- Net Exposure,
- Leverage,
- Positionsgrößen,
- Sektor-Exposure,
- Länder-Exposure,
- Faktor-Exposure,
- Volatilität,
- Drawdown.
Risikolimit versus Warnschwelle
Es kann sinnvoll sein, zwei Ebenen einzurichten.
Beispiel:
Warnschwelle: 8 % Drawdown
harte Grenze: 12 %
Bei der Warnschwelle erfolgt eine Meldung.
Bei der harten Grenze kann das System automatisch Risiko reduzieren oder den Handel stoppen.
8. P&L-Monitoring
Performance sollte auf mehreren Ebenen überwacht werden:
- Gesamtportfolio,
- Strategie,
- Asset,
- Trade.
Dabei sollte zwischen realisierten und unrealisierten Ergebnissen unterschieden werden.
Außerdem sollte der P&L mit Brokerdaten abgeglichen werden.
9. Drawdown-Monitoring
Ein Drawdown sollte nicht nur als aktuelle Zahl betrachtet werden.
Interessant sind:
- Höhe,
- Dauer,
- Geschwindigkeit,
- historische Einordnung.
Ein moderater Drawdown über zwei Jahre kann operativ genauso problematisch sein wie ein schneller größerer Verlust.
10. Modellmonitoring
Eine Strategie kann technisch perfekt funktionieren und dennoch ihre ökonomische Wirkung verlieren.
Deshalb sollte untersucht werden:
- verändert sich die Signalqualität?
- sinkt die Trefferquote?
- steigt die Korrelation zu anderen Strategien?
- verändern sich Kosten?
- verändert sich die Verteilung der Features?
Model Drift
Model Drift bezeichnet Veränderungen, durch die ein ursprünglich entwickeltes Modell seine Relevanz verliert.
Ursachen können sein:
- Marktstrukturänderungen,
- andere Marktteilnehmer,
- Regulierungsänderungen,
- technologische Veränderungen.
Ein schwacher Monat ist allerdings noch kein Beweis für Model Drift.
Es benötigt statistische und ökonomische Analyse.
11. Infrastrukturmonitoring
Auch technische Ressourcen sollten überwacht werden:
- CPU,
- RAM,
- Speicher,
- Netzwerk,
- API-Verbindungen,
- Datenbankstatus.
Ein volllaufender Datenträger kann ein Handelssystem genauso stoppen wie ein fehlerhaftes Modell.
12. Logging
Monitoring zeigt den aktuellen Zustand.
Logging dokumentiert die Vergangenheit.
Gespeichert werden sollten beispielsweise:
- Signale,
- Orders,
- Ausführungen,
- Fehler,
- Warnungen,
- Modellversionen,
- Konfigurationen.
Damit lässt sich später rekonstruieren:
Warum hat das System diesen Trade ausgeführt?
13. Alerts
Nicht jede Abweichung benötigt einen Alarm.
Zu viele Meldungen führen zu Alert Fatigue.
Dann werden wichtige Warnungen möglicherweise ignoriert.
Alerts sollten deshalb priorisiert werden.
Beispielsweise:
Info
ungewöhnlicher, aber ungefährlicher Zustand.
Warning
mögliche Beeinträchtigung.
Critical
sofortige Intervention erforderlich.
14. Dashboard
Ein Monitoring-Dashboard kann zentrale Informationen zusammenführen.
Mögliche Bereiche:
Systemstatus
- Datenfeed
- Broker
- Prozesse
Trading
- offene Orders
- Positionen
- letzte Trades
Risiko
- Exposure
- Drawdown
- Volatilität
Performance
- Tages-P&L
- Monats-P&L
- Strategieergebnis
15. Kill Switch
Für kritische Situationen sollte eine Möglichkeit existieren, den Handel sofort zu stoppen.
Automatische Trigger könnten sein:
- extreme Positionsabweichung,
- Datenfeedfehler,
- Überschreitung harter Risikolimits,
- ungewöhnlich hohe Orderfrequenz.
Ein Kill Switch sollte allerdings selbst getestet werden.
Ein Notfallsystem, dessen Funktion nie überprüft wurde, bietet nur scheinbare Sicherheit.
16. Runbooks
Für typische Probleme können konkrete Handlungsanweisungen erstellt werden.
Beispiel:
Brokerverbindung unterbrochen
- neue Orders stoppen,
- vorhandene Positionen abrufen,
- Verbindung prüfen,
- Brokerpositionen mit internem System abgleichen,
- erst danach Trading freigeben.
Solche Runbooks reduzieren improvisierte Entscheidungen unter Zeitdruck.
17. Performance Attribution
Monitoring sollte langfristig auch beantworten:
Woher kommt die Performance?
Mögliche Komponenten:
- Alpha-Signal,
- Markt-Exposure,
- Faktor-Exposure,
- Execution,
- Kosten.
Dadurch lässt sich unterscheiden, ob ein Modell tatsächlich wie vorgesehen arbeitet oder lediglich von einem unerwarteten Markt-Exposure profitiert.
Monitoring darf kein permanentes Optimieren werden
Ein wichtiger Unterschied:
Monitoring beobachtet.
Research verändert.
Ein Live-System sollte nicht bei jeder schwachen Woche spontan neu optimiert werden.
Änderungen gehören in einen kontrollierten Research-Prozess mit:
- Hypothese,
- Test,
- Dokumentation,
- neuer Modellversion.
Sonst entsteht Live-Overfitting.
Beispiel eines Monitoring-Prozesses
Intraday
- Datenfeed,
- Orders,
- Positionen,
- Risikolimits.
Täglich
- P&L,
- Slippage,
- Brokerabgleich,
- Fehlermeldungen.
Wöchentlich
- Strategieperformance,
- Signale,
- Exposure.
Monatlich
- Modellqualität,
- Kostenentwicklung,
- Drift,
- Research Review.
Die konkrete Frequenz hängt vom Zeithorizont der Strategie ab.
Ein Hochfrequenzsystem benötigt andere Kontrollen als eine monatlich rebalancierte Faktorstrategie.
Wann sollte eingegriffen werden?
Eine Intervention sollte möglichst auf vorher definierten Kriterien beruhen.
Beispiele:
technischer Eingriff
bei fehlerhaften Daten oder Brokerproblemen.
Risikoeingriff
bei Überschreitung harter Limits.
Research Review
bei längerfristiger statistisch ungewöhnlicher Modellabweichung.
Diese Kategorien sollten nicht vermischt werden.
Fazit
Monitoring ist die operative Kontrollschicht eines Handelssystems.
Es umfasst:
Daten → Prozesse → Signale → Positionen → Orders → Execution → Risiko → Performance → Infrastruktur
Ein professionelles System sollte jederzeit beantworten können:
- Was tut es?
- Warum tut es das?
- Welche Positionen hält es?
- Welches Risiko besteht?
- Funktioniert die Technik?
- Entspricht das Verhalten den Erwartungen?
Damit ist Monitoring keine Zusatzfunktion.
Es ist ein integraler Bestandteil jedes produktiven quantitativen Handelssystems.
Weiterführende Literatur
- Narang, R. K.: Inside the Black Box.
- Kissell, R.: The Science of Algorithmic Trading and Portfolio Management.
- Chan, E. P.: Algorithmic Trading.
- Hull, J. C.: Risk Management and Financial Institutions.
Passende Fachbücher von Olaf Sund
- Von der Idee zum Tradingsystem
- Handelssysteme
- Handelssysteme in QuantConnect
- Quantitative Finanzen, Trading, Analyse und Engineering
Weiterführende Beiträge auf quantitativefinanzen.de
- Vom Backtest zum Live-Trading
- Risikomanagement für Handelssysteme
- Quant Engineering
- QuantConnect Live Trading