Automated Drawdown Protection: Multi-Account Controls

Automated drawdown protection is a set of software checks that can monitor account data, block supported new entries and request action when a configured threshold is approached. It cannot guarantee that a broker executes in time or that a prop-firm rule is never breached. With multiple accounts, calculate each account’s applicable limits separately and verify which order sources the control can actually govern.

Drawdown rules: configure the formula, not just a percentage

Historical peak-to-trough drawdown is a performance statistic; a programme’s daily or overall loss limit is a contractual calculation. They are not interchangeable. Record provider, product, phase, account cohort, initial simulated capital, balance/equity basis, open P/L and charges, reset time zone and any static or trailing rule. Use the strictest current applicable floor.

For the current FTMO CFD 2-Step Challenge, Verification and subsequent 2-Step Account, the daily floor is the balance at 00:00 CE(S)T minus 5% of initial simulated capital; the overall floor is static at 90% of that initial amount. The official objectives describe different 1-Step and Instant calculations. Do not copy the 2-Step profile to them or another provider.

An equity reading of $96,000 would already be below this daily floor, even though it is above $95,000. A hard-coded first-day floor would miss that breach. Include the provider’s treatment of floating results, swaps and commissions; do not subtract an open loss twice if equity already includes it.

Core controls: observation, trigger and execution are different

A local risk manager needs a tested sequence: receive sufficiently current account data, calculate floors, decide whether new exposure fits, request any permitted cancellation/closure, then reconcile actual outcomes. A submitted close request is not a completed close. In MQL5, OrderSend returning true does not prove execution; inspect the response and subsequent transactions.

Do not wait for the contractual boundary and claim that closing afterwards prevents a breach. An illustrative local trigger $300 above the $97,000 floor would be $97,300. That reserve is a chosen test assumption, not a guarantee against gaps, slippage, rejection or disconnection. A stop moved to entry does not guarantee a net break-even result after spread, charges and execution differences.

• Data uncertain: block supported new entries, report the missing/stale input and use the documented incident procedure for existing exposure. Never label unknown positions as flat.
• Threshold triggered: record account, rule version, time and intended action; stop controlled sources from adding risk while handling supported outstanding orders.
• Close pending: track accepted and rejected requests, partial quantities and remaining positions. A retry must not blindly duplicate an order whose outcome is unknown.
• Paused: retain the reason across restart. Reconcile account state and confirm the current rule profile before a controlled resume.

Multi-account architecture and position sizing

A central manager can coordinate supported agents; distributed controls can evaluate individual accounts. Neither architecture is automatically reliable. Document the controller, credentials/permissions, connection health and owner for each account. A dashboard view alone does not confer trading authority. Prevent two controllers from independently managing the same order stream without coordination.

Keep per-account floors even when using a portfolio alarm. A gain elsewhere does not repair a breach. In a fictional equal-sized portfolio, three $100,000 accounts each losing $1,000 lose $3,000/$300,000 = 1% combined, not 3%. All three can nevertheless reach their own 1% local trigger together. Common trades and shared infrastructure create common failure exposure.

Calculate proposed price risk from the actual instrument contract, stop distance, account currency and tradable volume step, then compare it with remaining room after additional open-position risk and cost assumptions. A fixed 1% or 2% allocation is not universally safe. Minimum lots can make an order too large; do not round upwards just to place it.

Test the protection layer before relying on it

1. Test reset boundaries and daylight-saving changes, an open loss at reset, a changed balance and each applicable static/trailing floor.
2. Test stale quotes/account data, disconnection, restart, rejected/partial closes and an order with an initially unknown outcome.
3. Test manual trades, other EAs and other terminals: identify which entries the control actually blocks. Disabling MetaTrader AutoTrading is not a broker-side close and can also prevent the protection EA from sending its own trade requests.
4. Compare expected actions with requests, confirmed deals, remaining exposure and logs per account. A profitable backtest does not establish reliable failure handling.

MQL5 OnTick is driven by the chart symbol and queued events, not a promise that every account is checked every millisecond. Specify the monitoring design and stale-data threshold instead of assuming constant coverage. Hosting a local terminal closer to a broker does not remove market or programme risk.

Product scope and separate programme permission

The JPTC EA Hub is customer-operated MetaTrader software. Check the specific file’s documented controls and supported platform; this article is not evidence of an included central dashboard, copier, alert channel or universal rule engine. The separate hosted JPTC Algo requires no customer installation or own VPS. Neither is a compliance, pass or payout guarantee.

Permission to automate is a separate requirement even when software is described as a risk tool. Check the exact programme and third-party-software terms. Consistency objectives and minimum trading days are also separate: do not invent a single-trade profit cap or place artificial trades merely to make a counter advance. Sources checked on 16 October 2026; numerical account and trigger examples are fictional.