One operator stops a strategy when its price feed goes stale. Another keeps trading on the last quote, reasoning that the broker will reject anything too far from market. Those are opposite calls about the same failure, and the second makes a broker-side rejection do the work of a risk policy. An unattended agent needs explicit rules for data quality, order acceptance and what happens after a fault.
A 30-day implementation is enough to build and test a first control layer around a narrow strategy. It is not enough to prove a system safe for every market condition. Start with defined limits, observable behaviour and a way to shut the agent down without depending on the agent itself.
Days 1 to 7: define the boundary of permitted activity
Write down what the agent may trade before changing the order code. Specify account, instruments, session times, order types and maximum position.
If the strategy is meant to trade one liquid futures contract during regular hours, block other contracts and overnight orders at the gateway. Do not rely on a prompt or strategy configuration to enforce the boundary.
Set limits at three levels: per order, per instrument and across the account. Include both gross exposure and loss. A daily loss cap should use a clearly defined measure, such as realised plus unrealised P&L, with the treatment of fees and open positions specified. Decide whether reaching a limit cancels working orders, flattens positions, or freezes new orders.
Those actions carry different risks. A forced market exit can incur substantial slippage in a thin book; merely blocking new orders can leave an unwanted position open.
Turn policy into testable rules
Make the rules machine-readable and version controlled. Each rejected order should return a reason code, and each limit change should record the old value, new value, author and timestamp. Keep strategy permissions separate from risk permissions. The strategy may propose an order, but a small risk service should approve or reject it before it reaches the broker.
Set initial values conservatively, then tune them against the strategy's normal order size and volatility. These are typical starting ranges, not universal settings or audited results for any provider:
| Control | Typical starting range | What it constrains | Trade-off |
|---|---|---|---|
| Maximum single order | 0.5% to 2% of account equity in notional | One bad instruction or duplicate | Can block legitimate scale-in orders |
| Daily loss stop | 0.5% to 2% of equity | Accumulating strategy or execution losses | May stop a strategy during a normal drawdown |
| Stale quote threshold | 1 to 5 seconds for liquid intraday markets | Orders based on delayed prices | Stricter limits can reject orders during feed jitter |
| Price collar | 10 to 50 basis points from a fresh reference price | Fat-finger prices and abnormal limit orders | Needs wider bands in volatile instruments |
| Order-rate cap | 5 to 30 new orders per minute per instrument | Runaway loops and retry storms | Can throttle legitimate fast strategies |
Back-test the proposed limits against recorded order events where possible. Count how often each rule would have blocked a valid strategy order, not just how often it would have caught a fault. For simulated and agentic paper trading, a controlled environment such as an agentic paper trading environment can help exercise order logic without sending those orders to a live account.
Days 8 to 14: put a gate in front of every order
Route every order through one validation path, including replacements, cancels and orders produced by recovery logic. Validate symbol permissions, quantity, price, order type, trading session, buying power and current exposure. Recheck exposure after accounting for working orders. If the agent has a position of 10 and three open buy orders for 5 each, its possible exposure is 25, not 10.
Use idempotency keys or a durable client order ID for submissions. A network timeout does not tell the agent whether the broker accepted the order. On timeout, query order status using that identifier before retrying. Blind resubmission can create duplicate positions. Keep a local state machine for each order, with states such as proposed, submitted, acknowledged, partially filled, filled, cancel pending, cancelled and rejected. Reconcile it against broker reports regularly.
Separate fail-closed decisions from recovery
Reject an order when required checks cannot run, the account cannot be reconciled, or price data exceeds its freshness threshold. Do not treat an API error as permission to continue. At the same time, avoid a generic rule that cancels everything on every transient failure. A cancel request can also time out, and a filled order cannot be cancelled. Define recovery by state: stop new submissions, inspect broker state, then decide whether remaining orders should stay, be cancelled or be replaced.
Log the inputs and result of each risk decision: proposed order, reference price, position and working-order exposure, limits in force, decision, and broker response. Store timestamps in a consistent format and retain enough detail to reconstruct an incident. Avoid putting credentials or unnecessary personal data into logs.
Days 15 to 21: test failures, not just profitable paths
Build a test matrix around events that can occur without warning. Use recorded market data and a broker sandbox where available, but do not assume sandbox behaviour matches live execution. Simulate partial fills, delayed acknowledgements, rejected cancels, duplicate messages, reconnects, market halts, stale quotes and a clock that moves out of sync. Test the risk service being unavailable as well as the strategy failing.
For each case, define the expected system state and assert it in automated tests. For example, if an order submission times out, the expected action is a status query, not a second submission. If account positions differ from the agent's local state, the expected action is to block new risk until reconciliation. Set a timeout for every external call and bound retries with backoff and a maximum attempt count.
Run the agent in shadow mode next. It may generate proposed orders, but it cannot submit them. Compare its proposals with the validation service, and inspect rejected orders and exposure calculations.
Then move to paper trading with the same risk configuration planned for production. Agentic Trading Index offers agentic paper trading from $9.99 a month; a paper trading setup can be used to exercise the full order lifecycle before authorising live execution.
Days 22 to 30: rehearse shutdown and controlled launch
Build a kill switch outside the strategy process. It should block new orders even if the agent is stuck in a loop, and the operator should be able to reach it through a separate control path.
Define what the switch does to working orders and open positions. A useful default is to stop new orders immediately, then require an explicit decision about cancelling orders or flattening exposure.
Set alerts for rejected-order bursts, rising exposure, stale feeds, repeated timeouts, unexpected position changes and loss-limit events. An alert that arrives only in a dashboard is not an escalation plan.
Define who receives it, which event requires a human response, and how long the agent may remain paused before a decision is required. Test notification delivery, including outside normal hours.
Launch with a small allocation and limited instruments. Increase one dimension at a time: order size, instrument count or operating hours.
Keep a daily review of fills, rejects, slippage against the decision price, cancellations and reconciliation differences. If the observed behaviour differs from the test assumptions, reduce permissions and investigate before raising limits.
Before enabling unattended live orders, verify that an operator can:
- Disable new submissions without restarting the agent.
- Find all working orders and current positions at the broker.
- Tell whether a timeout caused an accepted order or a missing acknowledgement.
- Restore service from a known state without replaying stale instructions.
Stop doing these things:
- Stop retrying order submissions without checking broker status.
- Stop treating a strategy's own checks as an independent risk control.
- Stop leaving stale-data handling, loss limits or kill-switch behaviour implicit.
- Stop increasing live size before reconciliation and failure tests pass.
Frequently Asked Questions
What limits should an unattended trading agent have?
Set per-order, per-instrument and account-wide exposure limits, plus a loss stop and order-rate cap. Choose values against the strategy's normal order size and volatility, then test how often the limits would block valid trades.
What should a trading bot do after an order submission times out?
It should query the broker using the original client order ID or idempotency key before attempting another submission. A timeout does not establish whether the broker accepted the order, so blind retries risk duplicate exposure.
Should a kill switch cancel open positions?
The kill switch should at least block new orders through a path independent of the strategy process. Whether it cancels working orders or closes positions should be an explicit policy, since market exits can create slippage and cancellation requests can fail.
