Development of an Automatic Fibonacci Levels System for Trading

Why manual Fibonacci levels break a trading strategy

Manual marking of Fibonacci levels rests on a single assumption: the trader manages to rebuild the grid before the price moves away from it. On a trending instrument, this assumption stops working.

Each new impulse shifts the significant extremum, the old grid loses its meaning, and the trader either redraws it after the fact of the move, or trades by levels that the market has already worked out.

The signal lag here is not an accident, but a property of the method: while the marking is updated by hand, the entry point shifts by dozens of points from the calculated one.

The most costly part is the choice of extrema. Two traders mark the same section of the chart differently: one takes the local minimum on the lower timeframe, another waits for confirmation on the higher one.

Formally, both are right, but the Fibonacci levels come out different, which means the signals for the same strategy do not match.

A strategy that cannot be repeated twice on the same history cannot be verified or scaled to several instruments — and ceases to be a strategy in the engineering sense.

Hence the third problem — reproducibility. Manual marking leaves no trace: there is no rule by which the extremum was chosen, no fixation of the moment of rebuilding, no way to prove that the signal existed rather than being recalled in hindsight.

Any attempt to evaluate such a system runs up against the fact that its behavior depends on the state and attention of a person at a particular minute.

We break down how this is closed: how to formalize the choice of extrema so that Fibonacci levels are built by a single rule, and how to remove the signal lag from the very logic of marking.

What an automatic level grid provides

Manual Fibonacci level marking scales poorly: while an analyst is repositioning the grid to a new swing, the price has already passed two significant levels, and eyeballing the calculation produces variation from trader to trader.

Automatic marking removes this gap — the grid is recalculated according to a defined algorithm at the moment the candle closes, not at the moment a person gets around to it.

TradingView and similar terminals provide a basic tool, but they do not solve the main problem — reproducibility. When each team member builds levels from their own extremum, signals diverge, and the strategy stops being verifiable.

A single calculation standard is when the swing is determined formally rather than "by eye," and the result is the same for everyone.

What changes in terms of measurable parameters

• Reaction speed — the grid updates at the moment the swing is confirmed, not after minutes of manual work. The delay between price movement and up-to-date levels is reduced from minutes to seconds.
• Signal stability — the algorithm does not "repaint" levels retroactively: the swing is fixed on close, and until it is canceled the grid stays in place. A whole class of false triggers disappears, where a trader sees a level that no longer exists an hour later.
• Removal of routine — the analyst stops manually recalculating the grid for every instrument and switches to testing hypotheses. On a portfolio of dozens of pairs, this frees up hours of daily work.
• A single standard — all participants see the same grid with identical levels. The argument "where did you get this level from" disappears, because the calculation is deterministic and reproducible.

We break down how this is handled in code and how to integrate an automatic grid into an existing trading workflow.

Calculation modes: from swings to dynamic grids

The calculation mode determines which points the grid is built from and how it survives a change in market structure. The classic swing approach fixes two significant extremes — a swing high and a swing low — and lays out the levels 0.236, 0.382, 0.5, 0.618, 0.786 between them.

It is predictable and reproducible: the same pair of points yields the same grid, which makes this mode convenient for signals that need to be explained and verified against history.

A dynamic grid recalculates its boundaries as new extremes appear, while adaptive levels add weight to volume and volatility: the boundaries shift as long as the trend structure is confirmed, and freeze when the market moves into a sideways range.

This reduces the number of false breakouts on trending stretches, but the price paid is that the grid stops being static — a signal issued an hour ago may already rely on different values.

The limitations of the method are common to all modes: Fibonacci does not predict a reversal, it merely marks the zones where a price reaction is likely.

In a thin market and during liquidity gaps, the levels lose their meaning — they should be switched off rather than have their parameters tweaked. That is why in the calculation system we build in a mode switch and explicit conditions under which the grid is considered invalid.

The choice of mode is a trade-off between the stability of the signal and its sensitivity to the market. Below we break down how this choice is reflected in the calculation architecture and in what data the system stores for subsequent verification.

How we implement automatic Fibonacci levels

Implementation starts not with code, but with an audit of how Fibonacci levels are currently constructed. We look at which extremes the range is calculated from, whether gaps and weekends are taken into account, and what happens when the last bar is redrawn.

At this stage, the main cause of discrepancies usually comes to light: manual marking relies on the visual selection of points rather than on a formalized rule.

1. Audit of the marking logic. We document the current algorithm: data source, timeframe, method for determining extremes, behavior when a candle updates. The result is a map of discrepancies between manual and automatic marking.
2. Agreement on calculation rules. We agree on formalized conditions: the extremum search window, the minimum movement amplitude, the reaction to price gaps. We write the rules down so that they can be verified against data rather than discussed in words.
3. Configuration of level calculation. We implement the construction of a grid from a confirmed range, including intermediate values and extensions. Levels are recalculated when a new extremum appears, not on every tick.
4. Testing on history. We run the system on accumulated data: how many times the marking matched the reference, where false signals triggered, how the logic behaves under low liquidity and during sharp movements.
5. Configuration of alerts. We determine which events are worth notifying: approach to a level, breakout, return to the range. We configure the frequency so that signals do not turn into noise.
6. Handover of the system. We deliver the working loop together with the regulations: how to change parameters, how to roll back changes, what to do when there is a discrepancy with the market picture.
7. Post-launch support. For the first while, we compare the automatic marking with the manual one and adjust the rules until the discrepancies fall within an acceptable corridor.

The key readiness criterion is not "the code works" but reproducibility: the same logic produces the same marking on any run of the history.

Configuration, schemas, and access policies

A system of automatic Fibonacci levels lives not in the code as such, but in the configuration: calculation parameters, access rules, and maintenance regulations determine how it will behave in the real market.

That is why the handover includes not only a working service but also a complete set of artifacts that the client's team can use to operate, fine-tune, and develop it without us.

• Calculation configurations — parameters moved out of the code: the set of timeframes, the depth of history for finding extremes, the minimum movement amplitude for building the grid, the step and coefficients of the levels. They are changed without rebuilding or restarting the service.
• Level calculation schemas — visual and textual descriptions of the logic: how reference points are determined, how the grid is built, how data gaps and anomalous candles are handled, and where false-signal filters are triggered.
• Access policies — role separation: who can change calculation parameters, who only reads the levels, and who manages the connection to exchange streams. Keys and tokens are stored in a secure vault, not in configuration files.
• Integration documentation — a description of the interfaces, data formats, and events that the system exposes outward: how to connect it to a trading terminal, a bot, or the client's internal analytics.
• Maintenance regulations — the procedure for updating parameters, rollback rules in case of a calculation failure, monitoring checkpoints, and thresholds for alerts about discrepancies between levels and market data.
• Instructions for the client's team — step-by-step scenarios for typical operations: add a new instrument, change the set of timeframes, investigate an incident using logs.
• Deployment schema — a description of environments, dependencies, and startup order, so that the system can be brought up again on clean infrastructure without contacting us.

Each artifact is handed over in working form and verified at acceptance: we show how a change in a parameter affects the built levels and record this in the documentation. Describe your task — we will come back with an estimate and a plan for the scope of the handover.

Case study: how the level grid stopped lagging

The client is a managing partner of a small prop desk, four traders on five instruments.

Markup was done manually: after the hourly close, each one built a Fibonacci level grid on their own chart, checked extremes against the adjacent timeframe, and transferred the values to the trading journal.

Across five instruments, this took 40-60 minutes per day, and worse — the levels appeared with a delay: while one was recalculating the grid, the price was already working through the touch they had planned to take.

TradingView in their process was a source of quotes, but the markup lived separately from the signal logic.

We built a service that pulls candles, identifies significant extremes on its own using the fractal rule, builds a Fibonacci level grid, and recalculates it when a new confirmed extreme appears.

The levels go to the trading terminal and the journal simultaneously — the discrepancy between manual and machine markup no longer occurs.

Metrics before and after

We also handled the rollback separately: if a new extreme turns out to be false, the service restores the previous grid and flags the episode in the journal — the trader sees why the level shifted, rather than just a new set of lines.

What this delivered over the long run

The traders got back an hour a day for analysis instead of routine, and the team stopped arguing over whose grid was "more correct" — the construction rule is single and reproducible.

Over the quarter, the share of trades opened at a level that wasn't missed due to markup lagging grew from 78% to 96%.

This is the core effect of automation: not "pretty lines on a chart," but the absence of a window in which the signal already exists while the trader is still calculating.

How automatic levels differ from indicator-based levels

A ready-made indicator from the terminal is a black box with fixed logic. It takes extremes over a given number of candles, builds a grid using standard coefficients, and redraws it when data updates.

The trader sees the result but cannot intervene in how the reference points are chosen: the swing is determined by the vendor's algorithm, not by your trading logic.

In a trending market, such an indicator latches onto a random local extreme — and the entire grid shifts along with it.

A custom calculation system is code where the rules for constructing levels belong to you. We define what counts as a significant extreme: a swing confirmed by close, higher timeframe structure, a consolidation zone.

Fibonacci coefficients are set as a parameter rather than a constant — you can add extensions, cut off levels outside the working range, recalculate the grid only when market structure changes rather than on every tick.

The difference between the approaches shows up in three things. Control over logic: you see why a level is built exactly here, and you change the rule instead of adapting to someone else's.

Flexibility of calculation: the system works across multiple timeframes simultaneously and delivers levels to your strategy or trading bot as data rather than as a picture on a chart.

Reproducibility: the same input produces the same result — on history and in real time, without discrepancies caused by redrawing.

Indicator-based levels remain useful as a quick reference, but they do not scale to non-standard logic. As soon as a strategy needs its own rules for selecting extremes, volatility filters, or integration with risk management, a ready-made grid becomes a limitation.

A custom system removes that limitation: the logic is described in code, covered by checks on historical data, and versioned alongside the rest of the strategy.

Technical doubts before the start

Before the start, the same engineering questions almost always come up: what to do with the logic that is already deployed, how to make sure the calculations are correct, and what source data is needed from the client. Below are the answers that remove most of the doubts before the first line of code.

How do you verify that the levels are built correctly?

Correctness is verified on historical data: we run the calculation over past periods and compare the levels against a reference manual markup. Additionally, we build a set of tests for edge cases — sharp moves, gaps, thin markets. If the deviation from the reference exceeds the specified tolerance, we do not release.

What source data do you need from us?

We need access to the quote stream or a history export, the timeframes on which the levels are built, and a description of the rules your team trades by. If you have current settings and examples of markup, they speed up the verification.

The rest — the data source, format, and update frequency — we will agree on during the design phase.

How will the system fit into our current environment?

Integration goes through standard interfaces: the calculation module delivers levels to your terminal, trading robot, or internal service. We fix the exchange format and the failure behavior so that a source outage does not break the logic. We make the transition in stages, with the option to roll back to the previous scheme.

Let's discuss your Fibonacci levels task

To come back with an estimate and a plan, rather than generalities, we need baseline data on your task.

Describe which markets and timeframes the Fibonacci levels operate on, which swings are considered significant, and how the grid is currently built — manually, by script, or by indicator.

If you have existing work, specifications, or examples of markup, attach them: they will help us understand faster the logic that needs to be automated.

After that, the work proceeds in stages, and at each one you see a result, not just the final build:

• We break down the task and lock in the baseline data: instruments, timeframes, level construction rules, quote sources, and recalculation latency requirements.
• We agree on correctness criteria — how we distinguish a correctly built level from an erroneous one, and on which historical data we verify it.
• We prepare the architecture: where swings are calculated, how level history is stored, and how the system delivers signals to the trading terminal or bot.
• We build a prototype on your data — you see how levels are drawn on a real chart, before the main development.
• We implement the full logic: automatic recalculation, handling of gaps and weekends, and resilience to gaps in the quote stream.
• We run it on historical periods and compare against your manual markup, eliminating discrepancies.
• We hand over the system, documentation, and access, and train your team to work with it.

The first step is a short task breakdown: you describe what the result should be, and we ask clarifying questions about the data and logic. After that, we come back with a timeline estimate, scope of work, and a stage-by-stage plan. Describe the task — and we will move on to the next stage.