Sechzehn Fehlerquellen, an denen Handelssysteme scheitern

Serverzeit ist nicht Ihre Zeit

Die meisten Forex-Broker betreiben ihre Handelsserver auf UTC+2 im Winter und UTC+3 im Sommer, damit der Handelstag mit dem New Yorker Handelsschluss endet. Diese Umstellung folgt der amerikanischen Sommerzeitregel, nicht der europäischen — und die beiden fallen jedes Jahr zwei bis drei Wochen auseinander.

Die Folge: Ein Handelsfenster, das Sie als „08:00 bis 17:00 Uhr" beschreiben, verschiebt sich mehrfach im Jahr um eine Stunde, wenn im Programm einfach die Serverzeit abgefragt wird. In den kritischen Wochen zwischen der amerikanischen und der europäischen Zeitumstellung sind es dann zwei Stunden Abweichung. Dasselbe betrifft Nachrichtenfilter, Tagesabschlüsse und die Berechnung des Tagesverlusts.

Pip ist nicht Point

Bei fünfstelligen Brokern hat EURUSD fünf Nachkommastellen statt vier. Ein Pip entspricht dann zehn Points. Bei JPY-Paaren wie USDJPY gilt eine andere Stellenzahl: dort sind es drei statt zwei Nachkommastellen. Bei Gold, Indizes und Kryptowährungen wieder andere.

Ein System, das intern in Points rechnet, aber mit Pip-Werten parametriert wird, arbeitet mit dem Zehnfachen des beabsichtigten Stops. Umgekehrt wird ein als 200 gemeinter Stop-Loss zu 20 Points — und die Position schließt bei der ersten Spreadausweitung. Das ist die häufigste Ursache dafür, dass ein System „völlig anders handelt als im Test".

Symbolnamen unterscheiden sich je Broker

Dasselbe Instrument heißt bei verschiedenen Brokern unterschiedlich: EURUSD, EURUSD.r, EURUSDm, EURUSD_i, EURUSD-ECN. Gold wird als XAUUSD, GOLD oder XAUUSD.spot geführt, der DAX als GER40, DE40, DAX40 oder GERMANY40. Ein System mit fest eingetragenen Symbolnamen läuft nach einem Brokerwechsel nicht mehr — oder schlimmer: Es läuft, findet aber die Korrelationssymbole nicht und trifft Entscheidungen auf unvollständiger Basis.

Dasselbe gilt für Multi-Symbol-Systeme, die intern Paare vergleichen, und für Trade-Kopierer zwischen Konten bei unterschiedlichen Brokern.

Kontraktspezifikationen ändern sich

Broker passen Mindestlotgröße, Lotschrittweite, Hebel, Stop-Level und Margin-Anforderungen regelmäßig an — häufig ohne gesonderte Ankündigung an einzelne Kunden. Ein System, das eine Mindestlotgröße von 0,01 voraussetzt, scheitert stillschweigend, wenn der Broker auf 0,1 umstellt. Ein System, das den Stop-Loss zwei Punkte vom aktuellen Kurs entfernt setzt, bekommt eine Fehlermeldung, sobald der Broker ein Stop-Level von zehn Punkten einführt.

Besonders unangenehm ist der Fall, in dem die Order abgelehnt wird, das Programm den Fehlercode aber nicht auswertet: Die Position bleibt dann ohne Absicherung offen.

Der Backtest ist nur so gut wie seine Annahmen

Modellqualität, Spread, Kommission und Swap-Sätze bestimmen das Testergebnis oft stärker als die Handelsstrategie selbst. Ein Test mit konstantem Ein-Pip-Spread liefert Zahlen, die im Livebetrieb nicht erreichbar sind — reale Spreads weiten sich um Wirtschaftstermine, zur Tageswende und in dünnen Marktphasen um ein Vielfaches aus.

Bei kurzfristigen Strategien ist der Effekt dramatisch: Ein Scalping-System mit durchschnittlich fünf Pips Zielgewinn verliert bei einem realistischen statt eines idealisierten Spreads schnell seine gesamte Rendite. Hinzu kommen Kommissionen, die bei ECN-Konten gerne vergessen werden, und Swap-Kosten bei Übernachtpositionen.

Look-Ahead-Bias: der Test, der die Zukunft kennt

Ein Backtest, dessen Ergebnis zu gut aussieht, greift meist unbeabsichtigt auf Information zu, die zum Entscheidungszeitpunkt noch nicht vorlag. Die typischen Quellen: Es wird auf den Schlusskurs der aktuellen, noch laufenden Kerze zugegriffen. Ein Indikator aus einer höheren Zeitebene liefert einen Wert, der erst am Ende der Stunde feststeht, wird aber schon zu Beginn abgefragt. Ein Indikator zeichnet nachträglich um, sobald neue Kursdaten eintreffen.

Solche Systeme zeigen im Test eine nahezu perfekte Trefferquote und verlieren im Livebetrieb vom ersten Tag an. Die Ursache ist im fertigen Programm schwer zu erkennen, weil der Test formal fehlerfrei durchläuft.

Mehr Parameter bedeutet nicht besser

Jeder zusätzliche optimierbare Parameter erhöht die Wahrscheinlichkeit, dass die Optimierung Zufallsrauschen statt tragfähiger Marktstruktur findet. Wer zehntausend Kombinationen durchrechnet, findet mit Sicherheit eine, die auf den Testdaten hervorragend aussieht — allein deshalb, weil bei genügend Versuchen immer etwas gut aussieht.

Der Prüfstein ist nicht der Bestwert, sondern die Umgebung des Bestwerts. Wenn ein System mit Periode 14 hervorragend läuft, mit 13 und 15 aber Verlust macht, haben Sie kein System gefunden, sondern eine Zufälligkeit. Liegt dagegen ein breites Plateau vor, in dem alle benachbarten Einstellungen ähnlich abschneiden, ist das ein belastbares Ergebnis.

Der Endgewinn ist die falsche Zielgröße

Optimiert man auf den absoluten Gewinn, gewinnt fast immer die Variante mit dem größten Risiko — typischerweise eine, die einmal einen extremen Drawdown durchgestanden hat und danach zufällig wieder hochgelaufen ist. Live wäre das Konto in der Zwischenzeit liquidiert worden oder Sie hätten das System entnervt abgeschaltet.

Sinnvollere Zielgrößen setzen Ertrag ins Verhältnis zum eingegangenen Risiko: der Recovery Factor (Nettogewinn geteilt durch maximalen Drawdown), der Profitfaktor unter Berücksichtigung der Trade-Anzahl oder eine eigene Funktion, die zusätzlich die Gleichmäßigkeit der Kapitalkurve bewertet. In MetaTrader lässt sich eine solche Bewertungsfunktion selbst hinterlegen.

Klären Sie, was am Wochenende geschieht

Kurslücken bei der Sonntagseröffnung springen über Stop-Loss-Marken hinweg. Ausgeführt wird zum nächsten verfügbaren Kurs, nicht zum gewünschten — der tatsächliche Verlust kann deshalb erheblich über dem geplanten liegen. Bei Indizes und Einzelaktien treten dieselben Lücken über Nacht und um Quartalszahlen herum auf.

Die Entscheidung, ob freitags geschlossen, reduziert oder gehalten wird, ist eine strategische, keine technische. Sie muss aber getroffen werden, sonst entscheidet der Zufall. Dasselbe gilt für Feiertage mit verkürztem Handel und für den Rollover bei Terminkontrakten.

Mehrere Systeme auf einem Konto brauchen Magic Numbers

Ohne eindeutige Kennung greift ein Handelssystem auf Positionen zu, die ein anderes eröffnet hat — und schließt sie nach seinen eigenen Regeln. Bei zwei Systemen auf einem Konto führt das zu Verhalten, das sich in keinem Backtest reproduzieren lässt und dessen Ursache man tagelang sucht.

Betroffen ist auch der manuelle Handel auf demselben Konto: Eine von Hand eröffnete Position ohne Magic Number wird von einem schlecht abgesicherten System gerne mit übernommen. Zusätzlich muss die Margin-Auslastung über alle Systeme hinweg betrachtet werden, sonst blockieren sie sich gegenseitig.

Das System muss einen Neustart überstehen

Terminalabsturz, Windows-Update, Stromausfall, Broker-Wartungsfenster: Unterbrechungen sind der Normalfall, nicht die Ausnahme. Ein Programm ohne Zustandsspeicherung weiß nach dem Neustart nicht mehr, ob der Break-Even bereits gesetzt, die erste Teilposition schon geschlossen oder der Tagesverlust bereits angerechnet wurde.

Im günstigen Fall wird eine Aktion doppelt ausgeführt. Im ungünstigen Fall setzt das System einen bereits nachgezogenen Stop wieder auf den Ausgangswert zurück und gibt damit gesicherten Gewinn auf. Bei Systemen mit mehrstufiger Ausstiegslogik kann der Zustand dauerhaft inkonsistent bleiben.

Demo- und Livekonto verhalten sich unterschiedlich

Auf Demokonten wird praktisch jede Order sofort und zum angezeigten Kurs ausgeführt. Im Livebetrieb kommen Requotes, Teilausführungen, Ausführungsverzögerungen und Spreadausweitungen hinzu. Bei manchen Kontomodellen unterscheidet sich zusätzlich das Ausführungsmodell selbst.

Für Systeme mit weiten Zielen ist der Unterschied verkraftbar. Für kurzfristige Strategien entscheidet er über Gewinn und Verlust: Eine Verzögerung von 300 Millisekunden kostet bei einem Ausbruchssystem regelmäßig mehr als die gesamte kalkulierte Marge.

Betreiben Sie das System nicht auf dem Arbeitsrechner

Ein Rechner, der nachts in den Energiesparmodus wechselt, handelt nicht. Ein Windows-Update, das um drei Uhr morgens neu startet, unterbricht laufende Positionen ohne Vorwarnung. Und eine Heim-Internetverbindung fällt häufiger aus, als man annimmt.

Hinzu kommt die Latenz: Ein Server in geografischer Nähe zum Rechenzentrum des Brokers verkürzt die Ausführungsverzögerung deutlich. Für längerfristige Systeme ist das nebensächlich, für kurzfristige entscheidend.

Warum Ihr System das Prop-Konto sprengt

Prop-Trading-Firmen wie FTMO, FundedNext oder E8 erlauben automatisierten Handel ausdrücklich. Die Bedingungen unterscheiden sich aber grundlegend von einem Privatkundenkonto: Der Hebel ist meist auf 1:50 bis 1:100 begrenzt statt 1:500, die Spreads sind weiter, und es gilt eine harte Tagesverlustgrenze von typischerweise fünf Prozent sowie ein Gesamtdrawdown-Limit von acht bis zehn Prozent.

Ein System, das auf einem Retail-Konto mit hohem Hebel und engem Spread getestet wurde, verstößt auf einem Prop-Konto häufig schon in der ersten Woche gegen diese Grenzen — nicht weil die Strategie schlecht wäre, sondern weil die Positionsgrößen nicht zu den Regeln passen. Verfahren wie Grid und Martingale sind besonders gefährdet, weil sie die Positionsgröße nach Verlusten erhöhen; manche Anbieter untersagen sie deshalb ganz.

Zu beachten ist außerdem der Unterschied zwischen statischem und nachlaufendem Drawdown: Bei einem nachlaufenden Limit steigt die Verlustschwelle mit dem Kontostand mit, was für algorithmische Systeme deutlich schwerer zu handhaben ist.

Was KI-Konverter bei Pine Script übersehen

Es gibt inzwischen Werkzeuge, die Pine Script automatisch nach MQL5 übersetzen. Sie erzeugen Code, der fehlerfrei kompiliert. Das ist aber nicht dasselbe wie Code, der dieselben Handelsentscheidungen trifft — und der Unterschied fällt oft erst im Livebetrieb auf.

Der Grund liegt in den Ausführungsmodellen. Pine Script rechnet die gesamte Historie bei jedem Aufruf neu durch und wertet die laufende Kerze fortlaufend aus; MQL5 arbeitet ereignisgesteuert und behandelt eine laufende Kerze anders als eine abgeschlossene. Hinzu kommen abweichende Bar-Indexierung, unterschiedliche Standardwerte gleichnamiger Indikatoren, eine andere Behandlung fehlender Werte und ein völlig anderes Ordermodell: Pine kennt eine vereinfachte Strategiesimulation, MQL5 echte Orders mit Ablehnungen, Teilausführungen und Mindestabständen.

Sparen Sie an der richtigen Stelle

Der aufwendigste Teil eines Entwicklungsprojekts ist selten das Programmieren, sondern das Klären offener Fragen. Eine Strategie, die im Kopf des Traders vollständig erscheint, enthält typischerweise zehn bis zwanzig ungeklärte Randfälle — genau die, die auf dieser Seite beschrieben sind.

Jede dieser Fragen erzeugt eine Rückfrage, jede Rückfrage kostet Zeit auf beiden Seiten, und Änderungen nach Beginn der Implementierung kosten ein Mehrfaches gegenüber Änderungen in der Spezifikation. Wer seine Regeln vorab schriftlich und einschließlich der Randfälle liefert, senkt die Projektkosten deshalb spürbar — meist stärker als jede Preisverhandlung.