Nearly every setup of this kind starts with a sentence like this: buy when the 20-day moving average crosses above the 50-day average, then sell when it crosses back. It sounds precise. A person can fill in the missing details from habit. An unattended programme cannot, and different choices can produce different trades.
The job is not to make the sentence sound more technical. It is to preserve the intended behaviour as explicit rules, including what the agent does when the market, data feed or broker does not behave as expected.
What the strategy sentence leaves undefined
Take the moving-average example. Does a cross count when prices touch during a bar, or only after the bar closes?
Are averages calculated from adjusted close prices, raw prices or another field? Does the system check once per day, once per minute, or on every update? Each answer changes the signal and its timing.
Set the data contract
Write down the instrument universe, bar interval, time zone, session calendar and price field. Define how the system handles missing bars, duplicate updates, corporate actions and late data. A 20-period average over daily bars is not necessarily a 20-calendar-day average. State whether a signal may use a partial bar, because using it can make a backtest appear to enter earlier than a live system can.
A useful data specification includes:
- Instrument identifiers and rules for adding or removing symbols.
- Bar construction, including interval, session boundaries and timestamp convention.
- Warm-up history, so indicators do not run on incomplete inputs.
- Stale-data thresholds and the action to take when a feed stops updating.
Define the signal as a state change
A cross is an event, not a permanent condition. If the fast average stays above the slow average for three days, the agent should not submit a fresh buy order every day.
Define the transition, for example: previous completed bar had the fast average at or below the slow average, and the latest completed bar has it above. Then specify whether a signal can fire again after a restart, or only after a new cross.
Keep signal state separate from position state. A buy signal while already long may mean do nothing, add units, or rebalance to a target.
Those are different policies. Make the desired behaviour testable with examples of inputs and expected actions, including equality at the boundary and missing observations.
Convert intent into an order policy
Specify size, exposure and limits
"Buy" does not define quantity. A strategy may buy a fixed number of shares, a fixed cash amount, or a fraction of equity. For a target-weight strategy, state how the agent calculates equity, whether it includes unrealised profit and open orders, and how it rounds to the venue's lot size.
Also set a maximum position, gross exposure and order value. A 5% target weight can exceed a 5% limit after a price gap unless the system checks actual exposure before submitting.
Write down what happens if buying power is insufficient, the target is smaller than the minimum order, or a position already exists. If the strategy can short, specify borrow availability and the response to a locate or margin rejection. Never rely on an unstated default from a broker library.
Describe order handling, not just order intent
Choose an order type and give it a lifecycle. For example, submit a limit order at the signal price, wait two minutes, cancel any remainder, then either reprice once or abandon the trade.
Say whether the agent may cross the spread, how many replacements it can make, and when a partially filled order counts toward the target. Set a maximum time to live and a price collar to prevent an old signal from becoming an unexpectedly expensive fill.
The figures below are illustrative typical ranges for liquid instruments and modest order sizes. Actual costs and timing vary by venue, broker, market conditions and order size.
| Decision | Plain-language gap | Executable definition | Typical ranges |
|---|---|---|---|
| Signal cadence | When the cross is checked | Evaluate on completed bars in the named session | 1 minute to 1 day |
| API submission delay | How quickly an order follows the signal | Measure from signal timestamp to broker acknowledgement | About 0.1 to 2 seconds for many API workflows |
| Quoted spread | What crossing a market order may cost | Record bid-ask spread at decision and submission | About 1 to 5 basis points in liquid instruments during regular hours |
| Slippage | Difference between reference price and fill | Compare fills with the defined signal or arrival price | About 1 to 10 basis points for modest orders in liquid conditions |
These are planning ranges, not guarantees. Include fees, spread, slippage and market impact in the strategy's expected return. A backtest that buys at the bar close but assumes a fill at that same close may be using a price the live system could not obtain.
Test the missing decisions before live orders
Tests should check the rule and the operational path. Begin with deterministic examples: a cross at the boundary, an unchanged signal after restart, a late bar, a rejected order and a partial fill. Then run historical tests with the same data definitions and order policy intended for live use. Compare results with a paper environment that returns realistic order states and timing. An agentic paper-trading environment can help exercise those paths without sending live orders.
For each test run, inspect more than net profit. Record:
- Signals generated, including their input timestamps and values.
- Orders submitted, changed, cancelled, rejected and filled, with quantities and prices.
- Position and cash after every fill, reconciled against the agent's internal state.
- Fees, spread and slippage assumptions, plus the result when those costs worsen.
Set acceptable behaviour before testing. For example, a strategy might require zero duplicate orders after a restart, no new orders on stale data, and a daily turnover limit. These are implementation choices, not universal market standards. Choose thresholds that fit the instrument, frequency and risk budget, then test the system's response when each limit is reached.
Keep the human description, but give the agent a contract
Plain language remains useful for explaining why a strategy exists and for reviewing whether its rules still reflect the intended idea. It is a poor substitute for a specification. Keep the concise description beside a versioned rule set that defines inputs, signal timing, sizing, order handling, limits and recovery behaviour. When the rules change, record the change and rerun the same tests so that an apparently small wording change does not silently alter live behaviour.
This advice does not apply unchanged to discretionary strategies whose signal depends on judgement that cannot be represented as stable, testable inputs; those require a human decision process or a different model of the decision.
Frequently Asked Questions
How do I turn a trading strategy description into code?
Define the data inputs, signal conditions, timing, position sizing and order lifecycle separately. Add examples of inputs and expected actions, including boundary cases, so the implementation can be tested against the intended behaviour.
Why can the same trading rule produce different results?
The rule may leave open details such as bar timing, price adjustments, order type or sizing. Different choices affect signal timestamps, fills and exposure, even when the high-level idea is unchanged.
What should I test before letting a trading agent place orders?
Test signal calculations, restarts, stale data, rejected orders, partial fills and position reconciliation. Track actual order states and costs, not only whether the strategy generated a profitable signal.
Should an automated strategy use market or limit orders?
There is no universal choice. Market orders prioritise execution but can pay a wider spread or suffer slippage; limit orders control price but may not fill. Specify how the agent handles unfilled quantities and test that policy under realistic conditions.
