Custom indicator instead of built-in: where the signal is lost
Built-in indicators are based on averaged logic: a single formula with the same default values is applied to any asset and any timeframe.
A moving average, RSI, MACD or Bollinger Bands do not know what is being traded — liquid spot or a thin altcoin, where a single order moves the price by percentages.
Hence the signal lag: by the time the condition is formally met, the move has already covered most of the way, and the entry lands at its end.
The second source of losses is smoothing. The stronger the noise filter, the later the indicator responds to a reversal; reduce the period and you get false entries on every volatility spike in the crypto market.
Parameter tuning does not cure this: the trade-off between responsiveness and robustness is built into the design itself.
Typical parameters do not describe real trading conditions. Liquidity changes by hour and day of the week, night sessions are thinner than day sessions, derivatives are driven by the funding rate and liquidation cascades, and volatility spikes come in clusters.
A period fitted on one historical segment produces a completely different profile of entries and exits on another.
A custom indicator does not solve the task of "taking another formula" but the task of describing specific market conditions: volatility normalization, adaptive period, entry thresholds that account for commissions and slippage.
Such logic is tested on history and on data that was not used in tuning. Below we break down how this is assembled and where the line runs between a useful enhancement and curve-fitting to the past.
What a proprietary calculation delivers: precision, speed, robustness
A ready-made indicator calculates using a formula you cannot change: it either confirms an entry after the candle closes or smooths the move so heavily that the signal arrives on the pullback.
A proprietary calculation algorithm removes this limitation — the moment the signal appears shifts to the forming candle, with the same set of input data.
False triggers are cheaper to filter out before entry than to analyze after a failed trade. Confirmation conditions are added to the calculation: a volume spike, alignment with the higher timeframe, price position relative to the boundaries of the accumulated range.
Filtering works inside the logic rather than on top of a ready signal, so the share of false triggers on the test segment drops by a factor.
A sideways market is a regime where classic oscillators produce a stream of opposing signals and a strategy flips on every bounce.
Here a market regime classifier turns on: by volatility compression and the structure of extremes, the algorithm recognizes a range and switches the calculation to trading from the boundaries.
The number of flips over a comparable segment falls several times over, and drawdown during flat market shrinks.
The quote stream is processed incrementally: trades are aggregated into candles, only changed values are recalculated, not the entire history array.
Venues such as Binance provide data through channels with different frequencies — we bring them into a unified model and maintain calculation state so that a connection break does not cause a recalculation from scratch.
The effect is measured by three numbers: how much earlier the signal appears relative to the candle close, what share of false triggers occurs on the historical segment, and how many times the logic flips in a sideways market.
These metrics are captured before and after the calculation change — this shows what the proprietary logic contributed, rather than a lucky market period.
Implementation options: calculation in the terminal, a service, or a stream
A custom indicator has three fundamentally different calculation locations, and the choice between them determines everything else: where the quote history comes from, how quickly the formula can be changed, and who receives the signal.
A mistake at this step becomes visible later — through rewriting the indicator architecture when the logic is already loaded by users.
The starting point should not be development convenience but two questions: where the quote history resides and who the signal consumer is. Below are three working schemes and the limitations each imposes.
| Option | When it fits | Limitations |
|---|---|---|
| Calculation in a trading terminal | You alone need the indicator in real time, and quote history is already loaded into TradingView or another platform | The logic is tied to a specific platform, sharing the signal with subscribers is difficult, and heavy calculations over a large window noticeably slow down the chart |
| External calculation service | Many people need the indicator, a consistent result for everyone matters, and you have your own quote history | You handle loading and storing history, the signal arrives with a one-bar delay, and a separate access perimeter appears |
| Streaming calculation | Many instruments and high frequency, with signals sent to a bot or an external system | More expensive to support, stream monitoring and recovery after breaks are required, and repeated recalculation on history is harder |
In practice, the schemes are combined: the terminal for quick idea validation, the service for history and identical signals for everyone, and the stream for distribution. Let's discuss the task and assemble a combination for your scenario.
How the work is structured: from problem definition to code handover
A custom indicator is not a line over a chart but a calculation pipeline with verifiable behavior.
That is why we start not with code but with data audit and logic formalization: while it is unclear which stream we calculate on and what exactly we calculate, implementation merely reproduces mistakes retroactively. Below are the stages the work follows.
- Market data audit. We verify the source, history depth, and frequency; we look for gaps, duplicate timestamps, candle overlaps, and changes in trading regimes.
- Formalization of trading logic. We translate “a signal on momentum fading” into formal conditions: thresholds, signal priority, behavior in a sideways market, and a ban on future values.
- Calculation scheme. We fix what is calculated on a closed candle and what is recalculated on every tick: windows, smoothing, buffers, and protection against division by zero.
- Parameter tuning. We select values and test robustness — the result should not collapse under a small shift in input parameters.
- Historical testing. We run it on a trend, sideways market, and volatility spikes: we look at signal lag, the share of false triggers, and behavior at sample boundaries.
- Live stream testing. We compare real-time calculation with historical calculation over the same interval; any discrepancy above tolerance is investigated to its cause — data, rounding, or processing order.
- Indicator acceptance. We hand over code, configurations, tests, and documentation on parameters and limitations, and go through control scenarios together.
Handover package: source code, documentation, regulations
Handover is not an archive of files but a package your engineers can use to assemble the calculation themselves, test it on their own data, and develop it without our involvement.
We fix the contents in an acceptance document: each item closes a specific risk — a discrepancy in the formula, a break in the quote stream, a calculation stoppage without an owner, access “for everyone at once.”
- Indicator source code — a repository with change history and comments on formulas, not a built artifact: any edit is visible line by line, and rollback to a previous revision takes minutes.
- Calculation description — which input series are taken, how averaging windows are calculated, how outliers and gaps in quotes are suppressed, what assumptions are built in, and where they stop working.
- Data flow scheme — the path from the quote source to the moment the trading perimeter reads the value, with control points and described behavior on a connection break.
- Update procedure — who releases a new version and when, how compatibility with the already accumulated signal history is checked, and where the parameter edit log is kept.
- Access rights to the calculation — roles: who changes parameters, who only reads values, who deploys to the trading perimeter; parameter changes are written to an immutable log.
- Test environment — a set of reference calculations on historical data: after any edit, comparison shows which signals changed and why.
- Deployment instructions — the procedure for bringing it up from scratch in a clean environment, so that recovery after a failure does not depend on us.
We go through the package together with your team on live data — this way each item is confirmed before signing rather than discovered a month later.
Case study: arbitrage spread calculation on a quote stream
What it was before
The indicator calculated the arbitrage spread from a quote aggregate across six venues, but the aggregate was collected by periodic polling — once per second.
Notification delay reached 4-6 seconds, while a price discrepancy lives for less: the signal arrived when the window had already closed. The spread itself was calculated from the last trade, without order book depth or commissions.
We began the case analysis with measurement: how long the discrepancy lives and at which second after it the signal appeared. The before metric was six false entries out of ten.
What was changed
The quote aggregate was moved to streaming subscriptions, events from venues are aligned to a single time scale with clock drift compensation.
The spread is calculated from executable orders in the order book, accounting for commissions and withdrawal delay — the figure reflects real profitability, not the difference on a chart.
Noise was suppressed with an adaptive Kalman filter, and the entry threshold was made floating: it widens during volatility and narrows in a calm market.
What it became
Notification delay is less than a second, and the share of false entries fell from 60% to 12%. There are fewer signals per day, but the share of profitable ones among them increased several times over: the indicator stopped reacting to discrepancies that cannot be executed.
The custom indicator was moved into a separate service with a calculation log — any signal can be analyzed retroactively: which quotes arrived, which threshold was active, where filtering triggered.
How does a custom indicator differ from a built-in terminal indicator?
A standard terminal indicator is a fixed formula with exposed settings: period, smoothing type, price source, and sometimes volume accounting. By changing them, you adjust sensitivity and lag, but not the calculation logic.
The capabilities of a standard calculation end where context beyond a single price series is required.
Non-standard market conditions — thin liquidity, prolonged flat market, gaps at session junctions, liquidation cascades — are smoothed by the standard formula together with the useful signal.
It does not see order book depth, the funding rate, or the distribution of volumes across levels, and that is where the cause of a move most often lies.
A custom indicator is assembled for your trading logic: which sources we take, how we bring them to a common scale, which market state we consider a regime change.
The entry condition stops being a verbal description and becomes reproducible — it can be recalculated on history and compared with actual trades.
The boundaries of applicability matter more than the formula itself. Thresholds fitted on one instrument and one volatility regime produce false triggers on another asset.
That is why we fix which data the thresholds were calculated on, in which regimes the indicator stays silent, and when a signal is considered invalid.
The selection criterion is simple: if the task boils down to tuning a couple of parameters, a built-in calculation is enough. As soon as you need your own data, your own logic, and explicit boundaries, that is custom indicator development. Describe the task and we will return with an estimate and a plan.
Frequently asked questions: data sources, delays, historical recalculation
An indicator is honest only when the input data is complete and identical on every run.
That is why, before the first line of code, we sort out three things: where the quote history comes from, what happens during stream breaks, and how to exclude curve-fitting logic to past price moves.
We do not silently overwrite breaks: missed intervals are marked, loaded from a backup source, and remain in the recalculation log.
When aggregating multiple venues, data is brought to a single time scale and one calculation base — otherwise different candle types and different day boundaries produce false signals at junctions.
What should be done if quote history is incomplete?
Incompleteness is recorded rather than hidden: we calculate the share of missed intervals for each instrument, load them from a second source, and mark the restored sections.
On them, the indicator either does not issue a signal or marks it as unreliable — instead of quietly substituting zeros.
How do you protect against curve-fitting to past price moves?
The logic is tested on segments that were not used in tuning: parameters are selected on one period and tested on subsequent ones, including segments with sharp moves and sideways movement. If the result holds only in one market state, the parameters are rebuilt.
How accurate is recalculation when aggregating multiple venues?
Recalculation runs on the same set of instruments and the same window on every launch, so the result is reproduced point for point. We consider a discrepancy between two recalculations on the same history an error, not acceptable noise.
Let's discuss the task and return with an estimate and work plan
To make the conversation concrete, it is enough to attach to your request what is already at hand: an export of candle or trade history for a period, a draft of the calculation logic — even as text or a table — and a description of how the signal should look on the chart.
If the indicator has already been implemented on another platform, send the source and screenshots of its behavior: they immediately reveal the discrepancies that usually surface during migration.
In the first conversation, we will go over:
- data composition: history depth, whether there are individual trades, how we behave on quote breaks and gaps;
- calculation logic: smoothing window, reaction to sharp moves, behavior under low liquidity;
- markets and time intervals on which the indicator must produce a consistent result;
- output form: a separate panel, chart labels, levels, or alerts;
- what has already been built: a prototype, third-party code, ready-made modules that need to be reused;
- acceptance criteria: on which historical segments we compare values and what we consider a discrepancy;
- constraints on timelines and implementation order.
Based on the results, we will return with a work plan: stages, what is required from your side, and the sequence in which we release the calculation core and the visual part.
Describe the task in two paragraphs — that will be enough to state the timelines and scope of the first stage.