Forward-Beobachtung untersucht, wie sich ein festgelegter EA mit Daten verhält, die nach Fixierung des Testplans eintreffen. Sie ist nur sinnvoll, wenn Version, tatsächlich verfügbare Informationen und Prüfregeln nachvollziehbar bleiben. Ein nachträglich gewählter Gewinnzeitraum ist nicht dasselbe Experiment.
Betriebsbereitschaft, Belegvollständigkeit und Leistungsbewertung getrennt behandeln. Der Abgleich aus dem ersten Leitfaden klärt, was geschah; dieser Leitfaden legt die vorausschauende Beobachtung fest. Weder ein sauberes Journal noch ein abgeschlossener Zeitplan beweist Rentabilität oder erlaubt die Finanzierung eines Live-Kontos.
1. Die Frage vor der Ergebniserfassung formulieren
Verhalten und Umgebung der Prüfung benennen: Signalzeitpunkt, Entscheidungsreproduktion, Anfragebehandlung, Ausführungsunterschiede oder eine präzise Leistungshypothese. Vergleich und benötigte Belege festlegen. Ein steigender Kontostand beantwortet diese Fragen nicht gemeinsam.
Alle früheren Varianten und Auswahlversuche einschließlich gescheiterter dokumentieren. Ein neuer Forward-Zeitraum löscht die Modellauswahlhistorie nicht. Wiederholtes Nachjustieren nach Ergebniseinsicht macht diese Beobachtungen zu Entwicklungsdaten. Der Überanpassungsleitfaden erklärt die nötige Vorsicht bei attraktiven ausgewählten Backtests.
2. Shadow-, Demo- und Live-Belege unterscheiden
Shadow bedeutet hier einen Beobachter, der Entscheidungen ohne Orders protokolliert. Demo sendet Anfragen an ein simuliertes Brokerkonto; Live bedeutet Ausführung auf einem real finanzierten Konto. Den Modus ausdrücklich dokumentieren, statt Forward mit garantierten realen Ausführungen gleichzusetzen.
| Modus | Mögliche Aufzeichnung | Wesentliche Beleggrenze |
|---|---|---|
| Shadow-Beobachter | Entscheidungen und verfügbare Eingaben; keine Orders | Keine beobachtete Brokerausführung |
| Demokonto | Entscheidungen, simulierte Anfragen und Brokerbelege | Belegt keine Live-Ausführungen oder Kosten |
| Live-Konto | Reale Anfragen, Brokerbelege und Kontowirkungen | Kapital im Risiko; Ergebnisse bleiben unsicher |
Das erfundene Beispiel verwendet ausschließlich Demo und empfiehlt keine Live-Allokation. Modi erst nach Abgleich von Versionen, Daten und Zeitabdeckung vergleichen und ihre Belege getrennt halten. Der Demo-versus-Live-Leitfaden erläutert Ausführungsunterschiede; ein Beobachter kann reale Ausführungen nicht aus einem Bid-Chart ableiten.
3. Ein eindeutiges Versuchsmanifest fixieren
EA-Binärdatei/Build und, falls verfügbar, Quellrevision archivieren; Dateihashes, Eingabewerte und Parameterdatei festhalten. Brokerserver, Konto und Modus, Währung, Symbolzuordnung, Zeitrahmen, Abhängigkeiten, Terminal-Build, Zeitbasis, Datenquellen, Risikoregelversion, Start, Endregel und Prüfplan aufnehmen. Ein Dateiname allein identifiziert keine Konfiguration.
Im Lehrbeispiel EA-A und Eingaben I1 für einen Demo-Lauf auf EURUSD H1 fixieren. Das Manifest enthält Zeitstempel und Kennungen der fest eingeplanten Entscheidungstermine. Handels- und Risikoregeln bleiben unverändert; dieser Leitfaden liefert weder diese Regeln noch einen Controller. Die Betriebssicherheit folgt weiterhin der vorhandenen Kontorisikoregelung.
4. Tatsächlich verfügbare Entscheidungseingaben erfassen
Entscheidungsgrenze, Kennungen geschlossener Kerzen, relevante Kurse und Merkmale, Quell- und Empfangszeiten sowie Aktualitätsprüfungen sichern. Eine dokumentierte Zeitnormalisierung nutzen. Im erfundenen Beispiel ist F1 mit 09:00:00 datiert, trifft aber um 09:00:08 nach der um 09:00:05 fixierten Aufnahme ein. Es darf dieser Entscheidung nicht zugrunde liegen. Die Prüfung um 09:00:10 muss dies erhalten.
Ein früherer Quellzeitstempel beweist keine damalige Lesbarkeit für den EA. Die fixierte Regel für fehlende Daten befolgen, gegebenenfalls mit dokumentiertem Auslassen. Spätere Korrekturen getrennt speichern. Rekonstruktion mit revidierter Historie, inzwischen fertiger laufender Kerze oder später empfangenem Wert führt Informationen ein, die dem ursprünglichen Lauf fehlten.
5. Fenster und erwartete Gelegenheiten vorab festlegen
Start und Endregel, Marktkalender, erlaubte Sitzungen, Entscheidungstermine, Aufwärmausschlüsse und Prüfpunkte vor der Beobachtung festlegen. Umgang mit Marktschließungen, fehlenden Kerzen, Neustarts und Ausfällen erklären. Ein Ausfall darf nicht aus dem Nenner verschwinden, weil keine Order gesendet wurde. Geplante Termine von Signalen, Anfragen und abgeschlossenen Trades trennen.
Der erfundene Zeitplan enthält 100 erwartete Entscheidungstermine in 4 aufeinanderfolgenden Blöcken zu 25. Nach jedem Block prüfen und nach dem letzten Termin abschließen. Diese Zahlen machen den Abgleich reproduzierbar; sie sind weder Mindestempfehlung noch statistische Power-Berechnung. Tatsächliche Dauer und Belegbedarf hängen von Handelsfrequenz, Abhängigkeit, Marktbedingungen und Fragestellung ab.
6. Prüf-, Unterbrechungs- und Änderungsregeln vorab definieren
Quellenqualität, betriebliche Eskalation und Leistungskriterien trennen. Kennzahlen, Zuordnung, Kosten, Geldflussbehandlung, offene Positionen und Vergleichstoleranzen vor Kenntnis der Ergebnisse definieren. Die Leitfäden zu Eigenkapital und Drawdown sowie Kosten geben Buchführungskontext, keine universellen Abnahmeschwellen.
Für dieses Demobeispiel benötigt jede erwartete Entscheidung nachvollziehbare Belege, bevor das Leistungsdossier freigegeben werden kann. Ein ungeklärter Termin lässt die Freigabe offen. Geplante Prüfungen verzögern keine dringenden Maßnahmen nach bestehender Risikoregelung. Nicht bis zum Gewinn verlängern, am günstigen Hoch abbrechen oder nach Verlusten unbemerkt Schwellen ändern.
7. Das erfundene Abdeckungsbeispiel prüfen
Die Tabelle enthält überschneidungsfreie Blöcke, keine kumulierten Summen. Eine nachvollziehbare Entscheidung hat erhaltene damalige Eingaben und einen protokollierten Ausgang, auch dokumentiert kein Signal oder Auslassen; einem unbekannten Termin fehlen ausreichende Belege. R2 enthält einen bis zur Schlussprüfung fehlenden Entscheidungsbeleg. Nicht annehmen, dass dort Signal, Anfrage oder Exponierung fehlten.
| Prüfblock | Erwartete Entscheidungen | Nachvollziehbare Entscheidungen | Unbekannte Termine | Belegabdeckung |
|---|---|---|---|---|
| R1 | 25 | 25 | 0 | 100% |
| R2 | 25 | 24 | 1 | 96% |
| R3 | 25 | 25 | 0 | 100% |
| R4 | 25 | 25 | 0 | 100% |
Insgesamt sind 99 von 100 Entscheidungen nachvollziehbar und 1 unbekannt: Abdeckung 99%. Spätere vollständige Blöcke reparieren die frühere Lücke nicht. Nach der vorab festgelegten Vollständigkeitsregel bleibt das Dossier ohne abschließendes Ergebnis. Die Rechnung misst weder Trefferquote noch Strategiefehlschlag; selbst vollständige Belege erfordern eine gesonderte Prüfung von Aussagekraft und Leistung.
Optional: Belegzahlen und Abdeckung nachrechnen
Erwartete Termine: 25 + 25 + 25 + 25 = 100. Nachvollziehbare Entscheidungen: 25 + 24 + 25 + 25 = 99. Unbekannte: 0 + 1 + 0 + 0 = 1. Vollständiger Block: 25 / 25 × 100 = 100%. Unvollständiger Block: 24 / 25 × 100 = 96%. Gesamtabdeckung: 99 / 100 × 100 = 99%. Unbekannter Anteil: 1 / 100 × 100 = 1%. Zählprüfung: 99 + 1 = 100. Prozentwerte beschreiben nur Belegabdeckung; die Zahlen folgen englischer Schreibweise.
8. Geänderte Regeln als neuen Lauf behandeln
Ein anderer Schwellenwert, Eingabedatei, Symbolumfang, Sitzungsfilter oder Risikoregel verändert das Experiment. Grund und Wirksamkeitszeit dokumentieren, alten Lauf erhalten und neue gekennzeichnete Version starten. EA-B mit I2 darf etwa nicht unverändert an EA-A mit I1 angehängt werden. Auch Infrastrukturänderungen benötigen einen datierten Vorgang und eine Vergleichbarkeitsprüfung.
Eine Fehlerkorrektur kann nötig sein, macht bereits betrachtete Beobachtungen aber nicht zu ungesehenen Validierungsdaten. Vorfall und betroffenen Zeitraum erhalten und spätere Belege unter neuem Protokoll gewinnen. Alle Varianten und bisherigen Einsichten offenlegen. Schlechte Läufe nicht überschreiben, unvergleichbare Ergebnisse nicht bündeln und rückblickende Wiederholung nicht als ursprünglichen Forward-Beleg ausgeben.
9. Grenzen von historischem Tester und Plattform beachten
Historische Tests und Forward-Beobachtung beantworten verschiedene Fragen. Native MT4-Tests haben dokumentierte Grenzen: Externe Funktionen wie WebRequest() und SendNotification() werden im Strategy Tester nicht ausgeführt; Handelsoperationen auf anderen als dem getesteten Symbol finden nicht statt. Ein historischer Durchlauf belegt keine funktionierenden Live-Daten- und Warnwege.
Für Modell- und Datenannahmen den Backtesting-Leitfaden, für betriebliche Wege den Überwachungsleitfaden nutzen. Symbolübergreifende Eingabeverfügbarkeit getrennt von Ausführung prüfen. Reale Empfangs-, Verbindungsabbruch-, Wiederherstellungs- und Schutzbelege müssen aus einer geeigneten beobachteten Umgebung stammen, nicht aus angenommener unveränderter Übertragbarkeit des Testers.
10. Am Prüfpunkt eine begrenzte Schlussfolgerung festhalten
Protokollkennung, Modus, tatsächliche Daten, erwartete und beobachtete Abdeckung, Vorfälle, Änderungen, offene Punkte sowie vorab definierte Kennzahlen mit Grenzen berichten. Verluste und offene Exponierung einschließen, nicht nur günstige geschlossene Trades. Statistik muss Abhängigkeit und wiederholte Auswahl berücksichtigen; dieses Beispiel berechnet weder Signifikanz noch Überanpassungswahrscheinlichkeit.
- Wurden Manifest, Vergleich, Fenster und Prüfregeln vor den Ergebnissen fixiert?
- Nutzte jede Entscheidung nur tatsächlich zum Grenzzeitpunkt verfügbare Informationen?
- Sind Shadow-, Demo- und Live-Belege klar getrennt?
- Sind Lücken, Vorfälle, Kosten, offene Positionen und Versionswechsel sichtbar?
- Folgt die Schlussfolgerung den ursprünglichen Kriterien, ohne Abdeckung mit Rentabilität gleichzusetzen?
Präzise unterscheiden: Belege unvollständig, Belege vollständig, aber für die Frage unzureichend, oder dokumentiertes Ergebnis nach festgelegter Bewertung. Nichts davon stuft einen Demo-EA automatisch auf real finanzierten Betrieb hoch. Spätere Bereitstellung oder Allokation braucht eine eigene autorisierte Entscheidung und Risikokontrollen. Das Dossier für spätere Überwachung und erneute Validierung erhalten.
11. Fragen zur Forward-Validierung
Bedeutet Forward Handel mit realem Geld?
Nein. Shadow, Demo oder Live ausdrücklich angeben. Nur Live zeichnet die Ausführung eines real finanzierten Kontos auf und setzt Kapital Verlusten aus.
Reichen die 100 Entscheidungen des Beispiels zur EA-Validierung?
Das wird nicht behauptet. Sie sind ein erfundener Abdeckungsdatensatz, keine Stichprobengrößenempfehlung. Entscheidungen sind nicht zwingend Trades oder unabhängige Beobachtungen; vollständige Abdeckung beweist keinen Vorteil.
Darf ich Parameter verbessern und dasselbe Forward-Ergebnis behalten?
Das alte Ergebnis erhalten, die Änderung aber als neuen Lauf beziehungsweise neue Version kennzeichnen. Bereits zur Parameterwahl genutzte Beobachtungen sind Entwicklungsbelege, keine frische Validierung dieser Wahl.
Bedeutet 99% Abdeckung eine Trefferquote von 99%?
Nein. Dieser Anteil der geplanten Entscheidungstermine hat nachvollziehbare Belege. Die ungeklärte Lücke blockiert im Beispiel die vorab festgelegte Belegfreigabe unabhängig vom Handelsergebnis.
12. Quellen und Geltungsbereich
Primärquellen: Betrieb und Grenzen des MQL4 Strategy Tester, MetaTrader-Testereinrichtung und Eingabeparameter sowie Bailey und Mitautoren, The Probability of Backtest Overfitting. Geprüft am 2026-10-18. Die Forschung begründet Auswahlvorsicht, zertifiziert aber weder dieses Protokoll noch dessen Beispielzahlen.
Laufnamen, Merkmalszeiten, Zeitplan und Zählwerte sind erfundene Lehrdaten. Keine reale EA-Strategie, Live-Leistung, Mindeststichprobe, erwartete Rendite oder Finanzierungsempfehlung wird geliefert. Diagramme zeigen Protokoll und Belege statt ursprünglicher Testerberichte. Ein fixierter Plan verbessert Nachvollziehbarkeit und garantiert weder profitablen noch sicheren Handel.