Smart order routing: where orders lose out on liquidity fragmentation
A large order almost never finds its entire volume in a single order book. Liquidity is spread out: some sits on centralized exchanges, some in pools of decentralized venues, and some is posted by market makers. Each source has its own depth, its own spread, and its own execution rules.
Liquidity fragmentation itself is not the problem — the problem is that a single route is chosen: out of habit, by the best top quote, or by the most familiar venue. The system sees only the volume available at the selected source and sends the entire order there.
This leads to two classes of losses. Price slippage: each subsequent order book level is more expensive than the previous one, and the average trade price drifts away from what was visible at the moment of decision.
Partial execution: venue depth runs out before the volume, and the unfilled remainder is either returned or sent into a repeat request in an already shifted market.
Then the effect compounds. Repeat orders compete with each other and with other algorithms, and order volume loss grows nonlinearly: the larger the size, the worse the result of choosing a single venue.
Smart order routing closes exactly this gap — the route is assembled dynamically, from several sources, for a specific volume and the current state of the order books. Below we break down how it is structured and what execution quality depends on.
What changes after implementing order routing
The first thing visible within the first day after enabling routing is the fill rate.
The order no longer goes to a single preselected venue: the algorithm evaluates the available volume at each one and distributes the order in parts, so volume that previously remained unfilled or was manually canceled is filled in the same cycle.
The second effect is the average execution price. The router compares not only the best quote but also market depth at each level, fees, and expected slippage, and splits a large order so as not to eat through a single order book.
Over distance, this shifts the average price closer to the middle of the market and removes one-off overpayments at thin levels.
The third is resilience to the failure of an individual venue. If the connection drops, response latency grows, or available depth falls, the route is rebuilt to backup sources, and the unfilled remainder is moved there while preserving the original order conditions. The failure of one venue stops being an event requiring manual intervention.
The fourth is predictable costs. The more precisely volume is distributed, the fewer counter-transfers between venues and intermediate conversions there are, and the costs of moving funds stop depending on who placed orders manually and in what order.
Then the metrics stabilize: the fill rate and average price stop depending on which venue got "lucky" at the moment.
Observability appears — for each order, the selected route and the reason for selection are visible, so changes to the rules are verified against history, not gut feeling.
Routing modes: order book, liquidity pools, hybrid
Execution schemes differ not by the presence of an order book or liquidity pools, but by who holds the order at the moment of the trade and how the volume is divided.
This determines slippage, the number of partial fills, and how the setup behaves when one of the venues stops responding.
Below are working options to choose between when designing a router. We do not lock in the scheme in advance: first we look at where liquidity sits and how predictable the flow of opposite orders is, and only then do we propose an architecture.
| Scheme | When it fits | Limitations |
|---|---|---|
| Single venue | Liquidity is concentrated in one place, volumes are small | Single point of failure, slippage grows as order size increases |
| Order splitting | A large order against a thin order book | Fragments execute at different prices; partial fills and repeats need control |
| Router contract | Several liquidity pools in one architecture | Atomicity only within the architecture; routes are updated upon operator confirmation |
| Internal matching with hedging | The flow of opposite client orders is stable | Own position skew: risk limits and hedging are needed for each pair |
| Hybrid | Part of the volume is filled internally, the remainder goes outside | More order states, and it is harder to analyze executions from logs |
| Cross-network execution | Liquidity is distributed across several networks | Transfer delay, risk of an incomplete transfer, balance mismatch |
The options are combined: a router contract usually supplements order splitting, while internal matching runs on top of a hybrid.
Implementing a routing algorithm: stages of work
Routing is not written "in a vacuum": first you need to understand exactly where execution price is lost. The input is the goal of reducing slippage and the cost of walking the order book within a given time limit for the trade.
Below are seven stages, each ending with an artifact that can be verified and handed over to your team.
- Audit of venues and execution models. We collect order placement modes, cancellation rules, limits, and behavior on connection loss — documenting which liquidity sources are actually available.
- Route selection rules framework. We describe priorities: price, available volume, probability of execution, venue response latency. The rules are agreed in writing before the first line of code.
- Core prototype. A module for splitting a large order into parts and recalculating the route on every order book change.
- Integrations. A unified order and trade model, handling partial fills, retries, and venue failures.
- Backtesting on historical data. Running against recorded quote streams and comparison with the baseline strategy: slippage, fill rate, behavior in a thin market.
- Safeguards and monitoring. Limits on position size and order placement rate, automatic route shutdown when metrics deviate, and a decision log.
- Handover to operations. Configuration, rules documentation, change procedures, and training for your team.
Delivery artifacts: routing core, schemes, procedures
We deliver not a report but a working smart order routing setup that your team runs further without us.
Acceptance is practical: the client's engineers assemble the core from the repository themselves and change the route rules in a test environment — if they can do it without hints, the delivery has succeeded.
- Source code of the routing core and a reproducible build: repository, dependencies, tests for low-liquidity and venue-failure scenarios.
- Route scheme: graph of venues and connections, volume splitting order, priorities, and conditions for switching between routes.
- Connection configurations: session parameters, limits on volume and request frequency, behavior when a source is unavailable.
- Access and key policies: roles, permissions to edit routes, key rotation, separation of execution environments.
- Algorithm documentation: route selection criteria, model limitations, metric map, and interpretation of deviations.
- Monitoring procedure: list of execution quality metrics, alert thresholds, on-call actions.
- Rollback procedure: versioning of rules, return to the previous route set, procedure for taking a venue out of operation.
We hand over everything together with an analysis based on your data: where the bottlenecks are, which thresholds are set, and why. After that, adding venues and editing routes happen on your side, without contacting us for every iteration.
Case: routing an order flow across six venues
The client is a market maker that maintained an order flow across six venues. Before implementation, an operator chose the route manually: they compared liquidity tables, decided where to send volume, and in a moving market that decision lagged behind the price.
Part of the volume remained unfilled, and trades executed at a price noticeably worse than the benchmark.
We collected a unified order book from all six venues and taught the algorithm to distribute volume across available liquidity taking into account fees, response latency, and the risk of partial execution.
Connections go through FIX gateways — this provides a unified event stream and route log: venue, weight, reason for selection. A venue failure is handled routinely — its weight is redistributed among the remaining ones within a single cycle, without manual intervention.
Measurements before and after
| Metric | Before | After |
|---|---|---|
| Filled volume share | 61% | 94% |
| Average price deviation from benchmark | 11 bps | 3 bps |
| Failure of one venue | manual switching, downtime up to 15 minutes | weight redistribution, no downtime recorded |
| Disputed trade investigation | manual reconciliation, hours | route log entry, minutes |
The client performed both measurements independently, over different periods and different instrument sets, comparing the route log with an export from the trading systems.
Both showed the same direction: fill rate increased, deviation from the benchmark narrowed, and the failure of one venue stopped being an incident — orders went to the remaining ones, and execution quality did not decline.
These same measurements show where the bottleneck shifted: no longer manual venue selection, but the completeness and freshness of input liquidity data.
How a router differs from simple order splitting
Order splitting is arithmetic defined in advance: volume is divided into shares and spread across venues according to a fixed rule.
The router recalculates the route at every step: before sending the next part, it re-reads the state of the order book and liquidity pools, as well as the costs of transferring funds between venues.
The key difference is in the reaction to changes in market depth. A static grid does not know that liquidity has dropped at the second venue: it will continue allocating shares there and will collect execution at worse price levels.
A dynamic route checks depth at each level, compares it with the liquidity threshold, and moves the remainder to where it will be filled entirely, without slippage.
The second factor is costs and the risk of non-execution. Transferring funds between venues takes time and incurs network costs, and part of the volume may remain unfilled.
The router discards options where the price gain does not cover transfer costs and divides the remainder so that each part fits into the available depth.
Route recalculation happens after confirmation of each part, not once at the entry. Therefore, opposite volume that arrives during the process or liquidity leaving a venue changes the remainder rather than breaking the entire order.
An industry breakdown, Execution of Large Orders on Decentralized Venues, confirms: it is step-by-step recalculation that delivers the gain on volumes comparable to market depth.
On small volumes that fit into the first price level, the difference between approaches is almost imperceptible. On large ones, the filled volume share, the deviation of average price from the calculated one, and the share of partially filled orders diverge.
Technical questions: latency, partial fills, venue failure
The router operates where some responses arrive later than needed, and some do not arrive at all. Below is a breakdown of the doubts that most often come up when designing smart order routing.
What should be done if venue response latency increases?
The route is built taking into account quote freshness: stale snapshots are excluded, otherwise the price gain will be illusory. A limit is set on waiting for a response — if the venue does not meet it, the order goes to the next route.
How is the order remainder handled during partial execution?
The remainder is not sent blindly: the route is recalculated based on available depth, and the volume is split across venues. If liquidity is exhausted, the remainder is either canceled or placed as a limit part at a specified price.
What happens when a venue is unavailable?
The venue is checked before the order is sent, not after. After a series of errors, it is automatically removed from the route for a time, pending orders are canceled, and the flow goes through the remaining directions.
Are the costs of transferring funds between venues taken into account?
We count not only the fee but also transfer time and the risk of non-arrival. If the costs eat up the price difference, the route through that venue is not considered at all.
How difficult is it to integrate this into an already running system?
The router connects to your gateway through an adapter; the trading workflow and accounting remain the same. We enable it in stages: first part of the flow, with the ability to return processing to the previous workflow.
What is needed to start and how we will return with an estimate
To estimate a smart order routing algorithm, we need your context, not general wishes: without input data, any stage plan turns into guesswork. Below is what is sufficient to hand over at the first step. If some information exists only in a trader's head or in old logs, we will sort it out together.
- List of venues and instruments across which orders need to be distributed, including those planned for connection.
- Current execution rules: how the route is selected now — manually, by script, or by an external service — and what exactly is unsatisfactory about them.
- Execution quality indicators that you consider the norm: filled order share, price deviation from expected, time from decision to trade.
- Risk constraints: limits per venue and instrument, behavior during partial execution, what to do when one of the directions is unavailable.
- Nature of the order flow: frequencies, typical sizes, distribution over time — this determines how fast route calculation needs to be.
- Observability requirements: which events and metrics need to be seen in real time, what to store for incident investigation.
- Infrastructure constraints: where the algorithm will run, what access and environments already exist, who is responsible for operations after launch.
After that, the order is as follows: we discuss the task, study the submitted materials, and check key assumptions against historical data. Then we return with an estimate, a stage plan, and a scope of work — with a clear division of what we cover and what remains on your side.