The fundamental problem with strategy-level risk
Strategy-level risk controls live inside the same code path as the strategy itself. The risk check happens before the trade is sent, but the strategy decides whether to skip the check, retry, or escalate. This creates a single failure mode: when the strategy malfunctions in a way that produces invalid risk evaluation, the system can place the trade anyway.
This isn't theoretical. Every major retail algo blow-up of the last decade traces to a strategy-level bug that produced trades the risk system should have caught but didn't, because the strategy and the risk lived in the same scope.
Framework-level enforcement
The alternative: risk halt enforced at the framework level, outside the strategy's reachable scope. The strategy can request to trade; the framework decides whether the request is allowed. The strategy cannot bypass, override, or modify the framework.
Practical implications:
- Risk parameters are set in framework configuration, not strategy code
- Strategy code has no API to disable risk checks
- Risk-halt state is persisted across restarts (a flapping connection can't bypass)
- Audit log records every risk check and outcome
Why this matters during regime breaks
Markets behave 'normally' most of the time. Risk controls feel like overhead. Then a regime break happens — flash crash, halt, news shock — and the strategies that were profitable yesterday produce nonsense today. The risk system has to be unconditionally reliable in exactly the moments when the strategy is least reliable.
Strategy-level risk controls fail in these moments because the strategy that broke is the same code path that's checking the risk. Framework-level risk holds.
DayTrading Swarm's approach
The risk-halt invariant in DayTrading Swarm is enforced by the framework, not the strategies. Specifically:
- Risk halt is a state managed by the framework supervisor process
- Once tripped, the supervisor flattens all open positions (where possible) and stops accepting new orders
- Halt state persists across restarts via the durable state store
- Manual unhalt requires explicit operator confirmation; cannot be done programmatically
- Every halt is logged with full context for post-mortem
Other risk controls that compound
- Position size caps per instrument — strategy cannot request more than the cap regardless of conviction
- Daily loss cap — once daily P&L hits the cap, system stops trading until next session
- Slippage detection — if fills are coming in materially worse than expected, system pauses for human review
- Correlated-position limits — prevents 5 different agents from accidentally building the same trade
How to evaluate other platforms
Specific questions to ask:
- Where does the risk check live in the code path? Strategy module or framework supervisor?
- Can a misbehaving strategy bypass the risk check via any documented or undocumented API?
- Does halt state persist across restarts, or does a service restart reset everything?
- How is halt unhalted? Programmatically or only via operator action?
- Show me the audit log of the last 5 halts — what triggered each, what action was taken, what was the recovery path?
If the platform can't answer all 5 clearly, the risk control is probably more aspiration than implementation.
Frequently asked questions
- Why can't I just trust strategy-level risk controls if they're well-designed?
- Because the strategy that's well-designed today might have a bug introduced tomorrow. Framework-level risk gives you an unconditional fallback that survives strategy bugs. It's defense in depth.
- Does framework-level risk slow down execution?
- Microseconds at most. The risk check is essentially a constant-time lookup against pre-set parameters. The latency impact is invisible compared to broker network latency.
- What happens if the framework supervisor crashes?
- All trading halts immediately because no agent can place orders without supervisor approval. This is the correct behavior — fail closed, not open.
- Can I override the risk halt manually if I'm certain it's a false positive?
- Yes — but it requires explicit operator confirmation through a separate console, not a programmatic API. The friction is intentional. False positives are far less expensive than false negatives in risk management.
- How is the daily loss cap calculated?
- Net realized + unrealized P&L since session start. Cap is configurable per account; default is a conservative percentage of account equity. Once hit, no new positions can open until next session even if the operator manually unhalts.