Start with strategy rules, not indicators
The development specification should define exactly what creates an entry, what invalidates it, how stops and targets are selected, whether multiple positions are permitted and when trading is disabled. Terms such as “strong momentum”, “liquidity sweep” or “good trend” must be converted into measurable conditions.
Gold-specific execution controls
- Spread filter: block entries when the current spread is outside the strategy's tested range.
- Slippage handling: log requested versus filled price and define when an order should be retried or abandoned.
- Symbol normalization: support broker suffixes/prefixes and read tick size, tick value, stop level and volume step from MT5.
- Session/news rules: if the strategy avoids particular sessions or high-impact events, encode those boundaries explicitly.
- Gap behavior: define what should happen if price jumps across the intended stop or entry level.
Risk gate before every trade
A central risk gate is easier to audit than scattering checks through different strategy modules. It can evaluate current equity, daily P/L, existing exposure, margin, spread, requested stop distance and total portfolio risk before an order is allowed.
Structural + volatility-aware stops
For strategies that use structure and ATR, the rule should state which swing is valid, how ATR is calculated, whether a buffer is added and the maximum acceptable stop size. If the stop is too small for the broker or too large for the risk budget, the trade should be rejected or resized according to the specification.
Pyramiding without averaging down
If pyramiding is required, additional entries can be restricted to favorable movement only. The EA should cap the number of additions, recalculate total exposure before each add-on and prevent accidental martingale or loss-recovery behavior.
Backtesting that is harder to fool
- Use tick-quality data appropriate for the broker/symbol where possible.
- Include spread and execution-cost assumptions rather than testing at zero friction.
- Separate development/optimization data from final validation data.
- Run out-of-sample and walk-forward checks for parameter stability.
- Inspect drawdown clusters, not only total profit or win rate.
- Forward-test on demo before live deployment.
Win rate is not enough
A high historical win rate can coexist with poor risk-adjusted results if occasional losses are very large. Validation should look at profit factor, expectancy, maximum drawdown, average win/loss, exposure, trade frequency and sensitivity to spread/slippage. Future performance cannot be guaranteed from backtests.