Running an EA on a symbol it was never built for

[Fairman]

Running an EA on a symbol it was never built for

It's tempting. An EA works on EURUSD, so you try it on GBPUSD, gold, or an index. Sometimes it works. Often it doesn't, and the reasons are usually more mechanical than about the market.

First, pip and point size. Code that assumes a pip is 0.0001 will be off on JPY pairs and badly wrong on gold or indices. Stops, targets and position sizes will all be wrong.

Second, volatility. Fixed pip stops and targets designed for EURUSD are way too tight for gold and maybe too wide for EURGBP. If the EA uses ATR based values, it adapts better, but fixed values are common.

Third, trading hours and spread behaviour. Indices have sessions and gaps. Gold has different spread patterns. A session filter tuned to EURUSD might not suit the new symbol at all.

Fourth, contract size and lot step. A risk calculation that works for FX lots can be way off for an index CFD.

So before running an EA on a new symbol, check how it handles point size, whether stops and targets scale with volatility, and how it calculates size. Then test it properly on that symbol's data.

If the results only hold on the original pair, that tells you something too. The edge might be specific to that market.

[Fairman]

A good sign an EA is robust is if it works reasonably on several related pairs with the same settings. If it only works on one pair with one parameter set, it's probably fitted to that pair's history. Running the same settings on a few similar pairs, without reoptimising, is a quick robustness test. You don't need it to be equally profitable everywhere, but if it's a disaster on every other pair, I'd be suspicious of the original result too. Results that only exist on one pair with one exact set of settings usually belong to the history rather than to any real edge.

[Fairman]

In MQL, using SymbolInfoDouble for point and tick size, and SymbolInfoInteger for digits, makes the code adapt to whatever symbol it's attached to. A lot of older EAs hard code these values or use the Point variable in ways that break on five digit or three digit brokers. If you're writing your own, getting these from the symbol at runtime is one of the easiest ways to avoid a whole category of bugs when switching symbols. Older code often uses fixed point values that were written for one broker's digit count, and those break as soon as the EA moves.

[FXS Prop Desk]

Trading hours belong on that list too. An EA with a session filter for forex may trade outside index trading hours or during the thin periods for gold.

Spread is the other factor. A strategy that works on EURUSD with a 0.2 pip spread may not survive on GBPUSD with 0.8 or on gold with several pips, even if the price behaviour is similar. Testing with realistic costs for each symbol is essential.

[Fairman]

Session times are another thing that often doesn't transfer. An EA built for EURUSD might have a trading window set for the London session, which suits EUR pairs. On AUDUSD or USDJPY, the most active hours are different, so the same window might cover the wrong part of the day. I'd check what hours the EA trades and whether they make sense for the new symbol. Sometimes just adjusting the window improves results on a new pair more than any change to the strategy settings. The hours can usually be changed in the inputs, so it's a quick test.

[Fairman]

Costs as a share of the typical move change a lot between symbols. An EA that makes ten pips on average per trade on EURUSD with a one pip spread has costs at ten percent. On a pair where it makes the same ten pips but the spread is three pips, costs are thirty percent, which can turn a profitable system into a losing one. Before running an EA on a new symbol, I'd compare the average trade size in the backtest with the symbol's typical spread and commission. That comparison takes five minutes and can save months of disappointment.