Trading strategy description: plain words, missing rules

Week one versus week six

In week one, a developer can often turn a strategy into a working demo from a short description: buy a breakout, use a stop, risk 1% per trade. By week six, the unattended agent may have met a gap at the session boundary, received a partial fill, or retried an order after a timeout. The description did not say what to do in any of those cases.

That gap is not a writing flaw. A sentence is a compact summary of intent, while an order system needs decisions at every transition. It must know what counts as a breakout, which price is tested, when the signal expires, how size is calculated and what to do if the broker accepts an order but the acknowledgement is lost.

For software that places orders without a human watching, the useful question is not whether a person can understand the strategy. It is whether two independent implementations would make the same decision from the same market data and account state. Plain language is a good starting point. It is not a complete trading contract.

The approaches below trade ease of communication against precision and implementation effort. Most production systems need more than one: a readable explanation for people, plus structured rules that the agent can test and enforce.

Four ways to express one strategy

Take a simple example: buy a five-minute breakout above the previous 20 bars, use a stop, and risk 0.5% of account equity. A narrative explains the idea quickly.

A checklist can prevent common omissions. A decision table makes boundary cases visible. An executable specification makes the rules testable in code. Each approach leaves a different amount of interpretation to the implementer.

The figures below are typical planning ranges for a small strategy on one instrument family, not an industry survey or audited benchmark. The scenario count assumes a review of 20 representative cases, including boundary values, stale data and broker responses. Time estimates cover initial authoring and review, not the full trading system.

A checklist is quick to review but can still contain vague items such as "use a sensible stop". A decision table forces explicit outcomes for defined conditions, but grows awkward when many conditions interact.

Executable rules are precise only to the extent that the inputs and state have been defined correctly. A hybrid keeps the rationale readable and attaches testable rules to it.

For a platform review, separate strategy logic from broker constraints such as supported order types, tick sizes and session rules. A resource such as FX Tech can sit alongside that platform-side evaluation, but it cannot resolve an omitted strategy rule.

What plain language leaves out

Words such as "breakout", "near", "quickly" and "risk 1%" compress several choices into one phrase. A person may fill those gaps from context. An agent has to get them from code, configuration or an explicit default. Hidden defaults become accidental strategy changes when code is revised or moved to another broker.

For the breakout example, "above the previous 20 bars" needs a bar definition. Does the agent compare the last traded price with the high of 20 completed bars, or include the current unfinished bar?

Does a touch count, or must price exceed the level by one tick? Does a signal at 16:59 remain valid through an overnight session? The answer changes both signals and fills.

"Risk 0.5%" also needs a calculation. It could mean equity at the start of the day, current net liquidation value, or available capital.

Position size needs the entry estimate, stop distance, contract multiplier, currency conversion and lot rounding. A nominal risk limit does not guarantee the realised loss stays within that limit when prices gap or a stop fills poorly.

Before translating a description, make these decisions explicit:

• Signal: instrument, venue, timeframe, input field, bar completion rule, timezone and signal expiry.
• Entry: order type, limit price formula, time in force, permitted slippage and handling of a rejected or unfilled order.
• Size: equity source, risk fraction, stop distance, contract value, rounding method and maximum quantity or notional.
• Exit: stop trigger source, profit target, time-based exit, session handling and priority when exit conditions coincide.
• State: maximum open positions, treatment of partial fills, duplicate signals, pending orders and restart recovery.

Each item can alter actual exposure. For example, sizing from the stop distance before applying a 0.1-lot minimum may leave a small account taking more risk than intended.

Rounding down, rejecting the trade or scaling the stop are different policies. The agent should not choose among them implicitly.

Turn the description into an executable contract

Start by writing the strategy in ordinary language, then annotate every term that could produce two valid interpretations. Convert each annotation into a field, a formula or a stated exclusion. A structured configuration might define timeframe as five-minute bars, signal calculation on completed bars only, breakout threshold as prior 20-bar high plus one tick, and signal validity as the next bar only.

Then specify the order lifecycle. A signal can create an order intent, but an intent is not a position. The agent must distinguish new, submitted, acknowledged, partially filled, filled, cancelled, rejected and unknown states. If a network timeout occurs after submission, query the broker or reconcile open orders before resubmitting. Otherwise, a retry can create duplicate exposure.

Define units at the interface. Price may be quoted in points, currency or ticks. Quantity may mean shares, contracts or lots. A stop may trigger on last trade, bid, ask or mark price.

Include the expected precision and rounding behaviour for each field. These details are especially important when moving between instruments or broker APIs.

Build a decision table for cases where more than one rule might apply. For example: if an entry signal arrives while an exit order is pending, does the agent ignore the signal, cancel the exit or wait for reconciliation?

If the broker reports a partial fill and the remaining quantity is rejected, does the agent keep the filled position and attach protection? The table should specify the state transition and the action, not merely name the condition.

Use tests to make the contract durable. A useful suite includes ordinary examples, exact threshold values, one-tick-below and one-tick-above cases, missing or stale bars, market-session transitions, partial fills, rejections and restart recovery. Tests should assert orders and state changes, not just whether a signal function returned true. Paper environments can help exercise the plumbing, but their fill and rejection behaviour may not match a live venue.

Choose the level of detail by failure cost

Not every phrase needs a large formal model. Focus precision on decisions that change exposure, order validity or recovery after failure. A display label can remain descriptive. A maximum position, stop trigger or retry policy cannot. The higher the cost of an unintended order, the less room there should be for interpretation.

Before unattended release, review a small set of measurable controls:

• Confirm that every signal records its input timestamp, calculation version and reason for firing.
• Check that requested size respects configured quantity, notional and account-level limits after rounding.
• Verify that duplicate intents remain idempotent across timeouts, process restarts and repeated market events.
• Exercise partial-fill, reject, cancel and unknown-order paths using recorded broker responses or a suitable simulation.
• Alert on stale market data, unresolved order state, position mismatch and risk-limit breaches.
• Keep a kill condition for loss, exposure or system-integrity limits, with a defined response such as cancel open orders and block new entries.

Compare the implemented decision with the human-readable description after every material change. A rule may be precise in code and still contradict the intended strategy.

Version the specification alongside code and test data; retain the inputs and broker events needed to reconstruct a disputed order. That makes a live discrepancy diagnosable rather than a debate about what "quickly" meant.

The right format depends on the cost of ambiguity, not on a preference for prose or formal methods. A short narrative can be enough for an exploratory prototype that only emits trade proposals for approval. This advice does not apply unchanged to that case: when a human reviews every order and the strategy is still being explored, a full executable contract may add more maintenance than control.

#strategy specification #order management #automated trading rules #broker API #trading agent execution #algorithmic trading #risk limits #strategy testing