AI Risk Thresholds Explained Step-by-Step (Nobody Shows You This)

By Sebastian Smith Published custom Updated custom

Risk thresholds sound simple — a line in the sand that, once crossed, stops the agent trading. In practice, almost every retail “AI trading” product fakes this concept. Either the threshold is a decorative progress bar that never actually halts anything, or it’s a hidden trip wire with no human-readable logic behind it. RaptorBit AI thresholds are engineered in the open. This is the step-by-step walkthrough nobody shows you.

Step 1 — Two pools, two clocks

Every RaptorBit account starts with a conceptual split between deposited capital and realised profit. These are not separate bank accounts — they are an accounting layer that the risk governor uses to make decisions. Each pool runs its own loss clock. The default thresholds are:

Deposited capital pool — 20% drawdown from pool high-water-mark.
Realised profit pool — 30% drawdown from pool high-water-mark.

Why two clocks? Because deposited capital is money you brought in. Realised profit is money the agent earned. Letting the agent risk earned profit a little more aggressively than freshly deposited capital tends to produce better risk-adjusted outcomes — but you shouldn’t take our word for it; the thresholds are editable.

Step 2 — High-water-mark, not fixed line

Thresholds are measured against the high-water-mark of each pool, not against the starting value. If your deposited pool went from 10,000 to 12,000 and then started drawing down, the 20% threshold is measured from 12,000, not 10,000. This matters because it protects your gains without demanding you continuously edit the thresholds.

Step 3 — The pre-flight check

Before any signal becomes a live order, the risk governor runs a pre-flight that verifies:

Current drawdown on both pools.
Open-position concentration (no more than X% of pool in a single symbol).
Correlation with existing open positions (the governor refuses to add exposure to the same underlying driver twice).
Scheduled high-impact events inside the signal horizon.
Broker health check (margin available, API latency, order rejection rate in last 60 seconds).

Any pre-flight failure cancels the order and prints the reason to the dashboard. The signal itself is still saved in the audit trail, labelled as pre-flight failed, so you can see exactly which guard tripped.

Step 4 — The pause ladder

Thresholds don’t operate as a single switch. They operate as a ladder:

50% of threshold — Amber. The agent continues trading but reduces position sizing by 25% automatically. You get a dashboard note.
75% of threshold — Deep amber. Position sizing is reduced by 50%. The agent will only take signals of raptor-grade.
100% of threshold — Red. The agent halts new orders, requests orderly closure of open positions and sends you an email summary with the pause reason.
115% of threshold — Deep red. If, after closure, drawdown continues (e.g. a close happened on a worse fill than expected), the agent is locked out until you explicitly re-authorise.

Step 5 — What “orderly closure” really means

Orderly closure is not “sell everything at market”. It is a sequenced exit, respecting the current spread, the time-of-day liquidity profile and any correlation hedges. If an aggressive market order would do measurably more damage than a 60-second slow-exit, the agent slow-exits. The slow-exit timer is capped (default 180 seconds) so you are never left with a lingering position on a thesis the agent has already abandoned.

Step 6 — The pause reason, written down

Every pause event produces a short, structured pause reason: which threshold tripped, which pool, which signal class contributed most, and what would need to change for a safe restart. Pause reasons are kept in the audit trail with a hash so neither party can edit them later.

Step 7 — The restart gate

The agent does not resume trading automatically after a red pause. You restart it explicitly. Before the restart, the dashboard shows:

The drawdown at pause time.
The drawdown now.
Whether the market conditions that triggered the pause have normalised.
A proposed temporary threshold reduction (optional) for the next session.

Restarting with no changes is a one-click action. Restarting with a reduced threshold is a two-click action.

Step 8 — Why thresholds are not a maximum-loss promise

This is the uncomfortable truth. Thresholds are operating rules, not caps on your maximum possible loss. Market gaps across weekends, broker outages, cascading cross-asset moves and your own overrides can all produce losses that exceed the configured threshold. The threshold tells the agent when to stop doing; it cannot stop the market from doing.

Step 9 — Thresholds you should actually set

We get this question a lot. There is no universal answer, but here is the framework we recommend:

Start with the defaults (20% / 30%) for the first 30 days.
Review your weekly audit trail. If the agent paused and the market subsequently stabilised at a level that would have resumed anyway, your threshold is probably too tight.
If the agent never paused but your emotional comfort was tested, your threshold is too loose.
Adjust in increments of 2–3 percentage points, never in large jumps.

Step 10 — The audit question you should ask monthly

Open your monthly audit and ask: What percentage of my losses came from signals I activated, versus signals I overrode? The answer tells you whether the agent or you are the bigger risk in your account. Most of our beta users were surprised by this number, and it was the single most useful self-reflection the audit produced.