Unsupported Filling Mode (MT5 Error 10030)

You move an EA that has run flawlessly for months to a new broker, attach it to a chart, and the Experts tab fills up with Unsupported filling mode and OrderSend error 10030 — with not a single order going through. This is the single most common "day one on a new broker" failure in MT5. The EA isn't broken and your account is fine: the order's filling mode isn't allowed on this broker's symbol. That's the whole problem.

This is a complete reference for TRADE_RETCODE_INVALID_FILL (10030), written for both MT5 users running EAs and MQL5 developers writing them — what the error really means, FOK vs IOC vs RETURN, the 30-second check, and the auto-detect code that fixes it for good. For the full list of error codes, see the complete MT5 error-code guide.

What 10030 (TRADE_RETCODE_INVALID_FILL) means

The result of OrderSend() lands in MqlTradeResult.retcode. A 10030 = TRADE_RETCODE_INVALID_FILL is the server telling you: "the type_filling you specified in the request is not allowed on this symbol."

Meaning : the specified filling type is not supported
Constant: TRADE_RETCODE_INVALID_FILL
Value   : 10030
Log text: Unsupported filling mode / Invalid order filling type

// Typical log output
2026.07.07 09:15:32.441 EA_NAME EURUSD,M15: OrderSend error 10030
2026.07.07 09:15:32.441 EA_NAME EURUSD,M15: failed market buy 0.10 EURUSD [Unsupported filling mode]

The key insight: funds, lot size, and price have nothing to do with it. Error 10030 is about exactly one field — MqlTradeRequest.type_filling — and once that field carries an allowed value, the identical order goes straight through.

The four filling types

MQL5's ENUM_ORDER_TYPE_FILLING has four values:

For a typical forex EA the practical choice is FOK or IOC. RETURN matters for stocks and futures traded through exchange execution, and BOC is a niche tool for forcing maker orders.

Why a filling type becomes "invalid" — SYMBOL_FILLING_MODE

Which filling types are accepted is a per-symbol setting configured by the broker, exposed as flags via SYMBOL_FILLING_MODE:

long flags = SymbolInfoInteger(_Symbol, SYMBOL_FILLING_MODE);
// SYMBOL_FILLING_FOK flag set → FOK allowed
// SYMBOL_FILLING_IOC flag set → IOC allowed

SYMBOL_FILLING_MODE is a bitmask covering FOK and IOC (both flags set means both are allowed). RETURN is not part of the mask — whether it applies depends on the symbol's execution mode (below).

So the anatomy of 10030 is trivially simple:

type_filling sent by the EA ∉ filling types allowed on this symbol → 10030

Why it strikes the day you switch brokers

There's a reason 10030 is the classic broker-migration error:

1. Allowed filling policies differ per broker AND per symbol. One broker enables only FOK on its forex symbols, another only IOC, a third allows both. Even within one broker, forex, CFDs, and equities routinely carry different settings.
2. Many EAs hardcode type_filling. An EA containing request.type_filling = ORDER_FILLING_FOK; runs for years on FOK-only broker A. It works in the author's environment, so nobody ever flags it as a bug — and it ships that way.
3. If broker B doesn't allow FOK, every order fails from the very first tick. The strategy tester often won't reproduce it (the tester is more lenient than a live server), so the problem surfaces exactly on the day you go live on the new account.

In other words, 10030 usually isn't a bug in the strategy — it's a hardcoded environmental assumption being exposed. The flip side: teach the EA to read the symbol's flags and pick a filling type dynamically, and it runs on any broker (code below).

Execution mode context (SYMBOL_TRADE_EXEMODE)

Separate from the filling flags, every symbol has an execution mode, which shapes which filling types make sense:

The exact allowed combinations are up to the broker's server configuration, but a working rule of thumb is: market-executed forex/CFD → FOK or IOC; exchange-traded instruments → RETURN. You can read the mode with SymbolInfoInteger(_Symbol, SYMBOL_TRADE_EXEMODE).

30-second triage

① Check the symbol's allowed modes (in MT5)

Market Watch → right-click the symbol → Specification, and read the "Filling" row. It shows Fill or Kill, Immediate or Cancel, or both. If your EA sends a mode not listed there, 10030 is guaranteed.

② Check the EA's inputs

Well-built EAs expose an input like FillingType / Filling Mode. If yours does, set it to a mode listed in step ① and you're done — no code changes needed.

③ Check in code (for developers)

long flags = SymbolInfoInteger(_Symbol, SYMBOL_FILLING_MODE);
PrintFormat("%s filling: FOK=%s IOC=%s exemode=%d",
            _Symbol,
            ((flags & SYMBOL_FILLING_FOK) != 0) ? "yes" : "no",
            ((flags & SYMBOL_FILLING_IOC) != 0) ? "yes" : "no",
            (int)SymbolInfoInteger(_Symbol, SYMBOL_TRADE_EXEMODE));

Run that in a script and you get the broker's actual per-symbol policy in one line.

The permanent fix — auto-detect the filling mode in MQL5

The right fix for 10030 is not "adjust it by hand after every migration" — it's making the EA read the symbol's flags and choose the filling type itself. Here is the standard, drop-in implementation.

The auto-detect function

// Return a filling mode actually allowed on this symbol.
// Preference: FOK → IOC → RETURN (exchange-style fallback)
ENUM_ORDER_TYPE_FILLING GetFillingMode(const string symbol)
{
   long flags = SymbolInfoInteger(symbol, SYMBOL_FILLING_MODE);

   if((flags & SYMBOL_FILLING_FOK) != 0)
      return ORDER_FILLING_FOK;    // execute only on full fill (no partials)

   if((flags & SYMBOL_FILLING_IOC) != 0)
      return ORDER_FILLING_IOC;    // fill what's available, cancel the rest

   return ORDER_FILLING_RETURN;    // no flags = exchange-style symbols
}

Using it with OrderSend

MqlTradeRequest req; MqlTradeResult res;
ZeroMemory(req); ZeroMemory(res);

req.action       = TRADE_ACTION_DEAL;
req.symbol       = _Symbol;
req.volume       = lots;
req.type         = ORDER_TYPE_BUY;
req.price        = SymbolInfoDouble(_Symbol, SYMBOL_ASK);
req.deviation    = 20;
req.magic        = MagicNumber;
req.type_filling = GetFillingMode(_Symbol);   // ← never hardcode this

if(!OrderSend(req, res) || res.retcode != TRADE_RETCODE_DONE)
{
   if(res.retcode == TRADE_RETCODE_INVALID_FILL)   // 10030
      PrintFormat("Unsupported filling mode: sent=%d, allowed flags=%d",
                  (int)req.type_filling,
                  (int)SymbolInfoInteger(_Symbol, SYMBOL_FILLING_MODE));
   else
      PrintFormat("OrderSend failed: retcode=%d", res.retcode);
}

With this in place, the same binary runs on FOK-only and IOC-only brokers alike — no per-migration surgery.

If you use CTrade

The standard library's CTrade ships with SetTypeFillingBySymbol(), which reads the symbol's flags and configures the filling type automatically:

#include <Trade/Trade.mqh>
CTrade trade;

int OnInit()
{
   trade.SetExpertMagicNumber(MagicNumber);
   trade.SetTypeFillingBySymbol(_Symbol);   // auto-select from the symbol's flags
   return INIT_SUCCEEDED;
}

If your EA throws 10030 because of an old hardcoded trade.SetTypeFilling(ORDER_FILLING_FOK);, replacing it with this one line solves it. If you prefer explicit control, pass the result of the GetFillingMode() above into SetTypeFilling() — same effect.

A note on BOC for pending orders

ORDER_FILLING_BOC (Book or Cancel) is for limit and stop-limit orders only, and is rejected if the price would execute immediately. It is never the right value for a market order, so market-order EAs can safely ignore it.

Broker notes (re-check after migrations)

• Filling policies differ not only between brokers but between symbols on the same broker. Forex allowing IOC while equity CFDs accept only RETURN is a completely normal configuration.
• Account-type and server changes can flip the settings too. It's not only full broker migrations — server moves, account-type switches, and symbol-spec revisions at the same broker can all make 10030 appear out of nowhere.
• The operational rule: whenever the account, server, or symbol changes, re-check the Specification window (or run the script above). An EA with the auto-detect code makes even this check unnecessary.

We deliberately don't publish "broker X is FOK-only on symbol Y" tables here — such details change with server configuration updates and go stale. Always verify against your own account's symbol specification.

Priority checklist

Summary

• Unsupported filling mode (10030 / TRADE_RETCODE_INVALID_FILL) is a server rejection meaning the order's type_filling (FOK / IOC / RETURN / BOC) isn't allowed on that symbol. Funds and lot size are irrelevant.
• Because allowed policies vary per broker and per symbol, an EA with a hardcoded type_filling fails wholesale the day it lands on a new broker — the classic migration failure.
• Users fix it in 30 seconds via the symbol Specification plus the EA's input; developers fix it permanently by reading SymbolInfoInteger(SYMBOL_FILLING_MODE) and choosing dynamically (or calling CTrade::SetTypeFillingBySymbol()).

For all error codes, see the complete MT5 error-code guide. The EAs distributed by FXEA365 implement filling-mode auto-detection and run broker-independently — see the EA list.

FAQ

Q: My EA worked for months, then I switched brokers and now everything fails with 10030. Is the EA broken?

No. The filling type it specifies (e.g. FOK) simply isn't allowed on the new broker's symbol. Check the "Filling" row in the symbol Specification, then either change the EA's FillingType input to match or fix the code to auto-detect. The strategy itself is untouched.

Q: FOK or IOC — which should I use?

If the symbol allows both, the difference only shows up when liquidity is short: FOK cancels the whole order unless it fills completely (no partial positions), while IOC keeps whatever portion filled. At retail forex lot sizes, insufficient liquidity is rare, so in practice either works. Preferring FOK, as in the auto-detect code, is a sound default.

Q: It never happens in the strategy tester, only on the live account. Why?

The tester's fill handling doesn't fully replicate a live server's configuration, so a type_filling mismatch can stay invisible in testing. Whenever an EA first runs on a live or demo account, compare its filling setting against the symbol Specification before anything else.

Q: Same broker, but some symbols throw 10030 and others don't.

That's expected. Filling policies are configured per symbol, so forex pairs may accept IOC while equity CFDs accept only RETURN. Multi-symbol EAs must read SYMBOL_FILLING_MODE for each symbol they trade.

Q: I only have the .ex5 and can't edit the code. What are my options?

First check the EA's inputs for anything named FillingType or similar. If there is none, that EA cannot run on this broker's symbol as-is: ask the author for a fix, or run it on a broker/account type whose symbols allow the filling mode the EA assumes.