Put the cost threshold beside a backtest win rate

Can the win rate in a strategy video be repeated on a continuous data window? That is the question behind the Supertrend plus EMA200 case. For an MT5 EA, a program that applies trading rules, I would ask a second question before changing its settings: what win rate would cover the costs used in this particular simulation?

The pair that matters

The frozen base run measured a win rate of 40.04% across 984 trades. The recorded break-even win rate was 41.10%. In this simulation under stated costs, the measured rate was below that threshold.

Those are historical model outputs. They do not predict an account result or whether a prop challenge will pass. The video's approximate 46% came from a different experiment. Its timeframe and parameters were not fully stated, so this is not an exact replication.

A review checklist before changing the EA

1. Keep the cost model beside the result. This case uses Dukascopy H1 Bid bars for EURUSD and EURJPY, from 2017-01-02 to 2026-06-26. The fixed spreads are 1.0 and 1.2 pips respectively. Commission is $7 per lot round trip. EURJPY conversion uses a fixed USDJPY assumption of 140. These are stated assumptions, not measured broker costs.

A screenshot with the win rate but none of those inputs leaves the reader unable to interpret the threshold.

2. Keep the held-out period visible. The split was declared before testing: exits before 2024-01-01 are in-sample; exits on or after it are out-of-sample. The pooled base figures were 705 in-sample trades with a win rate of 41.8%, and 279 out-of-sample trades with a win rate of 35.5%.

In this simulation under stated costs, the later sample did not repeat the earlier rate. Do not erase that difference by showing only the combined row.

3. Fix the ambiguous-bar rule before the run. Signals use closed bars and entries use the next bar's open. If one H1 bar touches both stop and target, the simulation uses stop-first. One base trade was affected. H1 bars do not reveal the real order of those touches.

Three acceptance checks for the report

• The displayed result, cost threshold and data window all come from the same frozen base run. A threshold from another spread setting fails the check.
• The report shows both sides of the declared date split. A combined percentage alone fails the check.
• An ambiguous bar is identified and its fixed resolution rule is recorded. A result described as an observed execution fails the check because these fills were modeled.

For a trader with their own challenge EA, that is a useful boundary: first make the historical simulation auditable. Challenge rules and live execution need their own checks. A win rate cannot stand in for them.

The canonical case study contains the rule sheet, figures, results and limits. The measurements above are copied from its RESULTS.md, not a new run.

Update, 2 October: the commission contract

A reader asked how to obtain the commission before opening an order. For an MT5 EA, a program that applies trading rules, I would first separate two records: the assumed charge in the historical simulation and the charge recorded after an actual execution.

They answer different questions. A simulation can use a declared fee. That does not turn the declaration into a broker receipt.

Freeze the meaning before the value

A useful cost record needs these fields:

type CostAssumption = {
  instrument: string;
  commissionBasis: "per_lot" | "per_order" | "trade_value";
  chargingSide: "entry" | "exit" | "round_trip";
  currency: string;
  spreadUnit: "pip" | "point" | "price";
  conversionRule: string;
  sourceKind: "declared_assumption" | "observed_charge";
};

This is a proposed data contract, not a broker integration. The fee amount belongs beside it. Do not let an absent charging side fall back to round trip. Do not treat a price point as a pip because both are numbers.

Four acceptance checks for the report

1. A complete trade: the entry and exit receipts identify which side carries the fee. A round-trip assumption must not be charged once as a round trip at entry and again as a round trip at exit.
2. A rejected order: keep the rejection separate from a fill. An attempted order is not evidence of the assumed execution charge.
3. A position still open: show whether the simulation has charged entry only or booked a declared round-trip estimate. Do not silently compare that estimate with a realized closed-trade total.
4. A currency mismatch: require the named conversion convention. A USD fee and an account balance in another currency do not share a unit automatically.

The expected result is an auditable cost record for each execution event. These checks test the bookkeeping contract. They do not establish that the chosen fee matches a future broker bill.

A frozen example

The canonical Supertrend case declares a $7-per-lot round-trip commission and fixed spreads of 1.0 pip on EURUSD and 1.2 pips on EURJPY. Its EURJPY conversion uses fixed USDJPY 140. These are assumptions recorded with the test, not observed live costs.

The historical simulation uses Dukascopy H1 bid bars from 2017-01-02 to 2026-06-26. In this simulation under stated costs, the reported numbers belong to that exact rule and cost contract. A changed charging side or conversion convention requires a separately recorded run.

For a prop-challenge comparison, there is another boundary: a closed-trade cost ledger alone is not the intraday account-value path required to check a loss rule. First establish what the report contains. Then decide which question it can answer.

Source question: the reader's cost question. The frozen case above contains the data, costs and limits. No account outcome or challenge result is promised.