A MetaTrader Risk-Management Solution Compared: Manual, EA-Based, Server-Side

A VPS in Frankfurt reboots for a host update at 02:14. The terminal comes back eleven minutes later, and the expert advisor that was enforcing a daily loss halt comes back with it — with its internal counter reset, because the counter lived in memory. For those eleven minutes there was no risk management on the account, and for the rest of the day there was a guard that believed the day had just started.

Nothing in that sequence is exotic. It is the single most common way a risk control fails, and it is a direct consequence of where the control was placed. That is the real question behind choosing a MetaTrader risk-management solution: not which one has more features, but what happens to it when something breaks.

The controls are the same in all three cases

Before comparing approaches, it is worth being clear that they are all trying to do the same four things.

1. 01Size each position from a percentage of equity and the stop distance, using the symbol's real tick value.
2. 02Ensure every position has a stop, and that the stop was actually accepted by the server.
3. 03Cap aggregate exposure — concurrent positions, total open risk, and correlated direction.
4. 04Halt at a daily loss threshold, measured on equity, on the right clock.

Anything beyond those four is refinement. The comparison below is about where those four live.

Approach one: manual

You compute the size in a spreadsheet or a calculator, type it in, set the stop by hand, and watch your own daily total.

What it costs. Nothing, except time and attention.

Where it is genuinely better. Discretionary trading at low frequency, where each position is considered individually and the act of computing the size is part of thinking about the trade. A trader placing two positions a week is well served by a spreadsheet and does not need software.

How it fails. It fails at the moment it matters most. The failures are predictable and they are all attention failures: a transposed lot size under time pressure, a stop left blank on a fast entry, a running daily total that was accurate until the third trade, and a position opened at 22:40 because the day felt fresh when the server's day was nearly over. None of these are discipline problems in the moral sense. They are the consequence of asking a serial processor to do continuous monitoring.

The honest limit. Manual risk management has no answer at all for the hours you are asleep. If you hold positions overnight, part of your risk control is unstaffed by definition.

Approach two: an expert advisor on the terminal

The controls live in MQL4 or MQL5 code running inside your terminal — either built into your strategy or as a separate risk-manager advisor on its own chart.

What it costs. A one-off purchase or your own development time, plus a VPS if you want it running when your machine is not.

Where it is genuinely better. Reaction speed and access. Code on the terminal sees every tick, knows the symbol's exact contract specification, and can act in milliseconds. For anything that needs to respond faster than a human — a stop that must be attached the instant a position appears, a halt that must block the next entry rather than the next one after that — this is the right placement.

How it fails.

• State in memory. Counters, daily references and halt flags held in variables are lost on restart, recompile, or a settings change. A guard must persist its state to a file or to a global variable that survives, and many do not.
• The terminal is a single point of failure. If MetaTrader is not running, nothing is enforced. Reboots, updates, crashes, an expired demo server connection, and a VPS provider's maintenance window all produce the same outcome.
• AutoTrading gets switched off. A single click, or a platform update that resets the setting, silently disables everything.
• Clock and timezone. The advisor reads the broker's server time, which is not your time and may not be the prop firm's reset time. A daily guard on the wrong clock is a guard on the wrong day.
• One terminal, one account. Enforcing consistent rules across five accounts means five installations, five configurations, and five opportunities to configure one of them differently.

Approach three: server-side

The controls live on infrastructure that is not your terminal — a service that holds an authenticated connection to the account, watches equity and positions continuously, and acts through the broker's API.

What it costs. A subscription, and a dependency on a third party whose uptime you do not control.

Where it is genuinely better.

• It does not stop when your machine does. No terminal to crash, no AutoTrading button, no VPS reboot at 02:14.
• It sees every account at once. A single set of rules applied across several accounts, with the state held in one place. For anyone running a strategy across multiple funded accounts, this is the difference between one configuration and five.
• State survives by construction, because it is in a database rather than in a variable.
• The audit trail is real. Every decision, every order, and every rejection is recorded and readable after the fact, which is what you need when reconstructing an odd afternoon.

How it fails.

• Latency. A round trip over the network is slower than code on the terminal. For a halt that blocks new entries, the delay is immaterial. For anything that needs to act within a tick, it is not.
• The connection is the dependency. An API session that drops, a credential that expires, or a broker that throttles requests takes the control offline just as surely as a terminal crash — the difference is that a good service tells you, and a crashed terminal does not.
• Trust surface. Server-side control means credentials held by someone else. That is a real consideration and it deserves a real answer from any vendor: what is stored, how it is encrypted, what the service can and cannot do with the connection, and what happens to the data if you leave.
• You inherit their incident. When the provider has an outage, you have an outage.

Side by side

The combination most working traders end up with

In practice these are not exclusive, and the arrangement that holds up is layered.

1. 01Sizing at the point of entry, computed by a tool rather than by hand, because the transposed-digit error is the most expensive and the most avoidable.
2. 02A hard stop on every position, on the server, placed as part of the order rather than managed by software after the fact. A stop sitting on the broker's server is the only control that works when everything of yours is switched off.
3. 03A terminal-side guard for the fast decisions — stop presence, maximum lot, blocking an entry that breaches a cap.
4. 04A server-side guard for the slow, continuous ones — the daily equity halt, aggregate exposure across accounts, and the monitoring that tells you when a terminal has gone quiet.
5. 05A weekly manual review, because none of the above can tell you that the strategy has stopped working.

Point two deserves emphasis. Every layer above it is software that can be off. A stop-loss order accepted by the broker is not software you are running; it is an instruction the venue holds. It is imperfect — it does not defend against a gap — and it is the only thing on the list that does not depend on something of yours being alive.

Choosing, in one paragraph

If you place a handful of considered trades a week and hold nothing overnight, manual plus server-side stops is sufficient and everything else is overhead. If you run automation and need fast, deterministic reactions on a single account, an expert advisor with properly persisted state is the right tool. If you run several accounts, or hold positions when you are not at a screen, the continuous part of the job belongs somewhere that does not share a fate with your terminal. Most traders discover that ordering the hard way, usually at 02:14.

Where this fits

For what each of those four controls actually enforces on MT5, and the limits of all of them, read mt5-risk-management-tools. If the daily halt threshold is the number you are trying to set, the arithmetic behind it is in what-is-daily-drawdown.