For a market maker, having capital is not the same as having usable liquidity. A firm might have $10 million spread across several venues, but that doesn't mean the full amount is available to support quotes. Some capital may already be committed to open orders. Some may be tied up in inventory. Some may be held on a venue where the firm can't hedge efficiently. Another portion may be moving between accounts.
So the system needs to answer a more useful question than, “How much capital do we have?”
It needs to know how much liquidity is actually available, where it is, what is consuming it, and whether that information is still accurate. That's what makes liquidity management a core part of market making infrastructure.
A production liquidity management system sits between account balances, positions, orders, market data, risk controls, trading strategies, venue connectivity, hedging, and reconciliation. If one of those views becomes stale or inconsistent, the trading system can make decisions using liquidity that doesn't really exist.
A basic balance figure doesn't tell a market maker much about what it can actually trade. Consider a market maker with $2 million in USDC on an exchange. At first glance, that looks like $2 million of available capital. But suppose $600,000 is already committed to open orders, $300,000 is reserved against an existing position, and another $200,000 is being transferred to a different venue. The firm's total balance hasn't changed, but its immediately deployable liquidity has. A useful liquidity management system therefore needs to distinguish between several states:
This distinction becomes even more important when a market maker operates across several venues. A strategy may see an attractive opportunity on one exchange, but the firm might not have enough usable capital there to support the trade. Moving funds may take time, incur costs, or temporarily increase operational risk. The system's job isn't simply to report balances. It needs to provide a reliable view of what the trading operation can actually use right now.
State in a liquidity management system refers to the platform's current perception of all trade activity. It comprises position state, which keeps track of the assets the company actually possesses; order state, which includes open, partially filled, canceled, or completed orders; account state, which includes balances on each venue; and liquidity state, which establishes how much capital is still deployable after accounting for those commitments.
Risk state matters too because a market maker may technically have enough cash to place another order, but doing so could push its exposure beyond a predefined limit. In that case, the cash exists, but it isn't necessarily usable for that strategy.
The challenge is keeping all of these states consistent. Let's say the system displays $500,000 as available. After a while, $50,000 starts to relocate to a different location, $200,000 is used to place new orders, and $100,000 of an existing position is filled. The liquidity engine will still display $500,000 as available balance if those modifications are not properly processed.
The strategy would then be making decisions based on an outdated picture, this is why liquidity management software development isn't simply about building a dashboard that displays balances. The underlying system needs to maintain a reliable and continuously updated representation of the trading state.
Liquidity doesn't exist in isolation from the market. A market maker's usable capital changes as prices move, inventory builds, spreads widen or narrow, and volatility changes. The liquidity management system therefore needs to work closely with market data and the pricing strategy.
Consider a market maker quoting BTC/USDT across several venues. The strategy may start with a balanced BTC position and quote aggressively on both sides of the market. If buy orders begin filling faster than expected, the firm's BTC inventory increases. The system now has a different risk profile. The market maker may respond by reducing the size of its buy quotes, increasing the price on one side, or looking for a hedge on another venue. This decision depends on more than the order book. The system needs to know:
This creates a feedback loop between liquidity and trading. The market conditions affect pricing. Pricing affects order flow. Order flow changes inventory. Inventory changes risk. Risk changes how much liquidity the strategy can deploy.
A liquidity management system has to reflect those changes quickly enough for the trading strategy to work with current information, whereas risk controls are part of this process rather than a separate layer that only intervenes after a problem occurs.
Depending on the operation, controls may include maximum position size, maximum notional exposure, per-asset and per-venue limits, order-size limits, collateral requirements, price deviation checks, stale-market-data checks, loss or drawdown limits, and emergency cancellation controls.
For example, if market data from a venue stops updating, the system shouldn't continue treating that venue's order book as current simply because the connection itself still appears open. A stale price can lead to incorrect quotes, which can then consume liquidity in the wrong direction.
The liquidity engine therefore needs to understand not only how much capital exists, but also whether that capital is safe to deploy under current conditions.
Liquidity becomes considerably harder to manage when capital is spread across multiple venues. A market maker might hold $1 million on Venue A, $750,000 on Venue B, and $500,000 on Venue C. On paper, that's $2.25 million.
Operationally, those balances aren't interchangeable because Venue A may have the best liquidity for one trading pair. Venue B may offer better hedging opportunities. Venue C may have attractive prices but limited withdrawal capacity. Each venue may also have different collateral requirements, order limits, API behaviour, and settlement processes.
The liquidity management system therefore needs to understand liquidity at both the firm level and venue level.
Hedging adds another dependency. Suppose a market maker accumulates ETH inventory on one venue after a series of fills. The strategy decides to hedge that exposure somewhere else. The hedge depends on capital being available at the second venue, the market being sufficiently liquid, and the venue connection working correctly.
If the hedge venue is unavailable, the system may need to reduce quoting activity on the first venue rather than continue trading at the same size.
This is why multi-venue liquidity isn't simply a matter of adding more exchange integrations. The system needs to understand how liquidity on one venue affects trading decisions across the rest of the network.
Transfers create another operational complication. Funds moving between venues shouldn't simply disappear from the system until they arrive. Their status needs to be represented accurately:
Available → Reserved → In Transit → Received → Available
If $500,000 is being transferred from one venue to another, the liquidity engine needs to know that the money still belongs to the firm but cannot currently be used at either side.
The same principle applies when a venue becomes unavailable.
The system must decide whether quoting should cease, whether current orders should be canceled, and whether the venue's balances and positions can still be trusted if a connection is lost while the strategy is in progress. A safer recovery flow might look like:
Connection lost → protect quoting → reconnect → refresh market data → check open orders → confirm actual venue state → resume
The important part is that the platform doesn't simply reconnect and assume everything is back to normal.
One of the easiest ways for a liquidity system is to become unreliable for order state and account state to fall out of sync. Consider a market maker that has $100,000 available and sends a $40,000 order.
The system should now account for that capital as committed. If the order is cancelled, the amount becomes available again. But what happens if the order is partially filled while the cancellation request is being processed?
That's a common type of state transition that trading infrastructure needs to handle carefully. A cancellation request does not necessarily mean the order was cancelled. The order may have been:
The liquidity system needs to reconcile the actual venue state with its internal state before deciding how much capital remains available. This becomes even more important when the platform manages several venues simultaneously. The same applies to transfers and settlements. A transfer can be initiated but not yet received. A withdrawal can be submitted but rejected. A deposit can arrive at the venue but take time before becoming available for trading.
These events directly affect deployable liquidity. That's why reconciliation shouldn't be treated as a back-office process that happens at the end of the day. For a market maker, reconciliation is part of the trading system. The platform needs to regularly compare its internal records against venue data for:
If the internal position says the firm owns 100 ETH but the venue reports 97 ETH, the difference needs to be identified before the trading strategy continues relying on the internal figure.
The same applies to cash. If a liquidity engine believes $500,000 is available but the actual venue balance is $450,000, the difference can affect order sizing, risk calculations, and hedging decisions. A strong reconciliation process therefore doesn't just identify accounting differences. It protects the trading system from acting in an incorrect state.
A production system usually consists of several connected layers rather than one standalone liquidity service. A simplified architecture looks like this:
Market Data → Account & Position State → Liquidity Engine → Strategy/Pricing → Risk → Order Management → Venue Connectivity → Hedging/Rebalancing → Reconciliation → Monitoring
Each layer has a specific responsibility.
Collects order books, trades, prices, spreads, and other market information from connected venues. Data freshness needs to be tracked because an old price can be more dangerous than missing data.
Maintains the firm's balances, positions, collateral, and available funds across venues.
Combines account information, open orders, positions, transfers, venue limits, and risk constraints to determine what liquidity is actually deployable.
Uses that liquidity information alongside market conditions and inventory to determine quote prices and sizes.
Checks whether proposed trading activity stays within defined limits before orders reach the venue.
Tracks the full lifecycle of orders, including submission, acknowledgement, partial fills, fills, cancellations, and rejected orders.
Handles the differences between exchanges, including APIs, authentication, rate limits, order types, market-data feeds, and recovery behaviour.
Moves exposure or capital when the market-making strategy needs to reduce inventory risk or reposition liquidity.
Compares internal state with actual venue state and identifies discrepancies.
Connects these events so operators can understand what happened when something goes wrong.
For example, if a market maker suddenly accumulates too much inventory, the operator should be able to trace the event from the original market-data condition through pricing, order placement, fills, risk checks, and the resulting position. That level of traceability is much more useful than a monitoring dashboard that simply says a service is “healthy.”
Liquidity management software has to fit the market maker's existing trading strategy and operating model. There isn't one architecture that works for every firm. At WebMob, the focus is on building the system around the actual trading workflow rather than treating liquidity as a standalone balance-management problem that can include exchange connectivity, account and position tracking, liquidity calculations, risk controls, order management, hedging workflows, reconciliation, and monitoring.
The architecture also needs to account for how the system will behave when conditions aren't ideal. Exchange outages, stale market data, partial fills, failed transfers, delayed responses, and inconsistent venue states are not unusual edge cases in production trading. They need to be considered as part of the system design. For firms building or extending market making infrastructure, that means defining the trading and liquidity model first, then designing the software around the decisions the system actually needs to make.
Before development begins, a market maker should be clear about a few fundamental questions:
Where is liquidity held?
Which exchanges, wallets, custodians, or accounts will the system manage?
What counts as deployable liquidity?
Does the calculation consider open orders, inventory, collateral, transfers, and venue-specific limits?
How does liquidity affect pricing?
Should available capital change quote size, spreads, or which markets the strategy supports?
What happens when liquidity becomes constrained?
Should the system reduce order sizes, stop quoting a market, move capital, or trigger a hedge?
How is the state verified?
How often should balances, orders, positions, and transfers be reconciled against external venues?
What happens when a venue fails?
Which trading activities should stop, and how should the system recover?
These decisions have a direct impact on the architecture. A system designed only to display balances will look very different from one that actively feeds liquidity constraints into pricing, risk, order management, and hedging.
Market makers don't just need access to capital. They need to know where that capital is, how much of it is committed, how much risk it carries, and whether it can be deployed at the moment a trading opportunity appears. That's why liquidity management sits so close to the core of market making infrastructure.
The difficult part isn't calculating a balance. It's maintaining an accurate picture while orders are being placed, fills are arriving, positions are changing, funds are moving between venues, markets are shifting, and external systems occasionally fail. A well-designed liquidity management system turns that constantly changing information into a reliable operating state that the trading strategy can actually use.
It's a system that tracks and evaluates the capital a market maker can actually deploy across its trading operation. It considers balances, open orders, positions, collateral, transfers, venue constraints, and risk limits rather than relying only on account balances.
Available balance is the amount an account reports as currently available. Deployable liquidity goes further by considering whether that capital is already committed, restricted by risk limits, needed for existing positions, reserved as collateral, or located on a venue where it can't currently support the intended strategy.
Each venue has its own balances, markets, APIs, limits, order types, settlement processes, and connectivity behaviour. Capital held on one venue isn't automatically available on another, so the system needs both venue-level and firm-level views of liquidity.
Internal trading systems can temporarily disagree with external venues because of partial fills, cancelled orders, delayed transfers, rejected requests, fees, or connection problems. Reconciliation identifies those differences and prevents the strategy from continuing to rely on incorrect balances, orders, or positions.
Not necessarily. The architecture should match the firm's trading model, number of venues, asset classes, risk requirements, and operational complexity. A system supporting two venues and a limited strategy can have very different requirements from infrastructure supporting multiple strategies and dozens of trading venues.
Let’s discuss and plan how we can accelerate your growth. Fill out this form and take the first step towards constant advancement.
We will respond to you within 24 hours.
Access to dedicated product specialists.
.png)
.png)
