Permission to run an Expert Advisor is not what disqualifies automated prop-firm accounts. Automation permission is not where firms compete — they differentiate on payout splits, drawdown limits, and challenge fees. So the condition traders verify before signing is not the condition that ends their account.
What ends automated accounts is a second layer of rules that never mentions Expert Advisors at all. Those clauses restrict behaviour: how long a position stays open, when orders may be placed, how quickly they follow a price move, and how many accounts carry correlated flow.
Five families are worth reading the terms for. What matters for us as developers is not the list itself but a question the list raises: which of them can the EA evaluate at runtime, and which are structurally invisible to it?
The runtime-checkability split
Only one of the five — prohibited strategy classes — can an EA evaluate about itself with no outside input. It knows whether it is a martingale, because it is the thing doing the position sizing.
Three more become checkable only once you supply what the code cannot derive. A minimum hold-time threshold. Your firm's restricted event list, mapped onto a calendar feed. A latency limit. None of these is discoverable from the terminal, because none of them is a broker-level setting — they are contractual terms.
The fifth, account correlation, cannot be resolved from inside the code at any price. More on that below.
Minimum hold time and the accounting gap
This is the clause with the quietest failure mode. Where a firm applies the rule in review rather than at execution, nothing gets blocked. The order fills, the position opens and closes, the terminal records it, and the profit or loss lands in the balance the trader is watching. The rule is applied afterwards, when the firm evaluates the result and removes the non-qualifying trades from the calculation.
The consequence is two versions of the same account. The trader watches one equity curve; the firm evaluates another.
Nothing in MQL4 or MQL5 surfaces the requirement, so the EA can only enforce what you hand it — the threshold as an input, checked before any close:
Gate every close behind that check and the trades stop being voided. But notice what the gate actually does: it holds a position the strategy wanted to close. The compliance rule and the trading logic are in genuine conflict, and resolving that conflict is a strategy decision rather than a coding one. Defaulting the input to zero matters here — an unconfigured EA should behave exactly as it did before, not silently defer exits.
What the MT5 calendar gives you, and what it does not
MT5 ships a built-in Economic Calendar and MQL5 exposes it: CalendarValueHistory() , CalendarValueLast() , CalendarEventById() and the related functions return scheduled events with country, currency, and an importance flag. MQL4 has no equivalent, so on MT4 the data has to come from outside the terminal entirely.
On MT5, then, the problem is not access. It is mapping.
The calendar's importance flag is MetaQuotes' classification of the event. Your firm's restricted list is published in its own terms, and nothing reconciles the two for you. An EA that blocks trading around everything the calendar marks high-impact is not implementing the firm's rule — it is implementing a different rule that happens to overlap.
Three decisions remain, and the calendar supplies none of them: which events count, the buffer before and after (rarely symmetrical), and what happens to positions already open when the window opens. The third is where implementations fall short most visibly. A filter that blocks new entries but leaves positions running through the release satisfies neither party — the firm may still count the exposure, and the trader carries the volatility they were trying to avoid.
Worth separating this from session and timezone filtering, since the two get conflated. Session filters answer "what time is it on the broker's server?" — clocks and DST offsets. News windows answer "what is scheduled next, and does my firm care about it?"
The clause a code review cannot check
Account correlation is the interesting one for anyone auditing EAs.
Correlation, group-trading, and copy-trading clauses restrict running the same strategy across multiple accounts — several evaluations at once, an evaluation alongside a funded account, or a firm account beside a personal one. The EA behaves identically in every case. What triggers the clause is that the order flow across those accounts is near-identical in timing and direction.
A code audit clears this EA. There is nothing in it to find. The breach is created by where it runs, not by what it does.
There is a second-order version if you did not write the EA yourself: a commercially sold EA runs on other people's accounts too. If two buyers run the same system at the same firm, correlated flow exists without either of them doing anything, and neither controls it. It is invisible from every angle you would normally check — the code, the backtest, and the trade history all look correct.
Sorting the five before you write anything
For each clause, one question: can the EA enforce this, only detect it, or neither?
Enforce covers prohibited strategy classes, and minimum hold time once the threshold is supplied. Detect covers news windows once the firm's event list is mapped, and latency, where the EA can time its own reaction but not the threshold it is judged against. Neither covers account correlation.
Start with neither. No monitoring catches it and no rewrite fixes it, because it is decided before the EA ever runs.
