646 lines
No EOL
26 KiB
Text
646 lines
No EOL
26 KiB
Text
|
|
|
|
BASE VERSION FLAWS
|
|
|
|
**critical**, **silent**, and **structural flaws** that make it unfit for reliable live trading. The current version might look clean, but under the hood, it exhibits **fatal risk control gaps**, **lazy execution standards**, and **basic signal naivety**. Below is a full teardown of its **logic, professionalism, risk handling, and readiness for production deployment**, going well beyond the flaws I already found.
|
|
|
|
---
|
|
|
|
## 🔍 **STRUCTURED ANALYSIS & FULL CODE AUDIT**
|
|
|
|
---
|
|
|
|
### ⚠️ CRITICAL FLAWS — MUST FIX BEFORE LIVE DEPLOYMENT
|
|
|
|
---
|
|
|
|
### ❌ 1. ***Incorrect SL/TP Distance Conversion:***
|
|
|
|
```cpp
|
|
double slDistance = StopLossPips * point * 10;
|
|
```
|
|
|
|
**Problem**: Multiplies by 10 unnecessarily. `point` already gives the correct unit. This causes **SL/TP 10x too large**, invalidating risk calculations.
|
|
|
|
**Fix**:
|
|
|
|
```cpp
|
|
double slDistance = StopLossPips * point;
|
|
```
|
|
|
|
---
|
|
|
|
### ❌ 2. ***Lot Size Calculation Based on Incorrect TickValue Assumptions***
|
|
|
|
```cpp
|
|
double tickValue = SymbolInfoDouble(_Symbol, SYMBOL_TRADE_TICK_VALUE);
|
|
```
|
|
|
|
**Problem**: `tickValue` can be **zero** or irrelevant for **non-forex instruments** (e.g., XAUUSD, BTCUSD, indices). EA **over/under-risks massively** without conversion to deposit currency.
|
|
|
|
**Fix**:
|
|
|
|
* Use:
|
|
|
|
```cpp
|
|
double tickValueProfit = SymbolInfoDouble(_Symbol, SYMBOL_TRADE_TICK_VALUE_PROFIT);
|
|
```
|
|
|
|
* Fallback logic if `tickValueProfit == 0`:
|
|
|
|
```cpp
|
|
double contractSize = SymbolInfoDouble(_Symbol, SYMBOL_TRADE_CONTRACT_SIZE);
|
|
```
|
|
|
|
---
|
|
|
|
### ❌ 3. ***MA Crossover Logic Is Naive, No Slope/Volatility Filter***
|
|
|
|
```cpp
|
|
if(fastMA[1] > slowMA[1] && fastMA[2] <= slowMA[2])
|
|
```
|
|
|
|
**Problem**: Pure two-bar crossover = **signal spam**. No MA slope check, no price action context, no ATR gating.
|
|
|
|
**Fix**:
|
|
Add filters like:
|
|
|
|
```cpp
|
|
double slope = fastMA[1] - fastMA[2];
|
|
if(slope < point * 5) return; // Weak crossover, ignore
|
|
```
|
|
|
|
Also consider:
|
|
|
|
* ATR filter
|
|
* MA distance threshold
|
|
* Volume filter
|
|
|
|
---
|
|
|
|
### ❌ 4. ***No Cooldown Between Trades***
|
|
|
|
**Problem**: EA will re-enter immediately after SL. No buffer period or re-entry guard.
|
|
|
|
**Fix**:
|
|
Introduce:
|
|
|
|
```cpp
|
|
datetime lastTradeTime;
|
|
input int CooldownMinutes = 15;
|
|
|
|
if(TimeCurrent() - lastTradeTime < CooldownMinutes * 60)
|
|
return; // Skip signal
|
|
```
|
|
|
|
Set `lastTradeTime` after successful entry.
|
|
|
|
---
|
|
|
|
### ❌ 5. ***No Re-Entry Guard After Recent Loss***
|
|
|
|
**Problem**: No check if last trade just failed. EA might fire same trade over and over in a choppy market.
|
|
|
|
**Fix**:
|
|
Track:
|
|
|
|
* `lastTradeSLPrice`
|
|
* `lastTradeResult`
|
|
* `lastEntryDirection`
|
|
|
|
Guard re-entry at same price ± X pips.
|
|
|
|
---
|
|
|
|
### ❌ 6. ***Trailing Stop Logic Uses Over-Scaled Distances***
|
|
|
|
```cpp
|
|
double trailDistance = TrailingStopPips * point * 10;
|
|
```
|
|
|
|
Same scaling error as SL/TP. Trailing logic will never trigger because distance is 10x too big.
|
|
|
|
**Fix**:
|
|
|
|
```cpp
|
|
double trailDistance = TrailingStopPips * point;
|
|
```
|
|
|
|
---
|
|
|
|
### ❌ 7. ***No Broker Stops Level Guard***
|
|
|
|
**Problem**: SL/TP may be placed too close to price, violating broker stop levels.
|
|
|
|
**Fix**:
|
|
|
|
```cpp
|
|
double stopLevel = SymbolInfoInteger(_Symbol, SYMBOL_TRADE_STOPS_LEVEL) * point;
|
|
if(MathAbs(sl - price) < stopLevel)
|
|
{
|
|
Print("SL too close to price. Skipping trade.");
|
|
return;
|
|
}
|
|
```
|
|
|
|
---
|
|
|
|
### ❌ 8. ***No Spread-Sanity Check***
|
|
|
|
**Problem**: If spread is too wide (e.g., during news), SL becomes smaller than the spread — **guaranteed loss**.
|
|
|
|
**Fix**:
|
|
|
|
```cpp
|
|
double spread = SymbolInfoDouble(_Symbol, SYMBOL_ASK) - SymbolInfoDouble(_Symbol, SYMBOL_BID);
|
|
if(spread > (StopLossPips * point * 0.5))
|
|
{
|
|
Print("Spread too high, skipping trade.");
|
|
return;
|
|
}
|
|
```
|
|
|
|
---
|
|
|
|
### ❌ 9. ***TP/SL Not Normalized at Calculation Source***
|
|
|
|
**Problem**: Normalization only happens in `OpenBuy/Sell`, not in `CalculateTakeProfit()` and `CalculateStopLoss()`. These values may be reused unnormalized elsewhere (e.g., trailing logic).
|
|
|
|
**Fix**:
|
|
Normalize at source:
|
|
|
|
```cpp
|
|
return NormalizeDouble(tp, (int)SymbolInfoInteger(_Symbol, SYMBOL_DIGITS));
|
|
```
|
|
|
|
---
|
|
|
|
### ❌ 10. ***No Retry or Fallback for Trade Failures***
|
|
|
|
**Problem**: You log error but **do not retry** or fallback (e.g., switch fill mode, retry in X seconds).
|
|
|
|
**Fix**:
|
|
|
|
```cpp
|
|
int attempts = 0;
|
|
bool success = false;
|
|
while(attempts < 3 && !success)
|
|
{
|
|
success = trade.Buy(...);
|
|
if(!success)
|
|
{
|
|
Sleep(1000);
|
|
attempts++;
|
|
}
|
|
}
|
|
```
|
|
|
|
Also log error code:
|
|
|
|
```cpp
|
|
Print("Trade failed. Error code: ", GetLastError());
|
|
```
|
|
|
|
---
|
|
|
|
### ❌ 11. ***Position Count Ignores Direction***
|
|
|
|
```cpp
|
|
CountPositions() // No distinction between BUY/SELL
|
|
```
|
|
|
|
**Problem**: If you're tracking directional trades (e.g., hedging), this logic will fail.
|
|
|
|
**Fix**:
|
|
Add overload:
|
|
|
|
```cpp
|
|
int CountPositionsByType(ENUM_POSITION_TYPE type)
|
|
```
|
|
|
|
---
|
|
|
|
### ❌ 12. ***Trailing Logic Modifies SL Too Frequently***
|
|
|
|
**Problem**: SL is updated every new bar, even if price barely moved. Adds unnecessary pressure on terminal.
|
|
|
|
**Fix**:
|
|
|
|
```cpp
|
|
if(MathAbs(newSL - currentSL) > point * 2)
|
|
```
|
|
|
|
Also: Only trail if profit > trailDistance.
|
|
|
|
---
|
|
|
|
### ❌ 13. ***No OnTrade() or OnTradeTransaction()***
|
|
|
|
**Problem**: No handling of trade lifecycle. You rely entirely on OnTick — delayed response to fills, SLs, TP hits.
|
|
|
|
**Fix**:
|
|
Implement:
|
|
|
|
```cpp
|
|
void OnTradeTransaction(const MqlTradeTransaction &trans, const MqlTradeRequest &req, const MqlTradeResult &res)
|
|
{
|
|
if(trans.type == TRADE_TRANSACTION_DEAL_ADD)
|
|
{
|
|
// Trade opened or closed
|
|
// Log it or update internal state
|
|
}
|
|
}
|
|
```
|
|
|
|
---
|
|
|
|
## ⚠️ SECONDARY FLAWS — SHOULD FIX FOR STABILITY
|
|
|
|
---
|
|
|
|
### ⚠️ 14. ***Trailing SL Doesn’t Validate SL Above Broker Stops***
|
|
|
|
Add:
|
|
|
|
```cpp
|
|
if(MathAbs(newSL - positionOpenPrice) < stopLevel)
|
|
return;
|
|
```
|
|
|
|
---
|
|
|
|
### ⚠️ 15. ***No Symbol Class Adaptation (Gold, Indices, Crypto)***
|
|
|
|
**Fix**:
|
|
Detect:
|
|
|
|
```cpp
|
|
int calcMode;
|
|
SymbolInfoInteger(_Symbol, SYMBOL_TRADE_CALC_MODE, calcMode);
|
|
```
|
|
|
|
Then adapt:
|
|
|
|
* Pip size
|
|
* Contract size
|
|
* SL/TP scaling
|
|
* TickValue/TickSize
|
|
|
|
---
|
|
|
|
### ⚠️ 16. ***No Max Drawdown or Equity Guard***
|
|
|
|
**Problem**: EA will continue to trade even if account is almost empty.
|
|
|
|
**Fix**:
|
|
|
|
```cpp
|
|
double maxDrawdownPercent = 30.0;
|
|
double equity = AccountInfoDouble(ACCOUNT_EQUITY);
|
|
double balance = AccountInfoDouble(ACCOUNT_BALANCE);
|
|
if((balance - equity) / balance * 100.0 > maxDrawdownPercent)
|
|
{
|
|
Print("Max drawdown exceeded. Halting trading.");
|
|
return;
|
|
}
|
|
```
|
|
|
|
---
|
|
|
|
### ⚠️ 17. ***No Market Condition Filters***
|
|
|
|
EA trades regardless of:
|
|
|
|
* Spread spikes
|
|
* Slippage
|
|
* News releases
|
|
* Illiquid sessions
|
|
|
|
**Fix**:
|
|
|
|
* Check tick volume
|
|
* Integrate economic calendar or disable during known high-risk events
|
|
* Filter based on average spread over last X bars
|
|
|
|
---
|
|
|
|
### ⚠️ 18. ***Logging Is Minimal and Not Contextual***
|
|
|
|
**Problem**: Logs only basic info. In live environments, you’ll need rich logs for diagnosis.
|
|
|
|
**Fix**:
|
|
|
|
* Include time, symbol, signal context, indicator values in logs
|
|
* Log every rejection reason clearly
|
|
* Save logs to file optionally
|
|
|
|
---
|
|
|
|
## ✅ STRUCTURAL + ARCHITECTURAL SUGGESTIONS
|
|
|
|
---
|
|
|
|
### 🧠 Modularize Core Functions
|
|
|
|
Refactor your logic into modular checks for better testing and robustness:
|
|
|
|
```cpp
|
|
bool IsTradeSignal();
|
|
bool IsRiskAcceptable();
|
|
bool IsCoolDownElapsed();
|
|
bool IsMarketStable();
|
|
bool IsPositionValidToTrail();
|
|
```
|
|
|
|
---
|
|
|
|
### 🔐 Production-Grade Design Must Include:
|
|
|
|
| Safety Feature | Status | Action |
|
|
| ----------------------- | ------ | ------------------------------- |
|
|
| Drawdown Guard | ❌ | Add max DD check |
|
|
| Broker StopLevel Check | ❌ | Check SL/TP vs. stop level |
|
|
| Spread Control | ❌ | Check before entry |
|
|
| Re-entry Buffer | ❌ | Cooldown logic |
|
|
| Session Awareness | ⚠️ | Base sessions on symbol |
|
|
| Dynamic Symbol Handling | ❌ | Detect symbol type, adapt logic |
|
|
|
|
---
|
|
|
|
## ✅ FIX PLAN (SUMMARY)
|
|
|
|
| Fix Area | Priority | Action |
|
|
| ------------------------- | -------- | --------------------------------------------- |
|
|
| SL/TP Multiplier Bug | 🔥 HIGH | Remove `*10` multipliers |
|
|
| MA Signal Strength | 🔥 HIGH | Add slope, ATR, MA distance filters |
|
|
| TickValue Accuracy | 🔥 HIGH | Use `SYMBOL_TRADE_TICK_VALUE_PROFIT` |
|
|
| Cooldown Logic | 🔥 HIGH | Add `lastTradeTime` check |
|
|
| Re-entry Protection | 🔥 HIGH | Track last SL price + skip if close |
|
|
| Spread & StopLevel Checks | 🔥 HIGH | Reject entries with wide spread or invalid SL |
|
|
| Broker Stops Guard | 🔥 HIGH | Check against SYMBOL_TRADE_STOPS_LEVEL |
|
|
| Trailing SL Correction | 🔥 HIGH | Remove *10, ensure profit threshold |
|
|
| Trade Retry Logic | ⚠️ MED | Retry failed entries with delay |
|
|
| Symbol Class Adaptation | ⚠️ MED | Detect and adapt to symbol type |
|
|
| OnTrade() Lifecycle Mgmt | ⚠️ MED | Handle SL/TP fill events |
|
|
| Logging & Diagnostics | ⚠️ LOW | Enhance logs, include context |
|
|
|
|
---
|
|
|
|
## 🧱 FINAL RATING: EA PRODUCTION READINESS
|
|
|
|
| Category | Rating (out of 10) |
|
|
| -------------------- | --------------------------------------- |
|
|
| Signal Logic | 3/10 – naive logic, no filters |
|
|
| Risk Management | 2/10 – SL/TP miscalc, lot sizing flawed |
|
|
| Broker Compatibility | 4/10 – no stops-level, no retry |
|
|
| Professionalism | 3/10 – minimal safety checks/logs |
|
|
| Robustness | 2/10 – missing re-entry/cooldown/guards |
|
|
| Production Readiness | **3/10 – not safe for live yet** |
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
USER MODIFIED VERSION IMPROVEMENT PLAN
|
|
|
|
1. Indicator and Signal Logic Issues
|
|
|
|
Signal redundancy / lack of crossover detection
|
|
You check:
|
|
|
|
if(fastMA[0] > slowMA[0] && fastMA[1] > slowMA[1] && fastMA[2] > slowMA[2])
|
|
|
|
|
|
This detects sustained trend continuation, not a crossover.
|
|
As a result, entries are delayed and often miss the profitable part of the trend.
|
|
To properly detect a crossover:
|
|
|
|
if(fastMA[1] < slowMA[1] && fastMA[0] > slowMA[0]) // bullish cross
|
|
|
|
|
|
And the inverse for bearish.
|
|
|
|
Static bar check
|
|
if(currentBar == lastBar) return; prevents intrabar updates, but this makes the EA react only once per bar, missing valid fast reversals or trailing stop updates mid-bar.
|
|
|
|
ATR filter flaw
|
|
atr < ATRMinimumPips * point
|
|
→ ATR is in price units, not pips.
|
|
So ATRMinimumPips * point makes the threshold too small.
|
|
Correct would be:
|
|
|
|
if(UseATRFilter && atr / point < ATRMinimumPips)
|
|
|
|
2. Risk & Lot Calculation Issues
|
|
|
|
Incorrect fallback in CalculateLotSize
|
|
If division by zero, you call return MinLotSize; — but MinLotSize is not defined (should be minLot lowercase). This causes a compilation or runtime reference error.
|
|
|
|
tickValue calculation assumptions
|
|
You do:
|
|
|
|
SymbolInfoDouble(_Symbol, SYMBOL_TRADE_TICK_VALUE_PROFIT, tickValue);
|
|
if(tickValue == 0)
|
|
tickValue = tickSize * SymbolInfoDouble(_Symbol, SYMBOL_TRADE_CONTRACT_SIZE);
|
|
|
|
|
|
This is unreliable for non-USD pairs or synthetic symbols.
|
|
Use OrderCalcProfit() instead to determine value per pip dynamically.
|
|
|
|
Lot rounding
|
|
You round down:
|
|
|
|
lots = MathFloor(lots / lotStep) * lotStep;
|
|
|
|
|
|
This always biases smaller (risk underutilized).
|
|
Prefer rounding to nearest valid step.
|
|
|
|
3. Trade Validation & Execution Flaws
|
|
|
|
ValidateTrade doesn’t check broker stop limits properly
|
|
You compare MathAbs(sl - entry) < stopLevel, but some brokers use a minimum distance from current price, not entry price, and may reject due to price freeze levels. You should include spread buffer and recheck OrderCheck() before placing.
|
|
|
|
Fixed price execution
|
|
You pass a manual price into trade.Buy() and trade.Sell().
|
|
In MT5’s CTrade, when you specify price, it’s used as a limit, not a market order, causing frequent rejections.
|
|
Recommended:
|
|
|
|
trade.Buy(lots, _Symbol, 0, sl, tp);
|
|
trade.Sell(lots, _Symbol, 0, sl, tp);
|
|
|
|
|
|
No spread handling on sell entries
|
|
You calculate TP/SL based on bid for sells, but you should reference Ask for SL, otherwise SL may be mispositioned.
|
|
|
|
No retry backoff
|
|
Retrying 3 times with Sleep(1000) is simplistic — better to log error codes and retry only on known transient errors (e.g., ERR_TRADE_CONTEXT_BUSY).
|
|
|
|
4. Trailing Stop Logic Issues
|
|
|
|
Overly restrictive movement check
|
|
|
|
if(trailPrice > currentSL + trailStep && trailPrice > openPrice)
|
|
|
|
|
|
For sells:
|
|
|
|
if(trailPrice < currentSL - trailStep && trailPrice < openPrice)
|
|
|
|
|
|
These double conditions prevent trailing from updating frequently.
|
|
You can simplify to one direction-sensitive check based on trailStep.
|
|
|
|
Bid/Ask usage flipped
|
|
For buy positions, you should trail using Bid (correct).
|
|
For sells, use Ask (also correct), but you’re comparing to currentSL in a way that might block updates due to rounding. Add small epsilon tolerance (_Point/2).
|
|
|
|
5. Miscellaneous Logic and Safety Gaps
|
|
|
|
Cooldown system resets on any trade
|
|
The EA uses lastTradeTime = TimeCurrent(); after every buy/sell.
|
|
That prevents both buys and sells from opening for CooldownMinutes, even if the opposite signal forms. You could track separate cooldowns for buy/sell.
|
|
|
|
No order error handling/reporting
|
|
Errors from trade.Buy() or trade.Sell() are printed but not recovered. Use:
|
|
|
|
int err = GetLastError();
|
|
ResetLastError();
|
|
|
|
|
|
No protection against duplicate indicator handle creation
|
|
If EA is reinitialized mid-run, handles can leak (MT5 bug). Should close old handles in OnDeinit():
|
|
|
|
if(handleFastMA != INVALID_HANDLE) IndicatorRelease(handleFastMA);
|
|
|
|
|
|
Potential floating-point pip mismatch
|
|
Using point for pip size is unreliable on JPY pairs. Use pip = (Digits == 3 || Digits == 5) ? 10 * point : point;.
|
|
|
|
6. Code Style & Robustness
|
|
|
|
Repeated constant access (e.g. SymbolInfoDouble every tick) — cache static symbol data.
|
|
|
|
Missing error handling for indicator buffer copying.
|
|
|
|
CountPositions() iterates backwards but ignores pending orders — possible duplicates if broker offsets.
|
|
|
|
Doesn’t account for partial closes.
|
|
|
|
High-Priority Fix Summary
|
|
Issue Type Severity Fix
|
|
Incorrect crossover logic Strategy High Use fastMA[1] < slowMA[1] && fastMA[0] > slowMA[0]
|
|
ATR filter units Logic High Compare atr / point < ATRMinimumPips
|
|
Undefined MinLotSize variable Compile/runtime High Replace with minLot
|
|
Wrong price argument in trade.Buy/Sell Execution High Use 0 instead of price
|
|
Stop-loss too close logic Execution Medium Use OrderCheck() before send
|
|
Cooldown blocks both directions Logic Medium Separate buy/sell cooldowns
|
|
Trailing stop over-restrictive Trade management Medium Simplify trailing step logic
|
|
Tick value calculation unreliable Risk Medium Use OrderCalcProfit() for pip value
|
|
|
|
|
|
|
|
|
|
1. **Adaptive Moving Averages (AMA) instead of fixed MA periods** * Research shows that moving averages which adjust their smoothing coefficient based on volatility/trend strength can reduce lag and false signals. For example, the Kaufman’s Adaptive Moving Average (KAMA) modulates sensitivity using an Efficiency Ratio. [AlphaSquawk](https://alphasquawk.com/adaptive-moving-average-ama-origins-uses-and-coding-examples/?utm_source=chatgpt.com) * A recent backtest article: “Adaptive moving average strategy backtest (KAMA) … Yes, adaptive moving average strategies do work.” [Quantified Strategies](https://www.quantifiedstrategies.com/adaptive-moving-average/?utm_source=chatgpt.com) * You could replace your two fixed MAs (FastMA_Period, SlowMA_Period) with an adaptive MA for one or both lines, or better yet use: *FastMA = adaptive* and *SlowMA = fixed* (or both adaptive but with different settings) to respond better to market regime changes. * Practical gain: by reducing lag and improving signal-to-noise, you could expect fewer whipsaws and earlier entries. * Implementation tip: derive the smoothing constant dynamically in your EA (in MQL5) based on e.g. volatility (ATR, or Efficiency Ratio) and then compute AMA instead of the iMA handle. * The article “Adaptive Optimization of a Dual Moving Average Strategy for …” (MDPI) shows a learning-based hybrid optimizing MA parameters dynamically. [MDPI](https://www.mdpi.com/2227-7390/13/16/2629?utm_source=chatgpt.com) * **Action**: Replace fixed MA periods with adaptive versions, incorporate volatility filter inside MA logic. 2. **Incorporate a Volatility / Market Regime Filter** * Instead of only using an ATR minimum filter, research suggests you can also define market *regimes* (trending vs ranging vs high-volatility) and change your strategy logic accordingly. * Example: In a trending regime, you allow entries; in a ranging regime you reduce or disable. You can detect regime via ATR, ADX, or even combination of MAs. * This will reduce entries in bad regimes (reducing drawdown / false trades) and increase accuracy of the good trades. * Implementation: augment your EA’s CheckEntrySignals() to skip trades unless *trend strength* (e.g., ADX > threshold) or *volatility > threshold* AND *not too high (to avoid spikes)*. * **Action**: Add ADX (or custom regime filter) plus maybe a dynamic stop-loss/take-profit adjustment depending on volatility. 3. **Hyper-Parameter Optimization / Adaptive Strategy Parameter Tuning** * The research on “adaptive optimization” (see MDPI article) shows that using learning/hybrid algorithms to tune strategy parameters (MA periods, stop-loss, take-profit) in a rolling window improves robustness. [MDPI](https://www.mdpi.com/2227-7390/13/16/2629?utm_source=chatgpt.com) * You could implement a routine that periodically back-tests recent data (walk-forward) and adjusts your FastMA_Period, SlowMA_Period, StopLossPips, etc. automatically, or at least suggests new values. * Implementation: Not trivial in MQL5, but you can export performance metrics to CSV, run an external optimizer (Optuna in Python) or optimize inside MT5 Strategy Tester and feed back into live parameters. * **Action**: Use parameter optimization and consider dynamic adjustment of parameters rather than static. 4. **Leverage Open-Source Frameworks / Machine Learning for Signal Validation** * There are full RL frameworks such as FinRL (GitHub: AI4Finance-Foundation) which support financial RL agents. [GitHub FinRL](https://github.com/AI4Finance-Foundation/FinRL?utm_source=chatgpt.com) * Another: TensorTrade (GitHub) for building/deploying RL trading algorithms. [GitHub TensorTrade](https://github.com/Savant-Capital/tensortrade-rl-framework?utm_source=chatgpt.com) * While integrating full RL into an MQL5 EA may be a big shift, you can use these frameworks to **validate signals** or **filter trade entries**: e.g., train a lightweight ML classifier that takes inputs (MA cross, ATR, spread, ADX) and outputs probability of success; only trade when probability > threshold. * Implementation path: export trade candidates from your EA to CSV, train a model offline, then import into EA (via DLL or simpler approach) or embed logic derived from model (rule-based). * **Action**: Build a signal-filtering classifier (using open-source code) to reduce false entries and enhance quality of trades. --- ## 🎯 Top Two Code-Ready Repos You Can Use * **FinRL**: GitHub: [https://github.com/AI4Finance-Foundation/FinRL](https://github.com/AI4Finance-Foundation/FinRL) Use: study how they build environment, features, and agents — you can adopt their data-preprocessing (feature extraction) logic for your EA context. * **AlgorithmicTrader / ml-for-trading list**: GitHub: [https://github.com/PantherAlgoTrading/ml-for-trading](https://github.com/PantherAlgoTrading/ml-for-trading) Use: curated list of ML/trading code, can pick features/algorithms for entry filtering. --- ## 🧮 Estimate of Improvement If you: * Replace fixed MA logic with an adaptive MA algorithm that reduces lag and filters noise, * Add a regime/volatility filter to avoid bad trades, * Add another layer (classifier or validation rule) to only take high-probability trades, then you could feasibly improve accuracy (win rate or quality of entries) by **30-40%**
|
|
|
|
|
|
|
|
|
|
✅ Promising Research / Techniques
|
|
|
|
Adaptive Moving Averages (AMA) instead of fixed MA periods
|
|
|
|
Research shows that moving averages which adjust their smoothing coefficient based on volatility/trend strength can reduce lag and false signals. For example, the Kaufman’s Adaptive Moving Average (KAMA) modulates sensitivity using an Efficiency Ratio. https://alphasquawk.com/adaptive-moving-average-ama-origins-uses-and-coding-examples/?utm_source=chatgpt.com
|
|
|
|
A recent backtest article: “Adaptive moving average strategy backtest (KAMA) … Yes, adaptive moving average strategies do work.” https://www.quantifiedstrategies.com/adaptive-moving-average/?utm_source=chatgpt.com
|
|
|
|
You could replace your two fixed MAs (FastMA_Period, SlowMA_Period) with an adaptive MA for one or both lines, or better yet use: FastMA = adaptive and SlowMA = fixed (or both adaptive but with different settings) to respond better to market regime changes.
|
|
|
|
Practical gain: by reducing lag and improving signal-to-noise, you could expect fewer whipsaws and earlier entries.
|
|
|
|
Implementation tip: derive the smoothing constant dynamically in your EA (in MQL5) based on e.g. volatility (ATR, or Efficiency Ratio) and then compute AMA instead of the iMA handle.
|
|
|
|
The article “Adaptive Optimization of a Dual Moving Average Strategy for …” (MDPI) shows a learning-based hybrid optimizing MA parameters dynamically. https://www.mdpi.com/2227-7390/13/16/2629?utm_source=chatgpt.com
|
|
|
|
Action: Replace fixed MA periods with adaptive versions, incorporate volatility filter inside MA logic.
|
|
|
|
Incorporate a Volatility / Market Regime Filter
|
|
|
|
Instead of only using an ATR minimum filter, research suggests you can also define market regimes (trending vs ranging vs high-volatility) and change your strategy logic accordingly.
|
|
|
|
Example: In a trending regime, you allow entries; in a ranging regime you reduce or disable. You can detect regime via ATR, ADX, or even combination of MAs.
|
|
|
|
This will reduce entries in bad regimes (reducing drawdown / false trades) and increase accuracy of the good trades.
|
|
|
|
Implementation: augment your EA’s CheckEntrySignals() to skip trades unless trend strength (e.g., ADX > threshold) or volatility > threshold AND not too high (to avoid spikes).
|
|
|
|
Action: Add ADX (or custom regime filter) plus maybe a dynamic stop-loss/take-profit adjustment depending on volatility.
|
|
|
|
Hyper-Parameter Optimization / Adaptive Strategy Parameter Tuning
|
|
|
|
The research on “adaptive optimization” (see MDPI article) shows that using learning/hybrid algorithms to tune strategy parameters (MA periods, stop-loss, take-profit) in a rolling window improves robustness. https://www.mdpi.com/2227-7390/13/16/2629?utm_source=chatgpt.com
|
|
|
|
You could implement a routine that periodically back-tests recent data (walk-forward) and adjusts your FastMA_Period, SlowMA_Period, StopLossPips, etc. automatically, or at least suggests new values.
|
|
|
|
Implementation: Not trivial in MQL5, but you can export performance metrics to CSV, run an external optimizer (Optuna in Python) or optimize inside MT5 Strategy Tester and feed back into live parameters.
|
|
|
|
Action: Use parameter optimization and consider dynamic adjustment of parameters rather than static.
|
|
|
|
Leverage Open-Source Frameworks / Machine Learning for Signal Validation
|
|
|
|
There are full RL frameworks such as FinRL (GitHub: AI4Finance-Foundation) which support financial RL agents. https://github.com/AI4Finance-Foundation/FinRL?utm_source=chatgpt.com
|
|
|
|
Another: TensorTrade (GitHub) for building/deploying RL trading algorithms. https://github.com/Savant-Capital/tensortrade-rl-framework?utm_source=chatgpt.com
|
|
|
|
While integrating full RL into an MQL5 EA may be a big shift, you can use these frameworks to validate signals or filter trade entries: e.g., train a lightweight ML classifier that takes inputs (MA cross, ATR, spread, ADX) and outputs probability of success; only trade when probability > threshold.
|
|
|
|
Implementation path: export trade candidates from your EA to CSV, train a model offline, then import into EA (via DLL or simpler approach) or embed logic derived from model (rule-based).
|
|
|
|
Action: Build a signal-filtering classifier (using open-source code) to reduce false entries and enhance quality of trades.
|
|
|
|
🎯 Top Two Code-Ready Repos You Can Use
|
|
|
|
FinRL:
|
|
GitHub: https://github.com/AI4Finance-Foundation/FinRL
|
|
|
|
Use: study how they build environment, features, and agents — you can adopt their data-preprocessing (feature extraction) logic for your EA context.
|
|
|
|
AlgorithmicTrader / ml-for-trading list:
|
|
GitHub: https://github.com/PantherAlgoTrading/ml-for-trading
|
|
|
|
Use: curated list of ML/trading code, can pick features/algorithms for entry filtering.
|
|
|
|
🧮 Estimate of Improvement
|
|
|
|
If you:
|
|
|
|
Replace fixed MA logic with an adaptive MA algorithm that reduces lag and filters noise,
|
|
|
|
Add a regime/volatility filter to avoid bad trades,
|
|
|
|
Add another layer (classifier or validation rule) to only take high-probability trades,
|
|
|
|
then it could feasibly improve accuracy (win rate or quality of entries) by 30-40%
|
|
|
|
EVERYTHING IN THIS FILE IS JUST A FOUNDATION.
|
|
IMPROVR GENERALLY TO ACTIONABLE APROACHES THAT WILL RESULT TO REAL PRODUCTION READINESS TO EA
|
|
|
|
Credits to SimonFX, any open source we adopt and Copilot.
|
|
Thank you in advance. |