A self-learning EA is only as trustworthy as the trade log it learns from. If a single position closes in three separate pieces — a partial close, a scale-out, and a final close — and the logging code treats each of those as its own row, the resulting CSV overstates the trade count and fragments the true profit or loss across multiple lines. Getting this right in MT5 turns out to be more subtle than it sounds, because of how MT5 itself fires trade events.
Why One Position Can Generate Multiple Closing Deals
The EA's exit management includes partial position closes and scale-outs at intermediate profit targets (1.5R and 2.5R respectively), on top of the final close at the 3R take-profit or stop-loss. That means a single logical trade can involve three or more separate MT5 deals before it's fully closed — each one technically a distinct closing transaction, even though from a trading-performance perspective it's still just one trade with one net outcome.
The Fix: Accumulating P&L and Volume Per Position
Rather than logging each closing deal as its own CSV row, the OnTrade event handler accumulates profit/loss and volume across every closing deal that belongs to the same position, and only writes a single consolidated row once the position is fully flat. This means the CSV reflects true net profit per position — matching how a trader actually thinks about "did this trade win or lose" — rather than three fragmented partial results that would each look smaller (or occasionally, misleadingly, larger) than the real outcome.
The Hidden Bug: MT5 Double-Firing DEAL_ADD
Consolidating deals by position sounds straightforward until MT5's own event behavior gets involved: MT5 can fire the DEAL_ADD transaction event twice for the same underlying deal under certain conditions. Without a safeguard, this would cause the same closing deal to be counted twice in the accumulated P&L — silently inflating or duplicating the logged result for that position. The fix is a dedup guard inside the OnTrade handler that tracks which deal tickets have already been processed, so a duplicate DEAL_ADD firing for a deal already accounted for is simply ignored.
This is a good example of a bug that would be nearly invisible without deliberately looking for it — the EA would appear to work correctly in normal use, and only a careful audit of deal tickets against the logged CSV rows would reveal that some positions were being double-counted.
Getting the Exit Reason Right, Not Just the Profit
A related problem: knowing how much a position made or lost isn't enough if the logged exit reason is wrong. MT5's own DEAL_REASON field reports why a position closed from the broker/terminal's perspective, but this EA's exit logic can move a position's stop-loss to break-even or trail it before the position ultimately closes — meaning a position that closes at what looks like "stop-loss hit" might actually have closed at a profitable break-even-adjusted level, or a trailing-stop level, not the original SL. To log this accurately, the EA sets its own "pending exit" tag internally at the moment it decides why a position should close, and that internally-set reason takes priority over the raw broker DEAL_REASON when writing the CSV row. This lets the Statistics and Learning Engine correctly distinguish a break-even exit from a true stop-loss hit, and a trailing-stop exit from either — a distinction that matters a great deal when the Learning Engine is using win-rate and expectancy to adjust future confidence scoring.
Why This Level of Care Matters for a Self-Learning System
None of this affects whether individual trades are profitable — it's purely about whether the EA's own record of its performance is accurate. But for a system that feeds its own trade history back into future decisions, a corrupted or fragmented log doesn't just produce misleading reports for the trader to read later — it actively teaches the Learning Engine the wrong lesson. A double-counted losing position, or a break-even exit misclassified as a stop-loss, both distort the win-rate and expectancy numbers that future confidence-score adjustments depend on. Getting the plumbing right here is a precondition for the learning system being trustworthy at all, not a nice-to-have detail.
Related Reading
- Inside a Self-Learning MT5 EA's 8-Factor SMC Confidence Score (and a Learning Engine Bug)
- Percentage-Risk Sizing and Correlation Filtering in an MT5 EA (No Martingale, No Grid)
- Grading Structure Breaks in an MT5 SMC EA: The V1.49 Structure Scoring Redesign
- Drawing a Live Dashboard on an MT5 Chart: Canvas-Based Equity Curve and Confidence Gauge
.png)
0 Comments