The highest return in a settings table tells you which setting won that comparison. It does not tell you which setting will work next. When you try enough alternatives, the winner can capture quirks of the data as well as any useful pattern. That is the practical problem behind indicator overfitting.
This article uses a fictional parameter grid to examine the selection process. It offers no recommended RSI setting, measured crypto performance or trading signal. For the indicator itself, start with the RSI guide.
Define the rule before comparing settings
A parameter is a chosen input, such as an indicator's lookback length or a threshold used by a trading rule. A lookback of 14 refers to chart periods, not necessarily days. An RSI threshold is an indicator value, not a percentage probability of a reversal.
A setting alone is not a strategy. The exact trigger, when information becomes available, entry execution, exits, position size and costs all affect the result. Record the instrument, venue, timeframe, test dates and those rules before comparing alternatives. Otherwise a better-looking number may come from changing several assumptions at once.
The backtests and live results guide explains that distinction. Here the narrower question is how you chose the configuration shown in a report.
Read a fictional parameter grid
Imagine a worksheet comparing three RSI lookback lengths and three thresholds for the same otherwise-fixed rule. Every percentage below is invented for teaching; no strategy was run and no market data or trade log produced this grid. The cells represent hypothetical net account returns after assumed fees and slippage. They are neither RSI readings nor forecasts. The cost assumptions are held consistent across comparisons; this worksheet is not a complete backtest specification.
| Lookback | 25 | 30 | 35 |
|---|---|---|---|
| 10 | +1% | +2% | +1% |
| 14 | +2% | +9% | +2% |
| 18 | 0% | +3% | +1% |
The 14/30 combination wins this invented comparison. Holding lookback at 14 and moving the threshold to 25 or 35 changes the result from +9% to +2%. Holding threshold at 30 and changing lookback to 10 or 18 gives +2% or +3%. Those are sensitivity comparisons: change one input while keeping the other fixed.
The isolated peak is a reason to investigate, not proof of overfitting. Different trade counts, one unusual trade or a genuine threshold effect could produce a sharp change. The grid cannot distinguish them because it has no underlying trades. Equally, a broad region of similar results would not by itself prove a durable edge.
Count the search that produced the winner
Three lengths times three thresholds means 3 × 3 = 9 configurations. If you repeated that full grid on 10 markets and 4 timeframes, you would have 9 × 10 × 4 = 360 comparisons, before changing exits or test dates. These comparisons are not necessarily independent, so their count is not an overfitting probability.
A report showing only the best cell hides the search. Keep a record of all tried configurations, rejected variants and changed assumptions, including informal chart experiments. Selecting a winner after inspecting many results is different from specifying that one setting before seeing the data.
Bailey, Borwein, López de Prado and Zhu's research on backtest overfitting examines how searching configurations on finite data can select noise. It also explains why a holdout alone does not account for the full search. We do not calculate their probability measure here.
Keep validation out of the tuning loop
Development data are used to design and compare candidates. Validation data should test the frozen choice without further tuning. Decide the chronological split, selection rule, evaluation measures and rejection criteria before inspecting the validation results. Use only information that would have been available at each decision; overlapping trades or labels across the split can complicate separation.
Continue the fictional exercise: suppose 14/30 was selected on development data under a predeclared rule, then returns −2% in the untouched validation period. That result belongs in the record. Switching to another setting after seeing it, and calling the same period an independent test again, reuses validation as development.
A disappointing result does not prove the strategy is overfit; changing market conditions and sampling variation can also matter. Investigate, record any revision and reserve genuinely unseen data for a later assessment. Do not search until one revised version passes the same window.
TradingView's strategy documentation describes testing optimized parameters outside the optimization sample without further fine-tuning. That is a discipline, not a guarantee of future returns or a complete statistical correction for repeated trials.
Inspect the trades behind the headline
For an actual study, review the full trade record, sample size, drawdowns, turnover and cost sensitivity alongside the chosen objective. A small set of lucky fills can dominate a total. A neighboring setting may trade much more often and incur different total costs even when the same fee rate is used.
Keep execution assumptions explicit. Stop-and-target ordering within a candle can change a simulated outcome without any parameter change. Selection bias and execution ambiguity are different problems; fixing one does not fix the other.
Save a decision that can be checked later
Your review note should name the hypothesis, data boundaries, configurations tried, selection rule, frozen version, validation result and reasons to reject or continue research. Preserve the losing variants too. If the evidence is inadequate, “do not trade” is a valid decision.
The aim is not to find a setting that makes yesterday look perfect. It is to understand what evidence survives the choices made during research. Educational information, not financial advice; historical tests and careful validation cannot guarantee profits or prevent losses.
