How risk is enforced
Risk on Stretus is enforced in three places, at three different moments. Understanding which control lives where is what stops you assuming a limit exists when it does not.
Why this page exists first
Most platforms document risk under "deploy", as a thing you configure at the end. That is the wrong place, because the decisions are made earlier. Position sizing is a build-time decision. Drawdown tolerance is a validate-time decision. By the time you are on the deploy screen the shape of your risk is already fixed, and the only thing left is the size of the allocation.
So risk is a section, and it sits between validate and deploy, where the reading order matches the decision order.
The three layers
| Build time | Validate time | Execute time | |
|---|---|---|---|
| Controls | Stop-loss, take-profit and trailing, per-trade risk %, max trades, trading window, daily loss cap | Max drawdown, drawdown recovery time, consistency and sample size, cost-adjusted return, grade thresholds | Nine order gates, cooldown after loss, trading window, margin validation, capital ceiling |
| What the layer does | Written into the strategy object | Measured, not enforced | Evaluated on every order, before placement |
Layer 1: build time: the rules inside the strategy
When the AI assembles a strategy it writes risk controls into the strategy object itself: the stop-loss, the take-profit or trailing take-profit ladder, per-trade risk percentage, maximum trades, and the trading window. These are part of the strategy's definition. They are what the backtest simulates and what the live engine reads.
Set these by saying what you want: "1.5% stop, risk 1% per trade, no more than 3 trades a day". See Risk management in the builder.
Layer 2: validate time: measurement, not enforcement
The backtest measures the consequences of your layer-1 choices. Max drawdown, recovery time, profit factor, sample size. Nothing here blocks anything. It tells you what your rules did on past data so you can change them before they run on live capital.
The important distinction: a backtest showing an 11% max drawdown is not a promise of an 11% ceiling. It is the worst thing that happened in that window. See Backtest limitations.
Layer 3: execute time: the order gates
This is the layer most users do not know exists. Every order a deployed strategy tries to place is evaluated against a pipeline of nine risk validators before it reaches the broker. Each one either passes the order or blocks it with a named reason and a recorded violation.
Evaluation order is deliberate, cheapest and most decisive checks first, so an order that fails on shape never costs a metrics read:
| Order | Gate | What it checks |
|---|---|---|
| 1 | max_order_value | This order's notional against a ceiling |
| 2 | per_trade_risk | Stop-distance × quantity against a percent of allocation |
| 3 | max_open_positions | Concurrent open entries |
| 4 | max_trades_per_day | New entries opened today |
| 5 | max_consecutive_losses | Losing round-trips in a row |
| 6 | daily_loss_limit | Today's realised loss against a percent of allocation |
| 7 | mark_to_market_loss | Realised plus unrealised loss against an absolute amount |
| 8 | max_capital_allocation | Total deployed capital including this order |
| 9 | available_capital | Whether the strategy can fund this order at all |
Plus three controls that sit alongside the pipeline: a cooldown after a losing streak, a trading-window check, and margin validation for margined instruments.
Full reference with units, defaults and trip behaviour: The nine order gates.
The thing you must know before deploying
Seven of the nine gates are disabled until you configure a value. A zero value means the rule does not run. There is no implicit default, no platform-wide fallback, and no warning that a limit is absent.
Two gates cannot be disabled: max_capital_allocation against your allocation, and
available_capital. Those two are why a strategy can never exceed the capital you gave it.
Everything else is opt-in.
The configuration parser is also deliberately fail-open: a malformed risk configuration yields no enforced rules rather than blocking trading. That is the right choice for availability, a bad payload should never hard-block a strategy trying to exit, and it means a configuration you thought you set may not be in force. Verify your limits on the strategy's risk panel rather than assuming.
Which gates are on, which are off, and what to set them to: Which limits are on by default.
What the gates do and do not do
| The gates do | The gates do not |
|---|---|
| Block a new order that breaches a limit | Close an open position |
| Report the rule, the current value and the limit | Act between candle evaluations |
| Always allow exits, even at a limit | Prevent a gap through your stop |
| Record a violation you can see | Recover capital already lost |
The asymmetry is the design: entries are gated, exits are not. A strategy sitting at its
max_open_positions cap must still be able to close a position to release a slot. A gate that
blocked exits would trap capital in exactly the situations the gate exists to protect against.
The corollary is that a breached daily-loss cap stops new trades and leaves the open position running to its own stop. If you need to be flat, close the position at your broker.
Paper and live are gated identically
The risk pipeline runs the same way in paper as in live. That is what makes paper a real test of your configuration rather than a test of the strategy alone, a paper run that trips your daily-loss cap has told you something true about your limits.
Where to go next
| Page | What it gives you |
|---|---|
| The nine order gates | Every gate: unit, default, what trips it, what happens |
| Which limits are on by default | The on/off table and a recommended starting configuration |
| Alerts & breaches | What you see when a gate trips, and how to resume |
| Risk management in the builder | Setting layer-1 controls in plain language |
| Position sizing | How per-trade risk becomes a quantity |