How to specify risk controls for a trading bot

“Manage risk” is too broad for a software specification. A developer needs to know what to measure, when to block an action and how to record the decision. Start by describing what should happen before an entry, after execution and when the platform restarts.

Define filters before the bot sends an order

For a spread filter, document the unit, threshold and when the measurement is taken. A threshold in points is not necessarily equivalent to the same number in pips. State whether the bot should discard a blocked signal or reevaluate it within a defined window.

For exposure limits, clarify whether the scope covers positions opened by this EA, all positions on a symbol or the entire account. If calculated volume falls outside the broker’s minimum or volume increment, agree on whether to skip the trade or round in a specific way.

Separate trade execution from internal state

Submitting a request does not guarantee execution. The software needs to distinguish trade intent from confirmed execution and record what happened. If retries are allowed, define which errors qualify and how to avoid repeating an already executed trade.

If the program restarts, define how it identifies its positions and which state it must recover. Testing a restart while a position is open can reveal problems that a continuous backtest would miss.

Turn each rule into an acceptance case

1. A valid signal with excessive spread → log the reason and skip the order.
2. A valid signal at maximum exposure → block the new entry.
3. A rejected order → record the return code and leave the position unopened in the bot’s state.
4. A restart with a recognized open position → resume monitoring without opening a duplicate.

Write the expected result before running the test. Save the symbol, data, inputs and program version so you can reproduce it. Consult the MQL5 trade server return codes to distinguish server responses.