MT5 · code and request checks
MT5 error 10013: check the filling value before changing it
Your EA can carry an invalid filling value before any broker rule is checked. My MT5 run passed 6 local filling-value checks and sent zero orders. I check the value and its meaning before trying another policy.
Arnold Holm · 2026-10-18
What the error means
An EA is a program that applies your trading rules in MetaTrader. Error 10013 means the trade request was invalid, but the number alone does not identify the bad field. In the original trader question, the request log showed a large negative filling value. The author later reported success after setting IOC explicitly. That is evidence about that example, rather than a universal setting to paste into every EA. A filling policy tells the server how an order may be filled. FOK, IOC, RETURN and BOC are named choices, each with conditions. Start by checking whether the value in the request is actually one of those choices. A random negative integer is a different problem from a valid choice that does not suit the symbol or order. Mixing the two hides the reason for a failure. There is another trap. SYMBOL_FILLING_MODE returns flags describing symbol capabilities. MqlTradeRequest.type_filling expects an ENUM_ORDER_TYPE_FILLING choice. Both can appear as integers in a log, but that does not make them interchangeable. In my run the symbol flags were 3, and the numeric value of ORDER_FILLING_BOC was also 3. Copying the former into the latter would turn a capability mask into an order choice. An equal number has not established equal meaning. My first check is deliberately small. It rejects integers outside the four named constants. A known constant stays in a state that requires context checks. I prefer that explicit boundary to a helper whose true return value silently means both known integer and permitted order.
Three code paths to check
1. The request contains an unassigned or damaged filling value.
Log type_filling immediately before the request, together with the symbol and order type. If you see an unexpected negative number or another value outside the named constants, find where it was assigned. Replacing it at the last moment can hide the upstream defect. Initialise the request and assign each required field deliberately.
2. A symbol capability mask is copied into an order enum.
Keep the value returned by SYMBOL_FILLING_MODE separate from the selected filling enum. Decode the symbol flags for the relevant symbol, then select a named policy using the official rules. Do not cast the raw mask into type_filling because the compiler accepts the integer. The run below preserves both reads so the collision is visible.
3. A valid enum is treated as permission to send.
The enum name is only the first check. Execution mode, order type and the symbol capabilities still matter. RETURN, for example, is not available for Market Execution. BOC is a passive policy with its own supported order types. An IOC report from another account does not settle any of those conditions for yours. Keep the actual check result and server return code for the request you are investigating.
Six local comparisons in native MT5
I compiled and ran this original guard in MT5 build 6230. Two inputs, -370154256 and 999, returned INVALID_ENUM_NO_REQUEST. The four named constants returned KNOWN_ENUM_CHECK_CONTEXT. All six comparisons passed. The compiler reported zero errors and zero warnings. The separate EURUSD read recorded filling flags 3 and execution mode 2. The enum values were FOK 0, IOC 1, RETURN 2 and BOC 3. That makes the flags-versus-enum issue concrete without pretending that the guard selected the correct policy. I kept the context state in the function name and output so a caller cannot reasonably read it as broker approval. The screenshot shows these local results in the terminal. The script did not call OrderSend or OrderCheck. It isolates one early validation step, which is useful before investigating a rejected request but does not replace the rest of that investigation.
string FillingState(long raw)
{
if(raw==(long)ORDER_FILLING_FOK || raw==(long)ORDER_FILLING_IOC ||
raw==(long)ORDER_FILLING_RETURN || raw==(long)ORDER_FILLING_BOC)
return "KNOWN_ENUM_CHECK_CONTEXT";
return "INVALID_ENUM_NO_REQUEST";
}Six local integer checks, zero orders and no server 10013 reproduced. This guard does not validate the complete request or select a filling policy.
How you know it is fixed
Unexpected integers stop locally
Pass -370154256 and 999 to the guard. Both must return INVALID_ENUM_NO_REQUEST. Confirm that the caller does not fall through to sending a request.
Known enums still need context
Pass each named constant. The result must say KNOWN_ENUM_CHECK_CONTEXT. Inspect the separate symbol capability flags, execution mode and order type before choosing a policy.
Your five-minute request check
Take one failed request log. Write down the symbol, order type, type_filling, symbol flags, execution mode and actual return code. Trace where type_filling was assigned. If a raw flag mask was cast directly into it, separate those values before testing again.
Your own source
Find the next line to check
Start with the free EA-Check. Your code stays in your browser. It highlights patterns with line numbers; it does not prove the broker accepts an order.
Want one small change shown on your own case?
R49: one authorised, reproducible MT4/MT5 defect in readable source up to 500 lines, with three agreed cases. 49 USD fixed. Delivery within 48 hours after source review and funding. The exact case is agreed before funded work.
Send the expected and actual behaviourRelated checks
Common questions
Does setting IOC fix every 10013 error?
No. It changed the reported example. Error 10013 covers invalid requests, so inspect the actual fields and the conditions for the selected policy.
Did this test reproduce the server error?
No. It tested an integer guard locally. It sent no requests and did not test a broker accepting or rejecting an order.
Sources and limits
- Original trader question: invalid request and negative filling value
- Official filling policies and execution-mode table
- Native local run: six checks and zero orders
These public questions explain the error; use your own EA log to check whether the same cause applies.