Risk

What Risk is for

Risk is where you create reusable Live risk profiles and review the limits that govern every command in a bound deployment. Risk controls constrain defined behavior; they do not eliminate market, model, liquidity, provider, connectivity, or operational risk.

Create a risk profile

Give the profile a clear name, then set only limits you understand and can monitor.

Equity Limits can include:

• risk per trade;
• order notional;
• gross exposure;
• net exposure;
• symbol concentration; and
• daily equity drawdown.

Optional Hard Dollar Caps can place absolute limits on order notional, gross exposure, net exposure, and daily loss.

Operating rules can limit orders per minute, session duration, and the age at which a market-data feed is considered stale. The profile also records whether short positions are allowed and whether confirmation is required before arming.

Select the acknowledgement only after reviewing the complete profile. An unacknowledged profile cannot be saved or used to open order entry.

Understand effective limits

Percentage limits are resolved against the deployment's approved capital basis. When both a percentage limit and a hard-dollar cap apply, the stricter effective limit governs.

Live evaluates proposed mutations against current positions, working and unresolved orders, reserved capital, fills, session state, and the latest reconciled account truth. It must not admit new risk from a stale or incomplete cache.

The risk decision and the versioned state used for it are retained with the intent and downstream order lineage.

Bind a profile to a deployment

Select the profile in Deployments -> New/Edit Deployment. The deployment review shows whether the profile is acknowledged, compatible with the source and sizing method, and valid for the selected account and mode.

Changing a saved profile does not silently rewrite an already running deployment's accepted risk state. Review and explicitly apply the new profile through the deployment lifecycle.

Do not remove a profile while an active or retained deployment depends on it. The interface must show the dependency or block removal.

Strategy and Portfolio risk

A Strategy deployment applies the profile to its own orders and positions within the selected account scope.

A Portfolio deployment coordinates member risk before provider submission. It combines shared capital, member reservations, account exposure, concentration, drawdown, simultaneous intents, and whole-Portfolio limits. Member attribution remains available, but member limits are not presented as independent capital when the Portfolio policy shares capital.

Unknown member state, allocation, order, fill, position, or reconciliation closes new risk until resolved.

Read a risk block

A blocked decision should identify:

• the proposed mutation;
• the applicable limit and effective value;
• current usage and reserved exposure;
• the state version used for evaluation;
• whether the blocker is account, deployment, Portfolio, member, instrument, feed, or provider scoped; and
• the corrective action.

Open Decisions for the source intent, Monitor for current exposure and health, Orders for working or unresolved mutations, and Activity for the event sequence.

Do not increase or disable a limit merely to force a blocked order through. First verify that positions, orders, prices, capital, and provider state are current.

Pause, Flatten, and Kill

Risk blocks can close order entry automatically, but protective lifecycle actions retain distinct meanings:

• Pause prevents new strategy-originated risk while preserving the state needed for review.
• Flatten Deployment requests closure of positions owned by the deployment.
• Deployment Kill applies the emergency cancellation and closure policy.

None of these actions is complete from button acceptance alone. Confirm final provider orders and positions through Monitor, Orders, and Activity.

Recover from stale or unavailable risk state

When account, feed, order, or position truth is stale or unavailable, Live fails closed.

1. Keep order entry closed.
2. Identify which state owner is stale.
3. Refresh the applicable stream and independent snapshot.
4. Reconcile mismatches and unresolved mutations.
5. Confirm that effective limits and current usage have recalculated.
6. Resume only when the action policy reports the deployment ready.

A performance benchmark or healthy browser connection cannot override a stale risk blocker.