# Smart order routing in crypto: how routers pick venues

URL: https://fincodelabs.com/en/blog/smart-order-routing-crypto · Publisher: Fincode (Fincode Yazılım ve Teknoloji A.Ş.), Istanbul, Turkey · Category: Fintech development · Published: 2026-11-05 · Updated: 2026-11-05

Smart order routing in crypto: merged depth, fee-adjusted price, balances per venue, partial fills, re-routing, Binance SOR and where regulation starts.

**Short answer:** **Smart order routing in crypto** means software that splits one order across venues or order books and re-routes whatever stays unfilled. It compares merged depth after fees, the balance held on each venue, latency and the chance of a fill. Crypto routers differ from stock routers because each venue has its own API and data feed, the router must build its own merged view and balances must be pre-funded. A router can only choose among prices available at that moment; it promises no result, and trading can lose money.

Search results on this topic are full of vendor posts quoting percentage improvements with no method behind them. This guide repeats none of those figures. It explains how a router makes its decision, what crypto changes and how to test a claim yourself.

Exchange details come from official documentation read on 4 November 2026, as examples rather than recommendations; all prices in the code are hypothetical. Order state handling is covered in [crypto order management system](https://fincodelabs.com/en/blog/crypto-order-management-system) and building a live book in the [local order book guide](https://fincodelabs.com/en/blog/websocket-order-book).

## What does smart order routing mean?

Smart order routing means choosing where and how to send each part of an order by a written rule, instead of sending all of it to one place.

**Two scopes of smart order routing**

| Question | Inside one exchange | Across exchanges |
| --- | --- | --- |
| Who runs it | The exchange's matching system | Your own software, or a vendor's |
| What it compares | That exchange's related order books | Separate books with separate fees |
| Balances | One account | One pre-funded balance per venue |
| Main failure | Remainder handling | Stale data, partial fills and lost replies across several APIs |

Most of this guide covers the second case, because that is what a multi-exchange buyer has to build or commission. The router can be one component of an execution system, sitting behind the record-keeping layer.

## How does a smart order router work?

A router ranks possible fills by what they would really cost, then caps them by what the account can actually do.

**Router inputs, with official examples read on 4 November 2026 (alphabetical within cells)**

| Input | Why it matters | Documented source |
| --- | --- | --- |
| Depth | Shows the size at each price | Binance `GET /api/v3/depth`, up to 5,000 levels at weight 5 to 250; Coinbase `GET /api/v3/brokerage/market/product_book`; Kraken `GET /0/public/Depth`, 1 to 500 levels |
| Your fee rate | A better raw price can cost more after fees | Binance `GET /api/v3/account/commission`; Coinbase `transaction_summary`; Kraken `TradeVolume` |
| Balance per venue | An order cannot exceed the funds on that venue | Each venue's private balance endpoint |
| Symbol rules | Legs must fit tick, lot and minimum value rules | Binance `exchangeInfo`: for `BTCUSDT`, tick 0.01, step 0.00001, minimum notional 5 USDT |
| Latency | An old snapshot overstates what is available | Your own timing measurements |
| Request budget | Re-querying uses up limits | Binance 6,000 weight per minute in live `exchangeInfo`; Kraken call counter of 15 or 20 by tier |

Use your account's actual rates from those endpoints rather than a public fee table, since rates can vary by tier and symbol. Connecting to several exchanges through one library is covered in the [CCXT guide](https://fincodelabs.com/en/blog/ccxt-python-trading-bot).

## Smart order routing algorithms: a tested sketch

The basic algorithm sorts every level on every venue by all-in price and takes from the best until the order is done, a limit is reached or a balance runs out.

```python
from decimal import Decimal as D, ROUND_DOWN

venues = {   # hypothetical taker fees, quote balances and asks (price, size)
    "A": {"fee": D("0.0010"), "cash": D("30000"),
          "asks": [(D("100.00"), D("200")), (D("100.20"), D("400"))]},
    "B": {"fee": D("0.0030"), "cash": D("60000"),
          "asks": [(D("99.90"), D("300")), (D("100.10"), D("400"))]},
    "C": {"fee": D("0.0005"), "cash": D("10000"),
          "asks": [(D("100.02"), D("500"))]},
}
STEP = D("0.001")

def route_buy(venues, qty, max_all_in):
    levels = sorted((px * (1 + v["fee"]), px, size, name)
                    for name, v in venues.items() for px, size in v["asks"])
    left, spent, plan = qty, {n: D(0) for n in venues}, []
    for all_in, px, size, name in levels:
        if left <= 0 or all_in > max_all_in:
            break
        room = (venues[name]["cash"] - spent[name]) / all_in
        take = min(left, size, room).quantize(STEP, rounding=ROUND_DOWN)
        if take > 0:
            plan.append((name, px, take, round(all_in, 4)))
            spent[name] += take * all_in
            left -= take
    return plan, left, sum(spent.values())

plan, left, cost = route_buy(venues, D("550"), D("100.25"))
for leg in plan:
    print(leg[0], "price", leg[1], "qty", leg[2], "all-in", leg[3])
print("unfilled", left, "total cost", round(cost, 2))

# For comparison: all 550 on venue B, the best raw price, with no all-in limit
only_b = (D("99.90") * 300 + D("100.10") * 250) * (1 + venues["B"]["fee"])
print("venue B only", round(only_b, 2))
```

Output, on the hypothetical books above:

```
C price 100.02 qty 99.930 all-in 100.0700
A price 100.00 qty 200.000 all-in 100.1000
B price 99.90 qty 250.070 all-in 100.1997
unfilled 0.000 total cost 55076.94
venue B only 55159.98
```

Venue B shows the best raw price, yet its fee pushes that level to third place, and venue C's balance caps its leg at 99.93 units. The comparison line drops the router's 100.25 limit, since venue B's second level costs 100.40 all-in, and it is arithmetic on invented numbers: it shows why fees and balances belong in the ranking, and it says nothing about real markets or the fills you would get.

Real routers add design choices that the rules owner must decide and test, such as:

- counting only part of the displayed size, because some of it may be gone on arrival;
- ignoring a venue whose snapshot is older than a set age;
- skipping legs below the venue's minimum value;
- slicing large orders over time rather than sending them at once.

## Partial fills and re-routing rules

Every leg can fill partly or return no answer, so the re-routing rules must exist before the first order goes out.

1. Send legs with a time-in-force that cannot leave an unintended resting order. Binance documents `EXPIRED` as the status for `LIMIT IOC` or `MARKET` orders that partially fill.
2. Use the filled quantity from exchange events, never the requested one.
3. Treat a timed-out leg as possibly filled, and reserve its quantity until a query settles it.
4. Re-route the remainder on a fresh snapshot under the same overall limit price.
5. Stop after a set number of attempts, or when the all-in price passes the limit, and report what is left.

> **Hypothetical example.** A router sends 200 units to venue A and 250 to venue B to complete a 450-unit buy. A fills 120 and B times out. The remainder for immediate re-routing is 450 − 120 − 250 = 80, because B's 250 stays reserved. If a query then shows B filled 250, those 80 complete the order. If B filled nothing, another 250 can go out. Re-routing all 330 at once risks buying too much.

## What is different about crypto routing?

Crypto routing differs from stock routing in three structural ways: a self-built market view, pre-funded balances and quote assets that are not interchangeable by default.

- **No consolidated tape that we could find.** US exchange-listed stocks have consolidated market data under SEC rules, which the agency moved to modernize in December 2020. We found no regulator-run equivalent for crypto when this was checked on 4 November 2026, so plan for a router that builds its own merged view from venue feeds that arrive at different times, in different formats.
- **Pre-funded balances.** An order needs funds on that venue when it is sent; Binance's [error list](https://github.com/binance/binance-spot-api-docs/blob/master/errors.md) includes a rejection for insufficient balance. An on-chain transfer cannot rescue a live order, so moving balances is a separate treasury job with its own costs and risks.
- **Quote assets.** `BTCUSDT` and `BTC-USD` are different markets. Treat a stablecoin and a currency as the same asset only under an explicit rule, and record the difference.

Each venue also has its own API, symbols, precision and limits, which is why the adapter layer in an OMS matters. Venue choice adds counterparty and legal questions that no routing formula answers.

## Binance SOR: a router inside one exchange

Binance documents a smart order routing feature that fills an order from its own order books with the same base asset and interchangeable quote assets, defined as quote assets with a fixed 1 to 1 rate.

Its FAQ uses fictional books and ignores commission: a 5 BTC limit buy costs 153,100 USDT on the submitted book alone and 148,000 USDT with SOR across three books. What a builder should note, per the documentation read on 4 November 2026:

- Orders go to `POST /api/v3/sor/order`, which accepts only `LIMIT` and `MARKET` types and not `quoteOrderQty`.
- When selling, you always receive the quote asset of the symbol in your order.
- If the eligible books cannot fill the order, `LIMIT IOC` and `MARKET` orders expire, while the rest of a `LIMIT GTC` order rests on the original book.
- The `sors` field in `exchangeInfo` appears only where SOR is available. It was absent from the production, public data and testnet hosts when requested on 4 November 2026, so read it at run time and do not assume the feature is on.

This feature routes within one exchange. It does not compare other venues, and describing it is no recommendation of the platform.

## Patents and performance claims: what they can tell you

A patent can show a design and a vendor figure can start a conversation, but neither proves that a router will perform for you.

US patent 11,580,600 B2, "Distributed crypto-currency smart order router with cost calculator", was granted on 14 February 2023, and its [front page](https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/11580600) names CoinRoutes Inc. as assignee. Its first claim separates a decision engine in a central cloud, which does not hold exchange keys, from a router in the user's own cloud, which holds the keys and places the orders. That separation is a useful idea to study. Have a patent attorney review any similar commercial design, since Google Patents shows the status as active while noting it has made no legal analysis.

When a vendor quotes an improvement figure, ask:

- What was the baseline: one venue, the best venue or an arrival price?
- Are fees, partial fills and unfilled remainders included?
- Which period, symbols and order sizes were measured, and who measured them?

Then measure your own orders: the all-in average price against the mid-price when the order arrived, with unfilled quantity reported beside it. Past measurements do not guarantee later results.

## When routing orders becomes a regulated service

Routing your own orders under your own rules is software; routing clients' orders is regulated in many jurisdictions.

In the EU, MiCA lists execution of orders and reception and transmission of orders on behalf of clients as crypto-asset services (Article 3(1)(16)(e) and (g)). Article 78(1) requires firms executing client orders to take all necessary steps to obtain the best possible result, and Article 80(2) bars taking payment for directing client orders to a particular platform. For contrast, MiFID II Article 27 sets a best execution duty for financial instruments and names price, costs, speed, likelihood of execution and settlement, size and nature as factors. Those factors make a good checklist for your own routing rules, even when no such duty applies to you. This is not legal advice.

Rules depend on your jurisdiction and each platform's terms. For readers in Turkey, Article 99/A of Capital Markets Law No. 6362 treats activity by foreign platforms directed at Turkish residents as unauthorized, and the Capital Markets Board (SPK) says being on its [operating list](https://spk.gov.tr/kurumlar/kripto-varlik-hizmet-saglayicilar/faaliyette-bulunanlar-listesi) does not mean a firm is authorized. Never use routing to trade with yourself across venues or to create artificial volume; that is market abuse, whatever the software.

Fincode is a software company: it builds to rules the customer has written, on the customer's own accounts and keys, and does not route client orders or recommend strategies or venues. See [exchange API integration](https://fincodelabs.com/en/services/exchange-api-integration).

## Frequently asked questions

### Does a smart order router guarantee a better price?

No. It chooses among the prices it can see at that moment, and those can change before an order arrives. Fees, partial fills and latency all affect the result, and trading can lose money.

### What is the difference between a smart order router and an OMS?

An OMS keeps the record and state of orders. A router decides where the parts of an order should go. The router normally sits behind the OMS as a replaceable component.

### Do I need to hold funds on every exchange?

Yes, for spot orders placed through each venue's API. A leg can only use the balance already on that venue, so the router must cap each leg by available funds.

### Can I use a smart order router with client money?

That is usually a regulated activity. Under MiCA, executing or transmitting orders on behalf of clients requires authorization, so take legal advice in your jurisdiction before offering it.

## Sources

- [Binance Spot API documentation: Smart Order Routing FAQ (fictional example books)](https://github.com/binance/binance-spot-api-docs/blob/master/faqs/sor_faq.md)
- [Binance Spot API documentation: REST API (depth, commission, SOR order and exchangeInfo)](https://github.com/binance/binance-spot-api-docs/blob/master/rest-api.md)
- [Binance Spot API documentation: Enum definitions (EXPIRED status)](https://github.com/binance/binance-spot-api-docs/blob/master/enums.md)
- [Coinbase Advanced Trade: REST endpoints (public order book)](https://docs.cdp.coinbase.com/coinbase-app/advanced-trade-apis/rest-api)
- [Coinbase Advanced Trade API: Get Transaction Summary (fee tier)](https://docs.cdp.coinbase.com/api-reference/advanced-trade-api/rest-api/fees/get-transaction-summary)
- [Kraken: Get Order Book (public Depth endpoint)](https://docs.kraken.com/api-reference/market-data/get-order-book)
- [Kraken: Get Trade Volume (fee per pair)](https://docs.kraken.com/api-reference/account-data/get-trade-volume)
- [Kraken: Spot REST rate limits](https://docs.kraken.com/exchange/guides/rest/ratelimits)
- [Google Patents: US11580600B2, Distributed crypto-currency smart order router with cost calculator](https://patents.google.com/patent/US11580600B2/en)
- [SEC press release 2020-311: rules to modernize the market data infrastructure for NMS stocks (9 December 2020)](https://www.sec.gov/newsroom/press-releases/2020-311)
- [ESMA interactive single rulebook: MiCA Article 3, definitions](https://www.esma.europa.eu/publications-and-data/interactive-single-rulebook/mica/article-3-definitions)
- [ESMA interactive single rulebook: MiCA Article 78, execution of orders](https://www.esma.europa.eu/publications-and-data/interactive-single-rulebook/mica/article-78-execution-orders-crypto-assets)
- [ESMA interactive single rulebook: MiCA Article 80, reception and transmission of orders](https://www.esma.europa.eu/publications-and-data/interactive-single-rulebook/mica/article-80-reception-and-transmission-orders)
- [ESMA interactive single rulebook: MiFID II Article 27, best execution](https://www.esma.europa.eu/publications-and-data/interactive-single-rulebook/mifid-ii/article-27-obligation-execute-orders)
- [Capital Markets Law No. 6362, consolidated text, Article 99/A (Turkish)](https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6362.pdf)

> This guide is general information about software and markets, not investment, legal or tax advice. Automated trading can lose money, past or backtested performance does not guarantee future results, and the rules that apply depend on your jurisdiction and your exchange's terms. Sources, checks and corrections: see the [editorial policy](https://fincodelabs.com/en/editorial-policy).

---

Published by Fincode (Fincode Yazılım ve Teknoloji A.Ş.), a software company in Istanbul, Turkey: https://fincodelabs.com/en/blog/smart-order-routing-crypto

Cite as: Fincode, "Smart order routing in crypto: how routers pick venues", updated November 5, 2026, https://fincodelabs.com/en/blog/smart-order-routing-crypto