A market maker’s job looks simple from the outside: keep buy and sell orders in the book and update them as the market moves.
What is less visible is everything that has to happen before those orders can be updated correctly. The strategy needs to receive the latest market data, decide how its prices should change, send instructions to the exchange and learn what happened to its previous orders. All of that can happen through different connections with different speed, delivery and recovery characteristics.
So when a market maker evaluates an exchange, “Does it have an API?” — is only the starting point. The more useful question is whether the entire path from a market event to the next order is reliable enough to trade on.
A simplified market-making cycle looks like this:
market event → order-book update → pricing decision → order entry → execution → inventory update → next order
Every step depends on the one before it. If market data is late or incomplete, the pricing decision is based on the wrong market. If an order reaches the venue later than expected, the price may already be outdated. If a fill is not reflected quickly enough, the strategy can continue quoting without an accurate view of its inventory.
That is why connectivity is part of the trading system itself, not simply the technical work required to connect the system to an exchange.
The stack can be simplified into 3 main layers:
Different venues may expose these functions through WebSocket, FIX, REST, drop-copy feeds or other channels. What matters is not having the largest number of protocols, but using the right channel for each part of the trading cycle.
Raw latency gets most of the attention, but synchronization can be just as important.
Consider an incremental order-book feed. If one delta is dropped and the consumer misses the gap, later updates can continue arriving normally. The connection still looks healthy, but the local book is now being updated from the wrong state.
That creates one of the most dangerous situations for a market maker: the strategy keeps quoting, but the market it is quoting against is no longer the market the venue sees.
Recovery therefore has to be part of the design. The system needs to detect missing sequences, stop relying on corrupted state, retrieve a valid snapshot and rebuild the book before normal quoting resumes.
There is no single architecture used by every venue. Current institutional offerings show several ways to separate market data, order entry and account or execution events.
WhiteBIT Market Making Program
Bybit Market Maker Program
The comparison is therefore broader than the headline maker rebate. A market maker is also choosing the qualification model, available infrastructure and the operating conditions under which its strategy will have to maintain liquidity.
For a market maker choosing a venue, a basic API checklist does not go far enough. The better questions are:
How does market data reach us? What happens if an update is missed? How do we send and cancel orders? How do we learn that an order has been filled? How do sessions recover after a disconnect? How quickly can we rebuild a trustworthy state?
Those questions connect infrastructure directly to the job the market maker is trying to do: keep orders in the market while prices, executions and inventory are constantly changing.
A strong connectivity stack does not eliminate trading risk. It gives the market maker the information and execution channels needed to understand that risk fast enough to act on it.
Disclaimer: This is not financial or investment advice. DYOR before making any decisions. Use at your own risk.
From Market Data to Execution: How Market Making Works was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
