Vom Neuling zum Experten: Erweiterung einer Liquiditätsstrategie mit Trendfiltern

Inhalt:

1. Einführung
2. Methoden zur Filterung ungeeigneter Konfigurationen
3. Umsetzung
4. Tests und Ergebnisse
5. Schlussfolgerung
6. Wichtige Erkenntnisse
7. Anlagen

Einführung

Stellen Sie sich vor, Sie hätten eine solide, auf Liquidität basierende Strategie entwickelt. Sie funktioniert zwar, aber irgendetwas fühlt sich unangenehm an. Wenn der Markt stark tendiert, liefert Ihr System Signale in beide Richtungen, und Sie zögern, unsicher, ob Sie auf eine Korrektur setzen oder eine Trendwende befürchten sollen. Sie kommen mit einer funktionierenden Strategie zu diesem Artikel, der jedoch eine klare Richtungsorientierung fehlt – und damit geht jedes Mal, wenn sich der Kurs entscheidend bewegt, ein Gefühl der Unsicherheit einher.

Im Terminal-Chart wurden unzählige Regeln entwickelt, die mechanisch angewendet werden, und es sind noch viele weitere möglich. In vielerlei Hinsicht ähnelt das Handelsterminal einem wissenschaftlichen Labor. Indikatoren, Price-Action-Modelle und statistische Beobachtungen werden kontinuierlich getestet, verfeinert und neu kombiniert, und fast täglich entstehen neue Strategien. Durch Erfahrung und eingehende Beobachtung wird jedoch ein entscheidender Punkt deutlich: Die meisten Handelsregeln sind nicht wirklich unabhängig.

Eine Strategie mag für sich genommen robust erscheinen, doch mit der Zeit zeigt sich oft, dass sie zusätzliche Bestätigung benötigt. Sie liefert nur dann gute Ergebnisse, wenn er mit anderen Indikatoren, Filtern oder kontextbezogenen Einschränkungen kombiniert wird. Dies ist keine Schwäche der Strategie an sich, sondern spiegelt vielmehr die Komplexität des Marktes wider. Märkte sind dynamische Systeme, und Ansätze, die auf einer einzigen Regel basieren, halten einer längeren Belastung durch wechselnde Bedingungen selten stand.

Im vorherigen Artikel dieser Reihe haben wir eine liquiditätsbasierte Strategie entwickelt, die sich auf Kerzenmechanik und Liquiditätszonen konzentriert. Dieses System hat klassische Trendkonzepte bewusst außer Acht gelassen. Es wurde so konzipiert, dass es in jeder Marktphase – ob im Trend, in einer Seitwärtsbewegung oder in einer Übergangsphase – funktioniert, indem es ausschließlich auf das Liquiditätsverhalten reagiert. Diese Flexibilität ist zwar sehr wirkungsvoll, stellt jedoch eine Herausforderung für Trader dar, die eine strukturierte, trendfolgende Strategie bevorzugen. Ohne eine bestimmte Ausrichtung kann es vorkommen, dass sich die Strategie in Märkten mit starker Trendbewegung schwer steuern lässt oder als unzuverlässig empfunden wird.

Ziel dieses Artikels ist es, diese Einschränkung zu beheben. Wir werden die ursprüngliche Liquiditätsstrategie um eine trendbasierte Einschränkung erweitern, die es dem Händler ermöglicht, zu steuern, wie und wann Liquiditätskonfigurationen gehandelt werden. Auf diese Weise bewahren wir die Kernmechanismen des Liquiditätsmodells und richten es zugleich an einer Marktneigung mit höherer Erfolgswahrscheinlichkeit aus.

Dieser Artikel setzt voraus, dass Sie die vorherigen Teile der Reihe Vom Neuling zum Experten verfolgt haben und die zuvor behandelte grundlegende Liquiditätsstrategie verstehen. Im nächsten Abschnitt werden wir verschiedene Ansätze zur Filterung ungeeigneter Konfigurationen untersuchen und anschließend einen davon für die praktische Umsetzung in MQL5 auswählen.

Methoden zur Filterung ungeeigneter Konfigurationen

Um von der Unsicherheit zur Kontrolle zu gelangen, müssen wir zunächst verstehen, warum manche Konfigurationen scheitern, obwohl sie technisch gesehen einwandfrei erscheinen. Gibt es bei Forex-Charts schlechte Konfigurationen? Die kurze Antwort lautet: Ja. Eine genauere Antwort lautet, dass Konfigurationen in unterschiedlichen Wahrscheinlichkeitsumgebungen vorkommen. Eine technisch gültige Konfiguration kann dennoch statistisch schwach sein, wenn sie unter ungünstigen Marktbedingungen auftritt. Deshalb sind Filter nicht optional – sie sind unverzichtbar.

Betrachten wir einen starken vorherrschenden Trend. Wenn ein Liquiditätsindikator entgegen diesem Trend eine Angebotszone identifiziert, deutet das Signal möglicherweise eher auf eine vorübergehende Erschöpfung oder einen geringfügigen Rückgang hin als auf eine vollständige Trendwende. Ob eine solche Konfiguration funktioniert oder fehlschlägt, ist eine Frage der Wahrscheinlichkeit und nicht der Gewissheit. Ein konsequentes Handeln entgegen dem vorherrschenden Momentum erhöht das Risiko von Verlustphasen und verschlechtert die statistische Erwartung.

Die praktische Lösung besteht darin, Liquiditätsmöglichkeiten an der vorherrschenden Markttendenz auszurichten. Mit anderen Worten: Wir handeln Liquidität in Richtung des Trends und nicht gegen ihn. Dies erfordert die Einführung von Rahmenbedingungen – objektive Regeln, die akzeptable Marktbedingungen festlegen.

Zu den gängigen Kategorien von Einschränkungen gehören:

• Trendfilter (gleitende Durchschnitte, Marktstruktur)
• Momentum- oder Oszillator-Schwellenwerte (RSI, iMACD, Stochastik)
• Marktstimmung anhand von Kerzen und Kursverhalten
• Zeit- oder sessionbasierte Filter

Das Verständnis dieser Konzepte ist über diese konkrete Strategie hinaus von großem Wert. Sind sie erst einmal beherrscht, lassen sie sich auf praktisch jedes Handelssystem anwenden, um dessen Konsistenz und Robustheit zu verbessern.

Um das Konzept zu veranschaulichen, betrachten wir unseren Indikator für Liquiditätszonen in Kombination mit einem der am häufigsten verwendeten Trendindikatoren: dem exponentiellen gleitenden Durchschnitt über 50 Perioden (EMA 50). Wenn sich Liquiditätsmuster in Richtung der Steigung des EMA bilden, verbessern sich die Handelsergebnisse in der Regel spürbar.

Abb. 1. Hinzufügen der Indikatoren zum Chart

Dieser Grundsatz beruht nicht lediglich auf einer subjektiven Einschätzung. Einer der ältesten und am häufigsten wiederholten Grundsätze der Marktspekulation lautet: „Folge dem Trend.“ Sich dem Trend anzupassen, garantiert zwar keinen Erfolg, erhöht aber die Wahrscheinlichkeit erheblich, dass eine Konfiguration ihr angestrebtes Ziel erreicht.

Ein wichtiges Detail, das im vorherigen Artikel nicht ausführlich behandelt wurde, ist die Exit-Logik. Bei diesem weiterentwickelten Ansatz werden Gewinnziele vorrangig an den jüngsten Swing-Hochs oder -Tiefs in Richtung des vorherrschenden Trends festgelegt. Diese Niveaus stellen natürliche Bereiche dar, an denen der Kurs reagieren könnte. Wer diese berücksichtigt, passt die Strategie an die Marktstruktur an und trägt der Tatsache Rechnung, dass ein kürzlich erreichter Höchst- oder Tiefststand die letzte Ausdehnung vor einer bedeutenden Trendwende sein könnte.

Umsetzung

In diesem Abschnitt erweitern wir die ursprüngliche Liquiditätsstrategie durch die Einbindung eines Trendfilters. Unter den zuvor erörterten Filtermethoden wählen wir den exponentiellen gleitenden Durchschnitt mit einer Periode von 50 als unseren Trendfilter aus, da er einfach und übersichtlich ist und sich allgemein durchgesetzt hat.

Die Umsetzungsregeln sind bewusst einfach gehalten:

• Kauf-Limit-Orders sind nur zulässig, wenn oberhalb des EMA 50 eine Liquiditätszone auf der Nachfrageseite erkannt wird.
• Verkaufs-Limit-Orders sind nur zulässig, wenn unterhalb des EMA 50 eine Liquiditätszone auf der Angebotsseite erkannt wird.
• Bildet sich eine Liquiditätszone auf der falschen Seite des EMA, wird die Konfiguration ignoriert.

Diese Logik zwingt das System praktisch dazu, nur an trendkonformen Rückgängen teilzunehmen. Liquiditätszonen werden nicht mehr als Umkehrpunkte betrachtet, sondern als Chancen für eine Fortsetzung des Trends.

Abb. 2. Trendorientierte Liquiditätskonfiguration

Abb. 2. Ein typisches Beispiel für eine Konfiguration mit höherer Wahrscheinlichkeit nach Anwendung des Trendfilters. In diesem Fall bildet sich die Nachfragzone oberhalb des EMA 50, was die bullische Trendausrichtung bestätigt. Wir rechnen daher bei der erneuten Retest mit Kauf-Limit-Orders. Wie zu sehen ist, zieht sich der Kurs zurück in die Nachfragzone, die mit dem EMA 50 zusammenfällt, was bedeutet, dass sowohl die strukturelle Unterstützung als auch die dynamische Trendunterstützung im selben Bereich zusammenlaufen – was die Gültigkeit der Konfigurationen erheblich stärkt.

Abb. 3. Ungültige Liquiditätskonfiguration im Trendkontext

Abb. 3. Ein Beispiel für eine ungültige Konfiguration, bei der sich oberhalb des EMA 50 eine Angebotszone bildet. Gemäß unserer Regel zur Trendausrichtung muss bei Short-Chancen die Angebotszone unterhalb des EMA 50 liegen, um eine bärische Tendenz zu bestätigen. Da diese Bedingung nicht erfüllt ist, weist die Konfiguration keine Richtungsausrichtung auf und wird daher als weniger wahrscheinlich eingestuft.

Zusammenfassung der Handelslogik (Pseudocode)

Für jede neue Bar:

    Berechne den EMA(50) auf Basis der Schlusskurse.

    Wird eine bullische Liquiditätskonfiguration erkannt (Nachfragezone):

        Wenn das Tief der Basiskerze > EMA-Wert ist:

            Platziere eine Buy-Limit-Order an der Zone

    Wird eine bärische Liquiditätskonfiguration erkannt (Angebotszone):

        Wenn der Höchstwert der Basiskerze < EMA-Wert ist:

            Platziere eine Verkaufs-Limit-Order in diesem Bereich.

Dieser Pseudocode gibt die Kernlogik der Filterung wieder. Die folgenden Abschnitte enthalten die vollständige MQL5-Implementierung für alle, die den Expert Advisor programmieren oder anpassen möchten. Wenn Sie sich in erster Linie für das Handelskonzept und die Ergebnisse interessieren, können Sie direkt zum Abschnitt „Testen“ springen.

Aus programmiertechnischer Sicht wird der EMA mithilfe der Standardfunktion „iMA“ in MQL5 berechnet. Bei jedem Tick oder jeder neuen Bar (je nach Ausführungsmodell) werden der aktuelle Kurs und das erkannte Niveau der Liquiditätszone mit dem EMA-Wert verglichen. Die Handelslogik wird je nach Ergebnis dieses Vergleichs bedingt aktiviert oder deaktiviert.

Dieser Ansatz hat mehrere Vorteile:

• Es reduziert übermäßiges Handeln bei unruhigen Marktbedingungen oder gegen den Trend,
• vereinfacht die Entscheidungsfindung durch die Durchsetzung einer richtungsbezogenen Ausrichtung und
• behält die ursprüngliche Logik zur Liquiditätserkennung unverändert bei.

Entwurf des Filters als eigenständiges Modul

Wenn ich mit der Entwicklung einer neuen Komponente in MetaTrader 5 beginne, kläre ich zunächst immer, welche Rolle diese Komponente innerhalb des Gesamtsystems spielen wird. In diesem Fall ging es nicht darum, die bestehende Liquiditätsstrategie neu zu gestalten, sondern sie auf kontrollierte und nicht-invasive Weise zu erweitern. Das Ziel bestand darin, ein Trendbewusstsein einzuführen, ohne die Logik zu verändern, die Liquiditätsengpässe und Impulsverhalten erkennt. Diese Vorgabe bestimmte sofort den Aufbau der Lösung.

Anstatt die Trendprüfungen direkt in den Expert Advisor zu integrieren, habe ich mich dafür entschieden, diese Aufgabe in ein eigenes Filtermodul auszulagern. Dieser Ansatz sorgt dafür, dass die Strategie übersichtlich bleibt, und verhindert, dass die Funktion „OnTick()“ zu einer unübersichtlichen Ansammlung von Bedingungsregeln wird. Außerdem lässt sich die Trendlogik so in zukünftigen Projekten wiederverwenden, unabhängig vom zugrunde liegenden Einstiegsmodell.

Um diese Trennung im Code deutlich zu machen, habe ich eine eigene Header-Datei namens „TrendFilter.mqh“ erstellt. Diese Datei würde keinerlei Informationen zum Handel, zur Orderausführung oder zum Risikomanagement enthalten. Seine einzige Aufgabe bestünde darin, eine einfache Frage zu beantworten: Ist das aktuelle Marktumfeld günstig für Käufe oder Verkäufe?

//+------------------------------------------------------------------+
//|                      TrendFilter.mqh                             |
//|   Simple EMA-based trend constraint for strategies               |
//+------------------------------------------------------------------+
#ifndef __TREND_FILTER_MQH__
#define __TREND_FILTER_MQH__

Die Include-Guards stellen sicher, dass die Datei nur einmal verarbeitet wird, selbst wenn sie indirekt über mehrere Quelldateien eingebunden wird. Das ist zwar nur ein kleines strukturelles Detail, wird aber mit zunehmender Projektgröße immer wichtiger.

Den Filter als Zustandsklasse definieren

Anstatt freie Funktionen offenzulegen, habe ich die Trendlogik in einer Klasse gekapselt. Dadurch kann der Filter seinen eigenen internen Zustand – insbesondere den Indikator-Handle – verwalten, ohne dass Implementierungsdetails in den Expert Advisor gelangen. Außerdem wird die Schnittstelle dadurch aussagekräftiger und lässt sich leichter wiederverwenden.

class CTrendFilter
{

Zum jetzigen Zeitpunkt ist die Klasse bewusst minimal gehalten. Es gibt keinen Bezug zu Aufträgen, Symbolen (außerhalb des Chart-Kontexts) oder zur Ausführungslogik. Dadurch bleibt das Filterkonzept rein.

Interne Statusvariablen deklarieren

Im privaten Bereich der Klasse habe ich die Variablen definiert, die zur Berechnung und Verfolgung des gleitenden Durchschnitts erforderlich sind. Diese Werte geben den Konfigurations- und Laufzeitstatus des Filters wieder.

private:
   int                  m_period;
   ENUM_MA_METHOD       m_method;
   ENUM_APPLIED_PRICE   m_price;
   int                  m_handle;

Die entscheidende Variable ist hier m_handle. Dieser Handle erlaubt den Zugriff auf den EMA-Indikator, der im Terminal ausgeführt wird. Ist dieser Handle ungültig, darf der Filter keine Entscheidungen treffen. Wenn man den Handle als Teil des Zustands des Objekts betrachtet, lässt sich dessen Lebenszyklus leichter korrekt verwalten.

Konstruktor und sichere Initialisierung

Ich initialisiere Indikator-Handles immer explizit. Wenn ein Handle nicht initialisiert wird, kann dies zu schwer erkennbaren Fehlern führen, die erst beim Testen oder bei der Optimierung auftreten. Die Aufgabe des Konstruktors besteht nicht darin, den Indikator zu erstellen, sondern einen bekannten sicheren Zustand herzustellen.

public:
   CTrendFilter()
   {
      m_handle = INVALID_HANDLE;
   }

Indem ich den Handle auf INVALID_HANDLE setze, kann ich später mit Sicherheit überprüfen, ob die Initialisierung stattgefunden hat.

Erstellung der EMA während der Initialisierung

Die Erstellung von Indikatoren sollte in einer kontrollierten Initialisierungsphase erfolgen, nicht innerhalb des Tick-Handlers. Aus diesem Grund habe ich eine Init()-Methode eingeführt, die der Expert Advisor aus seiner OnInit()-Funktion heraus aufruft.

bool Init(int period = 50,
          ENUM_MA_METHOD method = MODE_EMA,
          ENUM_APPLIED_PRICE price = PRICE_CLOSE)
{
   m_period = period;
   m_method = method;
   m_price  = price;

   m_handle = iMA(_Symbol, _Period, m_period, 0, m_method, m_price);
   return (m_handle != INVALID_HANDLE);
}

Hier speichert der Filter seine Konfiguration und erstellt den EMA-Indikator unter Verwendung des aktuellen Chart-Symbols und des aktuellen Zeitrahmens. Wenn der Indikator nicht erstellt werden kann, gibt die Funktion „false“ zurück, wodurch der Expert Advisor den Start ordnungsgemäß abbrechen kann. Dadurch wird verhindert, dass die Strategie mit unvollständigen Abhängigkeiten ausgeführt wird.

Den EMA-Wert zuverlässig ablesen

Sobald der Indikator vorhanden ist, benötigt der Filter eine sichere und konsistente Methode, um dessen Wert abzurufen. Ich habe dies mithilfe einer speziellen Value()-Methode umgesetzt, die aus dem Indikatorpuffer liest.

double Value(int shift = 1)
{
   if(m_handle == INVALID_HANDLE)
      return 0.0;

   double buffer[];
   if(CopyBuffer(m_handle, 0, shift, 1, buffer) <= 0)
      return 0.0;

   return buffer[0];
}

Die Standardverschiebung von 1 stellt sicher, dass der Wert aus einer vollständig geschlossenen Kerze stammt. Dadurch wird vermieden, dass auf unvollständige Daten der aktuellen Bar reagiert wird, und das Filterverhalten bleibt sowohl beim Live-Handel als auch beim Backtesting stabil.

Darstellung der Trendlogik als Berechtigungen

Anstatt den rohen EMA-Wert in der Strategie offenzulegen, habe ich den Filter so konzipiert, dass seine Logik in Form von Berechtigungen zum Ausdruck kommt. Dadurch bleibt der Expert Advisor übersichtlich und es wird vermieden, dass die Berechnungen der Indikatoren direkt in die Handelsbedingungen eingebettet werden.

bool AllowBuy(double price)
{
   return (price > Value(1));
}

Bei Kauf-Konfigurationen ist die Logik bewusst einfach gehalten: Liegt der Kurs über dem EMA, sind bullische Liquiditäts-Konfigurationen zulässig.

bool AllowSell(double price)
{
   return (price < Value(1));
}

Ebenso sind Verkaufs-Konfigurationen nur zulässig, wenn der Kurs unterhalb des EMA liegt. Dem Filter ist es egal, wie der Preis festgelegt wurde oder welche Art von Auftrag erteilt wird. Es wertet lediglich den Richtungskontext aus.

Bereinigung der Indikatorressourcen

Die ordnungsgemäße Bereinigung ist ein oft übersehener, aber entscheidender Bestandteil der professionellen MQL5-Entwicklung. Wenn der Expert Advisor entfernt oder neu kompiliert wird, sollten alle von ihm erstellten Indikator-Handles unverzüglich freigegeben werden.

void Release()
{
   if(m_handle != INVALID_HANDLE)
   {
      IndicatorRelease(m_handle);
      m_handle = INVALID_HANDLE;
   }
}

Diese Methode ist dafür vorgesehen, von der Funktion „OnDeinit()“ des EAs aufgerufen zu werden, um sicherzustellen, dass die Plattform Ressourcen sicher und vorhersehbar freigeben kann.

Integration des Filters in den EA

Die Integration beginnt auf der Ebene der Abhängigkeiten, wo der Expert Advisor angibt, dass er sowohl auf die Handels-Engine als auch auf das Trendfiltermodul angewiesen ist. Hier geht es nicht nur um die Kompilierung; damit wird festgelegt, dass die Trendlogik eine erstklassige Einschränkung im Ausführungsablauf darstellt. Durch das Einbinden von „TrendFilter.mqh“ delegiert der EA die Entscheidung über die Richtung formal an eine wiederverwendbare und gekapselte Komponente, anstatt die Logik des gleitenden Durchschnitts direkt in den Code einzubetten.

#include <Trade/Trade.mqh>
#include <TrendFilter.mqh>

Sobald die Abhängigkeit deklariert ist, instanziiert der EA die Objekte, die über die gesamte Laufzeit des Expert Advisors bestehen bleiben. Die CTrade-Instanz übernimmt die Ausführung und die Auftragserteilung, während CTrendFilter zu einem persistenten, zustandsbehafteten Objekt wird, das für die Verwaltung des Indikator-Handles und die Trendvalidierung zuständig ist. Diese Trennung stellt sicher, dass die Trendauswertung nicht bei jedem Tick blind neu berechnet wird, sondern kohärent gesteuert wird.

CTrade       trade;
CTrendFilter trend;

Die Trendfilterung erfordert eine Konfiguration, und in diesem System wird diese Konfiguration bewusst als Benutzereingabe bereitgestellt. Die Periode des gleitenden Durchschnitts ist nicht fest codiert, sondern wird bei der Initialisierung vom EA an den Filter übergeben. Dieses Konzept sorgt dafür, dass die Handelslogik stabil bleibt, während der Händler gleichzeitig selbst bestimmen kann, wie streng oder locker die Trendausrichtung sein soll.

input int    TrendMAPeriod       = 50;

In der Initialisierungsphase nimmt der Trendfilter seinen Betrieb auf. Während der Funktion „OnInit“ ruft der EA explizit „trend.Init()“ auf und übergibt dabei die ausgewählte MA-Periode. Intern wird hier der Handle für den gleitenden Durchschnitt erstellt und validiert. Sollte dieser Schritt fehlschlagen, weigert sich der EA zu starten, was entscheidend ist – denn der Handel ohne gültigen Trendfilter würde gegen die Kernregel der Strategie verstoßen.

int OnInit()
{
   if(!trend.Init(TrendMAPeriod))
   {
      Print("Failed to initialize trend filter");
      return INIT_FAILED;
   }
   return INIT_SUCCEEDED;
}

Ebenso wichtig ist ein verantwortungsvoller Umgang mit Ressourcen. Wenn der EA entfernt oder neu kompiliert wird, muss der Trendfilter sein Indikator-Handle freigeben. Dadurch werden verwaiste Ressourcen vermieden und die Stabilität des Terminals gewährleistet, insbesondere bei häufigen Strategietests oder Optimierungsläufen. Der EA delegiert diese Verantwortung vollständig an den Filter zurück.

void OnDeinit(const int reason)
{
   trend.Release();
}

Sobald der Trendfilter initialisiert und aktiv ist, fährt der EA mit seinem normalen Ausführungszyklus fort. Die Funktion „OnTick“ ist so geschützt, dass die gesamte Logik nur bei einer neuen Bar ausgeführt wird, wodurch die Konsistenz zwischen der auf Kerzen basierenden Logik und der Trendbewertung gewährleistet wird. Das ist wichtig, weil der vom Trendfilter verwendete gleitende Durchschnitt ebenfalls auf Bars basiert und nicht durch Ticks verzerrt ist.

void OnTick()
{
   if(!IsNewBar())
      return;

Bevor eine Handelslogik ausgewertet wird, werden Marktbedingungen wie beispielsweise der Spread überprüft. Dadurch wird sichergestellt, dass der Trendfilter nur in Umgebungen herangezogen wird, in denen die Ausführungsqualität akzeptabel ist. Die Ausrichtung auf Trends allein reicht nicht aus – sie muss mit den praktischen Handelsbeschränkungen in Einklang stehen.

   if(SymbolInfoInteger(_Symbol, SYMBOL_SPREAD) > MaxSpreadPoints)
      return;

Während der EA die Konfiguration für die Liquiditätskompression aufbaut, identifiziert er die Impuls-Kerze (A) und die Basis-Kerze (B), berechnet deren Spannen und überprüft das Kompressionsverhältnis. In dieser Phase wird noch keine Trendlogik angewendet – die Konfiguration muss zunächst für sich genommen strukturell stichhaltig sein.

   int A = 1;   // Impulse candle
   int B = 2;   // Base candle

   double rangeA = CandleRange(A);
   double rangeB = CandleRange(B);

   if(rangeB > rangeA / RatioMultiplier)
      return;

Sobald die Struktur bestätigt ist, gelangt die EA an den Punkt, an dem die Richtungsabsicht eine Rolle spielt. Für ein bullisches Szenario reicht die Kursentwicklung allein nicht aus. Selbst wenn beide Kerzen mit einem Aufwärtstrend schließen, überlässt der EA die endgültige Entscheidung dem Trendfilter. Der Aufruf von trend.AllowBuy(lowB) wirft eine einfache, aber wichtige Frage auf: Befindet sich der Kurs im Verhältnis zum vorherrschenden Trend an der richtigen Stelle?

   if(AllowBuy && closeA > openA && closeB > openB)
   {
      if(trend.AllowBuy(lowB))   // trend constraint
      {
         double sl = lowB - offset;
         double tp = highA;

         PlaceBuyLimits(highB, lowB, sl, tp, expiry);
      }
   }

Die gleiche Delegation gilt symmetrisch auch für bärische Konfigurationen. Selbst bei einer rückläufigen Dynamik und einer gültigen Kompression sind Liquiditätsfallen auf der Verkäuferseite nur dann zulässig, wenn der Trendfilter bestätigt, dass der Kurs unterhalb des gleitenden Durchschnitts liegt. Dadurch bleibt die Strategie auf die Fortsetzungslogik ausgerichtet und nicht auf Spekulationen gegen den Trend.

   if(AllowSell && closeA < openA && closeB < openB)
   {
      if(trend.AllowSell(highB)) // trend constraint
      {
         double sl = highB + offset;
         double tp = lowA;

         PlaceSellLimits(highB, lowB, sl, tp, expiry);
      }
   }
}

Durch diese Integration wird eine klare Trennung der Zuständigkeiten erreicht.

Der EA ist für Struktur, Ausführung und Risiko verantwortlich.

Der Trendfilter verfügt über eine Richtungsberechtigung.

In die Strategie fließt keine Logik mit gleitenden Durchschnitten ein. Es gibt keine doppelten Berechnungen. Der EA fragt einfach: „Darf ich hier in diese Richtung handeln?“ – und der Filter gibt eine eindeutige Antwort.

Nachdem die konzeptionellen Grundlagen geschaffen sind, sind wir nun bereit, die Strategie im Rahmen strukturierter Tests zu bewerten.

Tests und Ergebnisse

Die Tests wurden unter kontrollierten Bedingungen mit dem MetaTrader 5-Strategietester durchgeführt. Es wurden dasselbe Symbol, derselbe Zeitrahmen und derselbe historische Zeitraum wie im vorherigen Artikel beibehalten, um einen fairen Vergleich zwischen der ursprünglichen und der gefilterten Strategie zu gewährleisten.

Das Testverfahren umfasste folgende Schritte:

• Aktivieren Sie den visuellen Modus, um das Handelsverhalten und die Interaktion zwischen den Zonen zu beobachten.
• Führen Sie einen Basistest mit der ursprünglichen Liquiditätsstrategie durch.
• Wenden Sie den EMA-50-Filter an und führen Sie den Test mit denselben Parametern erneut durch.
• Vergleichen Sie die Handelshäufigkeit, den Drawdown und den Verlauf der Kapitalkurve.

Abb. 4. Visualisierung des Strategietesters

Die Ergebnisse bestätigen, was die Logik nahegelegt hat. Die gefilterte Version führte zu weniger Handelsgeschäften – etwa 35 % weniger im Testzeitraum –, doch jedes einzelne Geschäft erfolgte innerhalb eines klareren kontextuellen Rahmens. Die Drawdowns verliefen gleichmäßiger und erholten sich schneller als bei der ungefilterten Version. Verlustserien gab es zwar nach wie vor, sie waren jedoch kürzer und weniger schwerwiegend.

Vor allem aber verliefen die Handelsgeschäfte konsequenter im Einklang mit der allgemeinen Marktentwicklung. Das zuvor bestehende Problem – das Schwanken zwischen dem Vertrauen in eine Korrektur und der Befürchtung einer Trendumkehr – löste sich auf, da der Filter eine klare Antwort lieferte. Lag der Kurs über dem EMA, wurden nur Kaufgeschäfte berücksichtigt; lag er darunter, nur Verkaufsgeschäfte. Die Strategie widersprach dem Trend nicht mehr.

Schlussfolgerung

In diesem Artikel haben wir gezeigt, wie ein einfacher Trendfilter die Schwierigkeiten beim Handel mit einer liquiditätsbasierten Strategie ohne Richtungsvoreingenommenheit beseitigen kann. Durch die Einführung des EMA 50 als Richtungsbeschränkung haben wir das System von einem neutralen Liquiditätsmodell – das unabhängig vom Kontext auf jede Zone reagiert – in einen kontrollierten, trendorientierten Rahmen umgewandelt. Die Strategie kämpft nicht mehr gegen den Markt an, sondern strebt eine Anpassung an den vorherrschenden Trend an, bevor Kapital eingesetzt wird.

Das Wichtigste dabei ist jedoch nicht der gleitende Durchschnitt an sich. Der EMA 50 dient lediglich als Beispiel – als praktische Veranschaulichung eines tiefergehenden Prinzips: des beschränkungsorientierten Entwurfs. Eine Strategie wird nicht dadurch robust, dass sie jede mögliche Konfiguration berücksichtigt, sondern dadurch, dass sie sich innerhalb klar definierter Grenzen bewegt, die die Marktstruktur widerspiegeln. Filter sind keine optionalen Erweiterungen; sie unterscheiden ein System, das lediglich Signale erzeugt, von einem System, das Chancen mit hoher Wahrscheinlichkeit liefert.

Eine kurze Zusammenfassung der wichtigsten besprochenen Erkenntnisse finden Sie in der Tabelle „Wichtige Erkenntnisse“ weiter unten sowie im Abschnitt „Anlagen“, der den in diesem Artikel verwendeten Quellcode enthält.

Wichtig ist, dass diese Erweiterung die Flexibilität der ursprünglichen Strategie bewahrt und gleichzeitig für mehr Zuverlässigkeit und Konsistenz sorgt. Die Mechanismen der Liquiditätssteuerung bleiben unverändert: Es werden weiterhin Zonen identifiziert, die Kompression weiterhin gemessen und Aufträge weiterhin präzise erteilt. Was sich geändert hat, ist der Rahmen, in dem diese Mechanismen wirken – ein Rahmen, der die vorherrschende Richtung des Marktes berücksichtigt.

Im nächsten Artikel dieser Reihe werden wir untersuchen, wie zusätzliche Einschränkungen – wie beispielsweise Volatilitätsfilter, sessionbasierte Regeln und Bestätigungen über mehrere Zeitrahmen hinweg – die Strategie weiter verfeinern können, ohne ihre Kernlogik zu beeinträchtigen. Auf dem Weg vom Anfänger zum Experten geht es nicht darum, den perfekten Indikator zu finden, sondern darum, zu lernen, Systeme zu entwickeln, die strukturiert, diszipliniert und effizient funktionieren.

Wichtige Erkenntnisse

Wichtigste Erkenntnisse:	Beschreibung
Filter sind wichtig	Die ursprünglichen Eingabebedingungen reichen für sich genommen selten aus. Durch den Einsatz von Filtern wird eine Strategie kontextbezogen gestaltet, wodurch sichergestellt wird, dass Signale im Rahmen der allgemeinen Marktbedingungen ausgewertet und nicht bei jedem Auftreten eines Musters mechanisch ausgelöst werden.
Trendausrichtung:	Die Ausrichtung der Handelsrichtung am vorherrschenden Trend verbessert die Handelserwartung, da dadurch die Fortsetzung der Dynamik gegenüber Reaktionen entgegen dem Trend bevorzugt wird. In der Praxis verringert dies das Risiko von falschen Ausbrüchen und minderwertigen Trendumkehren.
Entwurf von Nebenbedingungen:	Gut konzipierte Einschränkungen fungieren als logische Schleusen, die vor der Ausführung eines Handelsgeschäfts erfüllt sein müssen. Dieser Ansatz sorgt dafür, dass Strategien zielgerichtet bleiben, verhindert übermäßigen Handel und erleichtert es, Entscheidungsprozesse nachzuvollziehen und Fehler zu beheben.
Modulare Strategien:	Strategieerweiterungen sollten als eigenständige Module implementiert werden, die das Verhalten erweitern, ohne die Kernlogik zu verändern. Dadurch bleibt die Stabilität gewahrt, während gleichzeitig schrittweise Verbesserungen und eine einfachere zukünftige Wartung ermöglicht werden.
Lebenszyklussteuerung:	Indikatoren und Ressourcen in MQL5 müssen explizit initialisiert und freigegeben werden. Eine korrekte Verwaltung des Lebenszyklus verhindert Speicherlecks, ungültige Handles und unvorhersehbares Verhalten bei lang andauernden Sitzungen.
Zustandsbewusstsein:	Strategien müssen ihren Ausführungsstatus kennen, insbesondere in ereignisgesteuerten Umgebungen wie OnTick. Durch die Verfolgung von Bar-Übergängen wird sichergestellt, dass Signale einmal pro Kerze verarbeitet werden, wodurch doppelte Orders und Logikkonflikte vermieden werden.
Kapselung:	Durch die Kapselung der Indikatorlogik in eigens dafür vorgesehene Klassen bleiben Expert Advisors übersichtlich und gut lesbar. Diese Trennung reduziert Code-Duplikate und ermöglicht es, Indikatoren wiederzuverwenden oder zu ersetzen, ohne die Ausführungslogik zu verändern.
Frühzeitig abbrechen:	Initialisierungsfehler sollten die Ausführung sofort unterbrechen, anstatt zuzulassen, dass das System in einem teilweise fehlerhaften Zustand weiterläuft. Ein frühzeitiger Ausfall vereinfacht die Fehlersuche und verhindert unbeabsichtigtes Handelsverhalten.
Datenzeitpunkt:	Die Durchführung von Berechnungen auf der Grundlage von geschlossenen Kursen anstelle von Echtzeit-Ticks führt zu stabileren und besser reproduzierbaren Signalen. Dieser Ansatz verringert die Rauschempfindlichkeit und lässt sich besser mit Backtesting und visueller Analyse vereinbaren.
Freigabelogik:	Die Ausführung von Handelsgeschäften sollte als eine Entscheidung behandelt werden, die einer Genehmigung bedarf. Filter und Einschränkungen erteilen oder verweigern ausdrücklich die Handelsberechtigung, wodurch die Absicht der Strategie klar und das Ausführungsverhalten vorhersehbar wird.
Rollenentflechtung:	Eine solide Strategie trennt die Marktanalyse, die Handelsqualifizierung und die Auftragsausführung in klar voneinander abgegrenzte Zuständigkeiten. Dies verringert die Komplexität und hilft dabei, Fehler während der Entwicklung und beim Testen einzugrenzen.
Flexible Eingabeparameter:	Durch die Bereitstellung kritischer Parameter als Eingabewerte können Händler die Strategie an verschiedene Wertpapiere, Zeitrahmen und Marktbedingungen anpassen, ohne den Quellcode ändern zu müssen.
Risikoankerung:	Stop-Loss- und Take-Profit-Niveaus sollten sich an der Marktstruktur orientieren und nicht an willkürlichen Abständen. Durch strukturelle Verankerung wird das Risikomanagement an die Logik angepasst, die das Handelssignal erzeugt hat.
Zunächst zum Kontext:	Bevor eine Richtungsausrichtung angewendet wird, muss der Marktkontext überprüft werden. Struktur, Volatilität und Trendbedingungen entscheiden darüber, ob eine Konfiguration aussagekräftig ist oder gänzlich ignoriert werden sollte.
Saubere Integration:	Neue Komponenten sollten sich nahtlos in bestehende Systeme integrieren lassen, wobei der Ausführungsablauf nur minimal verändert werden sollte. Dadurch wird das Regressionsrisiko verringert und das ursprüngliche Strategieverhalten beibehalten.
Disziplin bei der Ausführung:	Strenge Ausführungsregeln stellen sicher, dass Handelsgeschäfte nur dann getätigt werden, wenn alle vordefinierten Bedingungen erfüllt sind. Diese Disziplin ist für Konsistenz, die Zuverlässigkeit von Backtests und die langfristige Bewertung von Strategien unerlässlich.

Anlagen

Name der Quelldatei	Typ	Version	Beschreibung
TrendFilter.mqh	Header-Modul	1.00	Stellt eine wiederverwendbare, auf EMA basierende Trendfilterklasse bereit, die die Handelsausführung auf die vorherrschende Marktrichtung beschränkt. Das Modul kapselt die Erstellung von Indikator-Handles, den Pufferzugriff und die Logik für die Richtungsberechtigung, sodass Strategien die Trendausrichtung abfragen können, ohne die Indikatorlogik direkt in den Expert Advisor einzubetten.
Single_Candle_Liquidity_Trader_Filtered.mq5	Expert Advisor	1.10	setzt eine Strategie zur Liquiditätskompression und Impulsfortsetzung um, ergänzt um einen EMA-basierten Trendfilter eines höheren Zeitrahmens. Der Expert Advisor erkennt Basis-Impuls-Kerzenstrukturen, platziert gestaffelte Limit-Pending-Orders innerhalb von Liquiditätszonen, steuert den Ausführungszeitpunkt auf Basis einzelner Kerzen und überträgt die Richtungsüberprüfung an das TrendFilter-Modul, um die Handelsqualität zu verbessern.