Designing rule-based strategies: from idea to testable rules

“Buy strong stocks when the market is healthy” sounds like a strategy, but it is really a mood. Two people could code it in completely different ways and get completely different results. A rule-based strategy removes that ambiguity: given the same data, it always makes the same decision. That consistency is what makes it possible to test, review and improve.

Start with a hypothesis

Before writing any rules, state in plain language why the idea might work. Is there a behavioral tendency, a structural flow, or a risk premium behind it? Who is on the other side of the trade, and why would they accept it? A strategy with a clear rationale is easier to evaluate, and when it stops working you have a better chance of understanding why.

Equally important, write down what would convince you the idea is wrong. Deciding this in advance protects you from explaining away every disappointing result.

The components of a complete specification

• Universe: which instruments are eligible, and how that list is chosen at each point in time.
• Data: which fields, at which frequency, adjusted or unadjusted.
• Entry rules: the exact conditions that open a position.
• Exit rules: the conditions that close it, including stops, targets or time limits.
• Position sizing: how much capital or risk each position receives.
• Risk limits: maximum exposure per instrument, per sector and in total.
• Execution assumptions: when signals are evaluated, which price is used, order types and cost estimates.

If any item is missing, the code will fill the gap with an implicit assumption, and implicit assumptions are where backtests go wrong.

Make timing explicit

The most important single line in many specifications is when a signal is evaluated and when it is acted upon. “Evaluated after the close, executed at the next session's open” is testable. “Buy when the price crosses the average” is not, because it does not say which price, which bar or which fill.

An example specification

Here is a simple, purely educational trend rule written as a spec:

1. Universe: a fixed list of liquid, broad-market ETFs.
2. Signal: after each close, the position is long if the close is above its 200-day simple moving average, otherwise flat.
3. Sizing: target 10% annualized volatility using a 20-day volatility estimate, capped at 100% of allocated capital.
4. Execution: trade at the next open, with an assumed cost per trade.
5. Review: no parameter changes during the test period.

Translated into code, each rule becomes a small, testable function:

import numpy as np
import pandas as pd

def trend_signal(close: pd.Series, lookback: int = 200) -> pd.Series:
    """1 when the close is above its simple moving average, else 0."""
    sma = close.rolling(lookback).mean()
    return (close > sma).astype(int)

def vol_target_weight(close: pd.Series, target_vol: float = 0.10,
                      window: int = 20, max_weight: float = 1.0) -> pd.Series:
    """Scale exposure so estimated annualized volatility is near target_vol."""
    ann_vol = close.pct_change().rolling(window).std() * np.sqrt(252)
    return (target_vol / ann_vol).clip(upper=max_weight)

close = prices["close"]  # one instrument's daily closes
weight = trend_signal(close) * vol_target_weight(close)
position = weight.shift(1)  # decided after the close, held from the next bar

Keeping signals, sizing and execution in separate functions makes each one easy to unit test and easy to swap out when you explore alternatives.

Keep the parameter count low

Every parameter is a dial that can be tuned to the past. A strategy with two or three meaningful parameters is far easier to validate than one with fifteen. When you do test parameters, look for broad regions where results are acceptable rather than a single best value.

Plan the test before you run it

Decide your in-sample and out-of-sample periods, cost assumptions and evaluation metrics before seeing any results. Include risk measures such as maximum drawdown and the number of trades, not just total return. Then run paper trading, which is simulated only, to see how the rules behave on new data without risking capital.

Version everything

Store the specification, the code and the results together, and record each change with the reason for it. Months later, being able to answer “what exactly did we test, and why did we change it?” is one of the most valuable habits in systematic research.

Rules do not make a strategy profitable. They make it testable, which is the first requirement for learning anything reliable about it.

Quantzivo Studio's strategy builder is being designed around exactly this kind of explicit specification. To practice the full process, explore the Algorithmic Trading with Python course.