One detail on the slippage-setting point: if an EA passes that input to MqlTradeRequest.deviation, its effect depends on the execution mode. That field is used with Instant/Request execution and ignored with Market/Exchange execution. Lowering it therefore doesn't cap slippage on a Market Execution symbol. I'd record the execution mode alongside requested and filled prices when comparing news trades.
thanks, I didnt know that. So a "max slippage" input can look like protection in the settings and do nothing at all on a market execution symbol.
If I buy an EA with such an input, I'd now ask the seller which execution mode it was tested on. And the requested vs filled price on a few live releases shows quickly if the setting does anything or not.
yes, the calendar in the tester was the reason i started asking sellers about it.
Your last point is the one I'd check first. A filter that only blocks new entries still leaves every open trade sitting through the release, and thats exactly where the stop gets filled far away from its price. So "has a news filter" tells me very little until I know which kind it is.
Best regards,
Chris
Hello Chris,
Agreed. When I ask a seller about it, I ask three things: does it only block new entries or also close or protect open trades, how many minutes before and after the release, and where the news times come from in the tester. If they can't answer the third one, the backtest is the "without" version.
For open trades there is also a middle option between "do nothing" and "close everything": move the stop to break-even or take partial profit a few minutes before high-impact releases. It keeps the trade but limits what a bad fill can cost.
Agreed. When I ask a seller about it, I ask three things: does it only block new entries or also close or protect open trades, how many minutes before and after the release, and where the news times come from in the tester. If they can't answer the third one, the backtest is the "without" version.
For open trades there is also a middle option between "do nothing" and "close everything": move the stop to break-even or take partial profit a few minutes before high-impact releases. It keeps the trade but limits what a bad fill can cost.
Best regards
Youness
Thanks Youness,
I'll add the third question to my list. If the seller cant say where the news times come from, that already answers it.
On the middle option I'd split it in two. Moving the stop to break-even doesnt change much on a real release, because a stop at entry gets skipped the same way as any other stop. Taking partial profit is different. A smaller position is what actually limits the bad fill.
I'll add the third question to my list. If the seller cant say where the news times come from, that already answers it.
On the middle option I'd split it in two. Moving the stop to break-even doesnt change much on a real release, because a stop at entry gets skipped the same way as any other stop. Taking partial profit is different. A smaller position is what actually limits the bad fill.
Best regards
Chris
Hello Chris,
Glad the third question is useful. And fair split: break-even is still just a stop, so a real release can skip it like any other. The smaller position is what actually limits the fill.
There is also a second problem with break-even right before news: on many brokers the spread widens before the release. A stop sitting at entry can then be hit by the spread alone, before price has really moved. So you pay the wide spread, lose the trade, and sometimes watch it go your way afterwards.
So if break-even is used at all, it needs room for the widened spread, or it's better done well before the event, not at the last minute.
@Yang Yu Qun that's a very useful test, and measuring only the trades the filter would block is the right way to look at it.
One thing I'd keep in mind when reading those numbers: with the tester's default "zero latency" setting, a stop is filled at the price in the tick history, with no execution delay. In the first seconds of NFP a live account can get filled later and worse than that. So the blocked trades probably look a bit better in the backtest than they would live. "No difference" is a good sign, but it's closer to a best case.
Two cheap ways to check it: rerun the same test with one of the tester's delay settings instead of zero latency, and on a demo or small live account log the requested vs actual fill price for the trades inside the window. If the gap stays small on your broker, leaving the filter off makes sense.
@Rui Nan Yang agreed, and it's worst for pending stop entries, since the breakout itself triggers them at the bad price.
Allow the use of cookies to log in to the MQL5.com website.
Please enable the necessary setting in your browser, otherwise you will not be able to log in.
You are signed in. Two-factor authentication has been disabled. Set it up again and scan a new QR code, or continue with two-factor authentication disabled.
One detail on the slippage-setting point: if an EA passes that input to MqlTradeRequest.deviation, its effect depends on the execution mode. That field is used with Instant/Request execution and ignored with Market/Exchange execution. Lowering it therefore doesn't cap slippage on a Market Execution symbol. I'd record the execution mode alongside requested and filled prices when comparing news trades.
MetaQuotes documents the distinction here: https://www.mql5.com/en/book/automation/experts/experts_market_buy_sell
The first few minutes of news broadcasts can cause significant slippage, which is extremely unfriendly to most types of EAs.
You might be opening a position and stopping out at a very bad price, far worse than you set your entry point.