1% of a $100,000 account is $1,000. Without an enforced daily loss limit, an unattended trading agent can lose more while its operator is away, especially if it keeps submitting orders after a data or connection failure.
Guardrails should constrain what the agent can do, not just describe what it should do. Put them in a separate risk layer between the strategy and the broker API.
The strategy proposes an order; the risk layer checks the proposal against current positions, working orders, account equity and data health. It then approves, reduces or rejects it.
Keep the layer independent of the strategy process. Give the strategy no credentials that let it bypass the checks, and make sure the risk service fails closed if its state is unavailable.
That choice can miss a trade during an outage. It is usually cheaper than accepting an order whose exposure cannot be calculated.
Set the risk budget before the agent trades
Choose limits that match the instrument
Define limits at more than one level. An account cap catches correlated losses across strategies. A strategy cap limits damage from one model.
An instrument cap prevents a single symbol or contract from consuming the whole budget. For derivatives, calculate exposure using contract multipliers and, where relevant, delta rather than treating one contract as one unit.
Set a maximum loss per trade using the estimated loss at the intended exit, then add a buffer for slippage and gaps. A stop price is not a guaranteed fill price. If a market gaps through a stop, realised loss can exceed the planned amount. Count both filled exposure and outstanding orders when deciding whether another order fits the budget.
The figures below are typical starting ranges for liquid strategies, not universal settings or venue rules. They need adjustment for asset, holding period, use, liquidity and the strategy's drawdown tolerance.
| Control | Typical starting range | Check before sending | Limit action |
|---|---|---|---|
| Estimated loss per trade | 0.1% to 0.5% of account equity | Risk at intended exit plus a slippage buffer | Reject or reduce quantity |
| Daily loss stop | 0.5% to 2% of account equity | Realised and unrealised P&L, fees included | Block new risk and apply the configured cancel policy |
| Gross exposure | 1x to 3x equity for liquid directional strategies | Positions plus exposure from working orders | Reject orders that exceed the account or strategy cap |
| Maximum order notional | 0.1% to 1% of equity per order | Quantity, price, multiplier and currency conversion | Clip quantity or reject |
| Quote age | 1 to 5 seconds for liquid intraday instruments | Exchange timestamp and local receive time | Pause orders until fresh data returns |
A daily loss stop needs a defined clock and reset rule. Choose the trading session or UTC day, calculate equity consistently, and persist the limit state outside the agent process.
Restarting the agent must not reset a breached limit. Decide whether the stop blocks new orders only, cancels working orders, or also submits a flattening order. Flattening can itself incur large slippage in a fast or thin market.
Reserve risk atomically
Two workers can each pass a check against the same available capacity and then jointly exceed the limit. Reserve the proposed order's risk atomically before sending it.
Release or update that reservation only when the broker reports a fill, rejection, cancellation or expiry. Treat a cancel request as pending, not complete, until the venue confirms the order is no longer live.
Use a simple exposure calculation for each instrument: filled position plus the maximum remaining quantity of open orders, converted to account currency. For a buy limit order, use its limit price for the reservation; for a market order, use a conservative price collar or reject it if no reliable collar is available. Account for buying power separately from risk. A position can fit a loss budget and still breach margin or cash limits.
- Check account, strategy and instrument caps on every order, including replacements.
- Include partial fills and orders awaiting cancellation in exposure.
- Store reservations durably so a restart cannot make capacity appear free.
- Use a single authoritative risk state if several agents share an account.
Make every order transition recoverable
Handle uncertain acknowledgements safely
A network timeout does not prove that an order failed. The broker may have accepted it and lost the acknowledgement on the return path. Retrying with a new order identifier can create a duplicate position.
Persist the intended order and a unique client order ID before submission. After a timeout, query the broker by that ID or reconcile the open-order list before deciding whether to retry.
Do not assume that an API provides idempotency unless its documentation guarantees it. If the venue cannot search by client ID, use a conservative recovery path: stop new submissions, fetch orders and executions, match them against the local journal, and require a safe state before resuming. A few seconds of missed opportunity is preferable to a second order sent into an unknown state.
Model the order lifecycle explicitly: created, submitted, acknowledged, partially filled, filled, cancel pending, cancelled or rejected. Persist each broker event before using it to change risk.
On reconnect, request a fresh snapshot and compare it with the event stream. Handle out-of-order updates and duplicate events without applying fills twice.
Bound retries and replacements
Retries should have a limit, a delay and a condition. Typical initial settings are one or two retries after checking order state, with a short backoff such as 250 milliseconds to 2 seconds where the venue permits it.
Do not retry a rejection with unchanged parameters. Classify the reason first: a price-band rejection, insufficient margin, invalid tick size and rate limit response need different actions. Cancel-and-replace is also a race. The original order may fill while cancellation is pending.
Track the old order until confirmed cancelled, and reserve for its remaining quantity alongside the replacement. Apply a per-instrument order-rate limit and a global request budget below the venue's published maximum. Leave headroom for cancels, status queries and recovery traffic rather than spending the whole allowance on new orders.
Set a maximum number of live orders per instrument and a maximum order age. Expiry is useful for quotes and entry orders that lose their rationale, but it should not silently cancel protective orders. Define different policies for entry, exit and risk-reducing orders. A cancel-all function should report what it attempted and what remains open; it cannot guarantee that the account is flat.
Stop trading when inputs or process state are unsafe
Check data quality before each decision. A fresh local timestamp does not mean a fresh market price, so compare exchange timestamps with receive time and detect sequence gaps.
Reject crossed or implausible prices, missing conversion rates and quotes older than the instrument's configured threshold. A one-second threshold may suit some liquid intraday products; a slower bar-based strategy can use a longer limit, while a fast strategy may need a much shorter one.
Monitor connection heartbeats, clock synchronisation, broker authentication expiry, margin availability and event-stream lag. Use separate states for degraded and stopped operation.
For example, stale market data can block new entries while allowing a verified risk-reducing order. A position mismatch, unknown live order or lost account snapshot should stop new risk until reconciliation completes.
Keep the kill switch outside the agent process so it can still act if the strategy hangs. Specify its behaviour in advance: block new orders, cancel eligible working orders, alert an operator and, only if configured, reduce positions. A local kill switch cannot override venue failure, and a cancellation request is not a completed cancellation. Use alerts that include account, symbol, order ID, trigger and last confirmed state. Alerts are evidence for an operator, not a control mechanism by themselves.
Track a small set of operational measures: rejected orders by reason, time from decision to acknowledgement, unconfirmed cancels, quote age at submission, position differences after reconciliation and risk-limit breaches. Alert on sustained deterioration, not just a single slow response. Keep logs durable and include the strategy version, risk decision and client order ID for every attempted order.
Test the controls under failure, not just normal flow
Exercise the risk layer with cases that can cause state divergence: delayed acknowledgements, duplicate fills, partial fills during cancellation, process restarts with open orders, stale quotes, rate limits and unavailable account snapshots. For each case, define the expected state and assert that no new order can increase risk until the state is known. Test daily-limit persistence across restarts and session boundaries.
Paper trading can check the order journal, rejection paths, sizing logic and recovery code without risking capital. It cannot establish how a live venue will behave under every queue, liquidity or outage condition.
Use an agentic paper-trading environment to run repeated failure scenarios; Agentic Trading Index paper trading starts at $9.99 a month. Before live deployment, compare paper fills and order transitions with the broker's actual API semantics, then start with low limits and a small set of instruments.
Deploy controls as versioned configuration, not hidden constants. Review changes to caps, retry rules and flattening behaviour like code changes.
A small staged rollout can begin with one strategy instance and strict notional limits, then expand only after reconciliation stays clean across restarts and market sessions. Keep a tested rollback path that disables new risk without depending on a successful strategy shutdown.
This playbook does not apply unchanged to sub-millisecond market-making or liquidation systems, where venue-specific pre-trade controls, latency budgets and position netting rules must be designed around the execution model.
Frequently Asked Questions
What limits should an unattended trading agent have?
Set account, strategy and instrument exposure caps, a daily loss stop, a maximum order size and an order-rate limit. Include working orders in exposure, and treat the figures as strategy-specific starting points rather than universal settings.
Should an agent retry an order after an API timeout?
Not until it checks whether the venue accepted the original order. Query by a persistent client order ID or reconcile open orders and executions first. Retrying with a new ID can create a duplicate position.
What should a trading agent do when market data becomes stale?
Block new risk until the feed is fresh and validated. Depending on the strategy, allow verified risk-reducing actions, but do not assume a stale quote is safe for pricing or sizing. Record the data fault and resume only after state checks pass.
