Risk management in the builder
Risk on Stretus lives in two places, and confusing them is the most expensive mistake available.
| Build-time controls (this page) | Execution gates | |
|---|---|---|
| Live where | Inside the strategy object | Per deployment |
| Simulated in the backtest | Yes | The engine runs them identically in paper and live |
| Enforced live | Yes, the engine reads them | Yes, if you configured them |
| Default state | Set by the builder, labelled if defaulted | Seven of nine are off |
Everything on this page is part of the strategy. Everything on The nine order gates is part of the deployment.
What to state
Say it in plain language and it becomes part of the strategy:
1.2% stop, risk 1% per trade, max 3 trades a day,
trading window 09:20 to 15:10, cooldown 3 bars after a loss
The controls
| Control | What it does | Stated as |
|---|---|---|
| Stop-loss | Maximum adverse move before exit. Mandatory | Percent, ATR multiple, price, or structure |
| Take-profit | Profit target, single or laddered | Percent or R-multiple |
| Trailing take-profit | Ratcheting profit-side line | Activation + trail distance |
| Trailing stop | Ratcheting protective line | Activation + trail distance |
| Break-even / lock profit | Move the stop to entry or to a locked gain | Percent or R trigger |
| Per-trade risk % | Share of allocated capital risked on one trade | Percent |
| Reward:risk | Target expressed against the stop distance | Ratio |
| Max trades | Concurrent open positions | Count |
| Max trades per day | Daily entry velocity | Count |
| Daily loss cap | Realised loss for the day that halts entries | Percent of allocation |
| Mark-to-market loss | Realised + unrealised loss that halts entries | Absolute amount |
| Max consecutive losses | Losing streak that halts entries | Count |
| Cooldown after loss | Bars to sit out after a losing streak | Bar count |
| Trading window | Time-of-day range for entries | Times, IST |
| Time exit | Wall-clock cutoff that force-exits | Time |
| Max order value | Ceiling on a single order's notional | Currency amount |
| Max capital allocation | Ceiling on total deployed capital | Currency amount |
Read the provenance
The builder distinguishes values you stated from values it defaulted.
Ask for an "aggressive" strategy and you get a stop, a target and a per-trade risk calibrated to "aggressive". Those are the platform's numbers, and the read-back labels them as defaults.
If a control matters to you, state it. The provenance split exists so this is visible rather than something you discover from a backtest. See How the AI reads your words
What the risk level actually does
"Conservative", "moderate", "aggressive" calibrate defaults. They do not set limits, and they are not a risk control in themselves.
| Risk level | Roughly implies |
|---|---|
| Conservative | Tighter stop, lower per-trade risk, fewer concurrent positions |
| Moderate | Middle values |
| Aggressive | Wider stop, higher per-trade risk, more positions |
Stating "aggressive, 2% risk per trade, 1.5% stop" gives you the aggressive framing and your own numbers, with both stated values marked as yours.
The trading window
A time-of-day range for entries, interpreted in IST.
Three things to know:
It carries no day-of-week or holiday information. The source string does not encode any; market calendars are handled separately. See Trading hours & holidays
It must overlap the instrument's session. A 16:00-18:00 window on an NSE equity gates the strategy to hours the market is closed. Validation catches the egregious cases.
On a continuous venue it is usually meaningless. A 09:15-15:30 window on BTC/USDT is not wrong so much as arbitrary, and validation flags it as probably not what you intended.
A window that wraps past midnight is handled correctly as spanning two days.
What the backtest tells you about your choices
The backtest measures the consequences of everything on this page:
| Read | To learn |
|---|---|
| Max drawdown, and its recovery time | Whether your stop and sizing are survivable |
| Longest losing streak | Whether your consecutive-loss thinking was realistic |
| Trade count against your daily cap | Whether the cap is binding or decorative |
| The Trades tab exit reasons | How trades actually ended |
If 80% of your exits are stop-losses rather than your exit condition, the stop is doing the work and the exit condition is decoration. That is a fact about your strategy no aggregate metric reports, and it changes what you should adjust.
The gap between build time and execution
The thing to internalise:
You can state a daily loss cap in the builder and see it in the strategy object and in the backtest.
That does not mean the corresponding execution gate is enforcing it on your live deployment. The execution gates read a deployment's risk configuration, seven of them are off until configured, and the parser fails open, a malformed payload leaves you with no enforced rules and no warning.
Verify your limits on the strategy's risk panel after deploying. Not from the chat transcript, and not from the backtest.
See Which limits are on by default.
Two controls that only exist at execution time
The builder cannot express these; they belong to the deployment:
| Control | Where |
|---|---|
| Mark-to-market breaker as a currency amount at build time | NOT_REPRESENTABLE in the strategy object, configure it as an execution gate |
| A cash reserve percentage | No field exists. Allocate less capital instead |
The builder refuses both rather than approximating. See AI limitations.
A starting configuration
Conservative, and a starting point rather than a recommendation:
1.5% stop-loss, risk 1% per trade, max 1 position at a time,
max 3 trades a day, stop trading if down 3% in a day,
stop after 4 losses in a row with a 3-bar cooldown,
trading window 09:20 to 15:10
Then read the assembled strategy and confirm every value landed.
Next
- Position sizing, how per-trade risk becomes a quantity
- The nine order gates, the execution half
- Which limits are on by default
- Strategy anatomy