How to define an AI trading strategy: rules and risk

Write the specification before the code

To describe a trading strategy to AI, define the market, data, exact entry and exit conditions, position-sizing method and halt rules. Ask it to identify gaps and ask questions first. Generated text or code does not establish correctness or demonstrate profitability.

“Create a profitable robot” does not define testable behavior. A useful first output is a document that lets you decide unambiguously whether to open a position, close it or do nothing. Binance Academy’s backtesting guide also connects systematic testing with predefined rules.

Questions the prompt needs to resolve

Market and data

Specify the pair, venue and market type. Spot trading and a perpetual contract are different tasks. Define the timeframe, time zone, price series and treatment of missing data. For an indicator, record its formula or exact name, parameters and required history.

Decide separately whether intrabar data is available. When the logic uses closed candles only, AI should not silently introduce decisions based on an unfinished candle. Terms such as “price,” “volume” and “signal” need one consistent meaning throughout the specification.

Entry and exit

Replace subjective phrases with explicit conditions. Instead of “strong growth,” define the quantities being compared and when they are checked. Distinguish the state “above a level” from the event “crossed a level.” Decide whether the same signal permits re-entry and what happens when several exit conditions occur together.

Give conditions an explicit priority. For example, a specification might check restrictions on new positions first, exit eligibility second and entry third. That illustrates a requirements structure, not a universal order for every trading system. Your specification needs to resolve conflicting actions explicitly.

Position size and limits

Separate position value from planned risk. In an educational example, a position worth 1,000 USDT with a stop distance of 2% has a calculated value change of 20 USDT before costs at that level. This unleveraged arithmetic example does not guarantee execution at the stop price or establish an appropriate risk level for the reader.

Define maximum simultaneous positions, total exposure limits, pause conditions and the restart procedure. State whether open positions count toward each limit. Do not let the model silently increase size after a loss or introduce leverage to improve a report.

An implementation also needs venue-specific constraints. For example, Binance Spot API documentation defines quantity-step and minimum-order-value filters. The existence of that documentation does not mean a particular tool already implements those constraints.

An educational AI prompt template

This template describes and tests behavior. Its parameters are hypothetical; it is not a recommendation to trade this way.

1. “Help me write a spot strategy specification for an educational BTC/USDT simulation. Do not send real orders.”
2. “Use closed hourly candles. First clarify the source, time zone, missing data and indicator warm-up rules.”
3. “The idea is to enter when a fast moving average crosses above a slow one. Ask which average types and periods to use; do not choose them yourself.”
4. “Define a crossover using two consecutive closed candles. State when execution is simulated after the signal.”
5. “Ask for exit rules, size, position limits, expenses and halt conditions. Prohibit leverage and increasing size after losses in this educational version.”
6. “Return a rule table, unresolved questions and test scenarios. Do not write executable code yet.”

After answering, save the specification as a separate version. Ask AI to list every assumption it made. If it selected a value itself, confirm or change it before calculating results. Avoid combining several changes in one version: that makes differences harder to explain.

What to check before historical testing

Prepare small scenarios whose expected answers can be worked out manually:

• insufficient data for the indicator;
• equal moving-average values without a crossover;
• a repeated signal while a position is already open;
• a missing or duplicate candle;
• a stop and another exit condition occurring together;
• a calculated quantity below the permitted minimum;
• delayed data arriving after a pause.

Record inputs, expected action and reason for each scenario. If two implementations disagree, clarify the rule first. Fixing code without resolving an ambiguous requirement can leave the underlying error hidden.

Pay particular attention to when information becomes available. TradingView’s explanation of look-ahead bias shows how using information that was not yet known distorts historical results. An attractive chart cannot substitute for this check.

What counts as a useful result

The first result is a clear set of rules, open questions, limitations and testing scenarios. Next, examine the backtesting method and the differences between historical, paper and live trading. A promise of guaranteed profit is not a specification acceptance criterion.

Keep a short acceptance checklist with the specification: every action has a reason, every limit has a calculation method, and every skipped signal can be explained from the log. Revisit it after any rule change. Explore the path from an idea to rules and testing in Clerix.