Nearly every unattended trading setup has a limit on order size and a kill switch. The gaps tend to sit between them: a position limit that ignores working orders, a stale price that still passes validation, or a restart that forgets the agent already submitted an order. A useful guardrail is an executable condition with a defined response, not a note in a strategy document.
Run this checklist against the live configuration, the order path and the recovery path. Record the configured value, the component that enforces it, and the test that proves it works. A control enforced only inside the agent is weaker than one repeated at the broker or account level, because a software fault can bypass the first check.
Bound what the agent is allowed to do
Start with authority. Write down the accounts, instruments, order types, sessions and maximum position direction the agent may use.
Compare that list with the permissions on its API key. If the key can trade every product in the account but the agent should only trade two, the system has a larger failure surface than its design claims.
Use an instrument allowlist and reject unknown symbols before building an order. Resolve contract multipliers, quote currency, minimum quantity, tick size and trading hours from current instrument metadata. A symbol mapping error can turn a sensible quantity into an exposure many times larger than intended. Where the broker supports separate credentials or subaccounts, isolate the agent from discretionary positions and unrelated strategies.
Calculate exposure from filled positions and live orders. For a buy order, include the remaining quantity as potential long exposure; for a sell, include its potential short exposure.
Define whether the check uses gross, net or both. Net exposure alone can hide a large long and short position in different instruments, while gross exposure alone can obscure a deliberate hedge.
Keep limits in one versioned configuration that the risk service reads before every order. Reject a missing, malformed or stale configuration rather than falling back to permissive defaults. Log the effective configuration version with each decision. If the strategy needs an exception, make it an explicit, reviewed setting with an expiry, not a code path that silently skips validation.
Put measurable limits before order submission
Use separate limits for an individual order, a position, total exposure and realised loss. A typical starting range depends on capital, liquidity and strategy horizon, so the figures below are examples to test against, not universal prescriptions. Set them in account currency where possible, and specify whether fees, funding and open P&L count towards loss limits.
| Control | Typical starting ranges | Check during the test |
|---|---|---|
| Single order notional | 0.1% to 1% of account equity | Reject a request just above the configured cap, including converted currency value. |
| Position per instrument | 1% to 5% of equity in notional | Count filled quantity plus remaining quantity on all open orders. |
| Gross exposure | 1 to 3 times equity | Test correlated instruments and both sides of a hedge. |
| Session loss stop | 0.5% to 2% of equity | Include the chosen treatment of fees and unrealised P&L, then block new risk. |
| Stale quote threshold | 1 to 5 seconds for liquid products; longer only by design | Advance the clock or freeze the feed and confirm the order is refused. |
These are typical market ranges for initial review, not audited results or a substitute for instrument-specific limits. A strategy trading thin contracts may need a lower order cap and a stricter spread check. A slower rebalancer may tolerate older prices, but it should document the tolerance and refuse to trade outside its defined session.
Before submission, check price bands, quantity increments, available buying power, order rate, spread and the agent's own loss state. Decide how to handle partial fills and fees in the exposure calculation. Use a conservative price for notional estimation, such as the worse of the limit price and current executable side, rather than a mid-price that may not be available.
Separate a warning threshold from a hard stop. A warning can reduce order size or alert an operator; a hard stop must fail closed.
Record the reason for every rejection in a structured event, including the measured value, limit, account, instrument and configuration version. This makes a blocked order diagnosable without weakening the control to get it through.
Make order and data failures predictable
Write an order state machine before testing retries. At minimum, distinguish prepared, submitted, acknowledged, partially filled, filled, cancelled, rejected and unknown.
A network timeout after submission is an unknown state, not proof that the broker did not receive the order. Query by client order ID or reconcile the broker's open orders before retrying. Reusing the same client ID where the API supports it can prevent duplicates, but still verify the returned order state.
Set different timeouts for connection, acknowledgement and execution. A connection timeout may justify reconnecting; an acknowledgement timeout requires a status query. A fill timeout does not mean an order should be resent. For every retry, cap attempts and apply backoff with jitter. If state remains unknown after the defined window, stop new orders and raise an alert instead of guessing.
Specify what a kill switch does. A solid first response is usually to block new orders, cancel working orders, and reconcile positions. Automatic flattening can create market impact, incur fees or turn a temporary feed problem into a larger loss. Make flattening a separate policy, with explicit triggers, permitted order types, price bounds and a check that the closing order will not exceed account limits.
A kill switch is a state transition, not a button: block, cancel, reconcile, then decide whether to flatten.
Make data validity a pre-trade condition. Check exchange timestamp and local receipt time, sequence gaps, crossed or locked markets, zero or negative prices where invalid, and feed connection health. A live socket is not proof of fresh data.
If the source is stale, conflicting or incomplete, block risk-increasing orders. Define separately whether risk-reducing orders can proceed, and which trusted price source they may use.
Prevent a restart from resetting risk. Persist order identifiers, session loss, last processed market-data sequence and the kill-switch state. On startup, reconcile broker positions and open orders before enabling the strategy. If local state disagrees with the broker, keep the agent disabled until the discrepancy is explained. A restart should not erase a loss stop or turn an unknown order into a fresh submission.
Run a fault checklist this week
Use a paper account or a controlled test environment for destructive drills. Do not test duplicate-order behaviour by sending uncontrolled live orders. This sequence takes a few focused sessions and produces evidence for each control, not just a green health check.
- Monday, inspect permissions and limits. Export the API permissions, instrument allowlist and effective risk configuration. Try one request that exceeds each limit and confirm the risk service rejects it before the broker call.
- Tuesday, test exposure accounting. Create a partial fill, leave a second order working, then submit a third order. Verify the calculation includes filled position and remaining working quantity across the account.
- Wednesday, interrupt order submission. Drop the connection after the request leaves the client but before acknowledgement. Confirm the agent queries order status by client ID, does not blindly resubmit, and stops if the state stays unknown.
- Thursday, degrade market data. Freeze timestamps, omit a sequence update and provide a crossed quote. Confirm stale or invalid input blocks new exposure and that the alert names the failed check.
- Friday, test restart and recovery. Restart with an open order and a tripped loss stop. Confirm the agent reconciles broker state, retains the stop and stays disabled until its recovery conditions are met.
For every drill, capture the input, expected response, observed response and event log. Check whether the control worked at the boundary, not just for a dramatically invalid request. A size limit of 10,000 shares should be tested at 9,999, 10,000 and 10,001 if the instrument uses whole shares. Boundary tests expose rounding and inclusive-versus-exclusive mistakes.
Paper trading can exercise the strategy and integration without putting capital at risk, but it may not reproduce queue position, rejects, latency or venue throttles. Treat it as one test layer, not proof of live behaviour. Agentic Trading Index offers agentic paper trading from $9.99 a month; its trading agent environment can help exercise order logic before live deployment.
Keep the operating boundary visible
Build a small dashboard around decisions an operator can act on: current gross and net exposure, session P&L, open orders, data age, broker connection, rejected orders, retry count and kill-switch state. Show the configured limit beside the live value. A chart of strategy returns is not a substitute for knowing whether the agent is currently allowed to place another order.
Alert on state changes and missing heartbeats, not every routine market event. A typical heartbeat interval might be 5 to 30 seconds, with an alert after two or three missed intervals, adjusted to the strategy's response needs.
Send alerts through a path separate from the trading process where possible. Test delivery and escalation, including who acts outside market hours.
Review configuration changes as code. Require a diff, a reason, a named approver and a rollback path for changes to limits, symbols, credentials and order behaviour. After a broker API update or strategy release, rerun the relevant fault drills. Record any temporary override with a time limit, and have the service reject an expired override automatically.
If this were my operation, I would first test the ambiguous order timeout and prove that a restart cannot submit a duplicate or clear a tripped stop. Then I would put the resulting evidence, limits and recovery procedure in one runbook that another operator can follow.
Frequently Asked Questions
What guardrails should an unattended trading agent have?
At minimum, use an instrument allowlist, order and position limits, exposure and loss stops, market-data freshness checks, and a defined response to unknown order states. Persist risk state across restarts and reconcile positions with the broker before trading resumes.
How often should an automated trading agent check risk limits?
Check risk before every order submission, including replacements and retries. Recalculate exposure when orders fill, partially fill, cancel or expire, and reconcile periodically against broker state.
Should a trading kill switch automatically close positions?
Not by default. Blocking new orders and cancelling working orders are usually easier to reason about; automatic flattening can create market impact or unexpected costs. If flattening is required, define its triggers, permitted order types and price controls separately.
How do I test trading agent guardrails without risking capital?
Use a paper account or controlled test environment to inject stale data, partial fills, timeouts, rejects and restarts. Verify exact boundary conditions and inspect structured logs. Paper testing does not prove live queue position, latency or venue behaviour.
