MT5 order rejected with retcode 10030: the fill mode enum is not the symbol flag

[Fairman]

MT5 order rejected with retcode 10030: the fill mode enum is not the symbol flag

A common EA bug on MT5: OrderSend comes back with retcode 10030, invalid fill type. The cause is usually a mix up between two different numbering schemes.

The symbol property SYMBOL_FILLING_MODE returns a bitmask of what the symbol allows: FOK is flag 1 and IOC is flag 2. The trade request's type_filling field uses a different enum: ORDER_FILLING_FOK is 0, ORDER_FILLING_IOC is 1 and ORDER_FILLING_RETURN is 2. If you take the symbol flag and pass it straight into the request, a symbol that allows only IOC gives you a 2, which the request reads as RETURN, and the server rejects it.

The mapping, which is where it goes wrong: flag 1 (FOK allowed) corresponds to enum 0, and flag 2 (IOC allowed) corresponds to enum 1. So flag 2 looks exactly like enum 2, which is Return, and nothing in the compiler warns you.

If type_filling is left unset it's 0, which is FOK, and that gets rejected on symbols that only allow IOC.

Return is treated as always available, except that it isn't allowed in Market execution mode, which is what many ECN style accounts use.

A short version that picks the mode from the flags:
int fm = (int)SymbolInfoInteger(sym, SYMBOL_FILLING_MODE);
ENUM_ORDER_TYPE_FILLING f = ORDER_FILLING_RETURN;
if((fm & SYMBOL_FILLING_IOC) != 0) f = ORDER_FILLING_IOC;
else if((fm & SYMBOL_FILLING_FOK) != 0) f = ORDER_FILLING_FOK;
request.type_filling = f;

Do this per symbol, not once per account. Different symbols on the same account often allow different modes.

[FXS HongKong Scalper]

A very common bug, thanks for spelling it out. The SYMBOL_FILLING_MODE flags can also be different on different account types at the same broker. An EA that works on a demo can fail on live if the live account uses a different execution mode. Checking the flags at startup and choosing the fill type from them, with a log line showing the choice, avoids this. For market execution symbols, RETURN is usually not allowed, so FOK or IOC should be selected.

[Fairman]

FOK and IOC behave differently once the volume is large. FOK means the whole volume at the price or nothing. IOC means fill whatever is available at the price or better, within your deviation, and cancel the rest, so partial fills are possible. A 0.1 lot order almost never splits. A 20 lot order on a news spike can fill 13.4 lots and drop the remainder. If the EA assumes the full volume filled, it'll report the wrong position size and manage a stop for a different amount than it holds. After sending, read the deal volume from the result or from the history, and compare it against the request.

[Fairman]

Print the allowed modes for every symbol the EA trades when it starts, so the log tells you what you're dealing with. Illustrative reading of the values: 3 means both the FOK and IOC flags are set, 1 means FOK only, 2 means IOC only, and 0 means neither flag is set, in which case the snippet above falls back to Return. Seeing those numbers in the Experts log at startup saves the hunt for a rejected order at the worst moment, and it makes it obvious when a symbol on the same account behaves differently from the one you tested on.

[Fairman]

A backtest can pass while live fails, because the tester takes its symbol specifications from the server the terminal is connected to, and brokers differ. An EA tested on a demo server that allows FOK and then run on a live server whose symbol is IOC only will test clean and reject orders live. If you can, run the tester on the same broker's server as the live account, and make the fill mode selection part of the code, not an input. And keep the 10030 retcode in the log with the symbol and the mode you tried, since the symbol alone doesn't tell you what went wrong.

[Fairman]

A way to check without risking a trade is OrderCheck. It fills an MqlTradeCheckResult with the retcode the server would give for a given request, without sending it. Loop over the three fill types for a minimum volume request, log the retcode for each, and you have a map for that symbol on that server, with 10030 showing where a mode isn't allowed. OrderCheck also reports problems with stops and volume, such as 10016 for invalid stops and 10014 for invalid volume, so one function catches a number of the common rejections. Do it on a demo first, then repeat on the live server, as the two can differ.