Shadow-Deployment von Trading-Modellen live mitlaufen lassen, ohne Geld zu riskieren.

Ein Backtest, so sauber er auch gebaut ist, sieht eine Sache nie: die echte Welt. Reale Latenz, tatsächliche Slippage, verzögerte oder lückenhafte Datenfeeds, das Verhalten der Ausführung unter realen Marktbedingungen — all das bleibt im Backtest eine Annahme. Shadow-Deployment schließt genau diese Lücke. Ein neues Modell läuft dabei parallel zur Produktion live mit, trifft echte Entscheidungen auf echten Daten in Echtzeit, schickt aber keine realen Orders. Stattdessen werden seine Entscheidungen protokolliert und mit dem verglichen, was im Backtest erwartet wurde und was das produktive System tut. So testet man ein Modell unter den Bedingungen, die wirklich zählen — bevor auch nur ein Euro bewegt wird. Dieser Beitrag erklärt, wie Shadow-Mode technisch funktioniert, welche Diskrepanzen er aufdeckt, wie man die Ergebnisse richtig interpretiert, wo seine Grenzen liegen und wie er sich in einen sauberen Deployment-Prozess einfügt.

Was Shadow-Deployment vom Backtest unterscheidet.

Ein Backtest spielt ein Modell gegen historische Daten und simuliert, wie es gehandelt hätte. Das ist unverzichtbar, hat aber eine grundsätzliche Schwäche: Jede Annahme über Ausführung, Latenz und Datenverfügbarkeit ist eben nur eine Annahme. Der Backtest weiß nicht, wie lange der Datenfeed wirklich braucht, wie viel Slippage real entsteht oder wie sich das System bei einer Datenlücke verhält.

Shadow-Deployment ersetzt diese Annahmen durch Beobachtung. Das neue Modell läuft im selben Live-System wie die Produktion, bekommt dieselben Echtzeit-Datenfeeds, trifft seine Entscheidungen unter realer Latenz — aber seine Orders werden nicht an den Markt geschickt, sondern nur aufgezeichnet. Man sieht also, was das Modell live getan hätte, ohne das Risiko, es tatsächlich tun zu lassen.

Der entscheidende Unterschied: Im Shadow-Mode treffen echte Marktbedingungen auf das Modell. Wenn der Datenfeed ruckelt, ruckelt er auch für das Schattenmodell. Wenn eine Berechnung unter Last langsamer wird, merkt man es. Genau diese Reibung der Realität bleibt im Backtest unsichtbar — und ist oft die Stelle, an der vielversprechende Modelle scheitern.

Welche Diskrepanzen der Schatten aufdeckt.

Der Wert des Shadow-Modes liegt in den Abweichungen, die er sichtbar macht. Sie fallen typischerweise in einige wiederkehrende Kategorien:

Besonders aufschlussreich ist der Vergleich zwischen den Schatten-Entscheidungen und dem, was der Backtest vorhergesagt hatte. Stimmen sie nicht überein, gibt es ein Problem in der Pipeline — oft einen Training-Serving-Skew oder eine Datenlatenz, die im Backtest ignoriert wurde. Solche Befunde sind unbezahlbar, weil sie genau die Fehler aufdecken, die sonst erst mit echtem Geld sichtbar geworden wären.

Wie man Shadow-Mode technisch aufsetzt.

Technisch braucht Shadow-Deployment, dass das neue Modell denselben Datenstrom und dieselbe Infrastruktur nutzt wie die Produktion, seine Order-Entscheidungen aber an einer klar definierten Stelle abgefangen und nur protokolliert werden, statt an den Broker zu gehen. Die Aufzeichnung muss vollständig sein: jede Entscheidung mit Zeitstempel, den zugrunde liegenden Feature-Werten und dem hypothetischen Order-Detail.

Wichtig ist, dass der Schatten möglichst nah an der echten Ausführung sitzt — idealerweise so, dass er dieselbe Latenz und dieselben Datenfeeds erlebt wie die Produktion. Ein Schatten, der in einer separaten, idealisierten Umgebung läuft, verliert seinen Sinn, weil er dann wieder nur eine Simulation ist. Der ganze Punkt ist die Konfrontation mit der echten Reibung.

Für die Auswertung braucht es eine saubere Protokollierung und einen systematischen Vergleich: Schatten gegen Backtest-Erwartung und Schatten gegen Produktion. Erst dieser Abgleich macht aus den Rohdaten Erkenntnis. Ohne strukturierte Auswertung sammelt man nur Logs, ohne zu lernen — der Aufbau der Vergleichslogik gehört deshalb von Anfang an dazu.

Wie lange ein Schattenlauf dauern sollte.

Eine häufige Frage ist, wie lange man ein Modell im Schatten laufen lassen sollte, bevor man ihm echtes Kapital anvertraut. Eine pauschale Antwort gibt es nicht — sie hängt von der Handelsfrequenz und der Vielfalt der Marktbedingungen ab.

Die Logik ist: Der Schattenlauf sollte genug Entscheidungen und genug unterschiedliche Marktsituationen umfassen, um aussagekräftig zu sein. Ein hochfrequentes Modell sammelt in Tagen tausende Entscheidungen und kann entsprechend kürzer im Schatten bleiben. Ein Modell, das nur wenige Trades pro Woche macht, braucht deutlich länger, um eine belastbare Stichprobe zu erzeugen — oft mehrere Wochen bis Monate, damit auch ruhige und turbulente Phasen vorkommen.

Wichtig ist, nicht nur auf die Zahl der Entscheidungen zu schauen, sondern auf die Bandbreite der Bedingungen. Ein Schattenlauf, der nur eine ruhige Marktphase gesehen hat, sagt wenig über das Verhalten in Stress-Situationen aus. Wer ein Modell nach zwei ereignislosen Wochen freigibt, hat es nicht wirklich getestet — die entscheidenden Momente kamen schlicht nicht vor. Geduld an dieser Stelle ist günstiger als ein vorschneller Livegang.

Die Grenzen des Schattens.

Shadow-Deployment ist mächtig, aber kein perfekter Spiegel der Live-Realität. Seine wichtigste Grenze ist der Market Impact: Da der Schatten keine echten Orders schickt, beeinflusst er den Markt nicht. Ein Modell, das große Positionen bewegt, würde live durch die eigene Order den Preis verschieben — der Schatten sieht diesen Effekt nicht. Gerade bei größeren Volumina oder illiquiden Instrumenten bleibt hier eine Unsicherheit, die erst der echte Handel auflöst.

Zweitens testet der Schatten die Ausführung nur teilweise. Er sieht die Marktdaten und die hypothetische Order, aber nicht das tatsächliche Fill — ob die Order zum erwarteten Preis und Volumen ausgeführt worden wäre, bleibt eine Annäherung. Slippage lässt sich abschätzen, aber nicht endgültig messen, solange keine echte Order fließt.

Drittens deckt der Schatten nur auf, was während seiner Laufzeit vorkommt. Ein seltenes Marktereignis, das in der Schattenphase nicht auftrat, bleibt ungetestet. Deshalb ersetzt Shadow-Mode weder sorgfältiges Risikomanagement noch eine vorsichtige, schrittweise Skalierung beim echten Livegang. Er reduziert das Risiko erheblich — beseitigt es aber nicht.

Shadow-Mode im Deployment-Prozess.

Shadow-Deployment entfaltet seinen Wert am besten als fester Bestandteil eines gestuften Deployment-Prozesses, nicht als einmalige Aktion. Eine bewährte Abfolge:

• Backtest: leakage-frei und mit realistischen Annahmen — die erste Hürde.
• Shadow-Phase: live mitlaufen, ohne Orders, bis genug Entscheidungen und Marktbedingungen gesammelt sind.
• Kleine Live-Allokation: echtes, aber begrenztes Kapital, um Market Impact und echte Fills zu sehen.
• Schrittweise Skalierung: Erhöhung nur, wenn die Live-Ergebnisse den Erwartungen entsprechen.

Diese Stufung passt eng mit einer Model-Registry und sauberem Staging zusammen — der Shadow-Mode ist die Brücke zwischen „im Backtest gut“ und „verdient echtes Vertrauen“. Wer diese Brücke überspringt und direkt vom Backtest zum vollen Live-Kapital geht, verzichtet auf die günstigste Gelegenheit, teure Fehler zu finden. Der Schatten kostet etwas Zeit und Infrastruktur, aber er kostet nie echtes Geld — und genau das macht ihn zu einem der besten Werkzeuge, um ein Trading-Modell verantwortungsvoll in den Live-Betrieb zu bringen.

Sie wollen ein neues Trading-Modell unter echten Marktbedingungen prüfen, bevor Sie ihm echtes Kapital anvertrauen? Unverbindlich anfragen — wir richten gemeinsam ein Shadow-Deployment ein, das Latenz, Slippage und Datenfeeds real testet und sich sauber in einen gestuften Livegang einfügt.