Smart Order Routing in Crypto vs. Traditional Finance

Market Fragmentation and Data Infrastructure

The most fundamental difference between crypto and TradFi SOR is the state of market data infrastructure.

In U.S. equities, the Consolidated Tape Association (CTA) and the UTP Plan provide a single, regulated feed of the national best bid and offer (NBBO) across all exchanges. Every market participant sees the same prices, and the SEC's Order Protection Rule prevents trades from executing at prices worse than the NBBO. This means that SOR in equities is primarily an optimization problem around fees, rebates, and latency, since the price dimension is largely solved by regulation.

Crypto has no equivalent. Each exchange publishes its own order book, and there is no authoritative aggregated view. The bid-ask spread for BTC/USDT on Binance may differ meaningfully from the same pair on Coinbase, Kraken, or OKX at any given moment. During volatile periods, these discrepancies widen dramatically.

For SOR engines, this means the data aggregation layer must do much more heavy lifting. It is not enough to subscribe to a consolidated feed. The system must maintain direct connections to every venue, normalize different data formats, handle varying update frequencies (some exchanges push updates every 10ms, others every 100ms), and detect stale or anomalous data. The quality of the data aggregation layer is often the single biggest differentiator between SOR implementations in crypto.

Latency Profiles and Connectivity Challenges

In TradFi, latency optimization is measured in microseconds. Firms co-locate servers at exchange data centers, use kernel bypass networking, and invest millions in shaving nanoseconds off their round-trip times. The playing field, while expensive, is well understood.

Crypto latency operates on a fundamentally different timescale. Most exchange APIs introduce milliseconds of latency due to rate limiting, geographic distribution of matching engines, and the overhead of HTTP/REST protocols. While some exchanges offer co-location and FIX protocol access (which reduces latency), the baseline is orders of magnitude slower than equities.

This difference has important implications for SOR design. In equities, SOR decisions must be made in microseconds because opportunities vanish that quickly. In crypto, the SOR has more time to make decisions (milliseconds rather than microseconds), but it must also be more robust to adverse selection because stale quotes persist longer. A crypto SOR that routes to a venue based on a quote that is 50ms old faces a meaningful risk that the quote has already been taken by the time the order arrives.

Connectivity reliability is another challenge. Equity exchanges have contractual SLAs for uptime and data quality. Crypto exchanges experience outages during high-volatility events, precisely when reliable routing matters most. A production crypto SOR must include failover logic, circuit breakers, and venue health monitoring that would be considered excessive in TradFi.

Pre-Funding Requirements and Settlement Differences

Perhaps the most operationally significant difference between crypto and TradFi SOR is the pre-funding requirement.

In equities, a broker-dealer can route orders to any exchange through its clearing relationships without pre-positioning capital at each venue. This means the SOR engine's venue selection is unconstrained by capital allocation. The firm's full buying power is available regardless of which exchange receives the order.

In crypto, traders must deposit funds at each exchange before they can trade. A firm that wants to route across 20 exchanges must maintain balances at all 20. This creates a direct tradeoff: broader venue coverage (which improves execution quality) requires thinner capital distribution (which reduces the maximum order size at any individual venue).

This constraint fundamentally changes the SOR optimization problem. The routing engine cannot simply find the best price; it must find the best price given the available capital at each venue. If the best price is on an exchange where the firm has insufficient balance, the SOR must route to the next-best venue or split the order differently.

Advanced SOR platforms address this through predictive capital allocation. By analyzing historical trading patterns, the system anticipates which venues are likely to offer the best execution and pre-positions capital accordingly. Some platforms also support real-time capital rebalancing, though this is constrained by blockchain transfer times.

Settlement adds another layer of complexity. In equities, settlement is standardized at T+1. In crypto, settlement varies from instant (for on-exchange trades using pre-funded balances) to 30+ minutes (for cross-chain transfers requiring multiple confirmations). The SOR must factor settlement time into its venue scoring, particularly for traders who need to rapidly redeploy capital across venues.

DEX Integration: A Category That Does Not Exist in TradFi

Decentralized exchanges represent a category of liquidity that has no parallel in traditional finance. DEXs like Uniswap, Curve, and dYdX hold billions of dollars in liquidity that is accessible to anyone with a wallet, without the need for accounts, KYC, or pre-established relationships.

For a crypto SOR engine, DEX integration is both an opportunity and a challenge. The opportunity is clear: DEXs can offer better prices than centralized exchanges, particularly for long-tail tokens and during periods when CEX liquidity is thin. Some studies estimate that DEX liquidity accounts for 15-20% of total crypto trading volume, a share that has been growing steadily.

The challenges are substantial. Gas costs on Ethereum can add $5 to $50+ per transaction depending on network congestion, fundamentally changing the break-even calculus for routing. MEV (maximal extractable value) means that large DEX orders can be front-run by searchers who monitor the mempool, effectively imposing a hidden tax on execution. Slippage on AMM (automated market maker) pools follows a different mathematical model than order book slippage, requiring different optimization logic.

A complete crypto SOR must integrate both CEX and DEX liquidity, applying different cost models to each. For CEX venues, the model centers on order book depth and maker/taker fees. For DEX venues, it must account for gas costs, price impact curves specific to the AMM design (constant product, concentrated liquidity, etc.), and the probability and expected cost of MEV extraction.

Why Crypto SOR Must Be Purpose-Built

The cumulative effect of these differences is that SOR technology designed for traditional markets cannot be retrofitted for crypto. The data layer, optimization logic, execution management, and risk controls all require fundamental redesign.

Equity SOR assumes standardized protocols, reliable data feeds, unconstrained capital allocation, uniform settlement, and a regulatory framework that enforces price priority. Crypto SOR must handle heterogeneous APIs, unreliable data, capital-constrained routing, variable settlement, and an unregulated landscape where venues operate under different rules.

Institutional firms entering crypto sometimes attempt to extend their existing equity SOR to cover digital assets. This approach typically fails for two reasons: the integration burden of connecting to dozens of exchanges with unique APIs overwhelms systems designed for a handful of standardized venues, and the optimization logic produces suboptimal results because it does not account for crypto-specific cost factors like pre-funding constraints and gas costs.

The firms that achieve the best execution quality in crypto are those using purpose-built SOR platforms that were designed from the ground up for digital asset market structure. These platforms, like Mercury Pro, combine deep venue connectivity with crypto-native optimization logic and the operational infrastructure (capital management, settlement tracking, venue health monitoring) that institutional crypto trading demands.

What is smart order routing?

Smart order routing (SOR) is software that decides which venues receive an order, in what size and in what sequence, so the desk gets the best combined result on price, depth, fees, latency and venue reliability. In crypto there is no consolidated best price to route against, so the router has to build its own view of the market before it can route anything.

Smart order routing is the automatic splitting and directing of an order across several venues. Without it, a trader picks one exchange and accepts whatever that book offers. With it, the system looks at every venue the desk can reach, divides the order, and sends the pieces out together.

Two points are worth fixing early. A smart order router decides where an order goes. An execution algorithm decides when and how it is worked over time. The two are usually combined, and the Algo Suite shows how. And a smart order routing system is a stack, not a single feature: market data, a scoring model, an optimizer, an execution layer and a record of what happened.

For the one-paragraph definition, see the smart order routing glossary entry.

How a smart order routing system works

A typical router runs the same loop for every parent order.

1. Aggregate. It keeps live connections to each venue and liquidity provider, and merges their order books into one normalized view. This is liquidity aggregation.
2. Score. It estimates the all-in cost of trading at each venue: displayed price, the size available before the price moves, the fee schedule, how quickly the venue responds, and how reliable it has been.
3. Split. It divides the parent order into child orders, subject to limits such as the balance available at each venue and the maximum size per order.
4. Send and watch. It submits the child orders together, tracks fills and rejects, and reroutes what is left if a venue misses.
5. Record. It stores every decision and fill so the desk can review the result against a benchmark later.

Most failures happen in step 1 and step 4. A router that routes on stale data sends orders to prices that have gone, and a router with no plan for rejects leaves part of an order unfilled at the worst moment.

What the router weighs

The headline price is only one input. The table below lists what a routing engine has to weigh and what goes wrong when it is ignored.

Liquid Mercury's Sweep algorithm, for example, is documented as prioritizing liquidity depth, fee structure and latency when it routes. The weights a desk puts on each factor should reflect the desk's own policy, which is why configurable logic matters more than any one default. Regulators describe the same duty as best execution. In the EU, the framework for investment firms is MiFID II, and MiCA extends execution duties to crypto-asset service providers.

Withdrawal limits, stablecoin pairs and 24/7 markets

Withdrawal limits and transfer time. Moving inventory between venues is not instant. Venues can cap or delay withdrawals, and an on-chain transfer waits for confirmations. A router that ignores this will leave the desk with stock in the wrong place. Settlement time belongs in the venue score, especially for a desk that redeploys capital often.

Stablecoin pairs. The same asset trades against several quote currencies, including fiat and stablecoins. A router has to decide whether pairs are interchangeable, apply the conversion, and account for the risk that a stablecoin trades away from its peg. A price in one quote currency is not directly comparable to a price in another.

Markets also never close, venues go down in volatile periods, and rate limits and API behaviour differ by venue. A production router needs failover, venue health checks and a way to stop. The earlier equity router most firms already own is rarely a fit, because it assumes a consolidated feed, uniform protocols and capital that is not tied to a venue.

Smart order routing for OTC desks and exchanges

The word "routing" covers two different jobs. An exchange or a trading venue routes inbound orders to its own book. A desk or broker routes outbound orders to many venues and liquidity providers. The OTC desk sits in between, with its own needs.

For an OTC desk the question is not only where to send an order but which liquidity provider's quote to take and what to do with the risk afterward. A desk that quotes clients can internalize the trade, hedge it, or pass it straight through, and the hedge is itself a routing decision. For exchange operators, the connection side of the problem is covered in the guide to FIX API and crypto exchange connectivity, and for large clip sizes see crypto block trading.

What does a desk need to run smart order routing?

Whether you build or buy, the same list applies. Desks that evaluate routing tend to ask for the same two things: more liquidity providers behind one connection, and reporting that is easy to use. Each item below bears on one of them.

• Connections to the venues and providers you need. Exchanges, OTC liquidity providers and custodians, over the interfaces they offer. See crypto venue connectivity.
• One normalized book and one set of positions. Without it, limits mean different things on different venues.
• Balance and credit awareness. The router must know what the desk can spend at each venue before it sends the order.
• Risk checks before the order leaves. Size, notional and balance limits that reject a bad order at source.
• Configurable routing policy. Weights for price, depth, fees and latency that the desk sets, and a record of which policy applied.
• Failover and a stop. Venue health checks, rerouting, and a kill switch for the whole desk.
• A complete record. Every decision, child order and fill, in one place, with the benchmark used to judge it.
• A way to be wrong cheaply. Routing should be testable and reviewable before it handles client size.

If you are weighing an internal build against a purchase, count the maintenance of venue adapters as an ongoing cost. Each venue changes its interface over time, and each change is the desk's problem when it owns the adapter.

For the system that hosts the router, see crypto execution management system (EMS).

How Liquid Mercury's stack does it

Liquid Mercury, the Chicago-based institutional digital asset infrastructure provider, builds routing into its trading and OTC software.

Mercury Pro is Liquid Mercury's trading and execution platform. Its Mercury Pro page states 50+ venues connected across exchanges, OTC desks and liquidity providers. Its Sweep algorithm works in three steps. It aggregates order book data from several exchanges and liquidity providers, including OTC venues. It identifies the best available prices in real time and routes orders to multiple venues at once, prioritizing liquidity depth, fee structure and latency. It then chooses dynamically between market, limit and iceberg orders. Sweep supports spot, perpetuals, futures and options, and it is the base layer for several other algos in the Algo Suite. Orders pass through the Risk Engine, which runs pre-trade checks such as available balance, available credit, region restrictions, and per-order quantity and amount limits, before they reach a venue. A trader sees one order book and aggregated positions, risk and balances across connected venues.

Mercury OTC covers the OTC desk side. It lets a desk run RFQ, RFS and streaming quotes with single-dealer, multi-dealer or hybrid pricing, around the clock, and includes a dealing-book toolset to internalize, hedge or pass a trade through. Reporting spans compliance, risk and performance in one place. The platform is white-label, so the broker's clients see the broker's brand. K33, a Norwegian crypto exchange service and broker regulated by the Norwegian Financial Supervisory Authority, reported OTC trading volume growth of 5x across 200 trading pairs and 8 fiat currencies in its case study.

Desks that run an OTC business can see how these pieces combine on the OTC desks solution page. The connection layer, including FIX, REST and WebSocket, is covered in crypto venue connectivity.