Define what TSI is before you test it
TSI (commonly used as a momentum-type indicator) is a rule that converts a time series into an output by combining price-change information across one or more lookback settings. Backtesting is then the process of applying those rules to historical data to measure how the resulting indicator behavior would have looked.
A responsible starting point is separating two layers:
- The stable mechanics: how TSI is computed from the selected input series and parameters.
- The variable conditions: the market regime, the data quality, and the way results would translate into real execution.
Only after you are clear on both layers should you discuss implications.
Choose data inputs and assumptions you can explain
Backtests only mean something if the inputs match the intended use. For TSI, define these choices explicitly:
- Price series: what field is used (for example, mid-price vs bid/ask). If you cannot justify a choice, treat it as an assumption.
- Time handling: bar size, session rollovers, and alignment (for example, ensuring that indicator values only use information available at that time).
- Parameter settings: the exact lookback lengths and any smoothing steps.
- Data cleaning: how missing bars are handled, and whether outliers are corrected or removed.
If any part of your setup is ambiguous, document it and keep it consistent across all test runs. This makes your results independently verifiable.
Include costs and execution effects in the backtest model
Historical price movements are not the same as tradable outcomes. Even if you are not generating trade signals, your evaluation should still reflect that implementation has frictions.
Common modeling gaps include:
- Transaction costs: spreads, commissions, and fees.
- Execution delay: acting at the close of a bar while using the close price can be unrealistic.
- Slippage: the difference between expected and achieved prices.
A responsible backtest therefore uses explicit assumptions for these elements. Example approach (assumptions must be stated): use a constant cost per round-trip or a simple spread model, and apply it consistently whenever your backtest logic changes state (for instance, whenever an indicator condition changes). Avoid tuning costs until performance “looks right.”
Control bias and overfitting
Many backtesting failures come from bias rather than indicator design. Responsible testing includes controls that prevent you from “learning the future”:
- Pre-register the parameter search space: decide the ranges for TSI settings before running optimization.
- Use walk-forward (rolling) testing: select parameters on one period and evaluate on the next unseen period.
- Keep a final holdout: even if you iterate many times, set aside one segment that is not touched for model selection.
You should also test robustness by measuring sensitivity: if tiny changes in lookback settings drastically change results, the backtest is likely fragile.
Use out-of-sample checks that match the intended claim
A key principle: historical relationships do not establish future results. So your evaluation should focus on what can be supported by the design.
Practical, responsible checks include:
- Out-of-sample performance comparisons across multiple time windows.
- Stability across regimes: test in trending, ranging, and high-volatility vs low-volatility periods (defined by your own measurable criteria).
- Error bars and distribution checks: look at variability of outcomes rather than a single summary number.
If your purpose is to understand TSI behavior rather than to claim investability, you can still apply these checks to your metrics (for example, distribution of indicator values, persistence characteristics, or drawdown-like behavior under your chosen evaluation rule).
A material limitation: backtests can validate a pipeline, not the future
One common failure mode is confusing “the backtest ran correctly” with “the strategy would work.” Even with careful data handling and out-of-sample testing, responsible backtests can still be undermined by:
- Non-stationarity: market dynamics change over time.
- Hidden implementation differences: your assumed costs, execution timing, and order handling may not match reality.
- Selection effects: extensive iteration can produce results that fit noise.
Therefore, the most defensible interpretation is usually about robustness of the tested behavior under defined assumptions, not about guaranteed outcomes.
What to verify next
If you want to backtest TSI responsibly, verify your setup step by step:
- Confirm the TSI calculation inputs and parameter definitions match your intended interpretation. 2. Confirm your timing assumptions (when information becomes available vs when it is acted on). 3.