Define the indicator concept before measuring it
Schaff Trend Cycle (often shortened to STC) is a trend-following indicator that converts price movement into a bounded oscillator-style series. A responsible backtest starts by separating stable mechanics from variable conditions:
- Stable mechanics: how the indicator is computed from its inputs (moving averages, smoothing, and any oscillator mapping).
- Variable conditions: the market period, the price source, the execution method, and the trading environment.
Even if you only care about the indicator, backtesting still needs a precise definition of what counts as an “outcome.” For example, you might evaluate whether a particular STC level or direction change aligns with subsequent price movement. That choice must be stated upfront, because different evaluation rules can produce different results.
Set up data assumptions and cost assumptions explicitly
A careful backtest depends on the data pipeline. State these assumptions before any calculations:
- Price data: what series you use (e.g., bid/ask vs mid/last) and how missing timestamps are handled.
- Time alignment: whether indicator values at time t are computed using only information available at t.
- Resampling: whether you use native time bars or resample, and how boundaries are aligned.
Costs matter because indicator-based evaluations can look profitable when costs are ignored. Use explicit assumptions for:
- Transaction costs: commission, spreads, or both (expressed consistently with your chosen price series).
- Slippage: how execution price deviates from the reference price used for the backtest.
- Latency: whether you assume fills at the next bar open, close, or another rule.
To control uncertainty, run the same backtest under multiple plausible cost scenarios (e.g., low/medium/high slippage). If the conclusions change dramatically, that is a warning sign about robustness.
Control bias with out-of-sample testing and parameter stability checks
A common failure mode in indicator backtests is overfitting: tuning parameters and selection rules until the historical period looks good, without guaranteeing performance elsewhere. You can reduce this by separating workflow stages:
- Define once: decide the evaluation rule (what event triggers the metric) and the parameter set boundaries before looking at results.
- Tune with a training window: if you adjust any parameters, do it only on a training segment.
- Validate out-of-sample: test the chosen configuration on later data that was not used for tuning.
- Repeat with multiple splits: use several rolling or walk-forward segments to reduce the chance that results come from one lucky period.
A practical bias control is parameter stability: verify that small parameter changes do not flip the conclusion. For instance, if results depend on a narrow parameter range, the relationship is likely unstable.
Evaluate at least one material limitation or failure mode
Historical backtest success does not establish future results. Treat performance metrics as conditional on regime and execution assumptions. At minimum, test one material failure mode, such as:
- Regime shift: trend indicators often behave differently in range-bound periods than in sustained trends.
- Indicator delay: smoothing can cause late responses; evaluate whether the evaluation rule measures outcomes after the indicator’s informational lag.
- Sensitivity to costs/execution: if the indicator only “works” after removing spreads or assuming unrealistic fills, the conclusion is fragile.
Also check for data leakage: ensure your indicator values are computed using only data available at the decision time. Leakage can make oscillator backtests appear accurate even when the mechanics would not have been available live.
Verification and the next question you should ask
A responsible verification process answers two questions independently:
- Reproducibility: Can you rerun the backtest with the same data definitions and get the same results?
- External validity: Do the conclusions persist across different out-of-sample windows and cost scenarios?
As a next step, clarify your evaluation rule and metrics. For example, decide whether you are measuring direction alignment, event-based timing accuracy, or the profitability of a hypothetical rule. Then repeat the out-of-sample process after changing only one element at a time. If outcomes only hold under one narrow setup, your conclusion should be phrased as “conditional on assumptions,” not as a general promise.
Linking the concept page can also help you keep the computation and the test rule consistent.