A $100,000 account with a 1% exposure overshoot carries $1,000 more market risk than the approved plan. If an agent trades unattended, a guardrail that exists only in a design document will not contain that exposure. Each limit needs a data source, a calculation, a response and a record that lets the team check whether the response happened.
Start by specifying what the agent may do, not only what the strategy intends to do. A strategy can target a small position and still create a large one through duplicate submissions, stale prices or delayed fills. The risk layer should sit outside strategy logic, read account and order state independently, and be able to reject new orders even if the strategy process is unhealthy.
Set a measurable risk envelope
Define limits at account and strategy level
Set hard ceilings for gross exposure, net exposure, use and per-instrument concentration. Calculate exposure from current positions plus open orders that could still fill.
For options, use a risk measure such as delta-adjusted notional alongside contract count. A position-only check misses the risk in working orders; an order-only check misses the risk already filled.
Give each strategy its own allocation and loss budget, then enforce an account-wide ceiling across all strategies. That prevents several individually compliant processes from exceeding the portfolio limit together. Specify the units and reset time in code. A daily loss limit based on realised profit and loss alone can keep trading after a large open loss; include unrealised profit and loss, commissions and fees.
- Record the capital base used for every percentage limit, including how deposits and withdrawals affect it.
- Calculate gross and net exposure after fills and before accepting each new order.
- Keep a hard maximum order notional separate from strategy-level sizing.
- Define whether a breach blocks new orders, cancels working orders, or both.
Use a baseline the agent can verify
Risk calculations depend on reliable account state. Track the timestamp and source of positions, cash, open orders and market prices.
If any required input is missing, older than its permitted age, or inconsistent with the agent's internal ledger, do not treat the last known value as current. Block risk-increasing orders until state is reconciled.
Store each limit with its value, scope, measurement window and owner. A limit of "2% loss" is incomplete without saying whether it means account equity or strategy capital, whether the window is a trading day or rolling 24 hours, and whether unrealised loss counts. These details determine whether two systems calculate the same breach.
Measure the state the agent actually sees
Track freshness and reconciliation
Monitor age, not just availability. A connected market-data stream may still be delivering delayed prices.
Measure event timestamps against the agent's clock, and monitor clock drift as well. For account state, compare broker positions and open orders with the local ledger on a schedule and after important events such as reconnects, rejects and partial fills.
Use sequence numbers or event identifiers where available. Record when an order was submitted, acknowledged, partially filled, filled, cancelled or rejected. If an acknowledgement times out, the order may still be live. Treat its status as unknown, query the venue or broker, and avoid submitting a replacement until the original outcome is known.
Measure execution and control quality
Track metrics that can expose a control failure before it becomes a large position:
- Order reject rate, split by instrument, order type and rejection reason.
- Difference between intended and confirmed position, in units and as a share of allocated capital.
- Slippage against a named reference price, reported by instrument and time of day.
- Age of the oldest unacknowledged order and time to reconcile an uncertain order state.
- Frequency of risk checks that reject, clip or defer an order, with the reason attached.
Keep the raw events as well as the rolled-up metrics. A daily average can conceal a burst of rejects or a single long reconciliation gap.
For each metric, retain timestamps, instrument, strategy identifier, order identifier and the version of the risk configuration used. This makes an incident reproducible rather than dependent on log lines assembled after the event.
| Metric | Illustrative typical range | Example response to a breach |
|---|---|---|
| Market-data age for liquid intraday instruments | 100 ms to 1,000 ms | Hold new orders when the strategy's feed-age limit is exceeded. |
| Daily loss budget as a share of allocated capital | 0.5% to 2% | Stop risk-increasing orders; cancel working orders if policy requires it. |
| Position reconciliation interval | 1 to 5 seconds | Block additions if a mismatch persists beyond the configured grace period. |
| Per-order notional as a share of strategy capital | 0.25% to 2% | Reject or clip orders above the hard notional ceiling. |
| Slippage review threshold against a chosen benchmark | 2 to 10 basis points | Pause the affected instrument or strategy for investigation. |
These are typical illustrative ranges, not universal settings or audited performance figures. Instrument liquidity, order horizon, venue behaviour and strategy turnover change the right values. Set thresholds from observed paper and live-market behaviour, then document the reason for each threshold and the cost of making it tighter.
Turn limits into explicit stop conditions
Each limit needs a defined state transition. For example, a data-age breach can move the agent from trading to blocked, cancel orders that are still cancellable, and alert an operator.
A loss-limit breach may require a stronger response. Avoid a single generic "kill" action if the agent needs to preserve positions or reduce risk in an orderly way.
Specify the behaviour for at least these conditions:
- Risk-increasing orders are rejected when required inputs are stale or missing.
- Unknown order status blocks replacement orders that could duplicate exposure.
- A hard exposure or loss breach disables new orders and records the triggering values.
- Repeated API errors or a position mismatch move the process to a defined safe state.
- Resumption requires a fresh state check and, for material breaches, an explicit operator action.
Measure time from breach to action, and count breaches that were detected but not enforced. A tripwire that fires after the next order has already reached the venue is not equivalent to a pre-trade check.
Keep separate counters for blocked submissions, cancellation attempts, cancellations confirmed and unresolved orders. Those outcomes have different risk implications.
Test the guardrails under failure
Test the risk layer independently from strategy returns. Simulate stale feeds, dropped acknowledgements, duplicate events, partial fills, delayed position updates, rejected cancels and process restarts.
Verify both the decision and the resulting state. A test that confirms an error message, but not that the agent stopped adding exposure, has not tested the control. Measure:
- Trip latency, from the first qualifying event to blocked order submission.
- False-trip rate, with the cause and affected trading time recorded.
- Recovery time, including reconciliation and any operator approval.
- Coverage, expressed as tested failure modes divided by documented failure modes.
Paper trading can help exercise order flows without risking capital, but it will not reproduce every live venue delay or failure. Agentic Trading Index offers agentic paper trading from $9.99 a month for developers who need a repeatable environment to test their software. Keep a separate gap register for behaviours the paper environment does not model, then test those with controlled limits before expanding live access.
Review thresholds after material changes to instruments, order types, venues or strategy frequency. Keep the old configuration and the reason for each change so a later incident can be assessed against the rules active at the time. In the next team meeting, which guardrail can the agent prove it enforced, using the underlying order and account events?
Frequently Asked Questions
What guardrails should an unattended trading agent have?
At minimum, enforce limits for exposure, order size, daily loss, data freshness and unresolved order state. Each limit needs a measurable input, a breach action and an event record.
How should a trading agent handle stale market data?
Set a maximum permitted age for each required feed and measure event timestamps, not only connection status. When data exceeds the limit, block risk-increasing orders until fresh data is available.
Should a daily loss limit include unrealised losses?
Usually, yes, if the limit is intended to constrain current account risk. Define whether the calculation includes unrealised profit and loss, fees and open orders, and make the reset window explicit.
How do you test trading agent guardrails?
Inject failures such as delayed acknowledgements, partial fills, stale feeds and position mismatches. Measure detection and action latency, confirm the resulting order state, and track untested failure modes separately.
