Für wen dieser Artikel gedacht ist — Für alle, die eine Strategieversion festgelegt haben und sie mit erst nach dem Einfrieren eintreffenden Daten beobachten wollen, ohne Regeln, Stichprobe oder Kriterien nach dem Ergebnis umzuschreiben.
Der Forward-Test ist die prospektive Bewertung einer eingefrorenen Version: Die Spezifikation erhält zu einem genau benannten Zeitpunkt eine Kennung und trifft danach Entscheidungen im realen Zeitfluss. Künftige Daten können nach Betrachtung des Ergebnisses weder zurückgespult noch ausgewählt oder ersetzt werden. Der Test misst das Verhalten der Version im beobachteten Zeitraum; er beweist keinen fortbestehenden Edge und keine gleiche Ausführung bei größerer Skalierung.
Out-of-Sample und Forward beantworten verschiedene Fragen. OOS beschreibt, ob Daten an der Entwicklung beteiligt waren; auch ein bereits vorhandener historischer Abschnitt kann OOS sein, wenn er wirklich versiegelt blieb. Forward bezeichnet die Zeitfolge: Die Daten treffen nach dem Freeze ein. Paper, Shadow und Micro-Live sind Umsetzungsumfelder, in denen der Forward-Test stattfinden kann.
Datenbezug, Zeitbezug und Umfeld
| Begriff | Klassifiziert | Richtige Frage | Beispiel |
|---|---|---|---|
| Out-of-Sample | Daten-Entwicklungs-Bezug | Hat der Datensatz eine Entscheidung beeinflusst? | nie geöffneter historischer Holdout |
| Forward-Test | Zeitbezug | Lag die Entscheidung vor dem Eintreffen der Daten? | ab heute eingefrorene Version |
| Paper Trading | simuliertes Umfeld | Riskiert die Order echtes Kapital? | Demokonto mit modellierten Fills |
| Shadow Mode | parallele Implementierung | Erzeugt die Pipeline Orders ohne Routing? | Schattenorders und Echtzeitlogs |
| Micro-Live | kleines reales Umfeld | Welche Effekte zeigen kleine echte Orders? | Routing und Fills mit engen Limits |
Die Kategorien können sich überschneiden. Eine morgen von einer eingefrorenen und unveränderten Version erzeugte Beobachtung ist für sie forward und OOS. Sobald ihr Ergebnis einen neuen Filter lenkt, wird sie Entwicklungsinformation der Nachfolgeversion.
Was eingefroren werden muss
Nur „die Regeln“ einzufrieren genügt nicht. Zur Version gehören mindestens:
- Code, Abhängigkeiten, Konfiguration und relevante Seeds;
- Universum, Datenquelle, Kalender, Zeitstempel und Regeln für Missing Values;
- Features, Parameter, Signale und Verhalten ohne Trade;
- Portfoliokonstruktion, Sizing, Hebel und Einschränkungen;
- Ordertypen, Fillmodell, Kosten, Funding und Benchmark;
- Hauptkennzahlen, Kontrollen, Alarmschwellen und Abschlusskriterium;
- Paper-, Shadow- oder Live-Modus samt bekannten Unterschieden.
Eine materielle Änderung erzeugt eine neue Kennung. Ein Dokumentationstippfehler kann die Version unberührt lassen; Änderungen an Features, Universum, Verzögerung, Kosten, Sizing oder Orderverhalten tun dies gewöhnlich nicht. Das Register muss die Entscheidung nachprüfbar machen.
Prospektives Protokoll
- Mandat schreiben. Statistisches Ziel, Pipelineprüfung, Ausführungsqualität und operative Schulung unterscheiden.
- Freeze setzen. Version, Artefakt-Hashes, Datum und Uhrzeit, Verantwortlichkeit sowie vorab definierte Änderungs- oder Stoppkriterien bewahren.
- Umfeld wählen. Simulierte und reale Ereignisse nennen; Fillmodell, Broker, Venue, Feed und Latenz dokumentieren.
- Gesamten Fluss protokollieren. Empfangene Daten, Nullsignale, Absichten, Orders, Ablehnungen, Fills, Positionen, Kosten, Alerts und menschliche Eingriffe speichern.
- Nicht rückwirkend bereinigen. Fehler und Ausfälle bleiben sichtbar; Ausschlüsse folgen vorab festgelegten Regeln.
- Mit festgelegten Erwartungen vergleichen. Verteilung, Risiko, Exposure, Turnover, Ausführung und Benchmark einschließlich Unsicherheit bewerten.
- Abweichungen klassifizieren. Daten-/Betriebsvorfall, Implementierungsfehler, Execution Drift, normale Variabilität und mögliche Modellverschlechterung trennen.
- Mit nachvollziehbarer Entscheidung schließen. Fortsetzen, begrenzen, aussetzen, revalidieren oder neue Version erstellen sind andere Ergebnisse als Gewinn oder Verlust.
Dauer und Informationsmenge
Eine universelle Dauer existiert nicht. Benötigte Kalenderzeit hängt von Strategiefrequenz, Abhängigkeit der Signale, Positionshorizont, Seltenheit der Ereignisse und gewünschter Präzision ab. Viele korrelierte Trades sind nicht gleich viele unabhängige Beobachtungen; einige profitable Wochen müssen keine wesentlichen Bedingungen enthalten.
Das Protokoll sollte Kriterien auf Abdeckung und Entscheidung stützen: beobachtete Ordertypen, relevante Sitzungen und Ereignisse, Informationsvolumen, Kennzahlenpräzision und das Fehlen ungelöster Vorfälle. Ein Governance-Enddatum ist möglich, beweist aber keine statistische Suffizienz.
Auch eine einzelne Profit-Factor-, Sharpe- oder Drawdown-Schwelle entscheidet den Test nicht. Kennzahlen werden gemeinsam, nach Kosten, gegen einen vorab gewählten Benchmark und mit zur Abhängigkeit passenden Intervallen gelesen. Das Ergebnis kann günstig, mit der Hypothese unvereinbar oder schlicht nicht schlüssig sein.
Änderungen, Vorfälle und Reinheit
Während des Forward-Tests können operative Defekte sofortiges Eingreifen verlangen. Sicherheit geht vor statistischer Reinheit: Ein Kill Switch darf nicht verzögert werden, um „den Test zu retten“. Vorfall, Entscheidung und betroffene Daten bleiben im Register. Ändert die Korrektur das Verhalten, beginnt eine neue Version mit neuer prospektiver Periode.
Wiederholtes Betrachten und Anpassen macht den Forward-Test zur iterativen Entwicklung. Iteration ist zulässig, muss aber so heißen. Segmente mehrerer Versionen als einzigen unverunreinigten Track Record zu verbinden wäre irreführend.
Illustratives Beispiel — Version 1.0 wird mit Signalen, Sizing, Kosten und operativen Schwellen eingefroren. Im Shadow Mode speichert sie bei jedem Ereignis die hypothetische Order. Nach dem Start zeigt sich ein falscher Kalender für eine verkürzte Sitzung: Der Vorfall bleibt erhalten, die Pipeline wird korrigiert und Version 1.1 beginnt. Ergebnisse der 1.0 werden der 1.1 nicht zugerechnet. Tage oder Trades werden nicht vorgegeben, weil sie von Ziel und Informationsstruktur abhängen.
Ein begrenztes Micro-Live kann anschließend Routing und Abstimmung beobachten. Es ist weder in jedem Kontext verpflichtend noch ausreichend und benötigt Genehmigungen, Risikolimits und operative Kapazität.
Grenzen
- Forward beobachtet nur die Regime, die nach dem Freeze tatsächlich auftreten.
- Paper und Shadow bilden Warteschlange, Impact, Borrow und wirtschaftlichen Druck nicht vollständig ab; Micro-Live beweist keine Zielkapazität.
- Eine eingefrorene Version kann Daten- und Designbias mit dem Backtest teilen.
- Viele überwachte Kennzahlen oder Strategien erhöhen ex-post-Selektionsrisiken.
- Prospektivität verbessert Nachvollziehbarkeit, verwandelt Korrelation aber nicht in Kausalität.
Quellen
- Leonard J. Tashman, Out-of-sample tests of forecasting accuracy: an analysis and review, 2000 — zeitliche Ordnung, Rolling Origin und aufeinanderfolgende OOS-Bewertungen.
- Joseph Simonian, CFA Institute Research Foundation, Investment Model Validation: A Guide for Practitioners, 2024 — proaktive Validierung und Zuverlässigkeit von Investmentmodellen.
- National Futures Association, Interpretive Notice 9025 — Use of Promotional Material Containing Hypothetical Performance Results — Grenzen hypothetischer Performance im jeweiligen NFA-Bereich.
- U.S. Securities and Exchange Commission, Staff Report on Algorithmic Trading in U.S. Capital Markets, 2020 — Automatisierung, Handelsplätze und reale Orderinteraktion.
- Europäische Kommission, Delegierte Verordnung (EU) 2017/589, RTS 6 — Tests, Kontrollen, Dokumentation und Deployment im eigenen EU-Regelungsbereich.