ARTIKEL 25
Von QuantConnect-Backtests zum Live-Trading
SEO-Titel: QuantConnect Live-Trading – vom Backtest zum realen Handel
Meta-Description: Wie führt der Weg vom QuantConnect-Backtest ins Live-Trading? Broker, Datenprovider, Orders, Paper Trading, Risiko, Execution und Monitoring erklärt.
URL-Slug: /blog/quantconnect-live-trading/
Haupt-Suchbegriff: QuantConnect Live Trading
Weitere Suchbegriffe: QuantConnect Broker, LEAN Live Trading, QuantConnect Interactive Brokers, Algorithmus live handeln
Vom historischen Modell zum realen Handel
Ein erfolgreicher QuantConnect-Backtest ist noch kein Live-Handelssystem.
Zwischen historischer Simulation und realem Handel liegen mehrere zusätzliche Ebenen:
Live-Daten
→ Brokerage
→ Orderübermittlung
→ reale Fills
→ Risiko
→ Monitoring
QuantConnect versucht, Backtesting und Live-Trading durch die gemeinsame LEAN Engine möglichst konsistent zu gestalten. Dennoch unterscheiden sich Simulation und tatsächliche Marktausführung zwangsläufig.
Was bleibt gleich?
Ein wesentlicher Vorteil von LEAN besteht darin, dass dieselbe grundlegende Algorithmusarchitektur für Backtest und Live-Betrieb genutzt werden kann.
Das reduziert die Gefahr, eine Strategie für den Live-Einsatz komplett neu schreiben zu müssen.
Gleich bleiben beispielsweise grundsätzlich:
- Signalberechnung,
- Portfolio-Logik,
- Risikomodell,
- wesentliche Algorithmusstruktur.
Was verändert sich?
Im Backtest wird die Vergangenheit simuliert.
Im Live-Trading interagiert der Algorithmus mit realen externen Systemen.
Dazu gehören:
- Live-Datenprovider,
- Brokerage-API,
- Börsen,
- reale Kontostände,
- reale Orders.
Damit entstehen technische und marktbedingte Unsicherheiten.
1. Datenprovider
Ein Live-Algorithmus benötigt aktuelle Marktdaten.
Je nach Konfiguration können Daten von verschiedenen Providern stammen.
QuantConnect unterstützt auch Konfigurationen mit mehreren Datenprovidern und definierten Prioritäten.
Der Entwickler muss verstehen:
- welche Datenquelle genutzt wird,
- welche Auflösung verfügbar ist,
- welche Verzögerungen bestehen,
- welche Märkte unterstützt werden.
Historische Daten im Live-Modus
Auch ein laufender Algorithmus kann historische Daten benötigen.
Beispielsweise für:
- Indikatoraufbau,
- Rolling Windows,
- Modelle,
- historische Statistiken.
Allerdings können History Requests im Live-Betrieb andere Laufzeiteigenschaften besitzen als im Backtest.
QuantConnect weist beispielsweise darauf hin, dass solche Requests während des Live-Betriebs Zeit benötigen können und während ihrer Verarbeitung der Algorithmus nicht einfach wie ein historischer Batch-Prozess betrachtet werden sollte.
2. Brokerage-Verbindung
Die Brokerage stellt die Verbindung zum tatsächlichen Markt her.
LEAN validiert Orders entsprechend dem gewählten Brokerage-Modell, bevor sie an die reale Brokerage weitergereicht werden.
Damit spielen Brokerage-spezifische Regeln eine wichtige Rolle.
Brokerage-Modell bereits im Backtest verwenden
Eine sinnvolle Vorbereitung besteht darin, schon während des Backtests das geplante Brokerage-Modell zu berücksichtigen.
Dadurch können Annahmen beispielsweise zu:
- Ordertypen,
- Margin,
- Gebühren
realitätsnäher werden.
Der Backtest bleibt dennoch nur eine Simulation.
3. Live-Orders sind asynchron
Das ist einer der wichtigsten Unterschiede.
Im Backtest simuliert LEAN die Orderausführung.
Im Live-Betrieb wird eine Order an die Brokerage geschickt.
LEAN wartet anschließend auf die Rückmeldung zum Orderstatus.
Live-Fills erfolgen daher asynchron.
Warum asynchrone Ausführung wichtig ist
Angenommen, ein Algorithmus sendet eine Order über 1.000 Aktien.
Mögliche Realität:
- 300 Stück ausgeführt,
- 700 Stück noch offen.
Der Algorithmus darf nicht einfach annehmen, dass sofort die komplette Zielposition besteht.
Er muss mit tatsächlichen Orderzuständen umgehen können.
4. Tatsächlicher Fill-Preis
Im Backtest bestimmt das Fill Model, welcher Ausführungspreis angenommen wird.
Im Live-Handel wird der tatsächliche Fill von der Brokerage und dem Markt bestimmt.
Dadurch können Differenzen entstehen bei:
- Preis,
- Gebühren,
- Ausführungszeit,
- Teilfills.
5. Slippage wird real
Im Backtest ist Slippage ein Modell.
Live ist sie ein beobachtbares Ergebnis.
Dadurch kann geprüft werden:
Waren meine historischen Annahmen realistisch?
Eine Strategie sollte die realen Ausführungskosten laufend mit den Backtestannahmen vergleichen.
6. Paper Trading
Vor realem Kapitaleinsatz ist ein Paper- beziehungsweise Simulationsbetrieb sinnvoll.
Ziel ist dabei weniger die erneute Überprüfung der historischen Hypothese.
Vielmehr wird die technische Umgebung getestet.
Beispielsweise:
- treffen Daten korrekt ein?
- werden Signale zur richtigen Zeit erzeugt?
- funktionieren Orders?
- stimmen Zeitzonen?
- funktionieren Risikoregeln?
Paper Trading hat Grenzen
Paper Trading repliziert reale Marktbedingungen nicht perfekt.
Insbesondere können Unterschiede bestehen bei:
- Fill-Wahrscheinlichkeit,
- Slippage,
- Market Impact,
- Liquidität.
Deshalb sollte ein erfolgreicher Paper-Test nicht mit echtem Live-Trading gleichgesetzt werden.
7. Kleiner realer Start
Nach erfolgreichem Paper Trading kann ein bewusst kleiner Live-Start sinnvoll sein.
Dabei geht es nicht primär darum, maximale Rendite zu erzielen.
Es geht darum, echte Systemdaten zu sammeln.
Dazu gehören:
- reale Gebühren,
- reale Slippage,
- Fills,
- Brokerverhalten,
- Systemstabilität.
8. Portfoliozustand
Im Live-Betrieb verwendet LEAN reale Informationen über das Brokerage-Konto.
Der Portfoliozustand und offene Positionen müssen mit dem tatsächlichen Konto übereinstimmen.
Das macht Reconciliation besonders wichtig.
Reconciliation
Reconciliation bedeutet:
Stimmen die internen Systempositionen mit den tatsächlichen Brokerpositionen überein?
Beispiel:
Algorithmus:
100 Aktien
Broker:
95 Aktien
Diese Differenz muss erkannt und untersucht werden.
9. Risk Management
Vor Live-Deployment sollten Risikolimits fest definiert werden.
Beispiele:
- maximale Positionsgröße,
- maximale Hebelwirkung,
- maximales Tagesrisiko,
- Drawdown-Grenzen,
- Asset-Exposure.
Im Framework kann ein separates Risk Management Model Zielpositionen anpassen, bevor sie zur Execution gelangen.
10. Technische Schutzmechanismen
Live-Trading benötigt zusätzliche Schutzebenen.
Beispiele:
- maximale Ordergröße,
- Plausibilitätsprüfung,
- Kill Switch,
- Fehlerlogging,
- Alerts.
Ein Signalfehler sollte nicht unkontrolliert tausende Orders erzeugen können.
11. Logging
Ein produktiver Algorithmus sollte dokumentieren:
- Signale,
- Orders,
- Fills,
- Fehler,
- Risikoeingriffe,
- Systemzustände.
Damit kann später beantwortet werden:
Warum wurde diese Position aufgebaut?
12. Monitoring
Ein Live-System sollte überwacht werden auf:
Daten
Sind sie aktuell?
Orders
Wurden sie ausgeführt?
Positionen
Stimmen sie mit dem Broker überein?
Risiko
Werden Limits eingehalten?
Performance
Entspricht die Entwicklung grundsätzlich der Modellbandbreite?
Technik
Laufen alle Prozesse?
13. Backtest gegen Live vergleichen
Nach dem Start sollten Live-Ergebnisse nicht nur als Gewinn oder Verlust beurteilt werden.
Interessanter sind Abweichungen.
Beispielsweise:
Backtest-Slippage: 5 Basispunkte
Live-Slippage: 14 Basispunkte
oder:
Backtest: durchschnittlich 20 Trades pro Monat
Live: 45 Trades
Solche Unterschiede können auf:
- andere Marktbedingungen,
- Datenabweichungen,
- Implementierungsprobleme
hinweisen.
14. LiveMode
LEAN kann zwischen Backtest- und Live-Umgebung unterscheiden.
QuantConnect dokumentiert dafür den Live-Mode-Status.
Dieser sollte jedoch sparsam eingesetzt werden.
Idealerweise bleibt möglichst viel Strategiecode zwischen Simulation und Live-System identisch.
15. Historische Performance ist keine Garantie
Auch ein technisch perfekter Übergang in den Live-Modus beseitigt kein Modellrisiko.
Eine Strategie kann:
- überangepasst sein,
- einen Regimewechsel erleben,
- ihre Risikoprämie verlieren.
Live-Trading validiert deshalb nicht nur Technik.
Es liefert neue Out-of-Sample-Informationen über das Modell selbst.
16. Wann darf ein Live-System verändert werden?
Nicht nach jedem Verlust.
Ein kontrollierter Prozess sollte unterscheiden zwischen:
technischem Fehler
und
normaler Modellvarianz
und
möglichem strukturellem Modellbruch.
Änderungen sollten dokumentiert, getestet und versioniert werden.
Versionskontrolle
Eine produktive Strategie sollte eindeutig einer Code- und Modellversion zugeordnet werden können.
Beispiel:
Version 1.0
erste Live-Version
Version 1.1
technischer Bugfix
Version 2.0
neue Alpha-Logik
Damit bleibt nachvollziehbar, welche Strategie tatsächlich welche Performance erzeugt hat.
Research-to-Live-Prozess mit QuantConnect
Ein vollständiger Prozess könnte folgendermaßen aussehen:
1. Hypothese
↓
2. Research
↓
3. QuantConnect-Backtest
↓
4. Out-of-Sample
↓
5. Walk-Forward
↓
6. Kosten- und Stress-Tests
↓
7. Paper Trading
↓
8. kleiner Live-Start
↓
9. Monitoring
↓
10. kontrollierte Skalierung
Dieser Prozess ist wesentlich aussagekräftiger als:
Backtest sieht gut aus → Live starten.
QuantConnect und Interactive Brokers
QuantConnect unterstützt Brokerage-Integrationen, über die LEAN mit realen Konten verbunden werden kann. Die konkrete Verfügbarkeit, unterstützten Assetklassen und Kontobedingungen sollten jeweils anhand der aktuellen QuantConnect- und Brokerdokumentation geprüft werden.
Für einen quantitativen Entwickler ist dabei besonders wichtig, Brokerage-spezifische Bedingungen bereits während der Systementwicklung zu berücksichtigen.
Skalierung
Eine Strategie, die mit kleinem Kapital funktioniert, muss nicht beliebig skalierbar sein.
Steigende Kapitalgröße kann erhöhen:
- Market Impact,
- Slippage,
- Ausführungsdauer.
Deshalb sollte die Kapazität einer Strategie schrittweise untersucht werden.
Wann sollte nicht live gegangen werden?
Ein Live-Deployment ist aus methodischer Sicht problematisch, wenn:
- Out-of-Sample fehlt,
- Kosten unrealistisch modelliert wurden,
- das System technisch nicht getestet wurde,
- Risikolimits fehlen,
- keine Monitoring-Struktur existiert,
- die Strategie nur an einem exakten Parameterpunkt funktioniert.
Ein guter Backtest allein reicht nicht.
Fazit
QuantConnect erleichtert technisch den Übergang vom Backtest zum Live-Trading, weil LEAN beide Umgebungen verbindet.
Doch der eigentliche Übergang bleibt anspruchsvoll.
Neu hinzu kommen:
reale Daten + reale Broker + reale Fills + reale Kosten + reale technische Fehler
Ein professioneller Research-to-Live-Prozess sollte deshalb schrittweise erfolgen:
Backtest → Validierung → Paper → kleiner Live-Betrieb → Monitoring → Skalierung
Der wichtigste Grundsatz lautet:
Ein Live-System sollte nicht nur profitabel sein können. Es muss kontrollierbar sein.
Weiterführende Quellen
- QuantConnect Documentation: Live Trading
- QuantConnect Documentation: Brokerages
- QuantConnect Documentation: Trading and Orders
- QuantConnect Documentation: Historical Data in Live Trading
- QuantConnect Documentation: Algorithm Framework Risk Management
Passendes Fachbuch
Handelssysteme in QuantConnect von Olaf Sund.
Ergänzende Fachbücher
- Von der Idee zum Tradingsystem
- Handelssysteme
- Quantitative Finanzen, Trading, Analyse und Engineering
Weiterführende Beiträge auf quantitativefinanzen.de
- QuantConnect auf Deutsch
- QuantConnect mit Python
- Backtesting mit QuantConnect
- QuantConnect Algorithm Framework
- Vom Backtest zum Live-Trading
- Monitoring von Handelssystemen