Volume screener: where custom development breaks
Volume anomalies live for seconds, while the first version of the screener learns about them minutes later.
Volume screener development most often starts with polling the exchange's public interface across dozens of pairs — and already at a hundred instruments, a custom exchange screener hits exchange request limits: the allocated request weight is consumed within tens of seconds, a restriction comes back, then a temporary address block. The signal either lags or arrives after the move has already been consumed.
The workaround is obvious — a trade stream instead of polling.
It breaks on disconnects: the channel drops for minutes, and unless you store the cursor of the last processed event, insert trades idempotently by their identifier, and replay the missed interval from the archive, volume in the window doubles. On the chart this is a spike that never happened, and the entry is based on a false anomaly.
The third crack is metric divergence between sources. Volume in base and quote currency, spot and futures markets, different window boundaries and time zones produce figures that do not agree with each other.
Until there is unified normalization and conversion to a common unit, a cryptocurrency volume screener noisily triggers and loses traders' trust — they return to manually watching order books.
All three nodes — collection, recovery after a break, and normalization — are closed before the first trigger appears. Below we break down how this works in practice and where the boundary lies between your own customization and a ready-made pipeline.
What a ready-made volume screener on exchange data provides
A volume screener for trading calculates not absolute volume, but deviation from the instrument's own profile: median and median deviation over a sliding window instead of the mean.
Average volume is broken by one large trade; median is not, so a spike in a thin market does not look like an anomaly until it truly is one.
We pull the pair reference and liquidity assessment from open sources, such as CoinGecko, and verify them against what the exchanges themselves report.
Monitoring volume spikes runs on the trade stream: the signal is formed at the moment a trade arrives, not at candle close, so signal latency is fractions of a second.
Volume is normalized to the instrument's volatility and brought to a threshold in sigmas, so the same threshold works both on major pairs and on low-liquidity ones.
Deduplication merges a series of trades from one entry into a single notification, so the trader does not receive five messages about one event.
The accuracy of screener signals rests on filters, not on tweaking the threshold: minimum order book depth, maximum spread, confirmation by a second minute of volume.
Roughly a quarter of what a "bare" volume threshold produces reaches the trader, while missing real anomalies remains within the margin of error.
The class of failures that stops reaching the trader is an anomaly in a market where a single order moves the price: entering on it produces slippage greater than the potential move.
We log exactly what each filter discarded, and using this data we calibrate thresholds for specific instruments and trading hours, not for an averaged market.
Screener operating modes: streaming, batch recalculation, hybrid
The screener operating mode determines what the customer receives first — a signal about an anomaly or a consistent picture for the instrument.
Streaming trade processing reads the tape from exchange channels and accumulates volumes in sliding windows: the spike is visible seconds after the trade, but if the connection breaks, the segment of the tape is lost irrevocably.
Batch history recalculation takes trades and candles for a period from the archive and recalculates the metrics — the data reconciles down to the last trade, but the result arrives with a delay.
The hybrid screener mode combines both: the stream maintains online metrics and emits signals, while recalculation every few minutes reconciles windows with the archive and closes gaps.
Mode comparison
| Option | When it fits | Limitations |
|---|---|---|
| Streaming trade processing | Reaction to a volume spike at the moment of the event, signals for manual and algorithmic trading | Latency from fractions of a second; a connection break leaves a hole in history; sensitive to peak load |
| Batch history recalculation | Analytics, strategy backtesting, reports, retrospective anomaly search | Latency from minutes to hours; no instant signals; load grows with archive depth |
| Hybrid screener mode | The main option for a trading product: online signals plus verified history | More expensive in development and support: window alignment, deduplication, divergence control |
The choice is dictated by the task: for reaction to an event, streaming is enough; for analytics, batch; for a working trading pipeline, a hybrid with automatic divergence checking is used.
Volume screener development: stages from audit to handover
Volume screener development starts not with code, but with an audit of data sources.
At this step we compare venues with each other: whether they calculate volume the same way, with what delay they provide the trade stream, whether there are gaps in history, how to handle periods when trading was halted.
The audit output is a list of sources that provide comparable data and an explicit list of divergences that will have to be compensated on our side.
- Data source audit. We collect history for each venue, compare aggregated volume with independent snapshots, mark gaps, duplicates, and time breaks.
- Flow schema and storage. We describe the data path: ingestion of streaming channels, normalization to a unified time scale, duplicate filtering, aggregation into windows and candles. Separately, we decide what to store in raw form and what only in rolled-up form.
- Volume threshold setup. We calculate a spike not as an absolute number, but as an excess over the baseline for the window: we set the window length, trigger multiplier, minimum liquidity threshold, and spread-width cutoff.
- Selection rules and chatter suppression. We determine which events enter the output, how they are ranked, and how one spike does not turn into a dozen identical signals.
- Historical testing. We run the rules over the archive, measure the share of missed events and false positives, the time from volume appearance to signal, and refine the parameters.
- Screener acceptance. We verify operation on the live stream against a reference sample, record divergence, check the signal log and rollback to previous settings.
- Handover. We provide configurations, flow schemas, and operating procedures: how to change thresholds, how to add a venue, and by what signs to understand that a source has started providing incomplete data.
After handover, thresholds and rules are changed without code edits — the settings are kept separately, and decisions on each change rely on historical runs, not on intuition.
What remains with you: configurations, schemas, procedures
A volume screener is useless if the selection rules live in one engineer's head and in a couple of scripts on a server. Therefore, we close each stage with artifacts that can be opened, read, and handed to another team without long calls. Below is what exactly remains in your repository and documentation.
- Alert configurations — files with volume thresholds, accumulation window, and deviation coefficient from the norm; edited without rebuilding, versioned, and rolled back to the previous set.
- Data flow schema — the signal path from the trade and order book source to calculation and storage: where buffering is, where deduplication is, what latency exists at each segment.
- Selection rules description — metric formulas (volume spike to moving average, buy/sell imbalance) and thresholds separately for instruments with different liquidity.
- Screener documentation — service map, environment variables, incoming message format, procedure for recalculating history for past periods.
- Operations procedure — what to check when signals are missed, how to restart the calculation node, where to look at logs, and where the notification goes.
- On-call procedure — three levels of events (noise, suspicion, incident), response time for each, and escalation order.
- Integration schema — connection points to exchange interfaces, the trading terminal, and reporting, and access rights separation.
- Validation kit — historical windows on which the rules are replayed, and a test that changing the threshold does not break selection.
Case study: how a volume screener removed false signals
Before: a stream of signals with nothing to filter it by
The screener ran on one simple condition — send everything where volume over the last hour deviated from the average. With over forty monitored pairs, this produced 70–90 alerts per day, of which only a few related to a real spike.
The analyst spent 3–4 hours on manual review: checking candles, looking at market depth, and still often failing to enter the move.
What was changed in the selection mechanics
Trade streams from Binance and other venues were merged into a single normalized series, and volume was compared no longer with the average, but with the median profile by time of day and day of week.
The signal required confirmation on neighboring timeframes and was cut off if the spike came from one or two large trades without growth in the number of participants. Thin-liquidity pairs were removed from the sample by minimum turnover threshold.
What happened after implementation
The number of alerts fell from 70–90 to 8–12 per day, and the share of false ones from approximately 85% to 20%. Reaction time decreased from 25–40 minutes of manual checking to 1–2 minutes: the signal arrives with context — timeframe, pair liquidity, volume profile.
Missed spikes in the first quarter of operation were zero versus 5–6 per week before, and signal review stopped taking a whole workday.
Thresholds and averaging windows are kept in configuration, so rules can be rebuilt for a different trading horizon without rewriting the logic.
The alert history is stored with the parameters at the time of triggering — any signal can be rechecked retrospectively and you can understand why it passed the filter.
How does a streaming screener differ from batch recalculation?
A batch screener runs on a schedule: it takes a slice of trade history for a window, recalculates volume metrics across all pairs, and outputs a ready list.
The same slice always produces the same result — divergences between runs are explainable, and a disputed situation is easy to reproduce.
The limitation is that between recalculations the market lives its own life, and a volume spike at the beginning of the window you will see only by the next run.
Streaming mode keeps metrics in memory and updates them on every trade — signal latency is measured in seconds, not in the recalculation interval.
The price for speed: the result depends on the order and completeness of events, so sliding windows with a clear boundary and duplicate deduplication rules are needed.
The comparison of modes comes down to three axes: signal latency, data completeness, and behavior during a connection break. Batch survives a break unnoticed: the next run takes history anew and recalculates the missed interval.
Streaming loses a chunk of the window — the metric is understated, and the signal either fails to trigger or arrives on distorted volume.
Therefore, around the stream, an event buffer is built, consumer lag is monitored, and the missed segment is loaded from history with recalculation of affected windows.
The choice is dictated by trading logic. If you need reproducible reporting and a decision at interval close, batch recalculation is enough.
If you need reaction within the first seconds and a short-lived signal, streaming mode is used, and recovery after breaks is designed separately.
In practice, a hybrid is assembled more often: the stream provides an instant signal, and a batch run once per interval reconciles divergences and cleans up gaps.
Technical concerns: latency, exchange limits, false positives
Most engineering questions about a screener concern the boundary with venues: request frequency, thin market, connection breaks. Below are answers to what is most often checked before launch.
How do you bypass exchange data limits?
Requests are not duplicated: one collector per venue, and signals are distributed to subscribers inside the system. Trades and order books are taken via streaming subscription, history is loaded in batches with a margin against the limit, and coin references are cached.
When hitting the ceiling, the collector itself lowers the frequency for secondary pairs — priority ones remain at full rate.
Where do false positives in a thin market come from?
The filter cuts off pairs where the volume of single trades distorts the picture: minimum order book depth, maximum spread, number of trades per window. The signal is confirmed by multiple sources, and a volume spike without price movement is marked as one-off.
What happens during a connection break?
Reconnection without state loss: the buffer holds the latest ticks, after recovery we catch up on the missed interval and reconcile the slice.
If the divergence is above tolerance, the window is marked incomplete and signals on it are not published — it is better to miss than to output a distorted one. Resilience is checked as a procedure: we break the connection and restart the collector in a test environment.
How do you measure screener latency?
The metric is from the appearance of a trade on the venue to signal publication, separately for streaming and polling. Measurement runs for each node, so it is visible where time accumulates: collection, calculation, or notification delivery. We set the threshold from the customer's trading logic, not "market average".
Let's discuss the task: we'll return with a schema and implementation plan
So that the volume screener development estimate is based on facts, not guesses, a short set of inputs is needed before the start. We expect the following from the customer.
- List of exchanges and pairs: spot, perpetual contracts, individual quotation pairs — the number of trade streams depends on it.
- History depth: from what point volume spikes are needed and for what period the norm is calculated — this determines the loading and storage method.
- Anomaly rule: volume growth to the average over a window, share of pair turnover, or number of trades per minute — which attribute you consider a signal.
- Signal delivery channels and recipients: personal dashboard, chat, call to your system.
- Access: read-only keys, exchange test environment, request rate limits.
- Acceptance criterion: allowable latency from trade to signal and acceptable share of false positives.
In response, we provide not a verbal estimate, but a working package based on the first task review.
- Solution schema: data sources, processing, storage, failure points, and their workarounds.
- Scope of work by stages and volume screener development estimate with an implementation plan.
- Filtering rules with parameters: averaging window, threshold, minimum number of trades.
- Metrics log: data freshness, gaps, number of signals per pair and by day.
- Operations manual and the procedure for historical validation before launch.
Describe the screener task and available data — we will return with an estimate and implementation plan.