FULL FORENSIC AUDIT OF COMPLEX MT5 EA

MQL5 EXPERT REQUIRED — FULL FORENSIC AUDIT OF COMPLEX MT5 EA

I am looking for an experienced MQL5/MT5 developer and quantitative trading-system auditor to perform a complete independent code, architecture, signal-generation, execution, risk-management, and backtest audit of a sophisticated Expert Advisor.

This is NOT a request for a simple bug fix.

The objective is to determine exactly why the EA is currently underperforming, identify architectural and mathematical defects, and provide documented corrections that can be independently backtested and verified.

EA ARCHITECTURE

The EA is a multi-engine institutional-style trading system containing:

• Market State / regime classification

• Market Structure / BOS / CHoCH

• Order Blocks

• Fair Value Gap / liquidity concepts

• Multiple independent strategy engines

• E1 Trend Continuation

• E2 Connors Pullback / reversal logic

• E3 Jarroo / BOS / Order Block

• E4 Range Reversal

• E5 Micro-POC Rejection

• Tactical Intelligence / campaign governor

• Multi-layer gating system

• Council / weighted arbitration

• ATR-based SL/TP

• Trailing and profit protection

• Dynamic risk management

• Equity-based scaling / compounding

• Extensive diagnostic logging

• Multi-engine candidate ranking and execution

CURRENT PERFORMANCE PROBLEM

A recent high-quality Strategy Tester run using approximately 99% real-tick history produced:

• Starting balance: approximately $1,000

• Final balance: $458.13

• Net loss: -$541.87

• Total trades: 376

• Win rate: 43.09%

• Profit factor: 0.90

• Expected payoff: -$1.44/trade

• Gross profit: $5,023.34

• Gross loss: -$5,565.21

• Maximum balance drawdown: 70.98%

• Maximum equity drawdown: 72.61%

• Sharpe: -2.65

Engine attribution:

• E1: 104 trades, 42.3% win rate, -$142.10

• E2: 142 trades, 43.7% win rate, -$188.40

• E3: 38 trades, 44.7% win rate, -$48.90

• E4: 2 trades, 0% win rate, -$34.60

• E5: 90 trades, 43.3% win rate, -$127.87

The important issue is that the negative performance is distributed across multiple engines rather than being isolated to one strategy module.

KNOWN / SUSPECTED ISSUES REQUIRING INDEPENDENT VERIFICATION

1. MARKET REGIME / CONTEXT VALIDATION

The EA has sophisticated Market State logic, but we need to establish whether regime information is actually influencing trade approval correctly.

Audit:

• TREND / RANGE / EXPANSION / TRANSITION classification

• H1 vs M15 state interaction

• ADX interpretation

• ATR expansion/compression logic

• regime transitions

• whether regime information reaches every downstream gate

• whether conflicting regime/structure information can still result in approval

• whether stale state values are being used

• whether state calculations are synchronized with the candidate bar

2. GATE 2 PREMIUM / DISCOUNT FAILURE

A significant identified defect is that Gate 2 was originally acting as telemetry rather than enforcement.

The system could identify:

BUY in Premium Zone

but continue toward Council approval.

Example losing trade:

• E1 BUY

• Entry: 113.154

• Swing High: 113.00

• Swing Low: 105.50

• Market State: EXPANSION

• ADX: 41.5

• ATR: 3.85

• Price was at an extreme premium location

• Structural SL: 109.802

• Loss: -$167.90

The system recognized the premium context but did not veto the trade.

We need an independent audit of the correct mathematical definition of dealing-range premium/discount and whether continuation entries should be rejected at extreme locations.

Important: do NOT simply implement arbitrary thresholds. Validate the mathematics and trading logic first.

3. FIBONACCI / DEALING RANGE CALCULATION

There is a suspected distinction between:

• Fibonacci pullback depth

• Actual dealing-range position percentage

The EA has historically used a Fib786 value that may represent a pullback level rather than the actual percentage position inside [SwingLow, SwingHigh] .

Audit:

• Fibonacci calculations

• equilibrium

• premium/discount boundaries

• swing orientation

• BUY vs SELL interpretation

• whether levels are mathematically correct

• whether price-location calculations are consistent across engines

4. E1/E3 LATE-CYCLE ENTRIES

We need to determine whether E1 and E3 are allowed to enter after a move has already become excessively mature/extended.

Audit for:

• expansion age

• distance from equilibrium

• distance from structural swing

• ATR-normalized extension

• premium/discount location

• displacement occurring at exhaustion

• wide structural stops

• continuation entries immediately before mean reversion

• whether breakout continuation and late-cycle continuation are being incorrectly treated as equivalent

5. COUNCIL / ARBITRATION

The Council can approve trades with high scores even when important contextual risks exist.

Example:

• Structure: 25/25

• Momentum: 15/15

• Volatility: 10/10

• Ghost: 20/20

• Total: 88

• Trade subsequently lost -$167.90

Audit whether the scoring model:

• double-counts correlated evidence

• rewards high volatility when volatility should sometimes be a risk factor

• allows one strong category to overwhelm a hard structural objection

• contains redundant votes

• has thresholds that are too permissive

• correctly distinguishes confirmation from entry quality

• properly handles conflicting context

6. CAMPAIGN / PYRAMIDING GOVERNOR

The EA contains an Active Campaign & Pyramiding Governor.

Audit whether it actually enforces:

• minimum ATR spacing

• profit/BE defense before adding

• fresh post-entry BOS

• fresh HL/LH confirmation

• opposite CHoCH/sweep freeze

• maximum campaign layers

• same-direction exposure

• magic-number filtering

• campaign ownership

• correct campaign state persistence

There is concern that parts of the governor currently use proxies rather than actual post-entry structural events.

7. POSITION SIZING / 0.01 LOT PROBLEM

This is a major issue.

The current test shows virtually every trade executing at:

0.01 lots

The EA is intended to dynamically scale position size based on account equity/balance and approximately 1% risk per trade, subject to configured maximum lot size.

Current configuration includes approximately:

• CompoundingPercent = 1.0%

• MaxLotSizeLimit = 0.09

There is a suspected defect in ExecuteTradeSignal() / lot calculation involving:

• point value

• tick value

• tick size

• silver contract specifications

• SL distance

• equity/balance scaling

• volume normalization

Audit the complete sizing formula from account equity → monetary risk → SL distance → raw volume → broker normalization → final volume.

Verify against actual MT5 symbol properties:

• SYMBOL_TRADE_TICK_VALUE

• SYMBOL_TRADE_TICK_SIZE

• SYMBOL_POINT

• SYMBOL_VOLUME_MIN

• SYMBOL_VOLUME_STEP

• SYMBOL_VOLUME_MAX

• contract size

The auditor must determine whether 0.01 is genuinely the mathematically correct result or whether the EA is incorrectly pinned to the minimum volume.

8. COMPOUNDING ENGINE

Verify that increasing equity actually produces increasing trade volume.

We need a controlled test demonstrating something like:

Equity ↑ → Risk $ ↑ → Lot Size ↑

rather than:

Equity ↑ → Lot Size remains 0.01

The audit must verify whether the configured compounding mechanism is actually connected to execution.

9. SL / TP ENGINE

Audit:

• ATR calculations

• structural SL selection

• minimum SL distance

• TP calculation

• R-multiple consistency

• spread/slippage effects

• whether structural stops become excessively wide

• whether wide stops destroy position sizing

• whether SL placement is logically consistent with the signal's invalidation level

10. EXIT / TRAILING LOGIC

Audit:

• trailing activation

• break-even

• partial close

• ATR trailing

• swing trailing

• profit locking

• whether exits are prematurely cutting valid trades

• whether losing trades are allowed to remain open unnecessarily

• whether exit logic conflicts with campaign logic

11. SIGNAL TRANSPORT / STATE BUGS

There have previously been cases where diagnostic output suggested an engine should fire but the resulting raw engine vote was zero.

Audit for:

• stale compiled code

• struct initialization

• candidate transport

• array indexing

• pass-by-reference/value errors

• overwritten engine votes

• enum mismatches

• stale Market State structures

• state persistence

• duplicate function implementations

• execution path discrepancies between diagnostics and actual orders

12. CODE QUALITY / ARCHITECTURE

Perform a full code audit for:

• duplicate functions

• dead code

• unreachable code

• stale variables

• unused inputs

• undeclared/mismatched identifiers

• hidden hardcoded values

• inconsistent symbol assumptions

• array bounds

• initialization failures

• handle management

• CopyBuffer errors

• insufficient historical bars

• incorrect shift usage

• look-ahead bias

• repainting

• future-data leakage

• tester/live discrepancies

• magic-number contamination

• position-selection errors

REQUIRED DELIVERABLES

I want a professional written audit containing:

1. Executive diagnosis

2. Complete list of defects

3. Severity classification:

   • Critical

   • High

   • Medium

   • Low

4. Exact source file/function/line for each defect

5. Explanation of why each defect affects trading behavior

6. Recommended correction

7. Corrected code where appropriate

8. Before/after logic comparison

9. Backtest verification procedure

10. Evidence from actual tester logs/trades

11. Engine-by-engine performance analysis

12. Position-sizing verification

13. Risk calculation verification

14. Confirmation that no look-ahead/repainting exists

15. Confirmation that tester execution matches intended live behavior

REQUIRED TESTING

The auditor must test the EA using the same historical dataset and comparable Strategy Tester configuration where possible.

I want controlled A/B testing:

Baseline → Fix #1 → Backtest → Measure

Then:

Fix #1 → Fix #2 → Backtest → Measure

Changes must be isolated so we can determine exactly which modification caused each performance change.

IMPORTANT

I am NOT looking for someone to simply:

• lower thresholds

• increase trade frequency

• increase lot size

• remove gates

• optimize parameters until the equity curve looks good

I want the underlying engineering and trading logic audited first.

The objective is to make the system correct, internally consistent, mathematically sound, and testable before optimization.

The EA source consists of multiple .mq5 and .mqh files and extensive diagnostic logs.

Required expertise:

• Advanced MQL5

• MT5 Strategy Tester

• Algorithmic trading systems

• Market structure / SMC concepts

• Risk and position-sizing mathematics

• Multi-module EA architecture

• Debugging complex state machines

• Backtest forensic analysis

Please provide examples of previous complex MQL5 EA audits/development work and explain your approach to performing a forensic audit of a multi-engine trading system.

I am specifically looking for someone who will prove the cause of the problems with code and test evidence rather than simply make parameter changes.

We already found that the current Gate 2 dealing-range calculation needs to be verified first, and the correct premium/discount percentage should be based on:

the bigger risk is paying $300 to someone who:

1. changes 20 things at once,
2. optimizes thresholds,
3. produces a better-looking backtest,
4. can't identify which change actually fixed the problem.

(Entry - SwingLow) / (SwingHigh - SwingLow)

Also, E3 should not necessarily be treated identically to E1. E3 is an OB/retest engine, and a valid structural OB retest can legitimately occur in a premium/discount context depending on direction and structure. The audit should prove the rule from the actual signal mechanics before hard-coding it.

payment contingent on evidence, not on profitability.

must not:

• optimize parameters to improve the backtest;
• remove gates simply because they block trades;
• change multiple systems simultaneously;
• claim profitability from a single backtest;
• rewrite the architecture before identifying the defect;
• use look-ahead/repainting;
• change entry logic without showing the exact reason.

must:

• reproduce the baseline;
• identify the exact function/file/line causing each defect;
• demonstrate the defect with logs or controlled tests;
• make one logical correction at a time;
• provide before/after trade counts and P/L;
• verify lot sizing independently;
• verify XAG/XAU symbol specifications;
• trace candidate → gate → council → execution → order → position → exit;
• test both winning and losing case studies;
• preserve the ability to revert each change.
  
  

  prove why the $167.90 Case B loss was allowed through the pipeline, all the way from:

  Market State → E1 → candidate → Gate 2 → Gate 3 → Council → execution → SL

  That single trace will tell you whether the primary failure is actually Gate 2, market-state interpretation, candidate generation, council arbitration, or execution.
  
  
  

  One additional requirement I want added to the scope:

  I do not want this project to end with only a technically corrected EA. The goal is a profitable and statistically viable trading system.

  I understand that no developer can guarantee future profits or a 100% win rate. However, I need objective proof that the repaired EA has a legitimate positive expectancy and is not simply optimized to fit historical data.

  As part of the final deliverables, I need you to:

  1. Repair the confirmed code, architecture, signal-propagation, market-state, gate, execution, and risk-management defects.

  2. Demonstrate that the repaired EA produces positive expectancy, not merely more trades.

  3. Provide before/after backtest results showing:

     • Net profit

     • Profit factor

     • Win rate

     • Average win/loss

     • Maximum drawdown

     • Expected payoff

     • Sharpe/return-risk statistics where appropriate

     • Trade count

     • Performance by individual engine

  4. Perform out-of-sample / forward validation so the result is not simply curve-fitted to the historical test period.

  5. Explain exactly what evidence supports the conclusion that the repaired system has a sustainable trading edge.

  6. Show that profitability remains after realistic spread, commission, slippage, and broker symbol specifications are applied.

  7. Do not optimize parameters simply to make the backtest profitable. Any parameter changes must have a documented logical/market justification.

  8. If the system cannot demonstrate positive expectancy after the confirmed defects are repaired, I want that stated clearly rather than artificially optimizing the EA to produce a profitable backtest.

  Most importantly, I want the final report to answer this question:

  “What objective evidence do we have that this EA has a real trading edge after the repairs, and why should I have confidence putting real money behind it?”

  I am looking for engineering proof and statistical evidence—not a promise of guaranteed profits.