Market Depth Screener: Where Liquidity Assessment Breaks
A trading decision is most often made based on the last price: it is single, easy to show and compare. But liquidity is determined not by price, but by the density of orders at levels near it.
A market depth screener collects the order book and calculates what volume can actually be executed without moving the quote — that is, it provides an assessment of liquidity instead of the illusion of "price."
This breaks down on thin pairs. The top of the order book looks dense, but behind it is empty: the first large order passes through a dozen levels and moves the price.
Price slippage turns out to be several times higher than estimated, and the position size that looked safe at the last price exceeds the pair's daily volume. At the same time, the asset itself trades on several venues, and the depth on each of them is different.
The second cause is stale data. A screener that requests the order book on a schedule shows a picture that no longer exists: between requests, limit orders are canceled, market orders are executed, and the level you counted on disappears.
An exchange data aggregator solves this with streaming updates and brings venue depth into a single picture, but requires normalization of tick size, fees, and different output formats for each source.
The cost of such an error is entering at a price that no longer exists and a signal that triggered after the move.
We further break down how liquidity assessment turns into a set of measurable metrics: depth within a deviation from the midpoint, spread width, and stability of a level over time. Each of them works only on streaming data — otherwise the metric lies.
What Changes After Implementation: Measurable Effects
A market depth screener turns a stream of quotes into a manageable signal: scattered observations across venues are replaced by a single control loop that reports the state of liquidity before a trade goes into slippage. Below are four consequences visible in metrics in the first weeks.
Reaction Speed Instead of Post-Mortem Analysis
Alerts about slippage arrive at the moment the depth threshold for a pair is crossed, not after execution at the worst price. The on-duty operator sees the order book change immediately, so reaction is measured in minutes, not in the duration of an incident investigation.
Manageable Share of False Signals
The threshold is built on the minimum depth within a specified price deviation, not on a single spread value. The noise of brief quote pullbacks is filtered out, the share of meaningless notifications drops many times over, and on-duty shifts stop burning out on empty triggers.
Reduced Execution Downtime
A frequent failure is an attempt to move volume through an empty section of the book, after which routing is rebuilt manually. Continuous liquidity monitoring removes this class: the route is reassembled from data, and downtime is reduced from hours to minutes.
Completeness of the Picture Across Venues
A single liquidity scale brings the depth of different markets to a comparable value, adjusted for fees and settlement scheme. The summary is checked against external aggregators such as CoinGecko, so the picture does not depend on whose interface the operator has open.
Operating Modes: Stream, Scheduled Snapshots, Archive
Data collection modes determine what will even enter the liquidity slice and how deeply it can later be verified.
A real-time data stream provides a complete picture of changes, scheduled order book snapshots provide comparable points for comparing venues, and an archive of liquidity slices provides the basis for history and investigation of disputed situations.
Each mode has its own limitation. A stream records every change and grows with market activity; snapshots save volume but miss everything that happened between polls; the archive stores aggregates from which an individual order can no longer be reconstructed.
What to Choose for the Task
| Mode | When it fits | Limitations |
|---|---|---|
| Real-time data stream | Alerts on sharp depth drops, monitoring of large orders | Recording grows linearly with activity; if communication breaks, the window is lost, buffering is needed |
| Scheduled order book snapshots | Venue comparison, reports, historical charts | Changes between polls are not visible; a short spike may go unnoticed |
| Archive of liquidity slices | Long periods, model validation, retrospective | Stores aggregates; details of an individual order cannot be recovered |
| Mixed: stream and snapshots | Both alerts and comparable history are needed | Two collection loops must be synchronized in time |
Work Stages: From Venue Audit to System Handover
Venues provide different market depth: in some places the entire order book is visible, in others only the top levels, and in others data arrives with delay and connection interruptions.
Assembling a single comparable stream from this is possible only after reconciling sources, so the work proceeds in stages — from venue audit to system handover.
- Exchange venue audit. We check which order book levels are available, how frequently they update, whether there is history for backtesting rules, and what limits the venue imposes.
- Data flow design. We determine what is collected via a continuous channel, what via periodic slices, and where a backup source is needed in case of a break.
- Data normalization. We bring pair symbols, volume units, price precision, and timestamps to a single form — without this, venue comparison produces false signals.
- Depth metric calculation. We calculate order density within a specified deviation from price, side imbalance, and the speed at which liquidity disappears.
- Alert setup. We set thresholds for each metric, condition holding time, and debouncing so the channel is not clogged with noise; we store rules in configuration that can be changed without rebuilding.
- Backtesting on historical data. We run the rules on records from past periods and look at the share of false positives and misses.
- System acceptance and documentation handover. We reconcile metrics with manual calculation, prepare reports, operating instructions, and the procedure for source failure.
What You Keep: Configurations, Diagrams, Procedures
A working screener is half the result. The other half is a set of artifacts your team can use to deploy the system, change sources, and investigate incidents without our involvement.
We hand over everything as text files and diagrams in your repository, not as "configured on our server."
- Connection configurations — source addresses, list of trading pairs, request limits, response timeout, and retry rules; edited without rebuilding code.
- Data flow diagrams — from order book snapshots and trade feed to depth, level density, and volume imbalance calculation, with restart points marked without state loss.
- Access rights and roles — a "role → action" matrix: who changes alert thresholds, who sees history, who manages keys; keys are stored outside the repository, actions are recorded in the audit log.
- Response procedure — what each alert type means, to whom and where it goes, what reaction time is expected, how to distinguish market movement from source failure, and what to do on a false trigger.
- Logs and metrics — data delivery delay, share of missed updates, number of triggers per rule, reaction time; export for a period and retention periods are described separately.
- System documentation — architecture, depth metric formulas, storage schema, procedure for connecting a new exchange and validating it on historical data.
- Deployment and rollback instructions — how to bring up the loop from scratch and how to return to the previous version of rules and configurations if the increase in triggers turns out to be false.
Case Study: False Signals on a Thin Market and How They Were Removed
Before: Manual Collection and Desynchronized Slices
An analyst manually consolidated the order book from four venues into one table. Slices arrived with a difference of several seconds, depth was calculated using different timestamps, and volume units did not match.
On a thin market, where price moves from a dozen large orders, such desynchronization produced up to seven false signals out of ten, and the team managed to react only after the pullback.
Let's break down what was changed. Venues were connected via stream, slices were brought to a single timestamp, and volumes were normalized.
The depth metric is calculated within a specified deviation corridor from the midpoint, not across the entire order book, so spread and "dust" at far levels no longer distort the picture.
After: Signal Is Confirmed by a Series of Slices
An alert triggers only if the imbalance holds for several consecutive slices and the depth on the pressure side exceeds the threshold.
The threshold is set in configuration separately for each instrument — CoinGecko is used as a reference for price reconciliation and filtering out outliers from a single venue.
The share of false signals fell from seven out of ten to one or two, and the team's reaction time was reduced from minutes to seconds.
The notification arrives together with a ready slice: you can see on which venue the depth was accumulated, how it changed, and which threshold triggered.
How Market Depth Differs from Trading Volume
Trading volume is a historical value: how many trades occurred over an interval. Market depth describes the current state: how much liquidity is placed in the order book on both sides of the midpoint and at what distance from it.
Volume growth does not guarantee execution at the expected price. An instrument may trade briskly, but liquidity is held in a narrow layer near the midpoint — an average-sized order eats this layer and moves the quote by several percent.
The combination of spread and order density is decisive: a narrow spread with a dense order book will let the price survive; a wide spread with the same volume means execution will be noticeably more expensive than expected.
| Metric | What it measures | What it says about a trade |
|---|---|---|
| Trading volume | completed trades over an interval | activity and interest — but in hindsight |
| Market depth | liquidity in the order book at a distance from the midpoint | how much can be executed without moving the price |
| Spread and order density | gap between best prices and concentration of orders by level | entry price and resilience to a large order |
Liquidity and volatility are inversely related: at thin depth, a small volume moves the price more than a large volume does on a dense order book.
For a screener, this means ranking instruments by volume alone is useless.
We calculate depth at several distances from the midpoint, the spread, and the distribution of density by level, and we issue a signal when depth is melting relative to the instrument's own profile — before a trade goes through at an unexpected price.
Technical Concerns: Delays, Sources, Reliability
Data delay is not a single number but a sum: trade publication on the venue, delivery via the quote stream, order book recalculation, and aggregation across exchanges.
We do not hide it by averaging: each signal has a timestamp and the depth volume by which it was calculated, so it is visible where the delay grew and what caused it — market movement or a source hang.
We connect quote sources through several independent channels: primary stream, backup, and reconciliation with an aggregator such as CoinGecko.
A signal is considered confirmed only when two sources match and there are no spread outliers, so verification filters out false triggers on a thin order book.
What happens if one source goes down?
The stream is marked as inactive, calculation continues on the remaining ones, and a warning about an incomplete picture appears in the interface. Signals are not suppressed at that moment, but they receive a note about incomplete reconciliation.
How does the system behave when communication breaks?
The connection reconnects automatically, the missed interval is loaded from history, and until restoration, data is marked as stale. An empty screen is better than an alert built on stale depth.
Can signals on low-liquidity pairs be trusted?
No, if the order book is thinner than the specified threshold — such pairs are excluded from calculation or go to a watchlist. The threshold is configured for your strategy, not hard-coded.
Let's Discuss the Task: What to Send for an Estimate and Plan
To come back not with general considerations but with an estimate and work plan, we need a minimum set of inputs.
The more precisely you describe the system requirements, the fewer assumptions we will put into the solution design and the more realistic the implementation timeline will be.
- Exchanges and markets to cover: spot, futures, specific pairs.
- Market depth screener metrics: order book depth at specified distances from price, spread, quote stability under large execution.
- Alert trigger conditions — absolute thresholds, deviation from the average over a window, sharp shift within minutes.
- Signal delivery channels: messenger, email, call to your system, browser panel.
- Operating mode — continuous quote stream or scheduled calculation; for what period we store history.
- Behavior in case of a communication break with the exchange and whether the source needs to be duplicated with data from other venues.
- Constraints: where to host the system, infrastructure preferences, who on the customer side accepts the result.
- Desired implementation timeline and the date by which a working loop is needed.
Describe the task in free form — this is enough to start. We will discuss it substantively and come back with an estimate and work plan: data collection design, set of metrics and alerts, stages, and implementation timeline.