In week one, an unattended trading agent may place a few test orders while its developer watches every log. By week six, it may run overnight, handle partial fills and retry after a network failure.
The gap is not simply more testing. It is whether the system can reject unsafe actions and reach a known state when something breaks.
Guardrails are independent controls around the strategy. They should limit what the agent can request, check what the broker actually accepted and stop new risk when the system cannot establish the facts. A strategy stop-loss alone is not a guardrail: it may depend on a live process, fresh prices and a working connection.
Turn the mandate into limits
Write down the agent's authority before writing its order logic. Specify the instruments, account, trading hours and permitted order types. Set a loss budget and exposure ceiling that apply even if the strategy behaves exactly as coded but the market moves against it.
Define a risk budget
Start with account-level limits, then allocate smaller limits to each strategy or agent. Typical starting points for a small automated system might include a daily loss stop around 0.5 to 2 per cent of account equity, a per-instrument exposure cap, and a maximum order value.
These are example ranges, not universal recommendations. Volatility, liquidity, use and the account's mandate change what is appropriate.
Make the limits unambiguous. "Trade conservatively" cannot be evaluated by a risk service. "Reject an order if projected gross exposure exceeds £25,000" can. Decide whether a loss limit uses realised profit and loss alone or includes mark-to-market losses, fees and estimated slippage. A daily stop should normally use a defined trading-day boundary and a reliable equity or balance source.
- Set maximum order quantity and notional value, including for amended orders.
- Set gross and net exposure caps across positions and working orders.
- Set a daily loss threshold and a separate maximum drawdown response.
- Allowlist symbols, venues, account IDs and order types.
- Define which conditions stop new orders and which also require cancelling working orders.
Keep these controls outside the strategy process where possible. A separate risk service or broker-side limit is harder for a faulty model loop to bypass. Apply the tightest applicable limit at both levels. Client-side checks cannot protect an account if the client is compromised or sends a malformed request directly to the broker.
Make authority explicit
Use separate credentials and accounts for separate environments. Give an agent trading permission only where needed, and do not give it withdrawal or administrative access. Restrict credentials by IP or network policy if the broker supports it. Store secrets in a managed vault, rotate them and ensure logs never print them.
Include a permission check in the order path, not just in configuration. A symbol outside the allowlist, an order outside the session or a request to change account settings should fail closed. Keep a human-controlled way to disable the agent and revoke its credentials if the normal control plane is unavailable.
Validate each order at the boundary
Every order should pass through one shared validation path immediately before submission. This catches unsafe actions regardless of which model, schedule or recovery task generated the request. Record the inputs, calculated limits and decision for each rejection as well as each accepted order.
Check price, size and state
Before sending, verify that the instrument is allowed, the market is open, the quote is fresh and the requested quantity fits the remaining risk budget. Check tick size, lot size, minimum notional and price collars for that venue.
A price collar can reject an order that is too far from a current reference price, but its width must account for normal volatility and spread. A collar set too tightly can block legitimate orders; one set too widely may not contain a bad price.
Use a conservative maximum age for market data. Typical operator starting ranges might be 1 to 5 seconds for liquid intraday instruments, with a shorter threshold during fast markets.
A less liquid instrument may need a different rule, but stale data should never silently count as valid. If the feed timestamp is missing, clocks are out of sync or the spread exceeds its limit, reject new risk rather than guessing.
Retries need particular care. A timeout does not tell the client whether the broker received the order.
Give each intended order a stable client order ID and use broker idempotency support where available. On an ambiguous response, query order status by that ID before retrying. Sending a fresh order after a timeout can double the position.
Expect failures and reconcile state
The agent's internal position is a claim, not the source of truth. Fills, cancels, corporate actions and manual intervention can make local state diverge from the broker. Reconcile open orders, executions, positions and cash on startup, after reconnect and on a regular schedule while running.
Use an explicit state machine for each order, such as pending submission, acknowledged, partially filled, filled, cancel pending, cancelled or rejected. Treat unknown states as unresolved. Do not submit replacement risk until the broker confirms the earlier order's status or a defined recovery procedure takes over.
- On stale data, block new orders and raise an alert.
- On a broker disconnect, stop submitting and preserve unresolved order IDs.
- On a position mismatch, freeze the affected instrument and compare fills against broker records.
- On a daily loss breach, cancel working orders where appropriate and prevent re-entry until an authorised reset.
- On a repeated rejection or rate-limit response, apply backoff rather than increasing request volume.
A kill switch should have a narrow, testable meaning. One mode can block new orders; another can also cancel working orders. Neither guarantees instant liquidation, since a cancel can race with a fill and a market order can execute at a poor price. Document the intended action, the acknowledgement to wait for and what happens if the broker does not respond. Alert through a channel independent of the trading process where practical.
Log order intent, client order ID, broker order ID, timestamps, quote age, risk checks, acknowledgements, fills and state changes. Use synchronised clocks and retain enough detail to reconstruct a decision. Keep alerts actionable: identify the account, instrument, breached limit and current order state, without exposing credentials.
Promote the system in stages
Do not move from a successful backtest straight to unattended live trading. Test controls with deliberate faults: duplicate submissions, delayed acknowledgements, partial fills, disconnects, stale quotes, rejected cancels and a breached exposure limit. Confirm that the expected control fires and that recovery does not create a second order.
The figures below are typical starting ranges used as operational reference points, not universal settings. Calibrate them to the instrument, broker, strategy cadence and account permissions.
| Control | Typical starting range | Operator response |
|---|---|---|
| Quote age for liquid intraday trading | 1 to 5 seconds | Block new orders when older |
| Maximum order notional | 0.5 to 5 per cent of account equity | Reject or split only under an approved schedule |
| Daily loss stop | 0.5 to 2 per cent of account equity | Stop new risk and alert an operator |
| Position reconciliation | At startup, after reconnect and every 1 to 5 minutes | Freeze affected trading on mismatch |
| Maximum order retries | 1 to 3, after status lookup | Back off and escalate unresolved state |
Begin with read-only observation, then paper orders, then small live limits during staffed hours. Increase access only after the agent has passed failure tests and operated through enough sessions to exercise its normal order lifecycle. Keep a rollback path: the previous configuration, the process to disable trading and a named operator able to act.
Paper trading can test order flow and recovery without risking capital, although simulated fills do not prove live liquidity or slippage. An agentic paper-trading environment starts at $9.99 a month. Use it to exercise the agent's checks and state handling, then treat live execution as a separate validation stage.
If this were my operation, I would first write a one-page authority and risk specification, then implement the order gate and reconciliation before adding strategy complexity. I would not leave the agent unattended until forced-failure tests show that it blocks new risk and reports an unresolved state clearly.
Frequently Asked Questions
What guardrails does an unattended trading agent need?
At minimum, define instrument and account permissions, order-size and exposure caps, a loss stop, stale-data checks and a way to block new orders. Reconcile positions and working orders against the broker, and alert an operator when state is uncertain.
How often should a trading agent reconcile positions?
Reconcile at startup, after every reconnect and after events that can change order state. A typical starting schedule while connected is every 1 to 5 minutes, adjusted for order frequency and broker limits.
Should an agent retry an order after a timeout?
Not until it checks whether the broker accepted the original request. Use a stable client order ID and query the broker by that ID; a blind retry can create a duplicate position.
What should a trading kill switch do?
Specify whether it blocks new orders only or also requests cancellation of working orders. Since cancellations can race with fills and may fail during an outage, define how the agent confirms status and alerts an operator.
