MQL5 OrderCheck: Why a Passed Check Is Not a Filled Trade

Published 2026-11-05 · Author: AlgoWay

View Markdown

Separate trade request validation, submission and execution records

A trading robot can report a successful check without having bought or sold anything. In MQL5, OrderCheck() examines a proposed trade request. It does not send that request for execution, and its success is not a fill receipt.

For automated trading, keep request validation, submission and executed volume as separate facts. When reviewing an AlgoWay MT5 workflow, apply the same distinction to the evidence you collect: a successful upstream step cannot substitute for the destination account's execution records. The functions below are public MQL5 APIs, not a description of AlgoWay's private implementation.

Read the check result, not just true or false

MetaQuotes explicitly warns that a true return from OrderCheck() does not guarantee successful execution. Inspect the returned check structure and use the documented error information when the call fails. The official example even shows a successful check followed by a sending failure on a closed market. See the OrderCheck reference.

This makes a common log message, “trade successful,” dangerously vague if it is printed immediately after the check. “Request check completed” describes the evidence much better. Give the later submission and execution steps their own records.

The MqlTradeCheckResult documentation lists the reply code, comment and projected account figures, including margin and free margin. These are check results for the proposed operation. They are not proof that the account has already taken on the resulting exposure.

For example, suppose a check reports projected free margin of 800 account-currency units. Recording that figure under “estimated free margin after request” preserves its meaning. Recording it as an observed post-fill balance invents an event the check has not established. This is an illustrative logging example, not a measured account result.

Sending is another boundary

OrderSend() submits a trade request. Its Boolean return still does not, by itself, establish a completed market fill. MetaQuotes says to inspect the server response code in the returned result, and the external-system code where applicable. Order or deal information may be available in that response, while later execution events can arrive after the call returns. See the OrderSend reference.

Evidence collected	What to record	What it does not establish alone
Request check	Check outcome, reply code, comment and projected margin	A submitted order or an actual fill
Submission response	Sending outcome and server response details	Full execution merely because the Boolean is true
Execution records	Relevant deals, their volume and resulting account state	That every other request has also completed

A useful review question is therefore not “did the function succeed?” but “which function, and what did its result say?” Those two extra details often decide whether you are fixing an invalid request, waiting for execution or investigating a completed trade.

Follow transactions without assuming their order

MQL5 provides OnTradeTransaction() for trade-event handling. One request can generate several transactions, and MetaQuotes does not guarantee their arrival priority. Account state may also change while the handler runs. The handler's request and result arguments carry the relevant additional information for request-type transactions; they should not be treated as populated identically for every event type. These details are documented in OnTradeTransaction.

For a custom robot, this argues for recording identifiers and transaction types, then reconciling them with current orders and history. Counting callbacks as completed trades is a poor substitute. Keep the handler short enough to avoid unnecessary processing delays, and do slower reporting work elsewhere.

Imagine a request for 1.00 lot and execution evidence showing 0.40 lot so far. The unresolved question concerns the other 0.60 lot and the order's current state. A new request for another 1.00 lot would be a new trading decision, not a harmless repetition of a check. This is a hypothetical reconciliation example; it does not predict a particular broker's fill pattern.

A practical review sequence

For a custom EA, retain the intended symbol, action and volume alongside each stage's result. If the check fails, diagnose the reported issue before submitting. If submission happens, inspect its actual response. If the execution outcome remains uncertain, examine the relevant order and deal records before deciding whether anything should be retried.

The companion guide to MT5 orders, deals and positions explains how those records differ. The distinction here comes one step earlier: validating a request has not created those execution records at all.

Review logs from a demo workflow against this sequence before relying on a custom robot's success messages. This article has not run an EA or tested broker execution. Its purpose is to make each claim in a log answerable: checked, submitted, rejected, partially executed or completed, with the corresponding evidence attached.