What Data Is Needed to Assess MT4 Expert Advisors?

Definition and the core question

An MT4 Expert Advisor (EA) is automated trading logic that runs in MetaTrader 4. To assess an EA, you need data that lets you understand (1) what the EA actually does, and (2) under what conditions the EA was evaluated. The goal is not to predict future profits, but to verify that its stated behavior and tested behavior are consistent and based on clearly defined assumptions.

Inputs: what data you need to describe the EA

Start with the EA’s operational description. The minimum useful inputs are:

Strategy logic and parameters: the rules the EA uses (entry/exit criteria, risk controls, position management) and the full set of tunable inputs. If the EA uses indicators, record which indicators, their parameter values, and how they are combined.
Trading session and execution assumptions: any filters like allowed trading hours, order types, slippage handling, and whether the EA limits trading during news-like events (if such rules exist).
Cost model assumptions: the assumed spread, commissions, swaps/financing charges, and any modeled trading costs. If the EA’s results are shown without documenting costs, that is a material missing input.
Data used for evaluation: the historical price series used for backtesting, including the timeframe, the bar model (how ticks/bars are constructed), and whether the backtest uses realistic execution assumptions.
Environment configuration: account currency assumptions, leverage-related constraints (if relevant to margin checks), and trade permissions. Even if the EA “only buys/sells,” margin limits and execution constraints can affect feasibility.

Provenance: where the data came from

Provenance means you can trace each dataset and setting to a source:

EA source and documentation: where the code or compiled binary came from, version/build information, and any documentation describing what each parameter is intended to control.
Configuration used during testing: the exact parameter values, order sizing method, and risk settings used during any reported performance.
Market-data origin: the supplier or dataset used for historical backtests. If the origin is unclear, you cannot judge whether the backtest captured liquidity and microstructure assumptions.
Evaluation method provenance: whether results came from backtesting, forward testing, or paper trading, and how long each period ran.

This matters because identical parameter settings can behave differently when the data origin or execution model changes.

Timeliness and “what was known when”

Even in a non-live context, timeliness affects interpretation. You need to identify:

The time window used for backtesting (start/end dates) and whether it overlaps with later evaluation periods.
Data leakage risk: whether any optimization used information from the same period it later “proved” performance on.
Out-of-sample definition: what was reserved for evaluation versus what was used to tune parameters.

A practical, evergreen approach is to require that the EA’s performance be evaluated with clearly separated periods and that you can explain what inputs were available at each stage.

Evidence or example: how to check the EA matches the claims

To assess an EA, compare three layers of evidence:

Specification-to-code consistency: do the documented rules match the code behavior (or compiled behavior if code is unavailable)?
Backtest realism: does the evaluation use plausible execution assumptions for the instruments and timeframe (including costs and handling of order fills)?
Reproducibility: can someone rerun the same backtest with the same parameters and data origin and get the same or very similar outputs?

If you cannot reproduce results with the same documented setup, treat the performance evidence as weak.

Limitations and risks: material failure modes to look for

Common limitations you should treat as first-class risk data include:

Overfitting: performance that depends heavily on specific parameter values or specific historical conditions.
Execution mismatch: backtest results that assume ideal fills, ignore slippage, or omit commissions/spread details.
Hidden regime dependence: logic that works in one market regime but fails in others (for example, when volatility or trend structure changes).
Operational edge cases: behavior during reconnects, insufficient margin, partial fills, or sudden spreads.
Indicator fragility: if the EA relies on indicators, check how sensitive it is to indicator parameter changes and to the data resolution used.

Historical relationships do not establish future results; the best available evidence is limited to the conditions you can verify.