What does 'buy the pullback' mean to the agent? It means nothing executable until the team defines the price reference, the size of the pullback, the order type and what happens if the price moves before the order reaches the venue.
Plain language is useful for agreeing intent. It is not a complete trading specification.
That gap is a risk and compliance problem, not just a software design problem. An unattended process can repeat an unclear instruction quickly, across multiple instruments and sessions. A human may infer what a phrase means from context. A programme needs explicit conditions, states and limits, with enough evidence to explain what it did afterwards.
The aim is not to remove plain English. It is to connect each sentence to a testable rule and make the assumptions visible. The resulting document should let a reviewer trace a strategy from signal, through risk checks and order handling, to a recorded outcome.
Plain language loses operational detail
Consider a description such as: 'Buy a breakout when volume confirms, but avoid volatile conditions.' It leaves several decisions open. Which price series defines the breakout? Is the bar complete? What counts as confirmation? How is volatility measured, and what happens when the measure is missing or delayed?
Even words that sound precise can hide choices. 'Close' might mean the last trade, a broker's mark, a midpoint, or the final value of a time bar in a particular timezone. 'At the open' might mean a market order at the session open, a limit order submitted before it, or a signal generated after the first bar closes. These interpretations produce different orders.
Separate the strategy into four layers:
- Intent: the market behaviour the strategy seeks to trade.
- Signal: the data and conditions that produce a trade decision.
- Execution: the order instructions and handling of fills, rejections and timeouts.
- Controls: limits that can block, reduce or stop activity.
Keep the plain-language intent, but attach a defined rule to each operational phrase. If two engineers can implement a phrase differently and still claim they followed it, the phrase is not specific enough for unattended use.
Turn strategy verbs into rules
Verbs such as buy, confirm, reduce and exit need a trigger, a reference and a time boundary. An illustrative breakout rule might say: calculate the highest completed one-minute bar close over the previous 20 bars; generate a signal only when the next completed bar closes above that level by a stated buffer. Those settings are examples, not recommended parameters. The important part is that the data source, bar construction, completion rule and comparison are all defined.
Then specify how a signal becomes an order. State whether the agent sends a market, limit or stop order; how it calculates quantity; the time in force; and whether it may replace an unfilled order. Define the price limit and maximum number of replacements. A 'retry on failure' instruction is especially dangerous if failure includes an ambiguous timeout: the first request may have reached the broker even when the response did not reach the agent.
Write down what happens in these cases, at minimum:
- The signal arrives while the market is closed, halted or outside the permitted session.
- The quote is stale, crossed or missing, or the required bar is incomplete.
- An order is partially filled, rejected, cancelled or left pending after a network timeout.
- The strategy restarts and discovers an existing position or open order.
- The broker reports a position that differs from the agent's local ledger.
These are not obscure edge cases. They are ordinary states in an order lifecycle. For example, after a timeout, the safe next step is usually to reconcile orders and positions before deciding whether to submit again. Blind retries can create duplicate exposure.
Make risk controls observable
A control only works if the agent can calculate it from reliable inputs and enforce it before the relevant action. 'Keep risk low' is not a control. Define maximum order quantity, gross and net exposure, use, and any concentration limit by instrument or asset group. Specify whether exposure includes working orders and how partial fills change the available limit.
Loss limits also need a measurement rule. A daily stop might use realised and unrealised profit and loss, a named currency, a session boundary and a defined price source. State what the agent does when the threshold is reached: block new entries, cancel working entry orders, reduce positions, or flatten them. These actions have different market and operational risks. A forced market exit can incur slippage; blocking entries while leaving old orders active can add exposure later.
Give every important input a freshness limit. A rule could block new orders if its quote is more than two seconds old, but the appropriate threshold depends on the instrument, feed and strategy. Treat that as an explicit configuration choice, not a universal standard. If the clock, market-data feed or risk service becomes unavailable, define a fail-closed state and the recovery procedure.
Test controls against states, not just values. Check that the limit blocks an order at the boundary, that a cancelled order no longer counts as working, and that a restart does not reset a daily loss counter. A control that cannot be observed in logs or reconciled against broker state is difficult to validate and harder to defend.
Keep an audit trail that explains decisions
For each signal and order decision, preserve the strategy version, input data identifiers or snapshots, timestamps, calculated values, risk checks and reason for the action. Record timestamps in a consistent format, preferably with timezone information, and distinguish event time from the time the agent received the event. This helps explain delays and data revisions.
Capture the complete order lifecycle: request, broker acknowledgement, exchange or venue updates where available, partial fills, cancels, rejects and final position reconciliation. Log a client order identifier that remains stable across retries and a separate identifier for each broker request. Redact secrets and avoid placing account credentials or personal data in general application logs.
Compliance review may require evidence that restricted instruments, account permissions and applicable trading controls were checked before an order was sent. Make the source and version of those restrictions traceable. The exact obligations depend on the firm, account, market and jurisdiction, so a strategy document cannot replace legal or compliance review.
Keep records in a form that survives a process crash and can be queried without rebuilding the entire system. Define retention and access controls with the relevant policy. A useful record should answer three questions: what information did the agent have, which rule did it apply, and what order or risk action followed?
Price the controls, not just the strategy
Operational controls have recurring costs. The figures below are typical market ranges for a small deployment, not audited prices or a quote.
Actual costs vary with asset class, venue permissions, usage and retention requirements. They exclude trading commissions, exchange charges that depend on activity, and losses from market moves.
| Cost item | Typical market range | What affects the cost |
|---|---|---|
| Market data and permissions | £0 to £500+ per month | Delayed or real-time feeds, venues, user classification and redistribution rights |
| Compute and log storage | £20 to £250 per month | Order volume, retention period, redundancy and query needs |
| Alerts and monitoring | £0 to £150 per month | Notification volume, integrations and service level |
| Incident investigation | £40 to £120 per staff hour, typically 2 to 12 hours for an incident | Whether broker records, market data and agent logs can be reconciled quickly |
These typical ranges are useful for planning, but a low monthly bill does not mean a system is adequately controlled. Missing data permissions, weak retention or no alert when reconciliation fails can create a much larger operational problem. Budget for the ability to investigate a rejected order, a duplicate submission or an unexpected position, not only for the process that generates signals.
Rehearsal can expose gaps before live orders are involved. An agentic paper-trading environment such as FX-Tech's paper trading can be used to exercise order states and recovery logic; paper fills still cannot establish how live liquidity or slippage will behave.
Checklist before unattended execution
Use this review before enabling an agent to place orders without a human watching. Each item should have an owner and a test or record that shows it is satisfied.
- Define the inputs. Name the instrument identifiers, price source, bar interval, timezone, session calendar and freshness rules.
- Make signals reproducible. Specify calculations, thresholds, boundary behaviour and what happens when data is incomplete or corrected.
- Specify the order lifecycle. Set order types, quantity calculation, price bounds, time in force, replacement rules and behaviour after uncertain acknowledgements.
- Set enforceable limits. Include order size, total exposure, concentration and loss measures. Define which actions follow a breach.
- Reconcile broker state. Test restarts, partial fills, rejected orders, open-order discovery and differences between local and broker positions.
- Preserve evidence. Record strategy versions, inputs, checks, decisions and order updates, with access and retention rules.
- Exercise failure paths. Simulate stale feeds, timeouts, rate limits, service restarts and unavailable risk checks. Confirm that the agent blocks or recovers as specified.
- Approve changes. Version changes to strategy rules and controls, review them before deployment, and keep a tested rollback path.
Plain-language descriptions are good for communicating what a strategy is meant to do. For an unattended system, every instruction that can change exposure also needs a precise, testable interpretation. The market has no shortage of strategies that sound clear in a meeting.
Frequently Asked Questions
Why is a plain-language trading strategy description not enough?
It often leaves price references, timing, sizing and exception handling open to interpretation. An agent needs those choices defined as testable rules before it can place orders consistently.
What should a trading strategy specification include?
It should define the data inputs, signal conditions, order types, sizing, risk limits and handling of rejected, partial or uncertain orders. It should also specify logging, reconciliation and recovery after a restart.
How should an agent handle an order request timeout?
It should not blindly submit the same order again. First reconcile open orders, fills and positions with the broker, using stable client order identifiers where available.
What should an automated trading risk control measure?
Typical controls cover order quantity, total exposure, concentration, use and losses. The specification should define the inputs, measurement period and action taken when a limit is reached.
What should trading agents log for compliance review?
Keep the strategy version, relevant inputs, timestamps, risk checks, decision reasons and full order lifecycle. Protect sensitive information and set retention and access rules that match the applicable policy.
