Trading agent guardrails for unattended order execution

Limits that only guard the strategy

Nearly every unattended trading setup has a position limit and a process that can still submit an order after its market data has gone stale. The limit looks sensible in a strategy document. The failure is that it often measures only the strategy's intended position, not the orders already working, the broker's actual position or exposure left behind by a restart.

Risk controls need to sit outside the strategy process. A signal generator can request an order, but a separate risk service should approve it against current account and market state. If that service cannot answer, the default should be no new risk. Do not let an exception handler turn a risk-service timeout into an approval.

Set caps at several levels: per order, per instrument, per strategy and across the account. Track gross exposure as well as net exposure.

A long position in one instrument and a short position in another may look neutral in dollars while retaining basis, currency or correlation risk. For leveraged products, use notional and margin headroom, not just units.

Also reserve exposure for working orders. If the account has 100 shares and two unfilled buy orders for 100 more, a check based only on the current position understates the worst case by 200 shares. Count each order at its maximum possible fill until the broker confirms a cancel or fill.

Broker state is not your internal state

Most agents keep an internal ledger and treat it as authoritative. It is not.

The broker may have accepted an order just before a network timeout, filled it while the process was down, or applied a corporate action your local store has not processed. A restart that rebuilds positions from yesterday's database can therefore send fresh orders against a position that no longer exists, or add to one that does.

On startup, reconnect and reconcile open orders, executions, positions, balances and account status before enabling risk-increasing orders. Compare broker state with the internal ledger, record the difference, then resolve it explicitly. If reconciliation fails, permit only a defined recovery action, such as cancelling known orders, or stay halted. Do not silently choose whichever position is more convenient.

Use broker sequence numbers or execution identifiers where available, and persist each state transition before acting on it. A message can arrive late or twice. Updates should be safe to process repeatedly, while an order request should have a stable client identifier across retries. Retrying with a new identifier after a timeout can create a second live order.

Market data needs equivalent checks. Reject quotes with old timestamps, broken sequence numbers or a disconnected feed. For liquid intraday systems, a maximum quote age of roughly one to three seconds is a common starting range, not a universal setting. Calibrate it to the feed, instrument and strategy horizon. A slower strategy may tolerate older data, but should still detect a frozen price.

Define what happens when limits trip

A threshold is not a response plan. If daily loss reaches a set amount, should the agent cancel working orders, stop opening positions, reduce exposure or flatten everything? Those actions have different costs.

A market order to flatten in a thin book can turn a controlled loss into a larger one. Write down the action for each trigger and distinguish risk-increasing orders from orders that reduce risk.

Use a small set of hard limits that can be evaluated quickly: maximum order notional, maximum account exposure, maximum open orders, maximum daily loss and maximum data age. Add instrument-specific checks where the product requires them, such as option delta or futures contract limits. Calculate loss from a clearly defined baseline and include fees and unrealised P&L. Make the reset time explicit, including the timezone and treatment of overnight sessions.

Controls can race. Two workers may each check that there is room under a cap, then both submit orders. Reserve the requested exposure atomically before sending either order. Release or adjust that reservation only after a confirmed rejection, cancellation or fill. Where a broker exposes buying power or margin, treat it as an additional constraint, not a replacement for your own limits.

Separate the emergency stop from ordinary strategy logic. It should be reachable when the strategy is stuck, and its state should persist across process restarts. A stop that only sets an in-memory flag is not a stop if a supervisor immediately launches a clean process that starts trading again.

Model costs before setting risk budgets

Risk budgets based on mid-price fills overstate available headroom. Include spread, fees, market impact and adverse movement while orders are pending. These are typical market ranges, not venue guarantees. Instrument, order size, time of day and volatility can move costs well outside them.

Typical market ranges for liquid instruments, expressed in basis points of traded notional:

Track realised execution against arrival price, not only the signal's reference price. Break results down by instrument, order type, size and volatility regime. Use a conservative percentile, such as the 95th or 99th percentile, when setting a loss buffer. A mean slippage estimate hides the rare fills that can exhaust a daily limit.

Paper trading can test whether controls behave as designed, but simulated fills rarely reproduce queue position, partial fills or market impact. An agentic paper trading environment is useful for exercising restart and rejection paths before live deployment. Treat its fill assumptions as a test input, not proof that live execution costs match.

Failure handling is part of the risk model

Most systems test the happy path: a signal arrives, an order is accepted and a fill follows. Unattended systems also need deterministic behaviour for disconnects, rejected orders, delayed acknowledgements, partial fills and clock drift.

Each condition should have a bounded response. A retry loop that runs forever is not recovery; it can flood the broker or keep a stale intent alive.

Use a heartbeat for the strategy, market data connection and broker connection. Define separate timeouts for each. A market-data outage might block new entries while allowing a reduce-only order. A broker outage may require the agent to stop all submissions because it cannot know whether the last request reached the venue. Do not assume that a successful TCP write means the broker accepted an order.

Log enough to reconstruct decisions: input timestamp, account snapshot version, risk checks, order intent, broker response and later execution events. Keep logs durable and use a monotonic clock for elapsed-time checks.

Alert on state disagreement, repeated rejects, stale data and unexpected exposure, but do not make an alert the control itself. The process must remain safe if nobody sees it.

Test these cases by injecting failures, not by waiting for them in production. Paper-execution tests can include dropped acknowledgements, duplicate events and restarts; see paper trading for agent workflows as one way to exercise those paths. Confirm that the agent neither duplicates an order nor resumes risk-increasing activity before reconciliation.

A deployment checklist, and its limit

Before enabling unattended orders, verify the controls in a staging account and record the expected behaviour for each failure. A compact checklist catches gaps that a strategy backtest will not:

1. Cap exposure. Set per-order, per-instrument, per-strategy and account limits. Include working-order reservations and use.
2. Gate on fresh state. Reject stale or out-of-sequence prices. Require broker connectivity and a recent account snapshot before new risk.
3. Reconcile on every start. Compare positions, open orders, fills and balances. Keep the agent halted when mismatches remain unresolved.
4. Make retries safe. Reuse stable client order identifiers and stop retrying after a defined number of attempts or a status ambiguity.
5. Specify trip actions. For every limit, define whether the agent cancels, blocks entries, reduces or flattens, and who can re-enable it.
6. Exercise failure paths. Test restarts, stale feeds, rejections, partial fills and broker outages. Check that logs can explain every decision.

Run the checklist again after changing the broker adapter, account configuration, risk service or deployment supervisor. These changes can alter order behaviour without changing a strategy line of code.

This advice does not apply unchanged to a fully manual workflow where every order is reviewed before submission, or to a system that only produces signals and has no order credentials. In those cases, controls should match the actual authority the software has, rather than assume it can trade unattended.

#unattended trading risk #automated trading limits #trading agent risk controls #stale market data controls #broker state reconciliation #order exposure limits #algorithmic trading safety