Direct answer
Responsible backtesting of a Fibonacci Fan approach means treating it as a measurable method, not as a visual pattern. You define exactly how the Fan is constructed, what decisions are generated from it (if any), and which assumptions drive every calculation. Then you test across multiple market regimes using out-of-sample data, while modeling costs and execution details that can materially change results.
What is a Fibonacci Fan, and what exactly gets tested
A Fibonacci Fan is a set of price levels (often trend “fan” lines) created from a chosen anchor pair (such as a start and end swing) and a set of Fibonacci ratios. The key point for backtesting is that the Fan is not just “drawn”—it has inputs.
To test responsibly, write down:
- Anchor selection rule: how the start and end are chosen (for example, a swing high/low rule). If the rule is subjective, your backtest can be biased.
- Ratio set used: which Fibonacci ratios are included.
- Direction handling: how the method behaves in uptrends versus downtrends.
- Recalculation timing: whether the Fan is redrawn only once or updated as new bars arrive.
- Mapping to decisions: if you convert line interactions into actions, define that transformation explicitly (for instance, “when price touches a specific Fan line, mark an event”).
This separates stable mechanics (the geometry and mapping rules) from variable factors (market conditions, costs, and execution). Note that historical visuals do not automatically imply that the same construction will work under future conditions.
Evidence and examples: build a testable workflow
A practical backtesting workflow can be expressed in consistent steps:
- Create a dataset: use historical price bars you can reproduce (open/high/low/close and timestamps).
- Generate Fan instances: apply your anchor selection and Fan construction rule at the correct time.
- Define outcomes clearly: decide what you measure—commonly event-based metrics (e.g., returns after a touch) or performance metrics tied to a hypothetical execution rule.
- Model costs (kostensoorten): include at least the main friction categories relevant to your execution model, such as spread/transaction costs, slippage, and delays between signal time and execution time.
- Control assumptions (aannames): state assumptions for every non-obvious step—especially anything involving bar-by-bar timing or order placement.
- Track uncertainty (variabele factoren): compare results across different time windows and market regimes rather than one continuous history.
A simple example of an event-based test is: “When price first touches a selected Fan line after anchor creation, compute the forward return over a fixed horizon.” Even if you do not trade, this still requires explicit definitions for touch detection, horizon length, and timing.
Limitations and risks (including failure modes)
Even a careful backtest can fail or mislead. Material limitations include:
- Look-ahead bias: if the anchor selection or “touch” detection uses information that would not be known at the time the Fan is created, results are inflated.
- Overfitting: tuning ratios, line selection, or event rules to maximize past performance can produce fragile outcomes that do not generalize.
- Execution mismatch: ignoring slippage, spread widening, or order timing can materially change realized outcomes.
- Non-stationary markets: relationships between geometry and future movement can change with volatility regimes, liquidity, and broader market behavior.
- Selection bias from subjective anchors: if anchors are chosen visually, a backtest effectively measures your ability to redraw rather than the method.
Verification and next checks
To verify responsibly, use checks that reduce bias and measure stability:
- Out-of-sample testing: reserve later periods for evaluation after you finalize rules.
- Walk-forward validation: repeatedly fit/define the method on one window, then test on the next.
- Sensitivity analysis: vary non-critical parameters within reasonable bounds (for example, how you define “touch” within a small tolerance) to see if results collapse.
- Robust reporting: report not only averages but also dispersion across periods, because results can depend on a small number of favorable intervals.
If you want to validate further, consider comparing against a simple baseline (for example, measuring forward returns from random line selections built with the same procedure but without the “Fan logic”) to see whether your measured effect survives controls.