How to audit request-to-deal execution logs before trusting multi-asset MT5 systems

How to Audit Request-to-Deal Execution Logs Before Trusting Multi-Asset MT5 Systems

Automated trading systems for MetaTrader 5 are often evaluated on one criterion: whether the signal logic looks reasonable. Traders inspect indicator parameters, review a backtest equity curve, and form a judgment. What rarely receives equal scrutiny is the space between a signal firing and a position actually opening — the execution layer. That gap is where multi-asset systems can fail in ways backtests do not reveal.

This article explains how to read MetaTrader 5 execution logs at the request-to-deal level, why that audit matters alongside signal quality, and what a practical pre-live verification workflow looks like. The focus is on intermediate traders evaluating an automated system — whether built in-house or sourced externally — before committing real capital across multiple instruments.

1. What the Execution Log Actually Records

MetaTrader 5 separates trading activity into three distinct objects: orders, deals, and positions. Understanding the difference is the foundation of any honest audit.

• An order is a request sent to the broker. It can be rejected, partially filled, re-quoted, or cancelled before it becomes anything else.
• A deal is a confirmed execution — the record that a transaction occurred at a specific price, volume, and timestamp.
• A position is the net result of one or more deals on a single instrument.

When a signal fires and an Expert Advisor calls OrderSend() , the terminal sends a trade request. The broker's server processes that request and returns a result code. If execution succeeds, a deal is recorded in the account history, accessible via HistoryDealSelect() . If it fails — due to a requote, invalid price, insufficient margin, or a symbol-specific restriction — a log entry still exists, but no deal follows.

This distinction matters. A system can appear to be working because it sends requests continuously, while a meaningful percentage of those requests fail. The live account equity curve may then diverge from expectation not because the signal was wrong, but because execution was incomplete.

2. Why This Matters Specifically for Multi-Asset Systems

A single-instrument Expert Advisor operating on one currency pair has a relatively contained execution environment. Margin requirements are predictable, spread behavior is consistent, and fills can be monitored manually if needed.

A multi-asset system changes that environment. When an EA simultaneously manages positions across, for example, a major forex pair, an index CFD, a commodity, and a crypto instrument within the same MT5 account, several complications arise:

• Each instrument has its own spread profile, which widens differently during news events or low-liquidity periods.
• Each instrument carries its own margin requirement, and those requirements can shift intraday based on broker risk parameters.
• Each instrument may operate under a different execution mode — instant execution on some symbols, market execution on others — so the broker's handling of slippage varies by instrument.
• Some instruments have trading hours restrictions that produce order rejections at times the EA does not anticipate.

When multiple symbols are active simultaneously, a failed execution on one instrument is not simply a missed trade. It can affect other positions: sizing logic that assumed a hedge was in place may be left unhedged; a correlated entry that depended on another leg executing first may create unintended directional exposure; margin freed by a failed close may be consumed by a new entry elsewhere. The signal layer has no visibility into any of this. Only the execution log does.

3. The Common Automation Mistake: Assuming Execution Mirrors Intent

The most pervasive mistake when evaluating automated multi-asset systems is treating signal generation and trade execution as a single unified process. In MetaTrader 5's Strategy Tester, execution is idealized by default: orders fill at the requested price unless explicit slippage modeling is configured, requotes do not exist, and margin behavior in multi-symbol tests differs from live broker conditions.

This creates a systematic blind spot. A trader reviews a backtest, finds the logic coherent, and concludes the system is sound. When run live, actual results diverge from the test — not dramatically at first, but consistently, and more so during volatile sessions. The cause is often that the system was never validated in a real execution environment.

This assumption takes several specific forms:

1. Fill assumption: Believing every order will fill at or near the requested price across all instruments at all times.
2. Latency assumption: Believing the time between signal and execution is negligible and uniform across symbols.
3. Rejection blindness: Not instrumenting the EA to handle, log, and respond to non-zero return codes from OrderSend() .
4. Margin assumption: Not accounting for how simultaneous entries across correlated instruments can consume margin in ways the model did not anticipate.

Each assumption is testable on a demo account before any live capital is involved.

4. The Technical Chain: From Request to Deal or Failure

To audit execution logs intelligently, a trader needs to understand the steps connecting a trade request to its outcome. In MT5, each step can produce a distinct failure mode.

Step 1: The EA calls OrderSend()

The EA constructs an MqlTradeRequest structure and passes it to OrderSend() . The function returns a boolean and populates an MqlTradeResult structure. A return value of true means the request was accepted for processing — not that the trade executed.

Step 2: The broker server processes the request

The server checks price validity, available margin, instrument trading hours, position limits, and broker-specific risk rules, then returns a result code. The critical field is result.retcode . A value of TRADE_RETCODE_DONE (10009) indicates success. Any other value indicates a problem that must be handled.

Step 3: The deal is recorded or rejected

If the retcode is TRADE_RETCODE_DONE , a deal ticket is assigned and appears in the account's deal history, accessible via HistoryDealSelect() and the HistoryDeal* family of functions. If the retcode indicates failure — such as TRADE_RETCODE_REQUOTE , TRADE_RETCODE_PRICE_OFF , TRADE_RETCODE_NO_MONEY , or TRADE_RETCODE_MARKET_CLOSED — no deal is created.

Step 4: The EA responds, or fails to

An EA that does not explicitly check result.retcode after every OrderSend() call has no mechanism for detecting failures. It continues executing signal logic as though the previous order succeeded, and the actual state of positions diverges from the EA's internal model. In a multi-asset system this divergence accumulates across instruments. By the time it appears in the account balance, the root cause — a pattern of undetected execution failures — can be difficult to trace unless logging was in place from the start.

5. How to Test This in MetaTrader 5: A Demo-First Workflow

The following workflow is designed to run on a demo account before any live deployment. It has three phases: instrumentation, observation, and audit.

Phase 1: Instrument the EA for Execution Logging

If you are evaluating an externally built system, ask the developer to confirm that all OrderSend() calls check and log result.retcode . If you are building your own system, add explicit logging at every execution point.

A minimal logging pattern in MQL5:

// Pseudocode — illustrates structure, not a complete compilable EA MqlTradeRequest request = {}; MqlTradeResult result = {}; // Populate request fields here (symbol, volume, type, price, sl, tp) bool sent = OrderSend(request, result); if (!sent || result.retcode != TRADE_RETCODE_DONE) { PrintFormat("OrderSend failed | Symbol: %s | Retcode: %d | Comment: %s", request.symbol, result.retcode, result.comment); } else { PrintFormat("Deal confirmed | Symbol: %s | Deal: %d | Price: %.5f | Volume: %.2f", request.symbol, result.deal, result.price, result.volume); }

This creates a structured record in the MT5 Experts log tab for every execution attempt, whether it succeeds or fails. That log should be the first thing you review after any demo session.

Phase 2: Run Across Multiple Instruments During Active Sessions

Demo testing loses much of its diagnostic value if run only during low-volatility periods. To surface execution failures, schedule demo runs that cover:

• Major session overlaps (London/New York for forex instruments)
• Scheduled news releases on instruments the system trades
• End-of-day or weekend rollover periods for instruments with overnight restrictions
• Periods when multiple signals fire within the same one-to-two bar window across different symbols

A system that handles execution cleanly during quiet midweek hours may behave differently when multiple instruments are moving simultaneously under higher volatility.

Phase 3: Audit the Log and History Against Each Other

After a demo run of at least one to two weeks covering active sessions, conduct a formal reconciliation by comparing three data sources:

1. The Experts log — every OrderSend() attempt and its retcode
2. The MT5 account history — every confirmed deal, accessible from the History tab filtered by date and symbol
3. The EA's internal signal log — every signal event that triggered an execution attempt

The reconciliation question is straightforward: for every signal logged, was there a corresponding order attempt? For every order attempt, was there a confirmed deal? Where the chain breaks, investigate the retcode.

Deal history can also be queried programmatically:

// Pseudocode — illustrates HistoryDeal query pattern
datetime from = D'2024.01.01 00:00';
datetime to   = TimeCurrent();

if (HistorySelect(from, to))
{
   int total = HistoryDealsTotal();
   for (int i = 0; i < total; i++)
   {
      ulong ticket = HistoryDealGetTicket(i);
      string sym   = HistoryDealGetString(ticket, DEAL_SYMBOL);
      double price = HistoryDealGetDouble(ticket, DEAL_PRICE);
      double vol   = HistoryDealGetDouble(ticket, DEAL_VOLUME);
      long   type  = HistoryDealGetInteger(ticket, DEAL_TYPE);
      PrintFormat("Deal %d | %s | Type: %d | Price: %.5f | Vol: %.2f",
                  ticket, sym, type, price, vol);
   }
}

Cross-referencing this output against the signal log reveals execution gaps that would otherwise be invisible.

6. A Practical Decision Checklist Before Going Live

The following checklist translates the technical audit into observable verification gates. Each item should be confirmed from demo logs before any live deployment decision.

These gates are diagnostic rather than binary. A system that fails one gate has revealed a specific, addressable problem. The appropriate response is to investigate, fix or configure around the problem, re-run the demo, and re-check the gate — not to discard the system without investigation, and not to ignore the failure and proceed to live capital.

7. Ongoing Verification Between Sessions

This audit is not a one-time exercise. Execution conditions change as brokers adjust margin requirements, instrument availability shifts, and market regime changes alter spread behavior. A system that passed execution audit during a low-volatility period warrants re-verification when conditions change materially.

Before each live session with any multi-asset automated system, consider these steps:

1. Open the Experts log from the last session and search for any retcode other than 10009 . If rejections appear, trace them to specific symbols and times before continuing.
2. Compare signal count to deal count for the session. A mismatch means the EA is operating in a state that differs from its intended design.
3. Check the account history for any open position without a confirmed stop-loss. Stop-losses attached via OrderSend() appear as part of the position record in MT5. An absence is a risk-control failure.
4. Review margin utilization at peak simultaneous exposure during the session. If the system approached high margin use, consider the effect on open positions if one instrument moves sharply against the account.
5. Document what you find. A brief written session log creates an evidence base that makes pattern recognition possible over time. A single anomaly may be noise; a recurring pattern of the same anomaly is a structural problem.

A signal alone does not make a system trustworthy. The regime it operates in, the quality of its execution, and the robustness of its risk controls are each necessary conditions that must be evaluated independently. The execution log is where all three leave a verifiable trace. Reading it is not an advanced skill reserved for system developers — it is a basic responsibility for any trader who intends to automate capital across multiple instruments.

Practical next step: If you want to evaluate this mechanism without forcing one strategy onto every market condition, the Ratio X Trader's Toolbox includes specialist MT5 systems for different jobs. Start on demo and examine how risk-control workflows apply to the context described above.

Evaluate the Ratio X Trader's Toolbox on Demo

The Ratio X Trader's Toolbox brings together 10 specialist systems, including one indicator, for regime analysis, trend, range, breakout, execution and XAUUSD workflows. It is designed for structured evaluation—not guaranteed trading results.

Lifetime access is available for a one-time payment of $147, backed by a 7-day money-back guarantee. Test one relevant module on demo, follow its setup guidance and decide whether it fits your process.

Explore the Ratio X Trader's Toolbox

If the Toolbox is the right fit and price is the final obstacle, use MQLFRIEND20 for 20% off. Only 10 coupons are available per month.