Off Quotes / Requote (MT5/MQL5) endgültig lösen — 10021

Off Quotes / Requote (MT5/MQL5) endgültig lösen

Wenn im Journal oder Experten-Tab beim Betrieb eines EA off quotes (10021) oder requote (10004) auftaucht, wirkt das zunächst wie eine Ablehnung durch den Broker und sorgt für Verunsicherung. Tatsächlich sind beide kein Problem mit Kapital oder Lotgröße, sondern ein Preisproblem. Der von Ihnen gesendete Preis und der Preis, den der Server aktuell führt, stimmten nicht überein — mehr steckt nicht dahinter. Die Ursache lässt sich fast immer auf einen der folgenden Punkte zurückführen: plötzliche Kursbewegung, zu enge zulässige Slippage, Ausführungsart oder Verbindungslatenz.

Dieser Artikel richtet sich sowohl an MT5-Anwender, die einen EA einsetzen, als auch an MQL5-Entwickler, die einen EA programmieren. Er fasst 10021 (TRADE_RETCODE_PRICE_OFF), 10004 (TRADE_RETCODE_REQUOTE) sowie die MT4-Fehler 136/138 vollständig zusammen: Ursache, Sofortmaßnahmen und dauerhafte Lösungen im Code. Eine Gesamtübersicht aller Fehlercodes finden Sie im umfassenden Leitfaden zu MQL5/MT5-Fehlercodes.

Worin unterscheiden sich diese beiden (+ MT4 136/138)?

Ablehnungen wegen "Preis stimmt nicht" gibt es in zwei Varianten, je nachdem, wie der Server antwortet.

① TRADE_RETCODE_PRICE_OFF = 10021 (keine verarbeitbaren Kurse)

Dieser Wert steht im retcode-Feld von MqlTradeResult als Ergebnis von OrderSend() und bedeutet "es gibt keine Kurse, um die Anfrage zu verarbeiten" (There are no quotes to process the request). Entweder liegt serverseitig kein gültiger Preis vor, oder der gesendete Preis weicht zu stark vom aktuellen Kurs ab, um verarbeitet zu werden.

Bedeutung: Keine Kurse zur Verarbeitung der Anfrage vorhanden
Konstante: TRADE_RETCODE_PRICE_OFF
Wert     : 10021

② TRADE_RETCODE_REQUOTE = 10004 (Requote = Angebot eines neuen Preises)

Ebenfalls ein retcode-Wert von OrderSend(), jedoch keine reine Ablehnung, sondern ein erneutes Preisangebot ("dieser Preis geht nicht, aber wie wäre es mit diesem neuen Preis?"). In MqlTradeResult werden in bid / ask die vom Server neu angebotenen Preise zurückgegeben.

Bedeutung: Requote — Angebot eines neuen Preises
Konstante: TRADE_RETCODE_REQUOTE
Wert     : 10004

// Typische Ausgabe, wie sie im Log erscheint
2026.07.07 21:30:02.118 EA_NAME EURUSD,M5: OrderSend error 10004 (requote)
2026.07.07 21:30:02.310 EA_NAME EURUSD,M5: OrderSend error 10021

③ Die MT4-Fehler 136 / 138

In MQL4 (MT4) wurde dasselbe Phänomen über den Fehlercode von GetLastError() zurückgegeben.

Wenn Sie in älteren EA-Beschreibungen oder Logs von MT4-EAs auf "error 136" oder "error 138" stoßen, gilt der Inhalt dieses Artikels unverändert (in MT4 war es Standard, vor dem erneuten Senden über RefreshRates() die Preise neu abzurufen — wie das in MT5 aussieht, folgt weiter unten).

Praktische Unterscheidung:

Beide sind vorübergehende (wiederholbare) Fehler. Durch Code-Anpassungen oder Konfigurationsänderungen lassen sie sich nicht vollständig vermeiden, die Häufigkeit lässt sich jedoch deutlich reduzieren.

Erste Einordnung in 30 Sekunden

1. Zeitpunkt des Auftretens anhand der Journal-Zeitstempel prüfen
   • Im Moment einer Nachrichtenveröffentlichung (Arbeitsmarktdaten, FOMC etc.) → normale, plötzliche Kursbewegung. Falls der EA einen News-Filter besitzt, diesen aktivieren
   • Um Mitternacht Serverzeit (Rollover) oder an Wochenend-Gaps → Zeitraum mit dünnen Kursen. Liegt im normalen Rahmen
   • Tritt unabhängig von der Uhrzeit zufällig gehäuft auf → Verbindung, VPS oder deviation-Einstellung prüfen
2. Betroffenes Symbol prüfen
   • Häufung bei wenig liquiden Symbolen wie exotischen Paaren oder CFDs → Ursache liegt in der dünnen Kurslage des Symbols
3. Testen, ob es bei manuellen Orders ebenfalls auftritt
   • Läuft eine manuelle Schnellorder problemlos durch, während nur der EA abgelehnt wird → sehr wahrscheinlich ist die deviation (zulässige Slippage) des EA zu eng eingestellt

Mit diesen drei Punkten lässt sich vorab eingrenzen, ob "der Markt", "das Symbol" oder "Einstellung/Umgebung" die Ursache ist, bevor die Ursachenanalyse im nächsten Abschnitt folgt.

Ursachen und Lösungen (5 Muster)

① Plötzliche Kursbewegung / News-Spike (gesendeter Preis war beim Eintreffen bereits veraltet)

Symptom: 10004/10021 treten gehäuft zu Zeiten von Wirtschaftsdaten-Veröffentlichungen, Aussagen von Notenbankvertretern oder am frühen Montagmorgen auf.

Ursache: Der EA berechnet den Preis anhand eines Ticks, doch bis die Order beim Server ankommt, vergehen einige zehn bis einige hundert Millisekunden — in dieser Zeit hat sich der Preis um mehrere Pips bewegt. Der gesendete Preis existiert nicht mehr, weshalb der Server entweder eine Requote (10004) oder "keine Kurse" (10021) zurückgibt. Das ist weniger ein Fehler als ein normales Phänomen bei schnellen Marktbewegungen.

Lösung:

1. Neue Einstiege rund um Nachrichtentermine stoppen (News-Filter). Die auf dieser Seite angebotenen EAs enthalten standardmäßig EconomicFilter
2. deviation (zulässige Slippage) auf einen realistischen Wert erhöhen (siehe ②)
3. Eine Retry-Logik implementieren (Code weiter unten)

② deviation (zulässige Slippage) zu eng eingestellt

Symptom: Tritt auch bei ruhigem Markt vereinzelt auf. Manuelle Orders werden ausgeführt, nur der EA wird abgelehnt.

Ursache: MqlTradeRequest.deviation gibt an, "bis zu wie vielen Points Abweichung vom gesendeten Preis akzeptiert wird". Ist dieser Wert auf 0 bis wenige Points begrenzt, wird bereits die übliche Abweichung durch normale Tick-Updates abgelehnt. Ein klassischer Fehler ist zudem die Verwechslung: Points, nicht Pips (bei einem 5-stelligen Broker gilt 1 Pip = 10 Points).

Lösung:

1. deviation zunächst auf 10–30 Points (= 1–3 Pips) setzen und beobachten. Für Nicht-Scalping-Strategien sind 20 Points ein solider Ausgangspunkt
2. Prüfen, ob eine Einheitenverwechslung vorliegt (z. B. "deviation=5" in der Annahme, das entspreche 0,5 Pips)
3. Bei Strategien, die überhaupt keine Slippage zulassen sollen, die Ablehnung als gegeben akzeptieren und nur die Anzahl der Retry-Versuche steuern

③ Unterschiedliche Ausführungsart (Requote tritt nur bei Instant-Ausführung auf)

Symptom: Bei Broker A tritt es häufig auf, bei Broker B nie.

Ursache: Requote (10004) ist ein Phänomen, das ausschließlich bei Instant Execution auftritt. Bei Instant-Ausführung lautet die Order "führe genau zu diesem Preis aus" — bewegt sich der Preis, bietet der Server einen neuen Preis an (Requote). Bei Market Execution hingegen lautet die Order "führe zum aktuellen Marktpreis aus". Hier kann eine Requote grundsätzlich nicht auftreten, stattdessen wird zum abweichenden Preis direkt ausgeführt (Slippage).

Das heißt: "Keine Requotes = besser" stimmt nicht — es handelt sich um einen Trade-off zwischen Ablehnung und Ausführung mit Slippage. Die Ausführungsart eines Symbols lässt sich im Feld "Execution" der Symbol-Spezifikation in MT5 oder im Code über SYMBOL_TRADE_EXEMODE prüfen.

Lösung:

1. Die Ausführungsart des eigenen Kontos prüfen (bei vielen internationalen Brokern arbeiten Standardkonten mit Market Execution, wodurch Requotes gar nicht erst auftreten)
2. Falls häufige Requotes die Strategie behindern, einen Kontotyp bzw. Broker mit Market Execution in Betracht ziehen
3. Da manche Broker deviation auch bei Market Execution respektieren und andere nicht, sollte bei geringer Toleranz gegenüber starker Slippage die tatsächliche Slippage anhand der Ausführungshistorie überprüft werden

④ Dünne oder ausgesetzte Kurse zu bestimmten Zeiten oder bei bestimmten Symbolen

Symptom: 10021 tritt um Mitternacht Serverzeit (Rollover), unmittelbar nach der Wochenend-Eröffnung, in ruhigen Phasen wie um Weihnachten oder bei wenig liquiden Symbolen auf.

Ursache: Während des Rollovers wird wegen der Swap-Verarbeitung die Kursübermittlung teils vorübergehend ausgesetzt oder der Spread weitet sich extrem aus. Unmittelbar nach der Wochenend-Eröffnung oder bei wenig liquiden Symbolen sind ohnehin kaum verarbeitbare Kurse vorhanden. Eine Order in dieser Situation führt zu 10021 (keine Kurse).

Lösung:

1. Neue Einstiege in der Serverzeit zwischen 23:55 und 0:05 Uhr vermeiden (Zeitfilter)
2. Die ersten Minuten nach der Wochenend-Eröffnung meiden (Einstellungen wie AvoidMondayOpen)
3. Einen Spread-Filter (MaxSpread) einsetzen. Da sich der Spread bei dünnen Kursen ausweitet, wird dieser Zeitraum dadurch praktisch automatisch umgangen

⑤ Verbindungslatenz (VPS zu weit vom Broker-Server entfernt)

Symptom: Unabhängig von Uhrzeit und Symbol deutlich häufiger als in anderen Umgebungen. Hoher Ping-Wert.

Ursache: Je länger die Hin- und Rücklaufzeit (Latenz) bis zum Server dauert, desto höher die Wahrscheinlichkeit, dass sich der Preis in dieser Zeit bewegt. Wer vom heimischen PC oder über einen VPS in einer Region weit entfernt vom Broker-Server (häufig London, New York etc.) arbeitet, erhöht strukturell die Häufigkeit von 10004/10021. Der unten rechts in MT5 angezeigte Ping-Wert ist ein guter Anhaltspunkt (mehrere hundert ms sind klar nachteilig, einige zehn ms oder weniger sind wünschenswert).

Lösung:

1. Den Ping-Wert unten rechts in MT5 prüfen; ist er dauerhaft hoch, die Ausführungsumgebung des EA überdenken
2. Auf einen VPS in einer Region nahe dem Broker-Server umziehen. Ehrlich gesagt lässt sich die latenzbedingte Häufigkeit von 10004/10021 nicht durch Code reduzieren — die einzige Lösung ist die physische Nähe. Eine Auswahlhilfe finden Sie unter Wie man den richtigen VPS für EAs wählt
3. Je mehr ein EA auf Scalping ausgelegt ist, desto größer der Einfluss der Latenz. Bei EAs auf Tages- oder H4-Basis hat diese Ursache eine niedrigere Priorität

Code zur Reduzierung dieses Fehlers in MQL5 (für EA-Entwickler)

Es gibt drei Grundprinzipien: (1) deviation realistisch setzen, (2) bei Ablehnung den aktuellsten Tick neu abrufen und erneut senden, (3) Retries ausschließlich auf preisbedingte retcodes beschränken.

deviation korrekt in Points einstellen

MqlTradeRequest req; MqlTradeResult res;
ZeroMemory(req); ZeroMemory(res);
req.action    = TRADE_ACTION_DEAL;
req.symbol    = _Symbol;
req.type      = ORDER_TYPE_BUY;
req.volume    = lots;
req.deviation = 20;   // Zulässige Slippage 20 Points (bei 5-stelligem Broker 2,0 Pips)
// req.price / req.sl / req.tp / req.magic ebenfalls setzen

Die Einheit von deviation ist Points. Bei Brokern mit 5-stelliger (bzw. 3-stelliger) Notierung entsprechen 10 Points 1 Pip. Ein Wert von 0 oder ein extrem kleiner Wert erhöht die Ablehnungsrate unnötig.

Nur bei preisbedingten retcodes erneut senden (mit dem aktuellsten Tick)

Entscheidend ist, bei jedem Retry den Preis über SymbolInfoTick() neu abzurufen (wird mit dem alten Preis erneut gesendet, kommt lediglich dieselbe Ablehnung zurück), sowie Retries nur auf 10004/10021 zu beschränken. Ein automatisches erneutes Senden bei unzureichendem Kapital (10019) oder ungültiger Anfrage (10013) bringt nichts und verschmutzt nur das Log.

bool IsRetryableRetcode(uint rc)
{
   return (rc == TRADE_RETCODE_REQUOTE       // 10004
        || rc == TRADE_RETCODE_PRICE_OFF);   // 10021
}

// Preis mit dem aktuellsten Tick aktualisieren und bis zu 3-mal erneut senden
bool SendWithRetry(MqlTradeRequest &req, MqlTradeResult &res, int maxTries = 3)
{
   for(int attempt = 0; attempt < maxTries; attempt++)
   {
      MqlTick tick;
      if(!SymbolInfoTick(req.symbol, tick))
      {
         Print("SymbolInfoTick failed: ", GetLastError());
         return false;
      }
      req.price = (req.type == ORDER_TYPE_BUY) ? tick.ask : tick.bid;

      if(OrderSend(req, res) && res.retcode == TRADE_RETCODE_DONE)
         return true;                          // Order erfolgreich ausgeführt

      if(!IsRetryableRetcode(res.retcode))
      {
         PrintFormat("OrderSend failed (no retry): retcode=%d", res.retcode);
         return false;                         // Bei anderen retcodes kein Retry
      }
      PrintFormat("Retry %d/%d after retcode=%d", attempt + 1, maxTries, res.retcode);
      Sleep(200 + 150 * attempt);              // Schrittweise warten: 200ms → 350ms → 500ms
   }
   Print("Order abandoned after retries (price kept moving).");
   return false;
}

Die Wartezeit von Sleep() wird schrittweise verlängert, da im Moment einer plötzlichen Kursbewegung ein sofortiges (0 ms) mehrfaches Senden nur dieselbe Ablehnung wiederholt provoziert. Wartet man dagegen zu lange, entfernt sich der Einstiegspreis zu weit von der strategischen Vorgabe — Retries sollten daher nach 2–3 Versuchen abgebrochen werden. Bei Pending Orders (TRADE_ACTION_PENDING) lautet der retcode bei Erfolg TRADE_RETCODE_PLACED (10008) — das sollte ebenfalls beachtet werden.

Den neu angebotenen Preis bei Requote (10004) nutzen

Bei 10004 enthalten bid / ask in MqlTradeResult den vom Server neu angebotenen Preis. Ein erneutes Senden mit dem aktuellsten Tick wie oben ist in der Praxis meist ausreichend. Wer bei Instant Execution jedoch eine Logik nach dem Muster "wenn der neu angebotene Preis innerhalb der Toleranz liegt, annehmen" umsetzen möchte, vergleicht res.ask / res.bid mit dem ursprünglich erwarteten Preis in Points, bevor erneut gesendet wird.

Zeiträume definieren, in denen grundsätzlich keine Order gesendet wird

Retry-Logik im Code ist eine symptomatische Behandlung. Wirksamer ist grundsätzlich ein Filter, der neue Einstiege rund um Rollover, Nachrichtentermine und bei ausgeweitetem Spread verhindert.

// Beispiel für einen Spread-Filter: Bei weitem Spread auf neue Einstiege verzichten
long spreadPts = SymbolInfoInteger(_Symbol, SYMBOL_SPREAD);
if(spreadPts > MaxSpreadPoints)
{
   // Neuen Einstieg aussetzen (vermeidet automatisch dünne Kursphasen, in denen 10021 häufig auftritt)
   return;
}

Die von FXEA365 angebotenen EAs implementieren diesen Spread-Filter, News-Filter und automatischen Retry bei preisbedingten retcodes standardmäßig.

Prioritäten-Checkliste

Zusammenfassung

• 10021 (TRADE_RETCODE_PRICE_OFF) bedeutet "keine verarbeitbaren Kurse vorhanden", 10004 (TRADE_RETCODE_REQUOTE) bedeutet "Angebot eines neuen Preises". Beide gehören zur selben Familie preisbedingter Ablehnungen wie die MT4-Fehler 136/138 und haben nichts mit Kapital oder Lotgröße zu tun.
• Die Ursachen lassen sich auf fünf Punkte zurückführen: plötzliche Kursbewegung, zu enge deviation, Instant Execution, dünne Kurse zu bestimmten Zeiten/bei bestimmten Symbolen sowie Verbindungslatenz.
• Requotes sind ein Phänomen, das ausschließlich bei Instant Execution auftritt; bei Market Execution zeigt sich stattdessen Slippage. "Kein Auftreten = gut" gilt nicht — es handelt sich um einen Trade-off.
• EA-Entwickler sollten dauerhaft vorbeugen durch 2–3 Retries mit Neuabruf des aktuellsten Ticks (beschränkt auf 10004/10021), eine passende deviation-Einstellung sowie Zeit-/Spread-Filter. Nur der latenzbedingte Anteil lässt sich ausschließlich durch physische Maßnahmen (VPS näher am Broker) reduzieren.

Eine Gesamtübersicht aller Fehlercodes finden Sie im umfassenden Leitfaden zu MQL5/MT5-Fehlercodes, kostenlose EAs mit diesen Maßnahmen als Standardimplementierung in der EA-Übersicht.

FAQ

F: Was ist gravierender, 10004 oder 10021?

Beide sind vorübergehende, preisbedingte Fehler ohne wesentlichen Unterschied im Schweregrad. 10004 bedeutet "ein neuer Preis wurde angeboten", 10021 bedeutet "es gab keine verarbeitbaren Kurse" — das ist der Unterschied in der Serverantwort. Einzelne Vorkommnisse können ignoriert werden. Nur bei gehäuftem Auftreten zu bestimmten Zeiten oder bei bestimmten Symbolen sollte die Ursache (News, Rollover, deviation, Verbindung) behoben werden.

F: Ist ein Broker, bei dem nie eine Requote auftritt, besser?

Das liegt sehr wahrscheinlich an der unterschiedlichen Ausführungsart. Bei Konten mit Market Execution kann eine Requote grundsätzlich nicht auftreten — bewegt sich der Preis, wird stattdessen direkt zum abweichenden Preis ausgeführt (Slippage). Da es sich um einen Trade-off zwischen Ablehnung und Slippage handelt, sollte die tatsächliche Slippage anhand der Ausführungshistorie beurteilt werden.

F: Bei meinem MT4-EA treten die Fehler 136 / 138 auf. Gelten dieselben Maßnahmen?

Ja. 136 (ERR_OFF_QUOTES) entspricht 10021, 138 (ERR_REQUOTE) entspricht 10004 — Ursache und Maßnahmen sind identisch. In MQL4 war es Standard, vor dem erneuten Senden RefreshRates() aufzurufen, um Bid / Ask zu aktualisieren — derselbe Gedanke wie der Neuabruf über SymbolInfoTick() in MQL5.

F: Im Backtest tritt der Fehler nicht auf, im Live-Betrieb schon.

Das ist normal. Im Strategy Tester existiert die "Verzögerung bis zum Eintreffen der Order beim Server" sowie die "Kursbewegung währenddessen" nicht (oder nur vereinfacht), weshalb sich 10004/10021 ausschließlich im Forward-Betrieb zeigen. Selbst bei gutem Backtest-Ergebnis sind im Live-Betrieb zusätzlich eine passende deviation-Einstellung, Retry-Logik und eine geeignete Ausführungsumgebung (VPS) erforderlich.