A trading strategy description loses detail at execution

Week one describes intent; week six exposes mechanics

In week one, a strategy might read: buy a liquid asset when its short-term price falls below its recent average, then sell when it recovers. By week six, the agent has encountered a market holiday, a partial fill, a stale quote and a restart with an open position. The sentence did not say what to do in any of those cases.

This is the gap between a strategy description and an executable specification. Prose is useful for communicating the economic idea. It is a poor substitute for defining timestamps, order types, sizing, position limits and recovery behaviour. A developer who translates each sentence directly into code often builds the intended signal, then invents the trading system around it.

That invention is where two implementations of the same strategy begin to differ. One may act on the candle close; another may act when the candle first crosses a threshold. One may cancel an unfilled order after five seconds; another may leave it working until the next signal. Both can claim to implement the same plain-language rule.

For unattended trading, the useful question is not only what should prompt an order. It is what the agent knows at that moment, what it is permitted to do, and how it behaves when the expected sequence breaks.

Signal language hides clocks and data rules

Words such as "recent", "below" and "recovers" sound precise until code needs a value and a time. "Below the 20-period average" requires a bar interval, a definition of the average, and a decision about whether the current unfinished bar counts. "Buy at the close" is not actionable until the system defines which close and when the order may be sent.

Write signal rules in terms of inputs that can be reproduced. For each input, record:

• The instrument identifier and trading venue, including how contract changes or ticker mappings are handled.
• The data field, source and timestamp convention. Distinguish exchange event time from the time your process received the update.
• The sampling interval, lookback, calculation method and treatment of missing or corrected observations.
• The trigger evaluation schedule, such as once per completed one-minute bar, rather than whenever a data callback arrives.

These choices change trade frequency and entry price. A close-based signal using completed bars will normally react later than a tick-based threshold. A bar with no trades may be absent from one feed and represented as a zero-volume bar by another. If the strategy assumes one convention and the data pipeline supplies another, the backtest and the agent are running different rules.

Set a maximum data age. For example, a system might block new orders if a quote is more than 2 seconds old, while the appropriate limit depends on the instrument and strategy horizon. Also define what happens after a feed gap: wait for a fresh bar, rebuild indicators from history, or disable the strategy until reconciled. Silent forward-filling is a decision, not a neutral data-cleaning step.

Position sizing is not an order instruction

"Risk 0.5% of capital" is a sizing intention, not a quantity the broker can accept. The implementation still needs to define the capital basis, the stop or risk distance, contract multiplier, currency conversion and rounding.

If the intended risk is £500 and the estimated loss per unit is £2, the raw quantity is 250 units. A lot-size rule, existing exposure or notional cap may reduce it.

Specify whether size is calculated from cash, net liquidation value or a fixed account allocation. State whether open orders reserve buying power and whether pending exits reduce exposure.

Define quantity precision, minimum order size and the price used for conversion. For a target weight, specify how far the current position may drift before rebalancing, and whether the order closes, opens or reverses exposure.

Then separate target position from the order needed to reach it. If the target is 100 shares and the account already holds 40, the agent should normally seek 60, not send a fresh order for 100.

That difference becomes critical after partial fills or a process restart. Calculate the desired position from reconciled holdings, then derive the remaining order quantity from working orders and confirmed fills.

Apply limits at more than one level: per order, per instrument, across correlated positions, and across the account. A limit of £10,000 per order does not prevent ten simultaneous orders from creating £100,000 of exposure. Include a policy for short availability, buying-power rejection and maximum use. These are strategy constraints, even when they live in a risk-control module.

Costs turn a signal into a different strategy

A rule that expects a small move can be erased by spread, fees and slippage. Use cost estimates that match the asset, venue, order size and time of day.

The following are typical market ranges, not fixed quotes. Actual costs vary with liquidity, volatility, account terms and order behaviour.

Do not add every row mechanically. A measured fill price may already include spread and slippage, while a broker statement may record commissions separately.

Double-counting makes estimates pessimistic; omitting spread because a backtest fills at the mid makes them optimistic. Record each cost component once, with its source and calculation.

Order choice also changes the cost and fill risk. A market order prioritises execution but accepts the available price. A limit order constrains price but can miss the move or receive only a partial fill. A marketable limit with a price collar may control the worst acceptable price, but needs a timeout and cancellation rule. Before comparing strategy variants, test these choices with realistic order-state behaviour. An agentic paper-trading environment, such as the one offered through Agentic Trading Index, can help exercise order workflows before live capital is involved.

Failure behaviour belongs in the specification

Many descriptions define the happy path and leave exceptions to library defaults. That is unsafe when nobody is watching. The agent needs explicit behaviour for rejects, timeouts, disconnects, partial fills and duplicate responses.

A timeout does not prove an order failed. The venue may have accepted it while the acknowledgement was lost.

For each order, persist a client-generated identifier and the intended target position before submission. After an uncertain response, query order status and reconcile holdings before sending another order. Blind retries can duplicate exposure. A rejected order should carry a reason and a defined response: correct a permitted parameter, wait, reduce size or stop trading. Repeating the same rejected request is not recovery.

Define thresholds that disable new orders, such as data age above the configured limit, position mismatch above one lot, repeated rejects within a rolling interval, or loss beyond a stated account limit. A trigger must specify whether it cancels working orders, attempts to flatten positions or simply blocks new entries. Flattening during a spread spike can increase losses, so the action and its trade-off need to be deliberate.

Keep a durable event record: signal inputs, decision, risk checks, submitted payload, venue response, fills, cancellations and reconciled position. On restart, rebuild state from those records and the broker, not from an assumed clean slate.

Paper tests should include dropped acknowledgements and partial fills, not just accepted orders. FX-Tech's paper-trading option, priced from $9.99 a month, is one route for rehearsing an agent workflow without placing live orders.

Turn the prose into a testable contract

Translate each sentence into a rule, an observable input and a test. Keep the economic hypothesis separate from execution policy so changes to one do not silently alter the other. A practical review checklist is:

1. Write the signal formula, input fields, bar interval and timestamp rule.
2. Specify when the agent evaluates the signal and how stale or missing data blocks action.
3. Define target position, quantity calculation, rounding and exposure limits.
4. Name the order type, price constraint, time in force, timeout and cancellation behaviour.
5. Define how partial fills, rejects, lost acknowledgements and restarts reconcile to the target.
6. List cost assumptions and identify which are already included in observed fills.
7. Set stop conditions, their thresholds, and whether they cancel, flatten or pause.
8. Test normal operation and failure cases, then compare intended state with broker-reported state.

A useful test asks what the agent should do, not merely whether a function returned success. Given a target of 100 units, 40 confirmed units and a working order for 20, the remaining desired quantity is 40, not 60 or 100. Given a timeout after submission, the next action is a status query, not an automatic duplicate. Encode examples like these as repeatable tests.

Keep the plain-language version, executable specification and code linked by version. When a trader changes "enter on a close" to "enter on a touch", update the test data and review the consequences for timing, spread and fill probability. The mistake most readers will still make after reading this is treating a clearer strategy sentence as a complete trading specification.

#paper trading #algorithmic trading execution #trading agent risk controls #order state management #execution costs #automated trading rules #order sizing #trading signal specification