Discussing the article: "Adaptive Trade Management in MQL5: Building a Broker-Aware, Deterministic, and Explainable Exit Engine"
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Check out the new article: Adaptive Trade Management in MQL5: Building a Broker-Aware, Deterministic, and Explainable Exit Engine.
This article presents an MQL5 trade-management engine that converts exit rules into proposal generators. A policy engine ranks all proposals by a configurable reason priority with documented tie-breakers. A broker-aware validator checks the candidates in that order and falls back to the next one on rejection, and an execution adapter sends the first accepted request. Reconciliation confirms the result on the position before the internal state changes. The engine uses R-multiples for thresholds, persists intratrade state, and records a decision trace for each managed position on every tick.
Many Expert Advisors implement breakeven stops, trailing stops, ATR-based stops, and time exits as independent pieces of logic. Implementing each rule is rarely the difficult part. The difficult part is deciding what happens when several rules trigger on the same tick. A trailing stop might want to move the stop closer, a breakeven rule might want to move it to entry, and a time exit might want to close the position entirely. When every module modifies the position directly, the order in which the modules run decides the outcome, and that order is often implicit and undocumented.
This article presents an architecture where exit modules never modify a position directly. Each module produces a proposal. A policy engine ranks all well-formed proposals in a strict, documented order. A validator checks the candidates in that order against risk invariants and broker constraints, and the first candidate that passes is handed to an execution adapter, the only component that interacts with the trade server. A reconciliation step then compares the broker-side position with the request before the internal state is updated. The engine does not decide when to enter. It only manages positions after they are open, using an R-multiple framework so that every threshold is expressed relative to the initial risk of the position.
The goal is to demonstrate a modular, broker-aware, deterministic decision process that can be tested and explained. The result is a seven-stage pipeline: Proposal, Ranking, Validation (with fallback to the next candidate), Execution, Reconciliation, State update, and Trace.
Author: Stanley Kimathi Kibaara