A client paid $600 for an FTMO Phase 1 challenge. He’d been trading the strategy manually for four months with consistent results. The automated version lasted nine trading days before the account was disqualified — not because the EA lost money, but because it kept trading for four hours after his daily loss limit was breached. The strategy was sound. The EA had no compliance layer — and that gap kills more prop firm challenges than bad strategies do.
Most prop firm EAs fail evaluations not because the underlying trading strategy is unprofitable, but because they treat compliance rules as an afterthought — a few `if` statements tacked on after the strategy logic is built. The three gaps I see most in client projects are: daily loss enforcement that checks on bars instead of ticks, trailing drawdown calculations that track the wrong reference point, and lot sizing that ignores which phase of the challenge the EA is actually running.
The Challenge Fee Is Real. The Compliance Layer Isn’t.
When you trade a prop firm challenge manually, compliance is automatic. You watch the P&L. When you’re close to the daily limit, you stop. When drawdown looks dangerous, you reduce size. Your brain is the compliance module.
Automation removes that brain.
An EA has no intuition. If the code doesn’t explicitly check the daily loss limit on every tick and halt execution when it’s hit, the EA will keep trading. The strategy logic doesn’t know the account is now in violation — it only knows that price moved and a signal fired.
The client I mentioned above had passed Phase 1 manually without difficulty. When I reviewed the EA he’d had built elsewhere — the code audit patterns in those projects are documented in our anatomy of a code rescue work — the daily loss check appeared only in `OnTimer()` — set to fire every 15 minutes. On the day of the disqualification, his EA hit the daily loss limit at 10:43 AM and kept opening trades until 11:00 AM when the timer fired, caught the breach, and halted. By then, three additional trades had been opened and closed, pushing the account further into violation. The prop firm’s rule was clear; the EA just wasn’t watching continuously.
The compliance layer is not technically complex. But it must exist as a separate, deliberate engineering decision — not an afterthought.
How Daily Loss Enforcement Must Actually Work
The correct implementation checks on every tick — not every new bar, not every timer interval.
On each `OnTick()` call, calculate the sum of all floating unrealized P&L plus all realized P&L since the start of the trading day. Compare that to `startOfDayBalance × maxDailyLossPercent`. If the result reaches or exceeds the limit, the EA must:
- Close all open positions immediately
- Delete all pending orders
- Set a `dailyHaltFlag = true`
- Skip all trading logic for the remainder of the session
The halt flag resets at the start of the next trading day. That reset must use the broker’s server time — not UTC, not the local machine’s clock. A mismatch between how the EA calculates “new day” and how the prop firm calculates it can produce a violation that looks inexplicable in the logs.
One detail most implementations miss: capture `startOfDayBalance` at the first tick of each trading day, not at EA initialization. An EA that stores the starting balance once at startup and uses it for the entire week will allow larger daily losses as the account grows — or halt prematurely on a day following a loss.
Trailing Drawdown Is Not Maximum Drawdown
Most prop firms don’t use a fixed drawdown limit. They use a trailing drawdown — the maximum loss allowed follows the highest equity point the account has reached, not the starting balance.
The math difference matters enormously. An account starting at $100,000 with a 10% trailing drawdown limit:
| Event | Trailing Floor | What a Fixed-Limit EA Tracks |
|---|---|---|
| Account opens at $100,000 | $90,000 | $90,000 |
| Equity peaks at $103,500 | $93,150 | $90,000 |
| Equity peaks at $107,000 | $96,300 | $90,000 |
An EA monitoring only `startBalance × 0.90` believes it has a fixed $90,000 floor. After the account peaks at $103,500, the actual floor has moved to $93,150. The EA thinks it has $3,150 more room than it does.
I’ve seen this exact gap get a client disqualified with equity sitting at $91,800 — comfortably above the $90,000 the EA was tracking, but $1,350 below the $93,150 trailing floor the prop firm was enforcing.
The correct implementation maintains a running `peakEquity` variable, updated on every tick when current equity exceeds the stored peak. The drawdown floor is always `peakEquity × (1 − maxDrawdownPercent)`.
Phase-Aware Lot Sizing
Risk parameters vary across prop firm phases and firms. Some programs impose identical loss limits across Phase 1 and Phase 2 but relax them at the funded stage; others differ in daily loss allowances or maximum drawdown thresholds between phases. In all cases, an EA configured at one phase’s risk level will calculate incorrect lot sizes when placed on a different phase.
The failure mode is subtle. The EA calculates lot size correctly for the account balance and the stated risk-per-trade percentage. The problem is that the stated percentage is too aggressive for the current phase. A 2% risk-per-trade that works comfortably within a funded account’s drawdown limits may be enough to breach Phase 1’s daily limit after two consecutive losses.
The fix is a phase configuration input. Before starting the Challenge, the user sets `IN_Phase = CHALLENGE` and the EA applies the conservative risk multiplier for that phase. Moving to Verification: `IN_Phase = VERIFICATION`. Funded stage: `IN_Phase = FUNDED`. The lot size calculation reads the active phase before determining size.
This also makes position sizing auditable. When reviewing why the EA traded a specific size on a specific day, the active phase is logged at `OnInit()` and visible in the journal — no guessing which configuration was active.
How MT5 Netting Mode Breaks EA Position Logic
Several major prop firms have migrated to MT5 accounts in netting mode, not the hedging mode that most MT5 EAs are designed for. An EA built for hedging mode will compile without error on a netting account — and behave incorrectly from the first trade. (See account margin mode constants in the MQL5 documentation for the full list of margin mode enumerations.)
On a hedging account, opening a long and then opening a short gives you two separate, independent positions. On a netting account, the sell partially or fully closes the long — there is no separate short. An EA expecting a hedge now has no position at all.
The position management logic then checks `PositionsTotal()`, sees zero, and re-enters — creating an unintended trade loop that compounds the problem. None of this produces a compile-time warning. The code is syntactically valid. It’s architecturally wrong for the account type.
The guard is a single check in `OnInit()`:
if(AccountInfoInteger(ACCOUNT_MARGIN_MODE) == ACCOUNT_MARGIN_MODE_RETAIL_NETTING)
{
printf("%s: WARNING - Netting account detected. EA requires hedging mode.", __FUNCTION__);
return INIT_FAILED;
}This halts the EA cleanly with a clear log message rather than letting it run incorrectly for weeks. If the EA is designed to support both modes, the check informs a deliberate execution path — but that requires explicit architectural design, not a default assumption.
What a Compliant Prop Firm EA Actually Looks Like
A prop-firm-ready EA has three infrastructure layers that are architecturally separate from the trading logic:
- Compliance module — continuous daily loss enforcement and trailing drawdown tracking. Runs on every tick. Has no knowledge of and no dependency on the strategy.
- Phase configuration layer — input profiles that map to each challenge phase. Position sizing reads the active phase before calculating lot size.
- Account mode guard — checks hedging vs. netting mode at initialization and either fails cleanly or adapts behavior accordingly.
The trading strategy itself is often unchanged from the manual version. The work is the compliance wrapper.
When we build EAs for prop firm evaluation accounts at barmenteros FX, the compliance module is always built and tested in isolation before any strategy logic is integrated. Testing it means verifying: the daily halt fires at the exact limit (not after), the trailing floor tracks correctly after an equity peak, and the EA refuses to place trades after a disqualifying condition — even when the strategy generates a valid signal.
That separation matters. A compliance module entangled with strategy logic is difficult to test and easy to break accidentally during a strategy update. One that stands alone can be verified end-to-end in an afternoon.
If you’re assessing whether an existing EA needs a compliance retrofit or a complete rebuild, our evaluation framework covers that decision.
If your strategy works manually, automating it for a prop firm challenge is an engineering problem with known solutions. The mistakes above are preventable — they just require building the compliance layer before assuming the strategy logic is sufficient.
If you’re working on a prop firm challenge EA and want the compliance infrastructure reviewed before submission, get a quote from our team — prop firm compliance builds and audits are a regular part of our client work.
Leave a Reply