A strategy description is a plain-language account of when a system should trade, what it should trade and how it should manage the position.
That sounds complete until a process must turn the account into orders without a person resolving ambiguity. "Buy the breakout" leaves open which price defines a breakout, when it is observed, what happens if the feed is late and whether the order should cross the spread. Two developers can implement the same sentence and produce different positions, turnover and risk.
The job is not to make the prose more elegant. It is to expose those choices, then test that the code follows them.
A strategy is not an instruction
Descriptions are useful for communicating intent. They are poor substitutes for a specification. Terms such as "trend", "liquid", "close" and "small position" compress decisions that affect signal generation and order placement.
Take "buy when the 20-day average crosses above the 50-day average". A reproducible rule still needs to say:
- Whether averages use closes, adjusted closes or another price field.
- Whether the cross is evaluated at the completed daily bar or intraday.
- What "crosses" means, for example, yesterday's 20-day average was at or below the 50-day average and today's is above it.
- When the order may first be submitted, and which price is available at that point.
If the signal uses a bar's final close, an order filled at that same close in a backtest may use information that was not available before the close. A live agent cannot act on a value it has not received.
Define the observation time and earliest eligible execution separately. Then check that the backtest uses the same sequence.
This distinction also matters in a multi-asset strategy. An exchange holiday, a delayed close or a missing bar can shift the apparent order of events. Prose rarely records those calendar rules. A trading system has to.
Name the assumptions the prose hides
List every noun and adjective that can change behaviour. "Liquid stocks" needs a universe and a measurable liquidity test.
"Avoid expensive trades" needs a cost estimate and a threshold. "Rebalance monthly" needs a calendar, a time and a policy for missed sessions.
Write the strategy as a set of decisions, not only as a formula. For example, define the eligible universe at each rebalance, whether symbols can enter or leave during the month, and what happens to an open position when a symbol becomes ineligible.
A universe built from today's constituents can quietly omit delisted securities in a historical test. That changes the evidence, even if the signal code is correct.
Make data rules explicit too. Record the source, timestamp convention, timezone, adjustment policy and treatment of corrections.
Decide whether late or duplicated events are ignored, replayed or treated as a fault. For indicators, define warm-up length and whether missing values pause the signal or invalidate the instrument. "Use clean data" does not specify any of these behaviours.
A compact specification should distinguish:
- Signal: the condition that creates an intention to trade.
- Portfolio rule: the position size, exposure limit and priority when several signals compete.
- Execution rule: the order type, price limit, time in force and handling of partial fills.
- Operational rule: the response to stale data, rejected orders, disconnects and restarts.
These rules belong in version control alongside the code. A prose change such as "use the latest complete bar" can alter fills and exposure. It should be reviewed as a behaviour change, not treated as copy editing.
Specify signal timing and data
Turn every signal into an event with an input timestamp, a calculation time and an action window. If the rule needs the completed five-minute bar ending at 10:00:00, specify whether the feed's bar is considered complete at 10:00:00, after a short grace period, or only when the provider marks it final. Include a maximum acceptable lag, such as two seconds for a liquid intraday feed, if that suits the system's operating conditions.
Then set a deterministic rule for late data. One conservative pattern is to reject a signal if any required input is older than the configured limit, record the reason and wait for the next valid event. Another is to recompute within a defined window. Recomputing after an order has already been placed can reverse the signal or create duplicates, so define whether existing orders are cancelled, amended or left unchanged.
Test the boundary conditions, not just ordinary bars. Include market open and close, daylight-saving changes, holidays, half sessions, halts, missing bars and corrected prices.
Verify that indicators reset or retain state as intended after a process restart. If the strategy uses rolling state, persist enough input history or state to reproduce the same decision after recovery.
For each signal, log the input values, their timestamps, the rule version and the resulting decision. A log that says "buy signal" is not enough to reconstruct why an order was submitted. A log that records the two averages, the comparison and the bar timestamp makes mismatches diagnosable without relying on an operator's memory.
Translate intent into orders and costs
"Enter at market" and "place a limit near the price" are not executable specifications. Set an order type, a limit-price formula, a time in force, a maximum order size and a policy for amend or cancel.
State whether a partially filled order remains active and for how long. For a limit order, say whether the limit follows the signal price, the current quote or a fixed offset, and when it expires.
Cost assumptions need the same care. These are typical market ranges, not quotes or audited results for any provider.
They vary by instrument, venue, order size, time of day and account terms. Use instrument-specific observations when available, and stress the model beyond the expected range.
| Cost component | Typical market range | Where it enters the rule |
|---|---|---|
| Spread crossing, liquid equities | About 1-10 basis points one-way | Marketable orders and aggressive limits |
| Major FX spread at liquid hours | About 0.1-1.5 pips | Entry and exit price assumptions |
| Commissions | $0-$5 per equity order, or $0.25-$5 per futures contract per side | Every fill, including partial fills where charged |
| Slippage on a small, liquid order | About 0-5 basis points per order; thin markets or larger orders can reach 5-25+ basis points | Fill price relative to the decision price |
| Overnight financing or borrow | Often 0-10%+ annualised, depending on rates and availability | Positions held across financing periods |
These numbers are planning ranges, not universal defaults. A strategy that trades small quantities during liquid hours may be dominated by commissions and spread. A larger order can face market impact that grows with participation rate. Estimate cost per order and per unit of turnover, then compare it with the expected edge. If a small increase in spread or slippage removes the edge, the specification should say when the agent skips the trade.
Platform capability affects whether those rules can be enforced. The Agentic Trading Index can help developers check platform features such as order types and API access, but the strategy still needs its own tests for behaviour under the chosen account and venue.
Write the failure path before the happy path
An unattended agent needs rules for bad states, not just the intended trade. Define what happens if an order request times out after reaching the broker, if an acknowledgement arrives late, or if a reconnect reveals a position that local state did not expect. A retry must not assume that a timeout means the order was not accepted. Reconcile open orders and positions before sending another instruction.
Use explicit states such as intended, submitted, acknowledged, partially filled, filled, cancelled and rejected. Specify which transitions are legal and which events trigger reconciliation.
Persist the broker order identifier and the strategy's own stable intent identifier. Where the API supports client order identifiers, use them consistently and check the platform's duplicate handling rather than assuming it.
Set operational limits in terms the process can measure: maximum position, maximum gross exposure, maximum order quantity, maximum daily loss and maximum age of market data. Specify the action for each breach. It may be to block new orders, cancel working orders, reduce exposure or stop the strategy.
These choices have different risks. Cancelling an entry order is not the same as flattening a position, and a failed cancel does not mean the order is gone.
Run failure tests with realistic timing: duplicate event delivery, delayed acknowledgements, partial fills, rejected amendments, rate limits and network loss during submission. Measure whether the agent returns to a reconciled state, not merely whether it retries. Keep enough logs and alerts for an operator to determine the position, working orders and reason for the last action.
Run this week's translation checklist
Choose one strategy and one instrument. Keep the first pass narrow enough to finish, then record the rule version and the person responsible for each unresolved decision. Run these steps before enabling unattended orders:
- Rewrite the idea as conditions. State the universe, inputs, comparisons and thresholds. Replace "strong", "near" and "soon" with measurable definitions or remove them.
- Pin down the clock. Record timezone, session calendar, bar completion rule, signal timestamp and earliest permitted order time. Check daylight-saving transitions and half sessions.
- Audit the data path. Test missing, stale, duplicated and corrected data. Set a maximum age and log the exact values and timestamps used in each decision.
- Specify sizing. Write the formula, rounding rule, minimum quantity, maximum quantity and exposure cap. Decide what happens when several instruments signal at once and available capital is insufficient.
- Define the order. Choose order type, price formula, time in force, expiry, amend policy and partial-fill behaviour. State when an order is cancelled and what happens if cancellation is not confirmed.
- Add realistic costs. Include spread, commissions, slippage, financing and borrow where relevant. Run a base case and a stressed case, then identify the cost level at which the expected edge disappears.
- Test state transitions. Simulate timeout after submission, duplicate messages, partial fills, rejection and restart. Confirm the agent reconciles broker positions and open orders before it acts again.
- Set trip conditions. Put numeric limits on exposure, order size, loss and data age. For each limit, define whether the system blocks, cancels, reduces or stops, including what it does if that action fails.
- Compare prose with traces. Replay a small set of ordinary and boundary cases. For each one, compare the expected decision with the logged inputs, order request, acknowledgement and final position.
- Review one change at a time. Version the prose, configuration and code together. Change one ambiguous rule, rerun the cases and keep the resulting traces for regression tests.
Do not use a successful replay as proof that every case is covered. It shows only that the chosen inputs produced the expected path. Keep the unresolved assumptions visible, and do not allow an undocumented default to determine live behaviour.
The mistake most readers will still make is treating a clear-sounding sentence as a complete executable rule.
Frequently Asked Questions
How do I turn a trading strategy description into code?
Separate the strategy into signal, portfolio, execution and operational rules. Specify inputs, timestamps, thresholds, sizing, order behaviour and failure handling, then test each rule against recorded events.
What details are missing from a plain-language trading strategy?
Descriptions often omit data timing, universe membership, order types, partial fills, costs and recovery behaviour. Each omission can change the position or fill, so define measurable defaults before unattended trading.
How should I test an automated strategy before live orders?
Replay ordinary and boundary cases, including stale data, partial fills, rejected orders, delayed acknowledgements and restarts. Compare the logged inputs and order events with the written rules, then repeat after each specification change.
