MQL5 Daily Loss Limit: Add an Account-Level EA Safety Guard

Quick Answer

An MQL5 daily loss limit needs a defined trading-day reset, a precise profit-and-loss measurement policy, and a persistent lock that prevents new entries once the threshold is reached. Decide whether it measures balance, equity, realized deals, floating P/L, or a combination. For multiple EAs on one account, a limit checked independently by each EA is not a reliable account-wide guard.

Why This Matters to Me (Personal Experience)

When I first started algo trading, I blew a $500 account in just three days because my EA had no daily loss limit. I woke up to a margin call. That painful lesson taught me that risk management isn't just a "nice to have" — it's the difference between survival and blowing up. Now, I never deploy an EA without a hard-coded daily drawdown guard. This guide is exactly how I implement it in MQL5.

Key Facts

| Design choice | Decide before coding | |---|---| | Reset clock | Broker server day, UTC day, or the prop firm's specified session | | Loss measure | Realized P/L, equity drawdown, or both | | Baseline | Day-start balance/equity or a specified reference | | Scope | One EA, one symbol, or the entire account | | Lock behavior | Block entries only, or also close positions / cancel pending orders | | Restart behavior | Preserve the lock and baseline across terminal or EA restarts |

Daily loss rules vary between firms and account types. Some use a fixed starting balance, others use equity including open losses, and the reset may follow a particular server timezone. Do not assume a common definition: check the actual account agreement and use its clock and calculation policy.

Also decide how the guard treats open positions that cross the reset boundary. If the rule is based on total account equity, losses on positions opened yesterday may still matter today. If it is based only on today's closed deals, floating losses may not trigger the same threshold. These are different policies and should not be conflated in the name of a single “daily loss” setting.

Define the Rule Before the Implementation

Suppose an account starts the trading day with a chosen reference value R, and the limit is L in account currency. An equity-based guard might block new trades when:

reference equity - current equity >= loss limit

A percentage threshold can be converted into cash using the reference specified by the rule:

cash limit = reference value × daily loss percentage / 100

That still leaves important choices. Does the system include commissions and swap? Do deposits affect the reference? Do open positions opened before the reset count? Should the EA close open exposure when the limit is hit, or merely prevent new orders? These decisions materially change behavior and must be aligned with the relevant risk policy.

Reliable State and Multiple EAs

The day-start reference and the locked/unlocked state need to survive an EA restart. An in-memory variable alone resets when the terminal restarts or the EA is removed. Store state persistently with a key that includes the account and the trading date, validate it at startup, and record when the limit is reached. If persistent state is missing or corrupt, choose a documented safe behavior; do not silently reset the daily loss counter.

For several strategies on one account, the limit should be enforced by a shared risk manager or a single coordinated component. Separate EAs can race: each can check the limit before another EA's trade changes equity. A terminal global variable or file is not automatically a complete multi-process risk system; define ownership, locking, failure handling, and account scope.

At the point an EA considers a new order, the control flow should be explicit:

1. Read or update the current trading-day state.
2. Calculate loss using the selected policy.
3. If threshold is reached, persist the lock and stop new entries.
4. Apply the documented policy to existing positions and pending orders.
5. Log the reason, reference, measured loss, threshold, and reset time.

Do not infer that rejecting new entries closes existing risk. Those are separate actions. Closing positions automatically can also incur slippage or interfere with other strategies, so it must be deliberately designed and tested.

If the limit must cancel pending orders, enumerate and cancel only the orders covered by the policy, verify each server response, and account for orders that fill during the cancellation process. If it should close open trades, define whether the rule applies to all positions or only positions owned by the EA. A local check cannot control trades placed manually or by an uncoordinated EA.

Testing Checklist

Test around the reset boundary, not only midday. Simulate an EA restart after a loss-limit breach and verify the lock remains. Check realized losses, floating losses, commissions, deposits, and positions carried over from the previous day according to the chosen policy. If multiple EAs share the account, test the shared control with overlapping signals.

For prop traders, compare the EA's measurement to the firm's actual dashboard and documented rules. A local guard is an additional control, not a guarantee of compliance or protection from gaps. Pair it with sensible risk-based lot sizing, conservative testing, and human monitoring.

Keep a visible status message or log that shows whether trading is permitted, why a lock is active, and when the system expects the next reset. This helps distinguish a deliberate safety lock from a disconnected EA or a strategy with no signals. Do not automatically clear a lock just because the terminal restarts.

Frequently Asked Questions

Should a daily loss limit use balance or equity?

It depends on the rule being enforced. Balance generally reflects closed results, while equity includes floating P/L. Many account rules define their own reference and timing; implement those exact terms rather than choosing by convention.

Does the daily loss limit reset at midnight?

Not necessarily. Midnight may refer to broker server time, UTC, or another session boundary. Use the timezone and reset time specified by the strategy or account rules.

Is one limiter in each EA enough for the whole account?

No. Separate EAs can each act on incomplete account context or place orders concurrently. Account-wide enforcement needs a coordinated design and must include other manual and automated exposure where relevant.

Treat the Limit as a System Requirement

A daily loss guard is only as dependable as its definition, persistent state, and account-wide coverage. Document what triggers it and what it does, then test restart and boundary cases on demo. CodeFlowOS can help translate strategy logic into compiler-verified MQL5 output, but account-level safety rules still need deliberate design and independent verification.