Ein sinnvoller Filter beantwortet eine praktische Frage: Darf dieser EA mit den derzeit verfügbaren Informationen eine neue Position erwägen? Eine Sitzungsbezeichnung oder ein leerer Kalender genügt dafür nicht. Die Regel braucht eine überprüfte Zeitbasis, klare Ereignisabdeckung und aktuelle Kurse des gehandelten Symbols.
Beginne mit einer einfachen Trennung: Bestehende Positionen nach eigenen Regeln verwalten; neue Einstiege erst nach bestandenen Pflichtprüfungen erwägen. Dieser Ratgeber konkretisiert diese Trennung, zeigt ein kurzes Entscheidungsprotokoll und erklärt die Prüfung. Er liefert weder einen fertigen EA noch einen Rentabilitätsnachweis.
1. Festlegen, was der Filter steuert
Trenne Handelszeitregel, Sperre für geplante Nachrichten und Einstiegssetup der Strategie. Die Handelszeitregel legt erlaubte Zeiten fest, die Nachrichtenregel schließt ausgewählte Intervalle aus, und das Setup beschreibt die Handelsgelegenheit. Die ersten beiden Prüfungen erzeugen kein Setup und heben weder Ausführungs- noch Kontorisikogrenzen auf.
Verwende drei eindeutige Ergebnisse: PASS, BLOCK und UNKNOWN. Das sind vom Autor definierte Datenkennzeichnungen, keine MT4-Fehlercodes. Ein bekanntes geschlossenes Zeitfenster kann sperren; fehlende Informationen rechtfertigen keine Freigabe. Bei der hier gezeigten Regel halten sowohl eine Sperre als auch ungeklärte Pflichtdaten neue Einstiege zurück. Die Positionsverwaltung hat eigene Daten- und Berechtigungsprüfungen.
2. Zeit- und Abdeckungsregeln vor dem Test aufschreiben
Nutze die datumsbezogene Zeitzuordnung aus dem Ratgeber zu Handelssitzungen und die Ereignisdefinitionen aus dem Ratgeber zum Wirtschaftskalender. Halte die Regeln in einer versionierten Spezifikation fest, die eine andere Person auf dieselben Eingaben anwenden kann.
- Instrument und Umfang: Broker, Konto, Symbol, relevante Währungen und ausgewählte Ereignisgruppen einschließlich nachfolgender Veröffentlichungsphasen.
- Handelszeit: vollständige Datumsangaben, Zeitzone, Wochentagsregeln sowie genau ein- und ausgeschlossene Intervallgrenzen.
- Zeitzuordnung: überprüfte Beziehung zwischen UTC, gegebenenfalls lokalen Regeln und datumsbezogener Broker-Serverzeit.
- Nachrichtensperre: Quelle der Ereigniszeit, Vor- und Nachlauf, Überlappungen sowie Umgang mit vorläufigen, verspäteten oder geänderten Terminen.
- Datenanforderungen: benötigte Datums- und Währungsabdeckung, Schema, Quellenversion, Aktualisierungsstatus und Altersgrenzen.
- Fehlerreaktion: Gründe für zurückgehaltene Einstiege, Fortsetzung von Überwachung und Verwaltung sowie nötiger Zustandsabgleich vor der Wiederaufnahme.
Lege bei lokalen Sitzungen über Mitternacht die Zuordnung zum Handelstag fest und behandle den Datumswechsel ausdrücklich. Beziehe Ereignisse benachbarter Tage ein, deren Sperrintervall den Entscheidungszeitpunkt erreicht. Prüfe bei Sommerzeitwechseln die gewählte Umrechnung doppelt vorkommender oder nicht existierender Ortszeiten. Ersetze eine fehlende Zuordnung nicht stillschweigend durch die Anzeigezeitzone des Computers.
3. Den Kalenderstand prüfen, nicht nur den Download
Ein Snapshot ist eine gespeicherte Kalenderversion, die für eine Entscheidung verwendet wird. Ein erfolgreicher Download oder eine leere Ereignisliste beweist keine Vollständigkeit. Prüfe, ob der Anbieter die verlangten Währungen, Daten und Ereignistypen abdeckt, alle nötigen Datensätze abgerufen wurden und Zeiten, Einheiten und Versionen korrekt eingelesen sind.
Speichere die Aktualisierungsangaben des Anbieters getrennt von deiner Empfangszeit. Eine neu empfangene Antwort kann alte Daten enthalten. Ersetze den aktiven Snapshot erst nach vollständiger Validierung der neuen Version; eine Teildatei oder halb aktualisierte Liste darf nicht als gültig gelten. Ein fehlgeschlagener Abruf oder erneutes Lesen des Caches darf das Alter der zuletzt geprüften Version nicht zurücksetzen.
Ein überprüfter, ausreichend aktueller Snapshot kann innerhalb seiner ausgewiesenen Abdeckung bestätigen, dass kein ausgewähltes Sperrintervall aktiv ist. Fehlende Abdeckung, ungeklärte Terminänderungen, unbekannte relevante Ereigniszeiten oder ein abgelaufener Snapshot bleiben ungeklärt. Halte davon abhängige neue Einstiege wie vorgesehen zurück und setze die definierte Fehlerbehandlung und Positionsverwaltung fort. Unangekündigte Nachrichten liegen außerhalb des Schutzes eines Terminkalenders.
4. Den Kurs des gehandelten Symbols separat prüfen
Erfasse Empfang und Gültigkeit des Bid/Ask dieses Symbols mit einer Laufzeitmessung, die Neustarts und Uhränderungen berücksichtigt. Ein kürzlich erfolgter Empfang beweist weder aktuelle vorgelagerte Daten noch eine mögliche Ausführung. Prüfe Datenfeed, Zeitkontext, Spread und Handelsberechtigungen getrennt; siehe EA-Überwachung.
In MT4 bezieht sich TimeCurrent() in OnTick() auf den gerade verarbeiteten Tick. In anderen Ereignisfunktionen kann es den letzten Kurs eines beliebigen Symbols in der Marktübersicht wiedergeben. Es belegt keinen aktuellen Kurs des eigenen Symbols. Im Livebetrieb hängt TimeGMT() von den Zeiteinstellungen des Computers ab; im MT4-Tester entspricht es dem simulierten TimeCurrent(). Die Differenz im Tester rekonstruiert keine historischen Broker-Zeitversätze.
5. Ein erfundenes Entscheidungsprotokoll nachvollziehen
Verwende nur für dieses Beispiel die UTC-Handelszeit [08:00, 17:00) am 2026-03-16. Übernimm die hypothetische Vereinigung der A/B-Nachrichtensperren [12:15, 13:05) aus dem vorherigen Ratgeber. Die erforderliche Abdeckung und alle Metadaten gelten als geprüft. Die Ereignisabdeckung umfasst den ganzen UTC-Tag und reicht für diese Tagesprüfungen samt Vor- und Nachlauf aus. Es wird kein realer Anbieter oder Veröffentlichungstermin behauptet.
Wähle für die Rechenillustration ein Snapshot-Alter von höchstens 30 Minuten und ein Kursalter des eigenen Symbols von höchstens 5 Sekunden. Das sind Eingaben des Autors, keine empfohlenen Aktualisierungseinstellungen oder Sicherheitsgarantien. Der erste Snapshot wurde um 12:00:00 geprüft; eine vollständige aktuelle Ersatzversion wird um 13:06:00 geprüft. Um 17:00:00 steht ein weiterer gültiger Snapshot bereit. Die Altersangaben setzen überprüfte, vergleichbare Zeitmessungen voraus.
| Entscheidung · UTC | Snapshot-Alter | Alter des eigenen Kurses | Nur Zeit-/Datenprüfung |
|---|---|---|---|
12:10:00 | 10 min | 1 s | Diese Prüfungen bestanden; weitere folgen |
12:20:00 | 20 min | 1 s | Sperre: aktives Nachrichtenintervall |
13:05:00 | 65 min | 1 s | Warten: Kalender veraltet |
13:06:06 | 6 s | 12 s | Warten: Symbolkurs veraltet |
13:06:07 | 7 s | 1 s | Diese Prüfungen bestanden; weitere folgen |
17:00:00 | 0 s | 1 s | Sperre: außerhalb der Handelszeit |
Um 13:05:00 endet die Nachrichtensperre, der alte Snapshot ist aber 65 Minuten alt. Um 13:06:06 ist der neue Snapshot 6 Sekunden alt, doch der letzte Kursempfang des Symbols um 13:05:54 liegt 12 Sekunden zurück. Ein Empfang um 13:06:06 ist um 13:06:07 erst 1 Sekunde alt. Diese Zeile besteht die gezeigten Zeit- und Datenprüfungen, nicht die Strategie-, Ausführungs- oder Risikoprüfungen. Die Grenze 17:00 ist ausgeschlossen. Es werden weder Auftrag noch Ausstieg oder Rendite simuliert.
6. Verwaltung erhalten und Broker-Aufträge abgleichen
Eine Einstiegssperre darf die festgelegte Überwachung und Verwaltung bestehender Positionen nicht umgehen. Verwaltungsaktionen benötigen weiterhin eigene gültige Daten und Berechtigungen; fehlende Kurse erlauben keine blinde Stop-Änderung. Lege den Umgang mit gehaltenen oder zu löschenden Pending Orders separat fest und prüfe den vom Broker bestätigten Zustand, statt eine Löschanfrage als erfolgreich anzusehen.
Die MT4-Schaltfläche AutoTrading verbietet automatisierte Handelsanfragen, während EA und OnTick() weiterlaufen können. Sie ist daher keine reine Einstiegspause: Auch Verwaltungsschritte mit Handelsanfragen können betroffen sein. Unterscheide sie vom Entfernen eines EAs oder einer Terminaltrennung. Bestehender Schutz beim Broker und clientseitige Verwaltung sind unterschiedliche Mechanismen; siehe Risikomanagement.
7. Datenabruf darf den Entscheidungsablauf nicht blockieren
Entscheide anhand eines vollständigen validierten Caches und aktualisiere ihn über einen kontrollierten Prozess. Definiere Zeitlimits, Fehlermeldungen und die Aktivierung neuer Versionen. Ein einmaliger Verwaltungsaufruf vor einer langsamen Anfrage hält die Verwaltung nicht am Laufen, während dieselbe EA-Ausführung blockiert ist.
Optional: Netzwerk- und Ereignisgrenzen in MT4
MQL4 WebRequest() arbeitet synchron. Eine Verlagerung von OnTick() nach OnTimer() im selben EA macht den Aufruf nicht asynchron; eine wartende Anfrage kann das Programm weiterhin verzögern. Eine separate Abrufkomponente kann einen validierten Snapshot liefern, doch Übergabe und Fehlerfälle müssen ebenfalls geprüft werden. Ein Zeitgeber plant Aufrufe, garantiert aber keine unterbrechungsfreie Positionsverwaltung.
Die logische Reihenfolge lautet: den vorgesehenen Verwaltungs- und Überwachungspfad ausführen, Pflichtprüfungen für neue Einstiege bewerten und erst danach ein aktuelles Setup mit Ausführungs- und Risikokontrollen erwägen. Das beschreibt Zuständigkeiten, keinen ausführbaren MQL4-Code und keine Garantie rechtzeitiger Verarbeitung. Prüfe tatsächliche Integration, Berechtigungen und Fehlerverhalten, bevor du dich darauf verlässt.
8. Ein neustartfestes Entscheidungsprotokoll führen
Protokolliere UTC-Entscheidungszeit, Serverzeit samt geprüfter Zuordnung, Regelversion, Snapshot-Kennung sowie Quell- und Empfangszeiten, Abdeckung, Kursempfang und -alter, aktive Sperren und Ergebnisgründe. Bewahre abgelehnte Kandidaten ebenso auf wie bestandene Prüfungen. Ein Protokoll sollte eine Warteentscheidung erklären, ohne sie später aus einem revidierten Kalender rekonstruieren zu müssen.
Gleiche nach Neustart oder Wiederverbindung bestehende Positionen, Pending Orders und offene Anfragen mit dem Broker ab. Stelle nur überprüfbaren Zustand wieder her; ein Neustart bedeutet weder ein positionsloses Konto noch einen aktuellen Cache. Verhindere die wiederholte Verarbeitung desselben Kandidaten. Halte bei ungeklärtem notwendigem Zustand neue Einstiege bis zum Abgleich zurück und setze definierte Fehlerreaktion und Verwaltung fort.
9. Korrektheit vor der Backtest-Auswertung prüfen
Erstelle vor Leistungstests kleine feste Fälle mit erwarteten Ergebnissen. Berücksichtige:
- Eingeschlossenen Sitzungsbeginn, ausgeschlossenes Ende und Intervalle über Mitternacht.
- Beginn und Ende von Nachrichtensperren, überlappende Ereignisse sowie verschobene oder geänderte Termine.
- Fehlende, teilweise, fehlerhafte oder außerhalb der Abdeckung liegende Kalenderdaten, einschließlich einer ungeprüften leeren Antwort.
- Datenalter genau an der gewählten Grenze und knapp darüber sowie einen frischen Tick eines anderen Symbols bei weiterhin veraltetem eigenem Kurs.
- Neustart, Uhrsprung, fehlgeschlagene Aktualisierung und unterbrochenen Snapshot-Austausch ohne Zurücksetzen des Alters.
- Brokerseitige Aufträge und Verwaltung während der Einstiegssperre, einschließlich abgelehnter Löschung und fehlender Handelsberechtigung.
Der MT4-Strategietester führt WebRequest() nicht aus und verarbeitet keine Timer-Ereignisse. Prüfe die gemeinsame Entscheidungslogik mit eingefrorenen Daten und einer geprüften historischen Zeitzuordnung über einen unterstützten Testpfad. Spiele jeden Snapshot erst ab dem Zeitpunkt ein, zu dem er verfügbar gewesen wäre. Eine historische Ereignistabelle allein bildet weder Liveabruf noch die Zeitplanung nach. Weitere Grenzen erläutert der MT4-Backtesting-Ratgeber.
10. Nutzen getrennt von korrekter Funktion bewerten
Ein korrekt implementierter Filter kann profitable wie verlustreiche Trades ausschließen. Vergleiche die vorgeschlagene Regel mit einer vorher festgelegten Referenz bei gleicher Strategie, Datenbasis und Kostenannahme. Bewahre alle Kandidaten und Ablehnungsgründe auf, reserviere spätere Daten zur Validierung und berücksichtige realistische Ausführungskosten. Viele Zeitfenster zu durchsuchen und nur das beste zu berichten kann zur Überanpassung führen.
Beobachte anschließend die echte Integration auf Demo bei normalen Daten und Datenfehlern. Miss fehlgeschlagene Aktualisierungen, Sperren wegen veralteter Daten, Kurslücken, Verwaltungsverzögerungen und Broker-Antworten. Ein sauberes Protokoll zeigt das Systemverhalten, beweist aber keine künftige Rentabilität. Bestätige vor einem breiteren Einsatz:
- Versionierte Spezifikation, Zeitzuordnung und Ereignisauswahl sind dokumentiert.
- Abdeckungs- und Altersprüfungen unterscheiden freie, gesperrte und ungeklärte Zustände.
- Grenz- und Fehlerfälle liefern die erwarteten Ergebnisse.
- Historische Tests beachten die Informationsverfügbarkeit und legen fehlende Historie offen.
- Demoprüfungen bestätigen Abruf, Neustarts, fortgesetzte Verwaltung und brokerseitigen Auftragszustand.
- Behaupteter Nutzen wird separat mit Kosten und späteren Daten bewertet, ohne erfundene Leistungszahl.
11. Fragen zu EA-Filtern
Soll der EA einsteigen, wenn der Kalender frei ist?
Nein. Ein geprüfter freier Kalender erfüllt nur einen Teil der Entscheidung. Handelszeit, Kursqualität, Ausführung, Kontorisiko und ein aktuelles Strategiesetup bleiben erforderlich. Unerwartete Nachrichten können außerhalb des Terminplans eintreffen.
Warum kann ein frischer Download den Zustand ungeklärt lassen?
Die Antwort kann veraltet, unvollständig, außerhalb der benötigten Abdeckung oder falsch eingelesen sein. Die Empfangszeit allein validiert keine Anbieterdaten. Halte neue Einstiege zurück, bis die relevanten Pflichtprüfungen bestanden sind.
Kann ich Live-Nachrichtenabrufe im MT4-Tester testen?
Der dokumentierte Tester führt weder WebRequest noch Timer-Ereignisse aus. Nutze eingefrorene versionierte Eingaben und einen unterstützten Pfad für die gemeinsame Entscheidungslogik. Prüfe tatsächlichen Abruf und Zeitplanung anschließend separat auf Demo.
Soll ich AutoTrading als Nachrichtenpause verwenden?
Die Funktion betrifft nicht nur neue Einstiege: Auch automatisierte Anfragen der Positionsverwaltung können verboten werden. Hier geht es um eine interne Einstiegssperre mit separat geprüften Verwaltungsaufgaben, nicht um einen universellen Schalter zum Entfernen von Marktexposition.
12. Quellen und Geltungsbereich
Die offizielle MQL4-Referenz zu WebRequest erläutert synchrone Anfragen und ihre Einschränkungen. Die Grenzen des MT4-Strategietesters beschreiben Zeitsimulation sowie nicht unterstützte externe Funktionen und Ereignisse. Prüfe die Funktionen deiner konkreten Plattform und Integration, statt die Kompatibilität eines Beispiels für eine andere Plattform anzunehmen. Quellen geprüft am 2026-10-17.
Dieser Ratgeber schließt die Ratgebergruppe zu Handelszeiten und Nachrichten mit einem Regel- und Validierungsrahmen ab. Termine, Snapshots, Altersangaben und Ergebnisse sind erfundene Lehrbeispiele. Die Grenzen sind keine Empfehlungen; weder EA-Ausführung noch Handelsergebnis werden behauptet. Filter beseitigen weder Markt- noch Ausführungs- oder Kontorisiken.