Automated Risk Management: Strategy vs Account Limits

A trader on a $100k evaluation with a 5% daily limit has $5,000 of room. He's running three strategies. Two behave. The third catches a gap, gives back $4,200 in forty minutes, and the other two are still opening positions into the same session because nothing told them to stop. The account breaches at 14:20 on a day where his actual edge was fine.

That's not a strategy failure. It's an enforcement failure, and it has a specific cause. The limits were in the wrong place.

Risk enforcement in an automated setup needs exactly two layers. Strategy-level limits contain a single strategy's behaviour: its own daily loss, its own trade count. Account-level limits watch the sum of everything and can halt all strategies at once. Without the second layer, one strategy can spend the whole account's budget while the others keep trading.

Why do most automated accounts fail on risk rather than strategy?

Because the failure data says so, across two independent datasets that don't share a methodology.

An analysis of more than 500,000 traders by hoc-trade found that 71% of first-phase prop challenge failures are daily-loss-limit breaches, most of them landing inside the first week. Overtrading appears in 49.5% of accounts. Revenge trading in 37.1%. A separate FPFX Tech study covering 300,000+ accounts across ten firms found 14% of traders pass the challenge, and only about 7% of everyone who buys one ever receives a payout.

Read those together and the picture is uncomfortable. The population isn't failing because their entries are bad. They're failing because a mechanical threshold gets crossed while nothing is watching the aggregate.

Automation doesn't fix this. It makes it faster. A strategy that would have taken you six discretionary trades to blow through a daily limit can do it in six minutes unattended, and the version of you that would have stopped at 3% isn't sitting at the desk.

What separates strategy-level from account-level limits?

Scope, and what happens when they fire.

A strategy-level limit knows about one strategy. It counts that strategy's realised P&L, its unrealised P&L, its trade count for the session. It has no idea what your other four strategies are doing, and it shouldn't. Its job is to contain one thing.

An account-level limit sits above all of them. It sums every strategy running on that connected account and measures against the account's own thresholds. When it fires, it stops everything, because at that point the problem isn't any single strategy. It's the account's total exposure for the day.

The distinction matters most in the case where every strategy is individually compliant and the account is not. Five strategies each configured to risk 1.5% a day are individually reasonable. Run together on a 5% daily rule, on a day when they correlate, they're a breach. Nothing at the strategy layer can see that. Only a layer above it can.

There's a third layer people ask for, and it shouldn't exist. Portfolio-level enforcement sounds like the natural extension, but a portfolio spans accounts at different brokers with different rules, different reset times and different definitions of what counts toward a daily loss. A portfolio-level stop would have to reach into venues that don't share a clock. Grouping accounts is useful for aggregate drawdown and per-strategy contribution, and it is not an enforcement boundary. Enforcement belongs where the rule belongs: at the account, because that's the unit the broker or the firm actually evaluates.

Which limits belong at which layer?

The one people skip is the daily unrealised limit, and it's the one that breaches accounts.

FundedNext's published trading objectives state that the daily loss cap "includes realized and unrealized P&L, swap, and commission" (fundednext.com/general-rules, verified 1 September 2026). If your automation only counts closed trades, you can sit at a comfortable-looking $1,800 realised loss with $3,600 of floating drawdown on open positions, be $400 past a $5,000 limit in the firm's eyes, and have no idea. The number on your screen is measuring something the firm isn't.

Swap is the version of this nobody writes about. Hold positions across the rollover on a 3% daily limit and overnight financing eats headroom you never traded away. On a $100k account with a 3% rule that's $3,000 of room, and a few hundred dollars of swap on a large FX position is a meaningful fraction of it before the session even opens.

What does the account layer actually measure against?

Three things decide whether your limit fires at the same moment the firm's does. Get any one of them wrong and your automation is enforcing a different rule from the one that terminates the account.

Equity, not balance. FundedNext calculates on equity, which moves with open positions. A limit computed from balance only changes when something closes, so it can sit still while an unrealised move takes you through the floor. If your platform lets you choose, choose equity. If it doesn't say which it uses, find out before you rely on it.

Static or trailing, and from what. FundedNext defines these plainly: a static limit is set from the starting balance and doesn't move, while a trailing one rises with profits, never falls back during losses, and stops climbing once it reaches the initial balance. The same firm can run both. FTMO's one-step uses a 10% max loss that trails on end-of-day balance; its two-step uses a 10% static one. Those are different products with different failure mechanics, and a configuration built for one will misfire on the other.

The reset boundary. FundedNext's daily limit resets at 0:00 server time, not your local midnight. If you're eight hours off server time and your automation resets its counter at your midnight, there's an eight-hour window every day where your limit and the firm's disagree about which day it is. Positions held through the firm's reset carry their floating loss into the new day's calculation on some models and not others.

Server time is the single most common misconfiguration I see in this category, and it produces the worst kind of failure: everything looks correct, the numbers reconcile, and then one position held through a rollover breaches an account that was never close to its limit.

What should happen when a limit is hit?

Two different things, and conflating them is a design mistake.

A strategy-level breach should pause that strategy until the next session. The system misbehaved, its day is over, tomorrow it resumes. It's a recoverable event, and treating it as terminal creates a different problem: traders disable limits when they get tired of manually re-enabling strategies every week.

An account-level breach should stop everything and stay stopped until you intervene. That's not a bad day for one system. That's the account hitting the number the firm measures, and the correct behaviour is a hard halt that requires a human to look at it before anything trades again.

The subtler question is what "stop" means for positions already open. Blocking new entries is easy. Deciding whether to flatten existing exposure is a real choice with no universally right answer. Closing at the limit locks the loss at the worst moment of the day. Leaving it open means the limit didn't cap anything. My own preference is to block entries and leave open positions to their own stops, because those stop levels were part of the plan and the limit wasn't meant to override them — but that should be configurable, and you should know which way yours is set before you find out during a breach.

How do execution modes change the picture?

A limit set for one-shot signal entries behaves differently the moment a strategy is allowed to open more than one position per idea.

DCA sequences and grids are designed to add into drawdown. That's the mechanism, not a malfunction. A DCA ladder with six safety orders will show its largest floating loss immediately before the recovery it was built for, which means the daily unrealised limit is the constraint that binds first, and it can close the sequence at precisely the point the strategy was constructed to survive.

So the numbers have to come from the ladder, not from a default. Work out the maximum floating drawdown the full sequence can reach at your deviation and multiplier settings, and check that figure against the account's daily headroom before the strategy runs anywhere near live money. If the ladder's worst case exceeds the daily limit, the strategy and the account rule are incompatible. Reduce the ladder or don't run it there.

Max concurrent positions does the useful work here. It's a strategy-layer control and it's the one that caps exposure shape directly, independent of P&L. Grids in particular will happily open twenty positions in a trending market that never comes back.

Trade count is the setting people are too generous with. If a strategy normally takes three to five trades a day, cap it at eight, not thirty. A signal source that starts misfiring — a webhook duplicating, an indicator repainting into repeated triggers — produces a volume anomaly long before it produces a loss big enough to hit a P&L limit. The trade count is your early detector, and it's free.

Where does enforcement physically have to run?

This decides whether the limits work at all, and almost nobody asks it.

There are two architectures. Enforcement can live in the terminal, inside an Expert Advisor on your MT5 install, computing limits locally from what that one terminal can see. Or it can live on a server, computing from its own record of every fill across every connected account and sending instructions down to a connector.

Terminal-side keeps working if the vendor's servers go down. Everything else about it is a constraint. It sees one terminal, so it structurally cannot enforce an account-level limit across an MT5 prop account and a crypto exchange account at the same time. It's harder to audit, because the logic lives on a machine you have to remote into. And it competes for a budget that terminates accounts: FTMO publishes a limit of 2,000 server requests per day, and a terminal-side system doing its own polling and order modification spends that on housekeeping.

Server-side inverts the trade. One place holds the state of every account, so a genuine account-level limit becomes possible across venues that share nothing else. The logic is inspectable. The cost is that it needs a live connection to act, which is a real failure mode with a real answer, and one worth a page of its own rather than a paragraph here.

Vectorhelm runs the second model. Every limit and every trigger is evaluated on our side, and the MT5 EA is a connector that carries instructions to the terminal and reports fills back. One thing about that is worth stating precisely, because it's the part most tools in this category leave undisclosed: when a strategy defines a stop loss and take profit, those are placed as real orders on the broker's server. They aren't levels we watch and close against. Once placed they execute whether the terminal, the connector or we are alive.

How do you set the actual numbers?

Start from the rule you're measured against and work backwards, leaving room for the things that consume budget without being trades.

On a 5% daily rule, set the account-level daily loss limit to 4%. That 1% absorbs spread on exit, commission, swap, and the gap between your limit firing and the fills landing. Setting it at 4.9% to use the room is how people breach by $60.

On a 3% daily rule — FTMO's one-step, FundedNext's Stellar one-step, The5ers — set it to 2.3–2.5%. The tighter the rule, the proportionally larger the buffer needs to be, because fixed costs like commission don't shrink with the limit.

Then divide downward. Running four strategies against a 4% account limit, don't give each a 4% strategy limit. That's four ways to spend the whole budget. Give each 1.5%.

The strategy limits sum to more than the account limit on purpose. They aren't a budget allocation. They're a containment ceiling for the case where one system misbehaves alone, and the account limit is the backstop for the case where they all misbehave together. If you set them to sum exactly to the account limit, you've given every strategy less room than it needs on a normal day in exchange for protection the account layer already provides.

Test the configuration somewhere it can't cost you anything before it runs on a live account. Not for a day. For long enough that a limit actually fires, because watching one fire is the fastest way to find out you set it wrong, and reading the setting back off a config screen tells you nothing about how it behaves at 14:20 on a bad Thursday.

The honest limitation

Enforced limits change the shape of your losses. They cut the left tail, the catastrophic session that ends an account. They do not make a losing strategy profitable, and they carry a real cost: a limit that fires on a day the strategy would have recovered turns a temporary drawdown into a locked loss.

That happens. It's the premium you pay for never having the other kind of day.

If your strategy's edge depends on holding through deep intraday drawdown, hard daily limits will hurt it, and you should know that before you set them rather than after. The traders they help most are the ones automating a funded account, where a breach has an explicit dollar cost and recovery isn't something the firm offers.

Start with the layer you're missing

Most people reading this already have strategy-level protection of some kind. A stop loss is one. Far fewer have anything watching the account.

Work out which rule actually terminates your account, and on what basis it's calculated — equity or balance, static or trailing, resetting at which clock. Set the account-level daily limit at roughly 80% of it. Then set per-strategy limits low enough that no single strategy can reach the account limit alone.

That ordering is the whole design. Everything else is tuning, and it applies whatever you're running it on.

We're building both layers of this into Vectorhelm, with a sandbox to configure them in before anything touches a live account. It isn't open yet. If you want it when it is, early access is here.

Vectorhelm is execution software. It runs the rules you define on accounts you own and control. Nothing here is trading advice, and no configuration of risk limits prevents losses.