An unattended trading agent is software that selects and submits orders without a human approving each trade.
That definition says nothing about whether the strategy is authorised, the account state is current, or an order can be stopped after a fault. Those are separate controls, and they must work even when the model, network or broker API does not.
Set a risk perimeter
Start with the account and instruments the agent may touch. Do not let strategy code decide its own permissions. Put an allow-list, account identifier and maximum exposure in a deterministic control layer that runs before every order submission.
Set limits in terms of both account equity and instrument risk. A notional cap alone can permit a large loss in a volatile or leveraged product. A workable initial policy might include:
- Maximum order notional, for example 1% of net liquidation value, subject to the strategy and market.
- Maximum gross and net exposure by instrument, asset class and account.
- A daily loss stop based on realised plus unrealised P&L, with a separate threshold for peak-to-trough drawdown.
- Allowed trading hours, order types, position direction and short-sale permissions.
These are starting points, not universal safe limits. A liquid equity strategy and a leveraged futures strategy need different budgets. Set limits from stress tests, capital and mandate, then keep the live limits outside model-generated configuration.
Gate every order
Validate the proposed order immediately before sending it. Check symbol, side, quantity, price collar, buying power, open orders and current position. Recalculate exposure using the broker's latest available account state, not only the agent's internal ledger. If the two disagree, block new risk until reconciliation succeeds.
Use hard checks for invariants and softer checks for alerts. A hard check rejects an order that exceeds a notional cap or uses a disallowed instrument. A warning can flag unusually high turnover or a sudden increase in order size for review. Do not rely on a prompt asking a model to respect a limit: encode the limit in code that cannot be bypassed by a strategy response.
Price collars should reflect the instrument and order type. For a liquid share, a collar of a few ticks may be sensible in normal conditions; a fixed percentage can be too wide for a low-priced share and too tight during a fast market. Recheck the collar against a fresh quote at submission, and reject rather than widen it automatically when the quote is stale.
Choose a failure state
Decide what the agent does when a dependency fails. For risk-increasing orders, the default should usually be to stop. Define acceptable data age by strategy: an intraday system might reject a quote older than one or two seconds, while a slower strategy can tolerate more. A single threshold is not suitable for every product or feed.
Use a state machine with explicit states such as ready, degraded, halted and recovery. A heartbeat can detect a dead process, but it cannot prove that positions are correct.
Reconcile open orders, fills, cash and positions after reconnecting. Do not resume trading merely because the API responds again.
Separate a kill command from normal strategy logic. It should block new orders, cancel working orders where appropriate, and report whether cancellations were confirmed. Cancellation is not the same as flattening: liquidating a position during a spread spike can increase losses. Define whether the incident policy holds, cancels or reduces exposure for each product.
Make compliance observable
Risk limits do not establish that trading is permitted. Confirm that the account owner has authorised automation and that the broker permits the relevant access method and activity.
Rules differ by jurisdiction, product and account type. Short sales, options, use, market data redistribution and trading on behalf of others can each bring distinct conditions.
Keep an audit record that can answer what the agent knew and why it acted. Store the strategy and configuration version, input timestamps, account snapshot, proposed order, checks passed or failed, broker response, fills and operator actions. Use synchronised timestamps and append-only storage where possible. Redact credentials and personal data; an audit trail should not become a secret store.
Apply restricted-instrument lists and trading-hour rules in the same pre-trade path as risk checks. Alert on repeated rejects, unusual order rates and attempts to trade outside the policy.
A paper run in an agentic paper-trading environment, available from $9.99 a month, can help test these control paths before live credentials are enabled. Paper fills do not establish that live execution or regulatory obligations will behave the same way.
Price the trading costs
Limits need to account for friction as well as strategy losses. The following are typical ranges for listed US shares, stated as illustrative market ranges rather than quotes. Actual costs depend on venue, broker, liquidity, order size and account terms.
| Cost | Typical range | Unit | Control implication |
|---|---|---|---|
| Commission | $0 to $0.005 | Per share | Include fees in expected net P&L. |
| Quoted spread | 1 to 10 basis points | Of share price in liquid names | Reject trades where spread consumes the expected edge. |
| Execution slippage | 1 to 10 basis points | Against a reference price in ordinary conditions | Measure by order size and time of day; stress-test beyond this range. |
| Stock borrow | 0.3% to 20% or more | Annualised, hard-to-borrow names can exceed this | Check availability and rate before opening or carrying a short. |
Costs can jump during volatility, thin liquidity or a locate shortage. Treat typical ranges as planning inputs, not caps. Set a maximum acceptable spread or slippage condition for each strategy, and halt or reduce size when realised execution costs breach it.
Use a pre-live checklist
Run the same checks after a deployment or configuration change. Record the result, the tested account and the person authorised to restart the agent.
- Verify account permissions, allowed instruments and trading hours against the mandate.
- Test order caps, exposure limits, loss stops and price collars with boundary values, including just above each limit.
- Simulate stale data, rejected orders, partial fills, duplicate events and a broker disconnect.
- Confirm that restart logic reconciles positions and working orders before permitting new risk.
- Trigger the kill path and verify its status reports, cancellation handling and escalation alerts.
- Review logs for sufficient decision detail and confirm that credentials and personal data are excluded.
Keep a named operator responsible for alerts and restart approval. Page on a breached hard limit, a failed reconciliation or an unexpected position. Set quieter thresholds for cost drift and elevated reject rates, but do not let alert volume become a reason to suppress critical events. These controls do not apply unchanged to regulated market-making, client-money management or high-frequency strategies, where jurisdiction-specific controls and venue obligations require specialist review.
Frequently Asked Questions
What is the most important guardrail for an unattended trading agent?
Use a deterministic pre-trade control layer that checks permissions, exposure, order size and price before submission. Keep it separate from the strategy so a model response cannot override the limits.
Should an automated trading agent stop when market data is stale?
Usually it should block risk-increasing orders when data exceeds a strategy-specific age limit. Set that limit based on the instrument and trading horizon, and require account and order reconciliation before resuming.
What should a trading agent's kill switch do?
It should block new orders and report the status of cancellations for working orders. Whether it should also flatten positions depends on the instrument and incident policy, since forced liquidation can increase losses in poor liquidity.
What should an audit log record for automated trades?
Record the strategy and configuration version, input and account timestamps, proposed order, control decisions, broker responses, fills and operator actions. Use access controls and avoid storing credentials or unnecessary personal data.