Devin Hartcastle
A plain-language trading strategy is not a complete trading specification.
"Buy when momentum turns positive and exit if the trade goes against us" communicates intent. It does not tell an unattended agent which price to use, how old a quote can be, how much to buy, or what to do with a partial fill.
Those omissions are not editorial details. They determine which orders reach the venue and what risk remains when conditions change.
Turn the description into a chain of observable inputs, decisions and actions. For each sentence, write down what the software reads, the exact condition it evaluates, and the resulting order or state change. If two developers could implement the sentence differently, the specification is not finished.
Plain language states an intention
Most strategy descriptions compress several assumptions into a few familiar terms. "Momentum turns positive" could mean a moving average crossover at a bar close, an indicator calculated on every tick, or a price change over a rolling window. "Exit if it goes against us" could mean a fixed stop, a volatility-adjusted stop, or a signal reversal. Each version produces different entries, holding times and losses.
Start by marking every word that hides a choice. Common examples include:
- Now: at the signal timestamp, the next bar open, or after an order acknowledgement?
- Price: last trade, bid, ask, midpoint, or a limit price derived from one of them?
- Enough: what numerical threshold qualifies as a signal?
- Exit: close the full position, reduce it, or cancel outstanding entry orders first?
- Risk: per trade, per instrument, per account, or across correlated positions?
Keep the original sentence alongside the executable rule. That preserves the intended meaning and makes later changes easier to review. Add a unit, a data source and a clock to every numerical threshold. A 20-period average is incomplete without its bar interval, price field and treatment of missing bars.
Convert each phrase into a testable rule
Replace qualitative language with conditions that return true or false. For example: "Buy when momentum turns positive" might become "At each completed one-minute bar, submit an entry signal when the 12-period EMA crosses above the 26-period EMA, using midpoint closes." That is still not a whole trading plan, but it can be calculated and tested consistently.
Specify both sides of a condition. State whether equality counts, whether the signal is evaluated once or repeatedly, and what resets it. If the averages remain crossed for five bars, should the agent submit five entries or one? If a data gap interrupts a bar, should the signal be skipped or reconstructed?
The table gives illustrative typical market ranges for execution context, not venue guarantees. Actual values vary with session, order size, volatility and connectivity.
| Measure | Major FX pairs, typical range | Liquid US shares, typical range | Thinner crypto pairs, typical range |
|---|---|---|---|
| Quoted spread | 0.1 to 1.5 pips | 1 to 10 basis points | 10 to 100+ basis points |
| Small marketable order slippage | 0.1 to 2 pips | 1 to 10 basis points | 5 to 50+ basis points |
| API order acknowledgement round trip | 50 to 500 ms | 20 to 300 ms | 50 to 1,000 ms |
Use ranges to challenge assumptions, not to hard-code a promise of execution quality. A backtest that fills every order at the signal price ignores spread and slippage. Add a fill model that reflects the instrument and order type, then compare its assumptions against recorded paper or live observations.
Put market mechanics back into the specification
A signal is not an order. Define the order type, time in force, quantity calculation, price protection and cancellation rules. For a marketable limit order, specify the maximum price deviation from the reference quote and how long the order may rest. For a market order, define when it is permitted and how exposure is capped if the book is thin.
Time matters just as much as price. Decide whether signals use exchange timestamps or local receipt times, how the agent handles clock drift, and how old a quote may be before it refuses to trade. A quote that was fresh when a signal was calculated can be stale by the time a request reaches the broker.
Write the order lifecycle as explicit states: pending submission, acknowledged, partially filled, filled, cancel pending, cancelled, rejected and unknown. An HTTP timeout does not prove an order failed.
Query by a stable client order ID before retrying, or a retry can create a duplicate position. Define reconciliation behaviour for every state the API can report.
A strategy rule without an order-state rule is only half an instruction.
Record the input snapshot and rule version with each decision. Include the instrument, timestamp, relevant prices, indicator values, target quantity and reason code. This gives the operator a way to distinguish a bad signal from stale data, a rejected order or a partial fill.
Define what the agent does when reality diverges
Unattended software needs a failure policy, not just an ideal path. Set hard limits for position size, order value, daily loss and message rate. Choose what happens when a limit is reached: reject new entries, cancel working orders, reduce exposure, or halt and alert. The choice depends on the strategy, but leaving it implicit means the implementation decides under pressure.
Prioritise the response in a runbook and encode the actions that must happen without a person present:
- Stop creating new exposure when market data is stale, malformed or outside the permitted trading session.
- On a submission timeout, look up the client order ID before retrying. Do not assume the venue received nothing.
- Reconcile open orders and positions after reconnecting. If local and broker state disagree, block new entries until the mismatch is resolved.
- Apply account and instrument limits to actual filled quantity, including partial fills and positions opened elsewhere.
- Log the trigger, action and resulting state. Send an alert for a halt or unresolved discrepancy, not for every routine update.
These controls have costs. A strict stale-quote cutoff may skip valid trades during a brief feed interruption. Automatic cancellation can remove a protective resting order. Define the desired safe state for each failure rather than applying one generic rule to every condition.
Test the translation under pressure
Test the executable rules against cases that expose ambiguity. Include a signal exactly on the threshold, a missing bar, a price gap, a rejected order, a partial fill followed by a disconnect, and two signals arriving before the first order is acknowledged. Check the resulting order and position state, not only whether the indicator calculation looks right.
Run deterministic tests first, then replay recorded market data with realistic spreads, fees and latency assumptions. Compare the strategy's expected position with the broker's reported position after every fill and cancellation. Useful measures include rejected-order rate, duplicate-order count, fill-to-signal delay, slippage in basis points, and time spent with a state mismatch. Set limits before testing so a result does not get judged by impression.
Paper trading can expose API and lifecycle bugs without risking capital, but it may not reproduce live queue position or market impact. Agentic Trading Index offers agentic paper trading from $9.99 a month for testing order workflows. Keep the rules and test records versioned, and document external dependencies in the runbook, including any relevant reference at fx-tech.ai.
The mistake most readers will still make is treating a precise signal as a precise trading system.
Frequently Asked Questions
What should a trading strategy description include?
It should define inputs, signal conditions, timing, position sizing, order types, exits and risk limits. It should also specify what the agent does with stale data, rejected orders, partial fills and connection failures.
How do I turn a trading idea into rules an agent can execute?
Replace qualitative terms with measurable conditions, data fields and timestamps. Then define the order action and expected state change for each condition, including boundary cases and missing data.
Should an automated strategy use market or limit orders?
It depends on the instrument, liquidity and urgency of execution. Specify acceptable price deviation and fill behaviour for each order type, and test the trade-off between missed fills and slippage.
How should a trading agent handle an order timeout?
Treat the order status as unknown until checked. Query using a stable client order ID before retrying, because the venue may have accepted the first request even though the response timed out.
Can paper trading validate an automated trading strategy?
It can test signal plumbing, order states, error handling and position reconciliation without risking capital. It does not fully model live queue priority, market impact or every venue-specific execution condition.
