Devin Hartcastle
Can this agent trade through a timeout without duplicating an order?
That is the question to ask the team. It should not, unless it has confirmed the broker's order state before retrying. A timed-out request may have reached the venue even if the client never received the response. Blindly resending it can double the position.
Unattended operation means software must handle both expected market conditions and uncertain system states. A guardrail is a rule that blocks, limits or stops activity without waiting for a person to notice a problem. It should be enforced before an order leaves the system, and where possible backed by a separate account-level or broker-side limit.
Build the control path so that a failure defaults to no new risk. If the risk service, position snapshot or market data is unavailable, pause new orders. That can miss a trade. It is usually less costly than placing one with unknown exposure.
Set limits outside the strategy
Strategy code should propose orders. A separate risk gate should validate them against current account state and configured limits. This helps prevent a strategy bug, a bad model output or a configuration error from quietly changing the risk budget.
Use several limits rather than relying on one stop:
- Order limits: cap notional, quantity and order count. Reject prices outside a collar around a fresh reference price.
- Exposure limits: cap gross and net exposure, use, and concentration by instrument or correlated group.
- Loss limits: measure realised and unrealised losses against a defined equity baseline. Specify whether fees and open positions count.
- Data limits: block orders when quotes are stale, timestamps drift, or required fields are missing.
- Activity limits: cap order submissions and cancellations per time window to catch loops and runaway retries.
For an early pilot, teams commonly test order caps around 0.1% to 1% of account equity and daily loss stops around 0.5% to 2%. These are planning ranges, not suitable limits for every asset or strategy.
A small account trading a thin contract may need a much lower notional cap. Define whether the loss stop blocks new orders only, cancels working orders, or also starts a separate liquidation process.
Budget for the controls
Guardrails have operating costs beyond commissions and spreads. The ranges below are typical monthly planning figures in USD for a small deployment.
Actual prices vary with data entitlements, retention, traffic and provider terms. They are not audited prices for a specific vendor.
| Cost item | Typical monthly range (USD) | What drives the cost |
|---|---|---|
| Market data | $0 to $500 | Delayed or basic feeds cost less; real-time exchange access and multiple venues cost more. |
| Compute and network | $20 to $200 | Instance size, redundancy, region and network requirements. |
| Logs, metrics and alerts | $10 to $150 | Event volume, retention period, alert routing and dashboard needs. |
| Paper execution and testing | $9.99 to $100 | Account tier, instruments and testing features. Agentic paper trading is available from $9.99 a month. |
| Backups and status checks | $0 to $75 | Storage, independent health checks and recovery requirements. |
These figures exclude exchange fees, commissions, borrow charges, financing, slippage and engineering time. Do not treat paper fills as a substitute for a live cost model.
Record fees and expected spread separately, then compare them with realised costs by instrument and order type. A low monthly infrastructure bill does not make a strategy economical if it crosses a wide spread on every rebalance.
Make every order state explicit
Track order intent, submission, acknowledgement, partial fill, cancellation and final status as distinct states. Store the client order ID and an idempotency key before sending the request. If the connection drops, query by that identifier and reconcile the account before deciding whether to retry.
Partial fills need their own handling. A cancel request can race with a fill, leaving the agent with an open remainder and a changed position. Recalculate exposure from confirmed fills and working quantities, not from the strategy's intended order size. Reconcile against broker positions and open orders on startup, after reconnects and on a regular schedule.
Make the kill switch equally precise. One action can block new orders; another can cancel working orders.
Liquidating positions is a separate action because a market order can increase losses in a thin or fast market. Log who or what triggered each action, the account state it saw, and the resulting broker response.
Test failures as well as signals
A profitable backtest does not test duplicate requests, stale quotes or a process that restarts halfway through a cancel. Exercise the execution path with injected faults.
Paper environments can help validate request handling and monitoring before live capital is involved. For example, FX-Tech's paper trading environment can be part of that test setup, but paper execution cannot reproduce every live queue, rejection or liquidity condition.
Include scenarios such as:
- A request times out after reaching the broker, then the client reconnects.
- A quote becomes stale between risk validation and order submission.
- A partial fill arrives while a cancel request is pending.
- The process restarts with open orders and a position different from its local record.
- The loss threshold is crossed while the market feed is delayed.
For each case, define the expected action and check the event log. Measure how long the agent takes to detect the fault, stop new orders and reconcile its state. Run the same tests after changes to the broker adapter, risk rules or deployment configuration.
Checklist before unattended deployment
Use this numbered checklist for a release review. Each item should have an owner, a test and a logged result.
- Set per-order, total exposure, concentration and daily loss limits.
- Confirm the risk gate rejects stale data, missing fields and invalid prices.
- Verify retries query existing order state and cannot create duplicates.
- Test partial fills, cancel races, reconnects and process restarts.
- Define separate actions for blocking orders, cancelling orders and liquidating positions.
- Alert on rejected orders, repeated retries, reconciliation mismatches and limit breaches.
- Compare expected and realised fees, spread and slippage in paper tests, then review them again with small live orders.
- Confirm the deployed configuration matches the reviewed limits, not just a local file or dashboard.
Before enabling the agent, open the production configuration and check the daily loss cap in per cent of equity: 1.0%.
Frequently Asked Questions
What guardrails does an unattended trading agent need?
Use order-size, exposure, loss, data-freshness and activity limits. The agent also needs a defined stop procedure and a way to reconcile its records with broker positions and open orders.
How should a trading agent handle an API timeout?
Do not resend the order blindly. Query the broker using the client order ID or another idempotency key, reconcile the order state, then retry only if the order was not accepted.
What is a reasonable daily loss limit for an automated trading pilot?
Teams often test initial limits in a range around 0.5% to 2% of equity, but the right setting depends on the strategy, instrument liquidity and account size. Specify how the limit treats open losses, fees and working orders.
How much does it cost to run guardrails for an unattended trading agent?
Typical small-deployment costs can range from about $40 to several hundred dollars a month for compute, data, monitoring and testing. Exchange fees, commissions, slippage and engineering time are additional.
Can paper trading prove an agent is safe for live trading?
No. Paper trading can test order logic, state handling and monitoring, but it may not reproduce live queue position, liquidity, rejections or market impact. Use fault tests and controlled live validation as well.
