[{"data":1,"prerenderedAt":113},["ShallowReactive",2],{"live-categories":3,"hub-risk-management":34},{"categories":4},[5,11,15,19,23,26,30],{"slug":6,"sort":7,"name":8,"description":9,"metaTitle":9,"metaDescription":9,"articles":10},"risk-management",1,"Risk Management",null,2,{"slug":12,"sort":10,"name":13,"description":9,"metaTitle":9,"metaDescription":9,"articles":14},"prop-firms","Prop Firms",5,{"slug":16,"sort":17,"name":18,"description":9,"metaTitle":9,"metaDescription":9,"articles":10},"tradingview",3,"Tradingview",{"slug":20,"sort":21,"name":22,"description":9,"metaTitle":9,"metaDescription":9,"articles":17},"mt5",4,"Mt5",{"slug":24,"sort":14,"name":25,"description":9,"metaTitle":9,"metaDescription":9,"articles":7},"crypto-exchanges","Crypto Exchanges",{"slug":27,"sort":28,"name":29,"description":9,"metaTitle":9,"metaDescription":9,"articles":7},"strategies",6,"Strategies",{"slug":31,"sort":32,"name":33,"description":9,"metaTitle":9,"metaDescription":9,"articles":7},"comparisons",7,"Comparisons",{"articles":35,"total":10,"page":7,"perPage":112,"pageCount":7},[36,82],{"id":37,"status":38,"publishedAt":39,"updatedAt":39,"author":40,"authorSlug":41,"coverId":9,"coverUrl":9,"ogImageUrl":9,"languageCode":42,"slug":43,"title":44,"excerpt":45,"body":46,"metaTitle":47,"metaDescription":48,"readingTime":49,"headings":50,"category":6,"midCtaAfterBlock":81},"c830fe64-1038-4da7-a3b3-b7cb62059532","published","2026-09-15T09:00:00.000Z","Michael Novik","michael-novik","en-US","prop-firm-drawdown-protection","Prop Firm Drawdown Protection: Where It Actually Runs","Every tool in this category sells daily loss protection. Almost none of them tells you where the limit is being watched from, or what happens to it when the connection drops.\n\n","\u003Cp>Read the sales pages in this category and they all say a version of the same thing. Daily loss protection. Drawdown limits. Automatic pause before you breach.\u003C\u002Fp>\u003Cp dir=\"ltr\">Now try to find one that tells you where that limit is being watched from, and what happens to it the moment your internet drops. You won't. The feature is on every page. The failure mode is on none of them, and the failure mode is the part that decides whether the protection is real.\u003C\u002Fp>\u003Cp dir=\"ltr\">\u003Cstrong>A daily loss limit has to be calculated somewhere, and there are only two places it can be: inside the trading terminal on your own machine, or on a company's servers. Terminal-side keeps working if the vendor goes down, but can only ever see that one terminal. Server-side can watch several accounts and several venues at once, but it needs a live connection to act. Neither is better in the abstract. What matters is that you know which one you bought and what it does when the link between the two breaks.\u003C\u002Fstrong>\u003C\u002Fp>\u003Ch2 id=\"section-0\" dir=\"ltr\">Where can a limit actually be watched from?\u003C\u002Fh2>\u003Cp dir=\"ltr\">Two places. That's the whole list.\u003C\u002Fp>\u003Cp dir=\"ltr\">\u003Cstrong>On your machine.\u003C\u002Fstrong> A program sits inside your MT5 terminal, watches the account, and closes trades or blocks new ones when a number is reached. Everything happens locally.\u003C\u002Fp>\u003Cp dir=\"ltr\">\u003Cstrong>On a server.\u003C\u002Fstrong> A company's system holds the picture of your account, does the arithmetic, and sends instructions down to whatever is connected to your broker or exchange.\u003C\u002Fp>\u003Cp dir=\"ltr\">That single choice decides everything else about how the protection behaves, and it's the thing least likely to appear anywhere in the product's marketing.\u003C\u002Fp>\u003Ch2 id=\"section-1\" dir=\"ltr\">What each one can and can't do\u003C\u002Fh2>\u003Ctable style=\"min-width: 75px;\">\u003Ccolgroup>\u003Ccol style=\"min-width: 25px;\">\u003Ccol style=\"min-width: 25px;\">\u003Ccol style=\"min-width: 25px;\">\u003C\u002Fcolgroup>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>Watched on your machine\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>Watched on a server\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Keeps working if the company's systems go down\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Yes\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>No\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Keeps working if your machine or internet goes down\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>No. The machine is the system\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>No, but it knows and tells you\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Can watch a prop account and a crypto account as one total\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>No\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Yes\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Can enforce a limit across several accounts at once\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>No\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Yes\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>You can see what it's doing\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Only by remoting into the machine\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>In the interface, from anywhere\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp dir=\"ltr\">The pattern is consistent. The closer the protection sits to your terminal, the less it depends on anyone else being alive, and the less it can ever see beyond that one account. The further away it sits, the more it can coordinate, and the more it depends on a connection.\u003C\u002Fp>\u003Cp dir=\"ltr\">If you run one MT5 account and nothing else, terminal-side has a genuine argument. The moment you have a second account, or a crypto exchange alongside your prop account, it stops being able to do the job at all, because a daily loss across two accounts is a number neither terminal can see.\u003C\u002Fp>\u003Ch2 id=\"section-2\" dir=\"ltr\">Why nobody publishes this\u003C\u002Fh2>\u003Cp dir=\"ltr\">Because the honest answer has a hole in it, and a sales page doesn't want one.\u003C\u002Fp>\u003Cp dir=\"ltr\">Every system in this category has a moment where the protection isn't running. Terminal-side has it when your laptop sleeps. Server-side has it when the connection drops. There is no architecture without the gap, and any product claiming its limits hold through a disconnection is describing something that can't happen.\u003C\u002Fp>\u003Cp dir=\"ltr\">So the useful question isn't which product has no gap. It's which one tells you how big theirs is, what it does while it's open, and what it does when it closes. Vagueness on those three is itself an answer.\u003C\u002Fp>\u003Cp dir=\"ltr\">Here are ours.\u003C\u002Fp>\u003Ch2 id=\"section-3\" dir=\"ltr\">What happens the moment the connection drops\u003C\u002Fh2>\u003Cp dir=\"ltr\">The account is paused. Not the strategies themselves, which carry on doing their own thinking. What stops is anything they decide reaching your broker.\u003C\u002Fp>\u003Cp dir=\"ltr\">In practice that means:\u003C\u002Fp>\u003Cp dir=\"ltr\">\u003Cstrong>Nothing new opens on that account.\u003C\u002Fstrong> No entries, no additions to a position, no fresh orders of any kind while the link is down.\u003C\u002Fp>\u003Cp dir=\"ltr\">\u003Cstrong>Your open positions stay exactly where they are.\u003C\u002Fstrong> Your broker is still holding them, and the stop loss and take profit attached to each one are real orders sitting on your broker's own systems. They execute whether we're connected or not. That protection doesn't depend on us and never did.\u003C\u002Fp>\u003Cp dir=\"ltr\">\u003Cstrong>Signals that fire during the gap are discarded, not saved up.\u003C\u002Fstrong> This one is worth being clear about because the assumption usually runs the other way. Nothing queues. A signal that would have triggered while you were disconnected does not fire when the connection returns.\u003C\u002Fp>\u003Cp dir=\"ltr\">That's deliberate. A queue that empties on reconnect would place trades against prices that have moved, on a setup that may have already played out, at a moment you weren't watching. The choice is between missing a trade and taking a bad one, and missing it is the smaller cost.\u003C\u002Fp>\u003Ch2 id=\"section-4\" dir=\"ltr\">What happens when it comes back\u003C\u002Fh2>\u003Cp dir=\"ltr\">Three things, before your account is allowed to trade again.\u003C\u002Fp>\u003Cp dir=\"ltr\">\u003Cstrong>It reads your broker, not its own memory.\u003C\u002Fstrong> Positions, balance, equity, and the record of every trade that happened during the gap. That last part is how it learns that a stop was hit while you were offline.\u003C\u002Fp>\u003Cp dir=\"ltr\">\u003Cstrong>Where its picture and your broker's disagree, the broker wins.\u003C\u002Fstrong> Always. Your account is whatever your broker says it is, and anything the platform believed before the drop is discarded in favour of what actually happened.\u003C\u002Fp>\u003Cp dir=\"ltr\">\u003Cstrong>It checks whether it missed any price history.\u003C\u002Fstrong> If bars are missing from the gap, the indicators a strategy relies on are rebuilt from the repaired history rather than carried forward from an incomplete picture. And the rebuild itself never produces a trade. Repairing the data can't trigger a signal.\u003C\u002Fp>\u003Cp dir=\"ltr\">Only after all three does execution resume.\u003C\u002Fp>\u003Cp dir=\"ltr\">The claim that comes out of that is narrow and it's the one worth holding us to: a strategy that starts again after an outage acts on what your broker actually did, not on what we last remembered.\u003C\u002Fp>\u003Ch2 id=\"section-5\" dir=\"ltr\">What if you breached a limit while disconnected?\u003C\u002Fh2>\u003Cp dir=\"ltr\">The halt fires late, and it fires on what genuinely happened.\u003C\u002Fp>\u003Cp dir=\"ltr\">Because reconnecting reads your account's trade history, a loss taken during the gap is counted. So a daily loss limit that was breached while you were offline halts the account when the link returns, rather than being quietly missed. The halt applies before execution resumes, so a breached account doesn't get to place one more trade and then stop.\u003C\u002Fp>\u003Cp dir=\"ltr\">There's an honest edge to this and it matters. A breach that happened \u003Cstrong>and reversed\u003C\u002Fstrong> while the connection was down isn't enforced retroactively. If your equity dipped through the limit at 14:40 and recovered by 14:45 while we couldn't see the account, there's nothing left to halt on when we come back. The limit protects you against a position, not against a moment nobody observed.\u003C\u002Fp>\u003Cp dir=\"ltr\">That's a real limitation of any server-side system, including this one, and it's a direct consequence of the same gap the whole article is about.\u003C\u002Fp>\u003Ch2 id=\"section-6\" dir=\"ltr\">How long is the gap?\u003C\u002Fh2>\u003Cp dir=\"ltr\">Under a minute, and I'm not going to give you a tighter number than that yet.\u003C\u002Fp>\u003Cp dir=\"ltr\">The connection has its own timeout, and detection is bounded by it. \"Seconds\" isn't something I can currently support with evidence, and \"instant\" isn't true of anything. Once we've measured it properly on a controlled disconnection, the measured figure gets published here with the date on it.\u003C\u002Fp>\u003Cp dir=\"ltr\">That number is the size of your unprotected window, so it deserves a measurement rather than a marketing adjective. Treat any competitor who gives you a confident figure without saying how they got it the same way you'd treat a backtest with no data.\u003C\u002Fp>\u003Cp dir=\"ltr\">You do find out it's happening. A dropped connection triggers a notification, which is the part that actually matters day to day. The specific danger of automation is silence, and no trades looks exactly like no signals until you check.\u003C\u002Fp>\u003Ch2 id=\"section-7\" dir=\"ltr\">Why crypto doesn't have this problem\u003C\u002Fh2>\u003Cp dir=\"ltr\">This is the part most traders haven't put together, and it changes how you think about where to run what.\u003C\u002Fp>\u003Cp dir=\"ltr\">An exchange account connects over the internet directly. Nothing has to be installed, nothing has to stay open, and your computer has no role in it. So a daily loss limit on a Binance or Bybit account keeps running with your laptop shut, your phone in your pocket, and you asleep. The connection is between two servers and neither of them is yours.\u003C\u002Fp>\u003Cp dir=\"ltr\">MT5 is the exception, and it's the only one. The terminal is a program on a machine, it only talks to your broker, and nothing can reach into it from outside. So automating MT5 means something runs in that terminal, and that terminal has to stay awake. Your machine or a rented one, but somewhere, always on.\u003C\u002Fp>\u003Cp dir=\"ltr\">Which produces an uncomfortable asymmetry worth knowing before you plan around it: the account type with the strictest rules and the hardest consequences, the \u003Ca href=\"\u002Fsolutions\u002Fprop-firm-traders\u002F\">funded prop account\u003C\u002Fa>, is the one running on the only platform that needs your computer to be alive. Crypto, where nobody terminates your account for a bad day, is the one that needs nothing from you at all.\u003C\u002Fp>\u003Cp dir=\"ltr\">The practical reading. If you're automating MT5, where the terminal lives is a risk decision, not an IT one, and a machine you close at night is a machine your protection sleeps with.\u003C\u002Fp>\u003Ch2 id=\"section-8\" dir=\"ltr\">The honest limitation\u003C\u002Fh2>\u003Cp dir=\"ltr\">No arrangement of this removes the gap. It only moves it.\u003C\u002Fp>\u003Cp dir=\"ltr\">Server-side protection can't act while it can't reach your account, and the reconnect behaviour described above is damage control rather than prevention. Terminal-side protection can't be taken down by a company's outage, and it also can't see a second account, can't span venues, and stops entirely when the machine does.\u003C\u002Fp>\u003Cp dir=\"ltr\">What actually reduces your exposure isn't picking a side. It's putting the protection that has to survive everything at the venue itself. A stop loss placed as a real order at your broker executes with nothing else in the world running, and it is the only layer with that property. Daily limits, account halts and kill switches all live somewhere that can be disconnected from.\u003C\u002Fp>\u003Cp dir=\"ltr\">Build with that ordering in mind and an outage is an inconvenience. Build without it and an outage is an open position with nothing watching it.\u003C\u002Fp>\u003Ch2 id=\"section-9\" dir=\"ltr\">What to check on whatever you're using\u003C\u002Fh2>\u003Cp dir=\"ltr\">Four questions, and any vendor should answer all four without hedging.\u003C\u002Fp>\u003Cp dir=\"ltr\">\u003Cstrong>Where is the limit calculated?\u003C\u002Fstrong> In my terminal, or on your servers.\u003C\u002Fp>\u003Cp dir=\"ltr\">\u003Cstrong>What happens the moment you lose the connection?\u003C\u002Fstrong> Specifically: does anything still open, and do my existing stops survive.\u003C\u002Fp>\u003Cp dir=\"ltr\">\u003Cstrong>What happens to signals during the gap?\u003C\u002Fstrong> Queued or discarded. Both are defensible. Not knowing isn't.\u003C\u002Fp>\u003Cp dir=\"ltr\">\u003Cstrong>What happens on reconnect?\u003C\u002Fstrong> Does it re-read my account from the broker, or carry on from what it last remembered.\u003C\u002Fp>\u003Cp dir=\"ltr\">A product that answers those clearly is telling you it has thought about the failure case. One that answers them vaguely is telling you something too.\u003C\u002Fp>\u003Cp dir=\"ltr\">Vectorhelm runs \u003Ca href=\"\u002Fplatform\u002Frisk-management\u002F\">limits at strategy and account level\u003C\u002Fa> on our side, across \u003Ca href=\"\u002Fintegrations\u002Fmetatrader-5\u002F\">MT5 brokers\u003C\u002Fa> and crypto exchanges in the same account view. That's why the disconnect behaviour above is written out rather than left off the page. It isn't open yet. Early access is here if you want it when it is.\u003C\u002Fp>\u003Chr>\u003Cp dir=\"ltr\">\u003Cem>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.\u003C\u002Fem>\u003C\u002Fp>","Drawdown Protection: Where It Actually Runs","Prop firm drawdown protection is only as good as where it runs. What breaks when the connection drops, and what happens to your limits when it returns.","9 min read",[51,54,57,60,63,66,69,72,75,78],{"id":52,"text":53},"section-0","Where can a limit actually be watched from?",{"id":55,"text":56},"section-1","What each one can and can't do",{"id":58,"text":59},"section-2","Why nobody publishes this",{"id":61,"text":62},"section-3","What happens the moment the connection drops",{"id":64,"text":65},"section-4","What happens when it comes back",{"id":67,"text":68},"section-5","What if you breached a limit while disconnected?",{"id":70,"text":71},"section-6","How long is the gap?",{"id":73,"text":74},"section-7","Why crypto doesn't have this problem",{"id":76,"text":77},"section-8","The honest limitation",{"id":79,"text":80},"section-9","What to check on whatever you're using",47,{"id":83,"status":38,"publishedAt":84,"updatedAt":84,"author":40,"authorSlug":41,"coverId":9,"coverUrl":9,"ogImageUrl":9,"languageCode":42,"slug":85,"title":86,"excerpt":87,"body":88,"metaTitle":86,"metaDescription":89,"readingTime":90,"headings":91,"category":6,"midCtaAfterBlock":111},"6c6860a0-3d9e-4ce8-9289-cd72310f4b47","2026-09-01T09:00:00.000Z","risk-enforcement-layers","Automated Risk Management: Strategy vs Account Limits","One strategy can spend an entire account's daily budget while the others keep trading. Where the limits sit decides whether that ends the account.\n","\u003Cp>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.\u003C\u002Fp>\u003Cp dir=\"ltr\">That's not a strategy failure. It's an enforcement failure, and it has a specific cause. The limits were in the wrong place.\u003C\u002Fp>\u003Cp dir=\"ltr\">\u003Cstrong>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.\u003C\u002Fstrong>\u003C\u002Fp>\u003Ch2 id=\"section-0\" dir=\"ltr\">Why do most automated accounts fail on risk rather than strategy?\u003C\u002Fh2>\u003Cp dir=\"ltr\">Because the failure data says so, across two independent datasets that don't share a methodology.\u003C\u002Fp>\u003Cp dir=\"ltr\">An analysis of more than 500,000 traders by hoc-trade found that \u003Cstrong>71% of first-phase prop challenge failures are daily-loss-limit breaches\u003C\u002Fstrong>, 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.\u003C\u002Fp>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Ch2 id=\"section-1\" dir=\"ltr\">What separates strategy-level from account-level limits?\u003C\u002Fh2>\u003Cp dir=\"ltr\">Scope, and what happens when they fire.\u003C\u002Fp>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Cp dir=\"ltr\">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 \u003Ca href=\"\u002Fplatform\u002Fanalytics\u002F\">aggregate drawdown and per-strategy contribution\u003C\u002Fa>, 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.\u003C\u002Fp>\u003Ch2 id=\"section-2\" dir=\"ltr\">Which limits belong at which layer?\u003C\u002Fh2>\u003Ctable style=\"min-width: 100px;\">\u003Ccolgroup>\u003Ccol style=\"min-width: 25px;\">\u003Ccol style=\"min-width: 25px;\">\u003Ccol style=\"min-width: 25px;\">\u003Ccol style=\"min-width: 25px;\">\u003C\u002Fcolgroup>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>Limit\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>Strategy layer\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>Account layer\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>Why\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Daily realised loss\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>✓\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>✓\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Strategy: contains one system's bad day. Account: the hard rule the firm measures\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Daily unrealised loss\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>✓\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>✓\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Firms count floating P&L. A closed-loss-only limit won't save you\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Trades per day\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>✓\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>✓\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Strategy: catches a signal source misfiring. Account: catches overtrading across all of them\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Max concurrent positions\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>✓\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>—\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Exposure shape is a property of one strategy\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Max drawdown from peak\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>—\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>✓\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Only meaningful against total account equity\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Kill switch\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>—\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>✓\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>By definition it stops everything\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp dir=\"ltr\">The one people skip is the daily unrealised limit, and it's the one that breaches accounts.\u003C\u002Fp>\u003Cp dir=\"ltr\">FundedNext's published trading objectives state that the daily loss cap \"includes realized and unrealized P&L, swap, and commission\" (\u003Ca href=\"http:\u002F\u002Ffundednext.com\u002Fgeneral-rules\">fundednext.com\u002Fgeneral-rules\u003C\u002Fa>, 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.\u003C\u002Fp>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Ch2 id=\"section-3\" dir=\"ltr\">What does the account layer actually measure against?\u003C\u002Fh2>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Cp dir=\"ltr\">\u003Cstrong>Equity, not balance.\u003C\u002Fstrong> 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.\u003C\u002Fp>\u003Cp dir=\"ltr\">\u003Cstrong>Static or trailing, and from what.\u003C\u002Fstrong> 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.\u003C\u002Fp>\u003Cp dir=\"ltr\">\u003Cstrong>The reset boundary.\u003C\u002Fstrong> 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.\u003C\u002Fp>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Ch2 id=\"section-4\" dir=\"ltr\">What should happen when a limit is hit?\u003C\u002Fh2>\u003Cp dir=\"ltr\">Two different things, and conflating them is a design mistake.\u003C\u002Fp>\u003Cp dir=\"ltr\">A strategy-level breach should \u003Cstrong>pause that strategy until the next session\u003C\u002Fstrong>. 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.\u003C\u002Fp>\u003Cp dir=\"ltr\">An account-level breach should \u003Cstrong>stop everything and stay stopped until you intervene\u003C\u002Fstrong>. 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.\u003C\u002Fp>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Ch2 id=\"section-5\" dir=\"ltr\">How do execution modes change the picture?\u003C\u002Fh2>\u003Cp dir=\"ltr\">A limit set for one-shot signal entries behaves differently the moment a strategy is allowed to open more than one position per idea.\u003C\u002Fp>\u003Cp dir=\"ltr\">DCA sequences and grids are designed to add into drawdown. That's the mechanism, not a malfunction. A \u003Ca href=\"\u002Fplatform\u002Fexecution-modes\u002F\">DCA ladder\u003C\u002Fa> 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.\u003C\u002Fp>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Ch2 id=\"section-6\" dir=\"ltr\">Where does enforcement physically have to run?\u003C\u002Fh2>\u003Cp dir=\"ltr\">This decides whether the limits work at all, and almost nobody asks it.\u003C\u002Fp>\u003Cp dir=\"ltr\">There are two architectures. Enforcement can live \u003Cstrong>in the terminal\u003C\u002Fstrong>, inside an Expert Advisor on your MT5 install, computing limits locally from what that one terminal can see. Or it can live \u003Cstrong>on a server\u003C\u002Fstrong>, computing from its own record of every fill across every connected account and sending instructions down to a connector.\u003C\u002Fp>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Cp dir=\"ltr\">Vectorhelm runs the second model. Every limit and every trigger is evaluated on our side, and \u003Ca href=\"\u002Fintegrations\u002Fmetatrader-5\u002F\">the MT5 EA is a connector\u003C\u002Fa> 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.\u003C\u002Fp>\u003Ch2 id=\"section-7\" dir=\"ltr\">How do you set the actual numbers?\u003C\u002Fh2>\u003Cp dir=\"ltr\">Start from the rule you're measured against and work backwards, leaving room for the things that consume budget without being trades.\u003C\u002Fp>\u003Cp dir=\"ltr\">On a \u003Cstrong>5% daily rule\u003C\u002Fstrong>, set the account-level daily loss limit to \u003Cstrong>4%\u003C\u002Fstrong>. 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.\u003C\u002Fp>\u003Cp dir=\"ltr\">On a \u003Cstrong>3% daily rule\u003C\u002Fstrong> — FTMO's one-step, FundedNext's Stellar one-step, The5ers — set it to \u003Cstrong>2.3–2.5%\u003C\u002Fstrong>. The tighter the rule, the proportionally larger the buffer needs to be, because fixed costs like commission don't shrink with the limit.\u003C\u002Fp>\u003Cp dir=\"ltr\">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 \u003Cstrong>1.5%\u003C\u002Fstrong>.\u003C\u002Fp>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Ch2 id=\"section-8\" dir=\"ltr\">The honest limitation\u003C\u002Fh2>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Cp dir=\"ltr\">That happens. It's the premium you pay for never having the other kind of day.\u003C\u002Fp>\u003Cp dir=\"ltr\">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 \u003Ca href=\"\u002Fsolutions\u002Fprop-firm-traders\u002F\">automating a funded account\u003C\u002Fa>, where a breach has an explicit dollar cost and recovery isn't something the firm offers.\u003C\u002Fp>\u003Ch2 id=\"section-9\" dir=\"ltr\">Start with the layer you're missing\u003C\u002Fh2>\u003Cp dir=\"ltr\">Most people reading this already have strategy-level protection of some kind. A stop loss is one. Far fewer have anything watching the account.\u003C\u002Fp>\u003Cp dir=\"ltr\">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.\u003C\u002Fp>\u003Cp dir=\"ltr\">That ordering is the whole design. Everything else is tuning, and it applies whatever you're running it on.\u003C\u002Fp>\u003Cp dir=\"ltr\">We're building \u003Ca href=\"\u002Fplatform\u002Frisk-management\u002F\">both layers of this\u003C\u002Fa> 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.\u003C\u002Fp>\u003Chr>\u003Cp dir=\"ltr\">\u003Cem>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.\u003C\u002Fem>\u003C\u002Fp>","Most automated accounts die on a limit that fired too late. Where trading risk management automation has to run, and what breaks when it runs in the wrong place","12 min read",[92,94,96,98,100,102,104,106,108,109],{"id":52,"text":93},"Why do most automated accounts fail on risk rather than strategy?",{"id":55,"text":95},"What separates strategy-level from account-level limits?",{"id":58,"text":97},"Which limits belong at which layer?",{"id":61,"text":99},"What does the account layer actually measure against?",{"id":64,"text":101},"What should happen when a limit is hit?",{"id":67,"text":103},"How do execution modes change the picture?",{"id":70,"text":105},"Where does enforcement physically have to run?",{"id":73,"text":107},"How do you set the actual numbers?",{"id":76,"text":77},{"id":79,"text":110},"Start with the layer you're missing",56,12,1792269975713]