Market making: why liquidity disappears on volatility
A calm order book looks deceptively reliable: bid-ask spread within a couple of price steps, dense market maker layers several levels down, an average-sized order passes with minimal price impact.
On the first impulse, price moves several percent in seconds — and all that depth disappears at once. The analysis starts not with the question "why did the bot turn off," but with which rules forced it to pull quotes.
The mechanics of the failure are almost always the same. Quoting logic is configured on a single trigger — price deviation or volatility spike — and widens the spread in a jump, without smooth depth reconfiguration.
At the same time, position risk limits and protection against undesirable flow trigger, while order replacement is delayed. The sum produces a gap: price has already moved, and new layers in the order book have not been placed yet.
Order book volatility in those seconds is several times higher than market volatility, and large orders hit exactly that.
Then the domino effect triggers. A large order for 20–30 levels eats the rest of the book and executes at worst prices: order slippage, which normally measured in tenths of a percent, one-time grows by an order of magnitude.
The exchange gets a drop in effective depth, institutional participants — unexecutable expectations on average price, and the market maker — adverse selection: its residual quotes execute against informed flow while it restores layers.
The damage is not one-time. Each such episode clears part of exchange liquidity: some participants move flow to other venues, and the remaining start placing orders farther from the midpoint, and the quote spread remains wide even after the market calms. Recovery takes hours versus the seconds in which the system collapsed.
We explain how this is closed: quoting parameters are tied to volatility, risk limits are calculated separately per pair, and order book depth is maintained by layers with different distance from the midpoint.
What managed liquidity provides: effect in numbers
Managed liquidity is measured not by the number of quoting robots, but by the state of the order book at the times the market really needs it: at trading open, during a news spike, on a drawdown of the underlying asset.
We build quoting on Hummingbot and proprietary venue connectors — depth at several levels from the midpoint is maintained constantly, not manually pulled up after another market maker leaves.
The share of executed large orders is the first metric that changes.
A market order with volume of a noticeable share of daily turnover previously passed through four-six levels and moved price several percent; after setup, the same passes within one-two levels, and slippage falls several times.
Alongside we calculate spread retention time: how many minutes per day the best price stays within the target corridor.
Quote stability is provided by automation, not shift duty.
Risk limits set the maximum net position per instrument, allowable price deviation from benchmark and pause on a sharp move; when approaching the boundary, the system narrows volume instead of shutting down entirely, so the order book does not crumble from one impulse.
Parameters are changed without restart — the engineer sees the effect in the current trading session.
A removed class of failures — desync between quotes and position. State reconciliation with the venue goes per each order, stuck and partially filled orders are cancelled automatically, and process restart does not leave orphan orders in the order book.
In reporting this shows as the share of minutes with correct limit coverage and the number of incidents requiring manual intervention.
Market making modes: comparison of approaches and limitations
Choosing a quoting mode determines not only order book depth at the start, but also who bears inventory risk when the market moves against the position. We build three schemes on exchanges, and each changes the operational load on the team in its own way.
Comparison of schemes
| Variant | When appropriate | Limitations |
|---|---|---|
| Own quoting program | Key pairs where the cost of error is high and there is a team for algorithms | Round-the-clock supervision of position and limits, risk remains on own account |
| External liquidity provider | Quick start, long tail of instruments, no in-house algorithmic team | Spread and quoting rules set by partner, dependence on a single counterparty |
| Hybrid scheme | We quote the core ourselves, tail given to partner | Need a unified risk contour and parameter reconciliation between own and external orders |
Own program gives full control over reaction to news, but requires fault tolerance and monitoring without pauses. External liquidity provider removes this load, but order flow and trading data go to a third party, and vendor exit leaves the order book empty.
Hybrid distributes roles: own algorithms on high-turnover pairs, exchange market maker on the rest of the list.
The boundary between schemes is mobile: the instrument set under an external provider is usually reduced as the own team grows.
The limitation of any approach manifests during sharp moves — quotes are held by the one who set position limits in advance and is ready to place orders against the trend.
Implementation procedure: from market audit to handover of control
The work order is built so the solution never encounters the real order book without limiters. First we measure the market and only then configure anything: any quoting parameter without data on depth and volatility is a guess.
Then — several weeks of observed operation with reduced volumes, and only after that control passes to your team.
-
Market and current order book audit. Collect trade and quote history, look at spread and depth by levels during the day, share of third-party bots, book behavior on sharp moves.
Result — a map of gaps that the market maker closes, and understanding of what share of volume can really be retained.
-
Quoting scheme design. Determine how many levels we hold on each side, what step they use, how they recalculate when price shifts, and what we do on abnormal moves. Here we also fix which pairs and during which hours are served.
-
Limits and safeguards setup. Instant position limit, daily risk cap, allowable portfolio skew, order cancellation speed when price moves away. Separately configure contours against cascading buyout — the scenario that most often breaks carelessly launched schemes.
-
Testing under real conditions. Launch with deliberately reduced volumes, parallel comparison of calculated spread with actual order fill. Based on results, fine-tune reaction to volatility and stop thresholds.
-
Observability. Metrics on position, spread and execution quality, alerts on limit breaches, clear manual intervention procedure. You see what is happening without waiting for a report.
-
Control handover. Access, description of scheme and limits, training of your engineers, planned shutdown procedure and support during the first weeks in live mode.
Describe the task — we will come back with an estimate and plan for these stages.
Handover package: configurations, schemes, procedures
After launch, the market making system remains with the client, not with the team that built it.
Therefore, together with the working contour, we hand over everything needed for independent operation: otherwise any settings change turns into a request to us, and an incident into downtime until clarification.
- System configurations — settings per each instrument: spreads, volume limits, maximum open position, automatic quoting stop thresholds. For each parameter, a comment: what changes, what this leads to and which values have already been tested.
- Order flow schemes — path of an order from queueing to execution confirmation, cancellation and residual reconciliation. The scheme marks risk check trigger points and system behavior when the channel to an external venue breaks.
- Access rules — role model: who changes quoting parameters, who only reads metrics and exports reporting, where second confirmation is required. Keys are issued personally and revoked when the responsible person changes.
- Documentation — description of components and their responsibility boundaries, dependencies on external venues, procedure for deploying a new configuration and rollback to the previous one.
- Duty procedure — what to look at on the monitoring panel first, which signals require human intervention, whom to notify, under what conditions to stop quoting.
- Failure action plan — balance discrepancy with the accounting system, stuck orders, sharp volatility growth: each scenario has its own sequence of steps and incident closure criterion.
- Change acceptance procedure — how to test a new setting on a limited instrument and by which metrics understand it can be rolled out to the entire portfolio.
We check the package at acceptance: the client's engineer changes a setting and rolls it back themselves. If this is possible without us — handover has taken place.
Case: order book density and slippage before and after
Exchange Meridian — a couple dozen spot instruments and own market makers. Spread was held, but volume sagged at near levels, and on a news impulse quotes were pulled first: market orders went deeper into the order book, and client flow quickly shifted to competitors.
Baseline measurements were taken for two weeks. Median density within three price steps — about 40% of target, limit order fill rate — 60%, slippage on an average order at impulse moment reached 200 basis points.
| Metric | Before | After |
|---|---|---|
| Order book density within three price steps | 40% of target | 90–100% |
| Limit order fill rate | 60% | 88% |
| Slippage on impulse, basis points | up to 200 | 30–50 |
| Quote recovery after impulse | 4–6 minutes | 20–40 seconds |
We rebuilt the quoting core: inventory limits per each instrument, asymmetric quote skew when position deviates, mandatory offset from reference price and switching to protective mode when volatility goes beyond the calculated band.
What the transition gave
The main effect — not medians, but behavior under stress. Previously the order book collapsed and reassembled over minutes, now density sags for tens of seconds and returns by itself.
Fill rate grew, slippage decreased, and inventory consumption remained within set boundaries — quoting stopped requiring manual interventions at the moment of market movement.
What to do if your liquidity provider is already running
A working liquidity provider is not a reason to pause the project: spread and depth are already held, and its access and limits remain untouched.
First step — audit of the current scheme: connect to trading interfaces with read-only keys, take order history, look at how exposure behaves when price moves and during which hours quoting sags. Output — flow map and understanding of what share of turnover the current contractor really closes.
Then — parallel launch: own keys, separate account, exposure limit deliberately lower than the working one.
We quote the same pair with a limited share of volume so comparison runs on identical volatility periods: time of two-sided quoting, average spread, depth drawdown on large orders.
Migration without stopping trading is redistribution of limits, not switching.
The previous provider's share decreases step by step, ours grows, and at each step emergency stop works: if there is a discrepancy with reference price or accumulated position goes beyond the threshold, our orders are cancelled automatically. Separately we monitor that flows do not intersect.
Replacing the contractor is the last step, not the first. First comparable metrics for identical intervals, agreed withdrawal schedule, stop rules and procedure for returning to the previous scheme. Access, configurations and risk parameters handed over in a form that can be raised without us.
Audit of the current scheme takes days and immediately becomes the basis of the transition plan — without pauses in trading.
Technical doubts: fault tolerance, control, reporting
Doubts about fault tolerance, access and reporting are removed before trading starts, not after the first incident. Below — three questions clients ask most often, with an answer on contour design.
What happens if communication with the exchange breaks or power fails?
Trading core, risk module and data collection are independent processes: failure of one does not stop others.
When connection to the venue is lost, the strategy goes into protective mode — new orders are not sent, confirmed ones are maintained according to the last valid state, position is reduced by a set rule.
After recovery, state is reconciled with exchange reports, discrepancies are closed before trading resumes: the strategy does not operate on stale data.
How is access to funds and trading keys restricted?
Trading keys do not have withdrawal rights — only placing and cancelling orders, funds remain on the account under your control.
Access is differentiated by roles: the operator sees positions and metrics, but does not change risk parameters; limits are edited only by the owner of the corresponding role. Any operator action goes into an immutable log — who, when and what changed.
What trading reporting does the client receive?
Daily summary: executed orders, volume, average entry and exit prices, realized result, deviation from target spread, contour downtime. Metrics and diagnostics are consolidated in Grafana — panels are open to you in read-only mode around the clock.
Trade history and action log are exported as files for reconciliation with the exchange and internal accounting.
Let's discuss the task: we will come back with an estimate and implementation plan
To come back with an estimate, not general wording, a concrete set of data is needed at input.
Minimum: list of venues and pairs where liquidity needs to be maintained, with priority by volume, target quoting parameters (spread, order book depth, maximum position per pair) and allowable drawdown at which the system must pull quotes.
If there is trade history and order book snapshots for a representative period — we use them to calculate real volatility and load profile, rather than taking averaged assumptions.
In parallel we will discuss who owns access and keys, how rights are restricted and who is on duty during failure — this determines the role separation scheme and emergency stop logic.
To the first meeting we come with draft architecture, risk breakdown and options for operating mode.
- List of venues and pairs with priorities — the number of connections and volume distribution logic depend on it.
- Target metrics: spread, order book depth, maximum position, quote cancellation threshold.
- Market data: trade history and order book snapshots for the period you consider representative.
- Requirements for access and keys: who owns, how rights are restricted, duty procedure.
- Responsible person on your side who approves parameters and accepts stages.
- Expected mode: only spread maintenance or plus inventory management on own pairs.
After receiving input data we come back with an estimate and implementation plan: stages, scope of work, what is checked at each point and what rollback looks like if launch fails. Approximately this is 3-5 business days — exact timeline depends on how complete market data is.
Describe the task in an email: venues, pairs and current liquidity behavior. Then we will ask clarifying questions about access and risks and come back with an estimate and plan.