Multi-Timeframe-Analyse: regelbasiert ohne Look-Ahead.

Multi-Timeframe-Analyse bedeutet, dass eine Strategie mehrere Zeitebenen mit getrennten Aufgaben verbindet: Die höhere Ebene liefert den Kontext, etwa die Trendrichtung auf Tagesbasis, die niedrigere bestimmt Setup und Einstieg, zum Beispiel auf Stundenbasis. Regelbasiert funktioniert das nur, wenn jede Bar der niedrigen Ebene ausschließlich Werte höherer Bars sieht, die zu diesem Zeitpunkt bereits abgeschlossen waren. Genau hier liegt der häufigste Fehler in Backtests: Wer beim Resampling die noch laufende Tageskerze verwendet, rechnet mit Wissen aus der Zukunft und erhält Ergebnisse, die live nicht wiederholbar sind. Dieser Artikel zeigt, wie Sie Zeitebenen sinnvoll aufteilen, wie der Look-Ahead-Bias beim Ausrichten entsteht und wie Sie ihn in Python, MQL5 und Pine Script vermeiden. Dazu kommt ein einfacher automatischer Test, der solche Lecks zuverlässig aufdeckt.

Was ist Multi-Timeframe-Analyse?

Bei der Multi-Timeframe-Analyse betrachtet eine Strategie denselben Markt auf mehreren Zeitebenen gleichzeitig, also mit Kerzen unterschiedlicher Dauer. Der Gedanke dahinter: Eine Bewegung, die auf dem Stundenchart wie ein Ausbruch aussieht, kann auf dem Tageschart nur eine Erholung in einem Abwärtstrend sein. Wer beide Ebenen kennt, filtert Signale, die gegen den übergeordneten Zusammenhang laufen.

Bekannt wurde der Ansatz vor allem durch Alexander Elders Triple-Screen-Methode, die drei Zeitebenen nacheinander prüft. Für ein regelbasiertes System ist weniger die konkrete Indikatorwahl entscheidend als die klare Aufgabenteilung. Jede Ebene beantwortet genau eine Frage:

Viele Systeme kommen mit zwei Ebenen aus: Kontext auf der hohen Ebene, Setup und Trigger zusammen auf der Handelsebene. Das ist oft die robustere Wahl, weil jede zusätzliche Ebene weitere Parameter und weitere Datenquellen mitbringt, die synchron gehalten werden müssen.

Wie weit sollten die Zeitebenen auseinanderliegen?

Verbreitet ist eine Faustregel aus dem Umfeld des Triple Screen: Die Zeitebenen liegen etwa um den Faktor 3 bis 6 auseinander, häufig wird der Faktor 5 genannt. Liegen sie zu nah beieinander, liefern beide Ebenen fast dieselbe Information. Liegen sie zu weit auseinander, ändert sich der Kontext so selten, dass er für den Einstieg kaum noch etwas aussagt.

Typische Kombinationen, die sich an verfügbaren Chartperioden orientieren:

• Woche, Tag, vier Stunden: für Positionen über mehrere Tage bis Wochen.
• Tag, vier Stunden, eine Stunde: für Swing-Systeme mit Haltedauern von Stunden bis Tagen.
• Vier Stunden, eine Stunde, 15 Minuten: für Intraday-Systeme.

Der genaue Faktor ist weniger wichtig als die Disziplin, ihn nicht zu optimieren. Wer im Backtest alle Kombinationen aus Zeitebenen, Durchschnittslängen und Schwellen durchprobiert, findet fast sicher eine Variante, die in der Vergangenheit gut aussieht. Legen Sie die Zeitebenen vor dem Test fest und begründen Sie sie mit der gewünschten Haltedauer, nicht mit dem Ergebnis.

Wo entsteht der Look-Ahead-Bias beim Resampling?

Look-Ahead-Bias bedeutet, dass ein Backtest Informationen verwendet, die zum simulierten Zeitpunkt noch nicht vorlagen. Bei mehreren Zeitebenen passiert das besonders leicht, weil die Daten zweier Auflösungen zusammengeführt werden müssen. Ein allgemeiner Überblick über Verzerrungen in Backtests steht im Artikel Bias-Korrektur in Backtests; hier geht es um den Spezialfall der Zeitebenen.

Das Muster ist fast immer gleich: Stundendaten werden mit resample("1D") zu Tageskerzen verdichtet. pandas beschriftet jede Tageskerze standardmäßig mit dem linken Rand des Intervalls, also mit 00:00 Uhr des jeweiligen Tages. Hängt man diese Werte anschließend per Vorwärtsfüllen an die Stundendaten, trägt die Stundenbar von 10:00 Uhr bereits den Schlusskurs des ganzen Tages, der erst am Abend feststeht.

Rechenbeispiel: Ein Filter erlaubt Long-Trades nur, wenn der Tagesschluss über seinem 20-Tage-Durchschnitt liegt. Steigt der Kurs an einem Tag von 100 auf 104 und schließt damit erstmals über dem Durchschnitt, meldet der fehlerhafte Backtest den Filter schon ab Mitternacht als erfüllt. Er kauft also bevorzugt an Tagen, deren positiver Ausgang bereits feststeht. Das Ergebnis wirkt stabil und lässt sich live nicht wiederholen, weil dort niemand um 10 Uhr den Schlusskurs kennt.

Dieselbe Falle gibt es in anderen Formen: der Durchschnitt der laufenden Wochenkerze in einer Tagesstrategie, ein Tageshoch, das erst am Nachmittag entsteht, oder Daten einer anderen Zeitzone, deren Tagesgrenze verschoben ist.

Höhere Zeitebenen in Python sauber ausrichten.

Die Lösung ist, jeden Wert der höheren Zeitebene mit dem Zeitpunkt zu versehen, ab dem er bekannt ist, also mit dem Ende seiner Bar. Ebenso bekommt jede Bar der niedrigen Ebene ihren Schlusszeitpunkt. Danach sucht pandas.merge_asof für jede niedrige Bar den letzten höheren Wert, dessen Bekanntzeitpunkt nicht nach ihrem Schluss liegt. Die Richtung backward ist dabei die Voreinstellung, beide Tabellen müssen nach dem Zeitschlüssel aufsteigend sortiert sein.

import pandas as pd

def htf_anhaengen(ltf: pd.DataFrame, htf_regel: str = "1D",
                  ltf_dauer: str = "1h", sma_len: int = 20) -> pd.DataFrame:
    """Hängt nur abgeschlossene Bars der höheren Zeitebene an (Index = Eröffnungszeit)."""
    htf = ltf["close"].resample(htf_regel, label="left", closed="left").last().dropna()
    filt = pd.DataFrame({"htf_close": htf, "htf_sma": htf.rolling(sma_len).mean()})
    # Ein HTF-Wert ist erst bekannt, wenn seine Bar geschlossen hat
    filt["bekannt_ab"] = filt.index + pd.tseries.frequencies.to_offset(htf_regel)
    links = ltf.copy()
    links["bar_ende"] = links.index + pd.Timedelta(ltf_dauer)
    out = pd.merge_asof(links.reset_index(), filt.reset_index(drop=True),
                        left_on="bar_ende", right_on="bekannt_ab",
                        direction="backward")
    return out.set_index(ltf.index.name or "index")

Wichtig sind drei Details. Erstens die Indikatoren immer auf der höheren Ebene berechnen und erst danach ausrichten, nicht umgekehrt. Zweitens müssen die Konventionen zum Zeitstempel bekannt sein: Viele Datenanbieter stempeln Bars mit der Eröffnungszeit, manche mit der Schlusszeit. Drittens legt die Tagesgrenze fest, welche Stunden zu einem Tag gehören. Bei Forex-Daten weicht sie je nach Broker oder Server von Mitternacht ab; hier helfen die Parameter offset oder origin von resample.

Das Signal einer Stundenbar wird anschließend frühestens zur Eröffnung der nächsten Stundenbar ausgeführt. So bleibt der Ablauf identisch mit dem, was ein Live-System tatsächlich tun kann.

Ein naheliegender Abkürzungsweg ist, die Tageskerzen mit label="right" zu beschriften oder die Tageswerte vor dem Vorwärtsfüllen pauschal um eine Periode zu verschieben. Das kann funktionieren, hängt aber still an der Annahme, dass beide Zeitreihen dieselbe Stempelkonvention haben und keine Lücken enthalten. Die Ausrichtung über ausdrückliche Bekanntzeitpunkte macht diese Annahme sichtbar und bleibt auch bei Wochenenden, Feiertagen und fehlenden Bars korrekt. Im Live-System entspricht dem eine einfache Regel: Ein neuer Wert der höheren Zeitebene wird erst übernommen, wenn deren nächste Bar eröffnet wurde, also die vorherige sicher abgeschlossen ist.

Umsetzung in MQL5 und Pine Script.

In MetaTrader 5 sind Zeitreihen rückwärts indiziert: Index 0 ist die laufende, noch nicht abgeschlossene Bar, Index 1 die zuletzt abgeschlossene. Für die höhere Zeitebene in einem Expert Advisor heißt das: Werte immer ab Index 1 abfragen, etwa mit iClose(_Symbol, PERIOD_D1, 1) oder CopyClose mit Startposition 1.

// Gleitender Durchschnitt der letzten abgeschlossenen D1-Bars
bool SmaD1(const int periode, double &wert)
{
   double c[];
   // start_pos = 1: die laufende Tageskerze (Index 0) bleibt außen vor
   if(CopyClose(_Symbol, PERIOD_D1, 1, periode, c) != periode)
      return(false);                 // Daten noch nicht synchron: kein Signal
   double summe = 0.0;
   for(int i = 0; i < periode; i++)
      summe += c[i];
   wert = summe / periode;
   return(true);
}

Der Rückgabewert verdient Aufmerksamkeit. Fordert ein EA Daten einer anderen Zeitebene an, die das Terminal noch nicht aufgebaut oder geladen hat, liefert die Funktion zunächst weniger Werte oder einen Fehler. Ein System sollte dann kein Signal erzeugen, statt mit Nullwerten weiterzurechnen. Die Tagesgrenze von D1 richtet sich nach der Serverzeit des Brokers, nicht nach Ihrer Ortszeit.

In Pine Script von TradingView lädt request.security Daten anderer Zeitebenen. Laut Dokumentation ist der einzige empfohlene Weg ohne Repainting, den Ausdruck um eine Bar zu versetzen und gleichzeitig lookahead_on zu setzen:

// Nur bestätigte Tageswerte: Versatz [1] zusammen mit lookahead_on
d1Close = request.security(syminfo.tickerid, "D", close[1], lookahead = barmerge.lookahead_on)

Ohne Versatz zeigt das Skript auf Echtzeit-Bars den unbestätigten Wert der laufenden Tageskerze, der sich nach dem Neuladen ändert. Weitere Unterschiede beim Übertragen zwischen den Plattformen beschreibt der Artikel Pine Script in MQL5 umwandeln.

Der Abschneide-Test: Look-Ahead automatisch erkennen.

Look-Ahead-Lecks sind im Code oft schwer zu sehen, aber leicht zu testen. Die Idee: Ein korrekt berechneter Wert für einen vergangenen Zeitpunkt darf nur von Daten bis zu diesem Zeitpunkt abhängen. Rechnet man dieselbe Pipeline einmal mit allen Daten und einmal mit Daten, die an einem Stichtag abgeschnitten sind, müssen alle gemeinsamen Zeilen identisch sein.

def test_kein_look_ahead(ltf: pd.DataFrame, schnitt: int = 1500) -> None:
    voll = htf_anhaengen(ltf)
    kurz = htf_anhaengen(ltf.iloc[:schnitt])
    a = voll.loc[kurz.index, ["htf_close", "htf_sma"]]
    b = kurz[["htf_close", "htf_sma"]]
    # Vergangenheit darf sich nicht ändern, wenn die Zukunft fehlt
    pd.testing.assert_frame_equal(a, b)

Mit der fehlerhaften Variante aus dem Resampling-Beispiel schlägt dieser Test fehl: Die Stundenbars des letzten, abgeschnittenen Tages sehen im vollen Datensatz einen anderen Tagesschluss als im gekürzten. Mit der Ausrichtung auf das Bar-Ende läuft er durch, weil die unvollständige Tageskerze erst nach dem Stichtag bekannt wäre und deshalb nirgends auftaucht.

Einige Hinweise für den Einsatz:

• Den Test mit mehreren Stichtagen ausführen, auch mitten in einer höheren Bar und genau an ihrer Grenze.
• Nicht nur die Indikatoren prüfen, sondern auch die Signal- und Orderspalten.
• Den Test fest in die Testsuite aufnehmen, damit spätere Änderungen an Datenaufbereitung oder Indikatoren kein neues Leck einführen.

Grenzen und Risiken mehrerer Zeitebenen.

Eine saubere Datenausrichtung verhindert einen bestimmten Fehler, macht eine Strategie aber nicht profitabel. Systematischer Handel kann zu Verlusten bis zum Totalverlust führen, bei gehebelten Produkten auch schnell und über den Einsatz einzelner Positionen hinaus.

• Überanpassung: Jede Ebene bringt eigene Parameter mit. Drei Zeitebenen mit je zwei Parametern ergeben bereits einen großen Suchraum, in dem sich Zufallstreffer finden lassen. Out-of-Sample-Tests und wenige, begründete Parameter sind hier wichtiger als bei einfachen Systemen.
• Verzögerung: Wer nur abgeschlossene höhere Bars nutzt, reagiert spät. Ein Tagesfilter springt frühestens am Abend um, ein Wochenfilter erst am Wochenende. Das ist der ehrliche Preis eines Backtests ohne Blick in die Zukunft.
• Seltene Signale: Mehrere Filter hintereinander reduzieren die Zahl der Trades. Kleine Stichproben machen Kennzahlen unsicher.
• Datenqualität: Lücken, Feiertage, Zeitumstellungen und unterschiedliche Sitzungszeiten wirken sich auf mehreren Ebenen gleichzeitig aus und verschieben Bar-Grenzen.
• Abweichung zwischen Test und Live-Betrieb: Backtester simulieren höhere Zeitebenen teils anders als das Live-System, etwa beim Zeitpunkt, zu dem eine neue Bar verfügbar ist. Vergleichen Sie die Signale beider Umgebungen über einige Wochen, bevor Sie sich auf den Backtest verlassen.

Was Sie jetzt konkret tun können.

Wenn Sie eine bestehende Strategie mit mehreren Zeitebenen haben oder eine planen, helfen diese Schritte:

1. Schreiben Sie für jede Zeitebene in einem Satz auf, welche Frage sie beantwortet. Fällt Ihnen für eine Ebene keine eigene Frage ein, streichen Sie sie.
2. Legen Sie die Zeitebenen anhand der gewünschten Haltedauer fest und nehmen Sie sie aus der Optimierung heraus.
3. Klären Sie die Zeitstempel-Konvention Ihrer Daten: Eröffnungs- oder Schlusszeit, Zeitzone, Tagesgrenze.
4. Ersetzen Sie jedes Vorwärtsfüllen von Werten höherer Zeitebenen durch eine Ausrichtung auf das Bar-Ende, in MQL5 durch Abfragen ab Index 1, in Pine Script durch den Versatz [1] mit lookahead_on.
5. Nehmen Sie den Abschneide-Test mit mehreren Stichtagen in Ihre Testsuite auf und lassen Sie ihn bei jeder Änderung laufen.
6. Vergleichen Sie nach dem Start die Live-Signale mit einem Backtest über denselben Zeitraum. Abweichungen sind fast immer ein Hinweis auf ein Ausrichtungs- oder Datenproblem.

Ein Backtest, der nach diesen Schritten schlechter aussieht als vorher, ist in der Regel nicht schlechter geworden, sondern ehrlicher.

Häufige Fragen.

Was ist Multi-Timeframe-Analyse im Trading?

Multi-Timeframe-Analyse betrachtet einen Markt auf mehreren Zeitebenen, etwa Tag und Stunde. Die höhere Ebene liefert den Kontext, zum Beispiel die Trendrichtung, die niedrigere bestimmt Setup und Einstieg. Ziel ist, Signale herauszufiltern, die gegen den übergeordneten Zusammenhang laufen. In einem regelbasierten System bekommt jede Ebene eine klar definierte Aufgabe.

Welche Zeitebenen passen bei der Multi-Timeframe-Analyse zusammen?

Als Faustregel liegen die Zeitebenen etwa um den Faktor 3 bis 6 auseinander, oft wird der Faktor 5 genannt. Typische Kombinationen sind Woche, Tag und vier Stunden oder Tag, vier Stunden und eine Stunde. Entscheidend ist, die Ebenen anhand der gewünschten Haltedauer festzulegen und nicht im Backtest zu optimieren.

Wie entsteht Look-Ahead-Bias bei mehreren Zeitebenen?

Look-Ahead-Bias entsteht, wenn eine Bar der niedrigen Zeitebene einen Wert der höheren sieht, der erst später feststeht. Typisch ist das Resampling zu Tageskerzen mit anschließendem Vorwärtsfüllen: Dann kennt die Stundenbar am Vormittag bereits den Tagesschlusskurs. Der Backtest sieht dadurch besser aus, als ein Live-System je sein kann.

Wie greift ein MQL5-Expert-Advisor korrekt auf eine höhere Zeitebene zu?

In MQL5 ist Index 0 die laufende, noch offene Bar und Index 1 die zuletzt abgeschlossene. Für Werte einer höheren Zeitebene sollte ein Expert Advisor deshalb ab Index 1 abfragen, etwa mit iClose oder CopyClose mit Startposition 1. Liefert die Funktion noch nicht alle angeforderten Werte, sollte das System kein Signal erzeugen.

Wie testet man einen Backtest auf Look-Ahead-Bias?

Ein einfacher Weg ist der Abschneide-Test: Dieselbe Berechnung läuft einmal mit allen Daten und einmal mit Daten, die an einem Stichtag enden. Alle Werte vor dem Stichtag müssen in beiden Läufen identisch sein. Weichen sie ab, nutzt die Berechnung Informationen aus der Zukunft. Der Test sollte mit mehreren Stichtagen fest in der Testsuite laufen.

Quellen und Stand.

• Other timeframes and data (request.security, lookahead) — TradingView Pine Script Docs
• pandas.DataFrame.resample — pandas Dokumentation
• pandas.merge_asof — pandas Dokumentation
• Indexing Direction in Arrays, Buffers and Timeseries — MQL5 Reference (MetaQuotes)
• CopyClose — MQL5 Reference (MetaQuotes)
• A Simple Triple Screen System for Trading Multi Timeframes — Forexop

Stand: 19. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.

Sie wollen eine Strategie mit mehreren Zeitebenen sauber automatisieren und testen lassen? Unverbindlich anfragen — wir klären Regelwerk, Datenausrichtung, Testumfang und den Weg in den Live-Betrieb. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.