Build algorithmic trading risk controls around every order and failure state

BotSpot capabilities

1. Separate strategy, portfolio, and operational risk

One exit rule cannot control every failure. Strategy risk covers how much one idea may lose. Portfolio risk covers combined positions, correlations, leverage, and concentration. Operational risk covers incorrect data, duplicate orders, rejected orders, disconnects, stale state, and software defects.

Write limits at each layer before deployment. Broker and exchange protections remain valuable backstops, but they do not replace controls inside the strategy.

• Strategy limits: order size, position size, loss budget, and permitted instruments.
• Portfolio limits: gross exposure, net exposure, concentration, and combined working orders.
• Operational limits: message rate, data freshness, order duplication, connection health, and account-state agreement.
• Broker constraints: buying power, margin, permissions, order types, sessions, and product eligibility.

2. Size positions from declared risk, not a universal percentage

No single position-size percentage fits every strategy or account. Define a maximum order quantity or notional value, maximum position exposure, and maximum combined exposure using documented capital and tested strategy behavior.

Include existing positions and working orders when calculating exposure. Otherwise, several pending fills can individually pass a check while jointly breaching the intended limit.

• Cap exposure by symbol, strategy, asset class, sector, and account where relevant.
• Measure gross exposure as well as net exposure; offsetting directions can hide large total positions.
• Account for correlated positions rather than assuming different symbols create independent risk.
• Model gaps, slippage, fees, and partial fills instead of treating a stop price as a guaranteed loss boundary.

3. Treat leverage and buying power as constraints, not targets

Broker-reported buying power describes what an account may currently submit. It does not define a prudent strategy allocation. Margin can magnify losses, create maintenance calls, and allow broker liquidation under changing house requirements.

Read current account state before opening risk, reserve capacity for adverse movement and working orders, and stop submitting new exposure when margin or buying-power data is missing or stale.

• Use broker-reported buying power and margin fields rather than reconstructing them from old balances.
• Expect product, jurisdiction, session, and account-type rules to differ.
• Handle increased margin requirements and reduced buying power without repeatedly retrying rejected orders.
• Do not assume paper-account leverage or fills reproduce live-account behavior.

4. Reject unsafe orders before submission

Pre-trade controls should block an order before it reaches the broker when required data is unavailable or a declared limit would be exceeded. Sending an unsafe order and attempting to cancel it afterward still leaves execution risk.

Apply controls to every order path, including retries, replacements, exits, scheduled actions, and manually triggered strategy operations.

• Maximum quantity and maximum notional value per order.
• Maximum resulting position, gross exposure, net exposure, and working-order exposure.
• Price-deviation checks against fresh, appropriate market data.
• Allowed symbols, asset classes, order types, sessions, and time-in-force values.
• Buying-power, margin, shortability, and account-permission checks.
• Duplicate-order protection using stable client order identifiers.
• Order-rate and message-rate limits that stop loops and retry storms.

5. Define loss and drawdown controls as state transitions

Daily-loss and peak-to-trough drawdown controls need an explicit data source, calculation method, threshold, action, and reset process. A threshold cannot protect an account when equity, realized profit and loss, or open-position values are stale.

When a loss control triggers, block new risk first, identify outstanding orders, reconcile positions, notify the responsible operator, and require a deliberate recovery decision. Do not silently reset a breached control because the clock changed or the process restarted.

• Document whether limits use realized loss, unrealized loss, total equity, or another defined measure.
• Decide how deposits, withdrawals, overnight gaps, and multiple strategies affect the calculation.
• Store breach state outside the process that may have failed.
• Test restart behavior so a stopped strategy cannot resume with forgotten loss state.

6. Monitor orders, positions, data, and infrastructure

A submitted order is not a completed trade. Monitor acknowledgements, fills, partial fills, rejections, cancellations, expirations, and replacements. Compare internal state with broker open orders, positions, balances, and buying power.

Streaming updates reduce delay, but reconnects and missed messages require periodic reconciliation against broker state. Missing confirmation should create an unknown state, not permission to submit another order.

• Alert on stale market data, disconnected streams, delayed strategy cycles, and failed heartbeats.
• Detect position or order differences between strategy state and broker state.
• Track repeated rejects, unexpected partial fills, abnormal order volume, and control breaches.
• Preserve timestamps, inputs, decisions, orders, broker responses, and configuration versions for investigation.
• Assign a person or process responsible for responding while live risk exists.

7. Make the kill switch precise and recoverable

A kill switch should have defined scope and observable confirmation. Blocking new orders, canceling working orders, stopping strategy evaluation, and closing positions are different actions. Closing positions automatically can introduce new execution and liquidity risk.

Design the safest supported stop sequence for each broker and market. Confirm cancellation and current positions through broker state, then keep new order entry disabled until the cause is understood and recovery checks pass.

• Provide a minimal-step way to stop one strategy and, when needed, broader account activity.
• Keep emergency controls independent from the strategy process they must stop.
• Define behavior when cancellation fails, connectivity is unavailable, or an order fills during shutdown.
• Require explicit authorization and state reconciliation before resuming.

8. Test controls and changes before increasing exposure

Test risk controls independently from expected strategy behavior. Simulate stale data, extreme prices, malformed quantities, duplicate signals, partial fills, order rejection, disconnects, restarts, rate limits, and unavailable broker services.

Keep code, configuration, tests, and control parameters versioned. Deploy material changes with limited exposure and heightened monitoring before considering broader use.

Limitations and risk

Risk controls can reduce selected failure modes; they cannot guarantee a maximum loss or profitable result. Markets can gap, orders can partially fill, liquidity can disappear, brokers can reject actions, and infrastructure can fail.

Regulatory materials cited here describe obligations or practices for regulated firms and trading venues. They provide useful control-design evidence, but this guide does not determine which legal requirements apply to a particular person, strategy, broker, or jurisdiction.

Frequently asked questions

Sources

• BotSpot broker connection manifest
• BotSpot Terms of Service
• SEC Market Access Rule FAQ
• FINRA algorithmic trading supervision guidance
• CME Group Risk Management Tools
• FINRA brokerage and margin account guidance
• FINRA concentration-risk guidance
• FINRA stop-order guidance
• Alpaca order documentation

Sources verified 2026-08-14.