What are Fibonacci Pivots, and what exactly do you backtest?
Fibonacci Pivots are a set of price levels derived from a reference range (for example, a prior period’s high, low, and close) and then mapped to fractions using Fibonacci ratios. Backtesting responsibly starts with separating two ideas:
- The stable mechanics: the formula that turns input prices into pivot levels.
- The variable context: how markets behave, what costs apply, and how trades (if you simulate them) are executed.
To backtest responsibly, you must state what you are testing. Common options are testing whether price reacts to the levels (e.g., touch or rejection behavior) versus testing a decision rule (e.g., entries/exits based on those levels). Even if you avoid trade recommendations, any “decision rule” is still a strategy, so your evaluation must match the exact rule you simulate.
Mechanics: define inputs, assumptions, and the backtest dataset
A responsible backtest begins by writing down the inputs and assumptions in plain terms.
- Reference prices: specify which data points define the range (e.g., prior period high/low/close) and from which session boundaries you take them.
- Time alignment: ensure every computed pivot level would have been known at the decision time. This avoids look-ahead bias, where future information accidentally leaks into earlier calculations.
- Frequency: define whether pivots are computed per day, per week, or another period, and what bar size (or tick aggregation) you evaluate against.
- Slippage and spreads (costs): if you simulate execution, you need a cost model. Otherwise, results may only reflect idealized fills.
- Rules for events: clarify how you detect a “hit.” For example, if price crosses a level during a bar, do you treat it as touched? The detection method changes outcomes.
At this stage, costs and “event detection” are part of the mechanics you test. Treat them as assumptions you can audit and modify.
Evidence: use bias controls and out-of-sample checks
Historical patterns do not establish future results, so your evaluation should focus on robustness.
Key controls:
- Look-ahead bias checks: recompute pivots using only data available at the decision time and verify your pipeline enforces that ordering.
- Parameter sensitivity: if you allow choices like which ratios to include or how to handle multiple touches, test whether performance depends on a specific fine-tuned configuration.
- Out-of-sample validation: split the dataset into training (for setting assumptions or selecting a rule) and testing (for evaluation). After choosing parameters on training, lock them and only assess on test.
- Regime coverage: verify results across different volatility and trend environments. A method that works only in one regime is easier to overfit.
A practical way to keep this credible is to record every assumption used to produce the results: pivot computation method, session boundaries, event rules, cost model, and selection criteria.
Limitations and risks: at least one failure mode to expect
Responsible backtesting also requires stating what could break the conclusions. Material failure modes include:
- Data and alignment errors: small mistakes in time zones, session cutoffs, or bar construction can shift computed levels and produce misleading “hits.”
- Hidden costs and execution mismatch: spreads, slippage, and partial fills can materially change realized outcomes versus paper levels.
- Overfitting to history: if you repeatedly tweak inputs to improve historical results, you may build a rule that explains past data but fails elsewhere.
- Market regime changes: relationships between price and pivot levels can vary when volatility, liquidity, or participant behavior changes.
Even when the computation itself is correct, these limitations can make backtest conclusions unstable.
Verification and next question to ask
To independently verify claims, you should be able to answer these checks without relying on other people’s results:
- Can you reproduce the pivot levels from the specified reference prices and session boundaries?
- Does your testing avoid look-ahead (every computed value must be available at the decision time)?
- Does your evaluation include a transparent cost model and realistic event detection?
- Are results consistent in an out-of-sample period, and do they persist across multiple regimes?
If you can do these steps, you are testing the method’s behavior rather than accidentally validating assumptions.