How to Build a Custom Crypto Scanner: Filters, Timeframes, and What to Tune

Most scanners fail for one reason: they mix good metrics with weak rule design.

If you want alerts that are both early and usable, you need three things:

1. A liquidity gate to remove noise.
2. A primary anomaly signal with direction.
3. Cross-timeframe confirmation so one noisy minute does not trigger an alert.

This guide walks through the exact field-level setup used in AnomIQ, with formulas and filter templates you can paste directly.

A custom crypto scanner is a rule-based market filter that evaluates live symbols against statistical thresholds, directional flow, and liquidity constraints. A good scanner does not chase every move. It isolates repeatable market behavior and alerts only when it breaks that symbol’s own baseline.

How do 5m, 15m, and 60m timeframes work?

Each timeframe (5m, 15m, 60m) is computed from a rolling window that includes:

• 4 completed 1-minute bars
• 1 in-progress 1-minute bar

For Z-scores, the platform uses:

z = (live_mean - historical_mean) / historical_stddev

Where:

• live_mean uses the current rolling window
• historical_mean and historical_stddev come from completed historical windows

This matters because your 5m metrics react quickly, while 15m and 60m provide stability.

Taker-flow imbalance as a short-horizon predictor of price drift is well-established in market microstructure literature; see Cartea, Jaimungal, and Penalva, Algorithmic and High-Frequency Trading (Cambridge University Press, 2015). Z-score normalization of volume and flow variables is the standard way to make that signal comparable across instruments with different baselines.

For a deeper statistical explanation, see Z-Score in Trading.

Which core metrics do you actually need?

You do not need 40 fields to start. You need a small set that captures activity, direction, and quality.

Each rolling metric in the table below exists on every timeframe (5m, 15m, 60m). In the UI the label does not carry the timeframe; you pick it per panel. In filter syntax we write the timeframe in parentheses after the field, e.g. Buy volume Z-score (5m).

The three derived identities worth remembering:

Intensity Z-Score          = Total volume Z-score - Total count trades Z-score
Buy Volume Concentration   = Buy volume Z-score  - Buy count trades Z-score
Sell Volume Concentration  = Sell volume Z-score - Sell count trades Z-score

Those differences are useful because they separate “more trades” from “larger trades.”

For directional flow context, see Net Taker Imbalance.

How do you build scanner rules in layers?

Layer 1: Liquidity Gate

Today Volume in $ > 500,000
AND Liquidity score 0-100 > 50

This avoids illiquid symbols where one order can distort everything. Kaiko’s ongoing liquidity work (Kaiko Research, 2024) points to the structural reason: order book depth on non-major crypto pairs is meaningfully thinner than on BTC or ETH, often by an order of magnitude, which is exactly why short-window statistics break down on thin symbols.

Liquidity score 0-100 is exactly what the name says: a 0–100 trade-continuity score. On BINANCE_PERPS almost every pair sits close to 100 because perpetual markets are deeply liquid by construction, so the gate effectively only binds on thin spot altcoin pairs. If you scan perps exclusively, you can tighten the gate to > 80 without losing real candidates, or drop it entirely and rely on Today Volume in $ as the hard floor.

Layer 2: Primary Signal

Choose one strong primary signal:

• Buy setup: Buy volume Z-score (5m) > 2.5
• Sell setup: Sell volume Z-score (5m) > 2.5

Layer 3: Directional Confirmation

Net Taker Imbalance (5m) > 25

or:

Taker Imbalance Z-Score (5m) > 2.0

Raw imbalance gives current directional magnitude. The Z-score tells you whether that imbalance is statistically unusual for this symbol.

Layer 4: Quality Filter

Buy Volume Concentration (5m) > 1.5

This favors events where buy volume is growing faster than buy trade count, often a sign of larger participants.

Layer 5: Cross-Timeframe Confirmation

Buy volume Z-score (15m) > 1.5

Lower threshold than 5m, but required for persistence.

Layer 6 (perps only): Open Interest Disambiguation

On BINANCE_PERPS, a buy-volume surge can mean two very different things. If open interest is rising at the same time, new longs are opening. That is genuine accumulation. If open interest is falling, shorts are being forced closed. That is a mechanical squeeze that will mean-revert once the short pool is exhausted. Add:

OI Change % (60m) > 0.5

Without this gate, perp scanners routinely fire on short-liquidation cascades and misclassify them as new demand. Omit on spot pairs (the field is zero there).

Three Scanner Templates

1) Aggressive Buy-Side Flow

Today Volume in $ > 500,000
AND Liquidity score 0-100 > 50
AND Buy volume Z-score (5m) > 2.5
AND Net Taker Imbalance (5m) > 25
AND Buy Volume Concentration (5m) > 1.5
AND Buy volume Z-score (15m) > 1.5
AND Current Return (5m) > 0.2

Use this when you are hunting continuation candidates. Both flow and price have to respond together.

2) Sell-Side Distribution

Today Volume in $ > 500,000
AND Liquidity score 0-100 > 50
AND Sell volume Z-score (5m) > 2.5
AND Net Taker Imbalance (5m) < -20
AND Sell Volume Concentration (5m) > 1.5
AND Sell volume Z-score (15m) > 1.5

This one catches sustained distribution, not a single red candle that reverses on the next print.

3) Cross-Timeframe Directional Anomaly

Today Volume in $ > 1,000,000
AND Taker Imbalance Z-Score (5m) > 2.5
AND Taker Imbalance Z-Score (15m) > 1.5
AND Net Taker Imbalance (5m) > 15
AND Trend Cleanliness (15m) > 0.6
AND Buy volume Z-score (60m) > 1.0

Reach for this when the imbalance has to stay unusual even as the window stretches out. The 15m Trend Cleanliness condition filters out choppy, direction-switching windows that can still post high imbalance Z-scores but are not real directional regimes.

What should you tune first?

Tune in this order:

1. Today Volume in $ floor (noise control).
2. 5m Z-score threshold (signal sensitivity).
3. 15m confirmation threshold (false positive reduction).
4. Concentration threshold (Buy Volume Concentration or Sell Volume Concentration) for trade-quality control.

I settled on this order after trying the obvious shortcuts first: tightening the 5m Z-score before the liquidity floor, tuning concentration ahead of confirmation. Each variant produced rules that looked cleaner in the editor and fired worse in live markets.

Common failure pattern: lowering the 5m threshold too early. That increases alert count but usually destroys precision.

If your rule is too strict, lower confirmation thresholds before removing the liquidity gate.

One portability note: absolute Current 5m Return thresholds (e.g. > 0.2) behave differently across symbols with different baseline volatility. A 0.2% move is noise on BTC but a real event on a quiet stablecoin pair. For cross-symbol scanners, prefer a volatility-normalized form, conceptually Current 5m Return / Current 5m Volatility, and set the threshold in units of σ rather than raw percent.

Mini Case: One Rule, One Trigger, One Decision

A practical example using the Aggressive Buy-Side Flow template, captured on 13 April 2026, 19:13 UTC:

• Symbol: XPLUSDT
• Window: 5m trigger with 15m confirmation
• Trigger snapshot:
  • Today Volume in $ = 2,400,000
  • Liquidity score 0-100 = 71
  • Buy volume Z-score (5m) = 3.1
  • Net Taker Imbalance (5m) = 34
  • Buy Volume Concentration (5m) = 1.9
  • Buy volume Z-score (15m) = 1.8
  • Current 5m Return = 0.46

Result: the rule fired once, the move continued for the next few windows, and no opposite-side distribution signal appeared in 15m during the immediate follow-through. The symbol is incidental. What matters is that liquidity, anomaly, direction, quality, and persistence all lined up in the same window. I only trust these triggers when every layer is aligned.

Absolute vs relative thresholds: which should you use?

Fixed absolute thresholds break when you scan many symbols with different baselines. That is why the core anomaly fields are Z-score based (Buy volume Z-score, Sell volume Z-score, Taker Imbalance Z-Score). They normalize each symbol to its own behavior.

Use absolute thresholds only for liquidity gates. Use relative thresholds for every anomaly signal.

This is the same principle explained in Relative vs Absolute Signals.

What’s the final checklist before saving a scanner?

• Keep at least one liquidity condition: Today Volume in $ or Liquidity score 0-100 (remember Liquidity score is 0–100, not 0–1; BINANCE_PERPS pairs sit close to 100)
• Use one primary signal + one directional signal
• Add at least one 15m confirmation condition
• For BINANCE_PERPS rules, include an open-interest gate (OI Change % (60m) > 0.5) to separate new longs from short-liquidation cascades
• Avoid rules that rely on a single metric only
• Re-check performance after major volatility regime changes

A good scanner fires for the same market behavior every time. That is the only bar that matters.

If you want to see how these metrics combine in a live order-flow context, read Order Flow Absorption vs. Exhaustion, then apply one of the templates above in your own scanner.

FAQ

What threshold should I start with for Buy volume Z-score?

Start with Buy volume Z-score (5m) > 2.5, then tighten or loosen based on alert volume and quality. Use 15m confirmation before lowering 5m thresholds.

Should I use Net Taker Imbalance or Taker Imbalance Z-Score?

Use both when possible. Net Taker Imbalance gives immediate directional magnitude. Taker Imbalance Z-Score tells you whether that reading is unusual for this symbol.

Why keep a liquidity gate if Z-scores are relative?

Relative metrics still fail on thin markets where one participant can distort the window. Today Volume in $ and Liquidity score 0-100 reduce this failure mode.

How many conditions should one scanner rule have?

For this setup, 5 to 8 conditions is enough: liquidity gate, primary anomaly, directional confirmation, one quality filter, and one cross-timeframe condition.

How often should I retune thresholds?

Retune after clear volatility regime shifts or when alert precision changes materially. Do not retune daily; that usually leads to overfitting.