Why one safety net isn't enough

Most traders who bother with risk management set a single rule: "I'll stop if I lose X% today." Better than nothing, but a single threshold is too crude. A bad trade, a bad day, a bad week, and a catastrophic drawdown each need a different response. One limit either triggers too early on normal variance or too late when things are genuinely falling apart.

Layered risk controls fix this. Each layer handles a different time horizon and severity level. The first layer catches small problems: stop opening new trades for the day. Deeper layers escalate, up to a full shutdown that needs human intervention to reverse. This isn't complexity for its own sake. Each layer exists because there is a failure mode the other layers miss.

Think of it like fire safety in a building. Smoke detectors are the first layer. Sprinklers are the second. A fire alarm alerting the department is the third. Sealing fire doors is the last resort. You wouldn't rely on just one. Same logic applies to managing risk in a crypto prop firm or a solo trading operation.

Risk per trade: first line of defense

Risk per trade caps how much capital you can put at risk on any single position. $10,000 allocated capital, 10% risk limit, maximum risk per trade is $1,000. If the order would exceed that, it gets rejected before reaching the exchange.

This prevents the most basic and most common mistake: concentrating too much in one trade. Without it, nothing stops a trader from putting 50% of their capital on a single leveraged position. One adverse move and the account is done.

The calculation is simple. Going long BTC at $60,000 with a stop at $57,000, the risk per unit is $3,000. At a 10% risk limit on $10,000, the trader can risk $1,000, so maximum position size is 0.333 BTC. If they try to submit 0.5 BTC with that stop, the system rejects it. No exceptions.

This is the fastest check in the system. Runs at order submission, binary answer: order goes through or it doesn't.

Daily loss limit: stopping bad days from getting worse

Risk per trade controls individual positions, but it doesn't address what happens when multiple trades go wrong in sequence. A trader with a 10% per-trade limit can still lose 10% five times in one day. 50% drawdown. Each trade was "within limits," but the cumulative damage is severe.

The daily loss limit tracks combined realized and unrealized P&L for the current day. When cumulative losses hit the threshold – typically 20% of allocated capital – all new orders are blocked. Existing positions stay open (force-closing in volatile markets often makes things worse), but no new risk can be added.

The limit resets at midnight UTC. A trader who hits 20% can come back the next day with a fresh allowance. This is intentional – not punishment, but a forced cooling-off period. Research consistently shows that traders who suffer significant losses in a session make increasingly poor decisions as the day goes on. Revenge trading, doubling down, widening stops. A daily limit interrupts these patterns mechanically.

The tracking accounts for both closed trades and open positions. Trader closed two losers for -$1,500, has an open position showing -$400 unrealized. System sees total daily loss of $1,900. On a $10,000 account with a 20% daily limit, $100 of headroom. If the open position moves further against them, new orders are blocked the moment -$2,000 is crossed.

One thing to watch: a daily loss limit that only checks at order submission is not enough. Prices move between orders. The system needs to evaluate the limit on every price tick, not just when the trader clicks a button. This distinction between server-side and client-side enforcement matters more than most people realize.

Weekly loss limit: catching slow bleeds

The daily limit has a blind spot: it resets every 24 hours. A trader who loses 19% on Monday, 19% on Tuesday, and 19% on Wednesday stayed within the daily limit each day. Their account is down 57% for the week. No single day triggered anything.

The weekly limit closes this gap. It tracks cumulative P&L over a rolling seven-day window, typically 30% of allocated capital. In the example above, the trader would have been stopped on Wednesday after crossing the 30% mark, well before 57%.

This catches a pattern the daily limit can't: persistent losing streaks that stay just below the daily threshold. These are more dangerous than a single bad day because they erode capital gradually. The trader may not even notice the severity – each individual day felt "manageable." The weekly limit forces recognition by aggregating across days.

Like the daily limit, the weekly limit blocks new orders but doesn't force-close positions. It resets on a rolling basis as losses from seven-plus days ago fall out of the window. No fixed weekly reset date. As time passes, headroom opens back up naturally.

For prop firms, the weekly limit is arguably the most important control. Traders focus on today's P&L. Firm managers need the medium-term view. A trader consistently hitting their daily limit is a red flag the weekly limit will surface before things get critical.

The kill switch: full stop

The kill switch is fundamentally different from daily and weekly limits. Not a temporary pause. A full stop.

When total losses reach the kill switch threshold – typically 40% of allocated capital – everything stops. All orders cancelled. No new orders accepted. And the kill switch does not reset automatically. Not at midnight, not after a week, not ever. Only an administrator can re-enable trading.

This exists for catastrophic scenarios: a rogue algorithm, a trader who has lost all discipline, a strategy hemorrhaging money in an unprecedented market condition. The correct response is not "wait until tomorrow." It is "stop everything and figure out what went wrong."

The admin reset requirement forces a conversation. When a kill switch fires, someone with authority – risk manager, fund admin, firm principal – has to review what happened, understand why, and deliberately decide to re-enable trading. That cannot be automated away. Human judgment applied to an exceptional situation is the entire point.

For solo traders, the "administrator" is themselves, but the friction still helps. Resetting a kill switch should mean logging into an admin panel, not clicking "resume" in the trading UI. That friction creates space for reflection that an automatic reset doesn't.

The threshold is set wider than daily and weekly limits because it should almost never be reached. If the 20% daily and 30% weekly limits are working, a 40% drawdown should be nearly impossible under normal conditions. When the kill switch fires, something unusual happened – earlier layers were insufficient or circumvented – and the situation demands investigation.

How the layers work together

Consider a concrete example. A trader is allocated $10,000 with the following limits:

Day 1 (Monday): The trader takes three trades. Each risks roughly $800 — within the $1,000 per-trade limit. All three lose. Total daily loss: $2,400, which is 24% of capital. The daily loss limit triggers at -$2,000, so the third trade's loss pushes them over the line. Result: all new orders are blocked for the remainder of the day. The trader cannot open any new positions until midnight UTC.

Day 2 (Tuesday): The daily limit resets. The trader has $7,600 remaining. They trade again and lose another $1,500 over three trades (each within the recalculated per-trade limit). Daily loss: $1,500 — within the day's 20% limit of $1,520 (20% of $7,600). But the weekly cumulative loss is now $3,900. The weekly loss limit of 30% ($3,000 on original capital, or roughly $2,280 on current equity) has already been breached. The weekly limit fires and blocks new orders for the rest of the rolling week.

If the weekly limit did not exist: The trader could continue on Wednesday, lose more, and push total losses to $4,000. At that point, the kill switch would activate. All trading stops. The system sends a notification. An administrator must log in, review the situation, and decide whether to reset the kill switch and re-allocate capital.

Notice how each layer provides a checkpoint. The per-trade limit kept any single position from being disproportionately large. The daily limit stopped Day 1 from getting worse. The weekly limit caught the multi-day accumulation. And the kill switch stands as the final barrier against total account destruction. No single layer would have been sufficient on its own.

Automatic reset vs admin reset

This is the design decision that separates a kill switch from "just another loss limit."

Daily and weekly limits reset on their own. That makes sense for their purpose – they handle normal variance and temporary losing streaks. A trader who loses 20% in a day might have been unlucky, might have been in unusual volatility, might have made a few bad calls. A night's rest is usually enough before resuming.

The kill switch does not reset on its own. That also makes sense. A 40% drawdown is not bad luck across a few trades. Either the strategy is broken, the trader is compromised, or market conditions have shifted so much that the existing approach no longer works.

Automatic reset here would be dangerous. If the kill switch fired because a trader was revenge-trading through their daily limits across multiple days, auto-reset just gives them another chance to do the same thing. If it fired because of a systematic strategy failure, resuming without analysis means deploying the same broken strategy with less capital.

The admin reset forces accountability. In a prop firm, the conversation after a kill switch event is itself a risk management function. Why did this happen? Were the limits set right? Is the trader still fit to manage this capital? Should the allocation shrink? A timer cannot answer these questions.

For solo traders, the admin reset still helps. Going through a deliberate reset process – instead of watching a countdown – creates a psychological break. The difference between "my limit expired, time to trade again" and "I need to actively decide to resume trading after a major loss." The latter produces more reflection.

Server-side enforcement

All of these limits share one non-negotiable requirement: they must be enforced server-side. The risk engine checks every limit on every incoming price tick, not just when orders are submitted.

Why does tick-level enforcement matter? A trader opens a position at 9:00 AM. At 9:05, they submit another order – system checks P&L, allows it, losses are within limits. Between 9:05 and 9:10, the market moves sharply against both positions. By 9:10, unrealized losses have pushed past the 20% daily threshold. If the system only checks at order submission, it won't notice until the trader tries to submit the next order – which could be hours later. In the meantime, they could open another position through an API call, a different interface, or a mobile app, all without hitting the limit check.

Server-side tick-level enforcement eliminates this gap. Every time a new price arrives, the system recalculates P&L and checks against all limits. The moment the daily threshold is crossed, trading status flips to blocked. Any subsequent order is rejected, regardless of what interface or API the trader uses.

This also means closing the browser doesn't bypass limits. The risk engine runs on the server, continuously, independent of any client connection. Position moves against the trader while they sleep? The system still tracks the loss and applies limits. When they wake up and try to trade, limits are already in effect.

Same principle applies to stop-loss enforcement. A stop in the browser is useless when the browser is closed. A stop on the server fires regardless. Risk limits work the same way – only as reliable as the infrastructure enforcing them.

Configuration can live in a settings page or admin panel, but the enforcement itself never lives on the client. The server is the source of truth. The client can display status – how close to each limit, which limits are active – but the actual decision to block or allow a trade happens on the server, on every tick.

RiskGate enforces four layers of risk protection — from per-trade limits to kill switch — on every price tick.

Learn more