Smart Order Routing en crypto : un ordre, douze venues, aucun NBBO

Vous devez acheter 400 BTC. Binance affiche la profondeur la plus importante. OKX et Bybit montrent chacun une taille correcte, un tick plus loin. Coinbase cote un meilleur prix affiché, mais en USD, pas en USDT. Le top of book de Kraken a l'air fantastique et date de 400 millisecondes. Upbit est encore meilleur, mais votre validation compliance pour la Corée n'existe pas, pas plus que vos KRW. Un trader actions face à ce désordre attraperait un smart order router et arrêterait d'y penser, parce qu'en actions les aspects difficiles du routage ont été intégrés dans la plomberie réglementaire il y a vingt ans. En crypto, c'est vous la plomberie. Il n'y a pas de tape consolidée, pas de règle de protection contre les trade-through, pas de plafond de frais, pas de règlement netté — et, plus fondamentalement encore, aucune possibilité de trader là où votre capital ne se trouve pas déjà.

Cet article traite de la construction du router malgré tout : le carnet consolidé et pourquoi le routage naïf au meilleur prix contre ce carnet perd de l'argent, le problème d'allocation formulé comme un programme convexe que l'on peut réellement résoudre dans le délai imparti à un ordre enfant, la contrainte de capital qui rend le SOR crypto indissociable de la gestion de trésorerie, le routage maker-aware entre venues, et la boucle de feedback TCA qui indique si tout cela fonctionne réellement. C'est le frère jumeau, côté ingénierie, de Complex Arbitrage Execution in Rust — cet article-là couvre les nanosecondes ; celui-ci couvre les décisions.

Ce que le SOR actions obtient gratuitement

Il vaut la peine d'être précis sur ce que le routage actions américain hérite de la réglementation, car chaque élément de la liste est une chose que vous devez reconstruire ou dont vous devez consciemment vous passer.

Regulation NMS (SEC, 2005) a fait trois choses importantes ici. La Rule 611, l'Order Protection Rule, interdit d'exécuter à un prix moins bon qu'une cotation protégée affichée sur une autre bourse — un « trade-through » — ce qui oblige chaque broker soit à router vers le meilleur prix affiché, soit à le balayer avec des intermarket sweep orders. La Rule 610 plafonne les frais d'accès qu'une venue peut facturer pour taker une cotation protégée à 0,003 $ par action, si bien que les prix affichés sont comparables entre venues à 30 mils près. Et la tape consolidée (les SIP) publie un National Best Bid and Offer, une seule réponse officielle à la question « quel est le marché ».

Le verdict académique sur cette architecture est qu'elle fonctionne étonnamment bien. O'Hara and Ye (2011), « Is market fragmentation harming market quality? » (Journal of Financial Economics 100(3), 459–474), ont examiné des actions américaines à différents niveaux de fragmentation et ont constaté que les titres les plus fragmentés avaient des coûts de transaction plus faibles et des exécutions plus rapides, avec des prix plus proches d'une marche aléatoire. Leur résumé est la formule clé : les actions américaines se comportent comme « un marché virtuel unique avec de multiples points d'entrée ». La fragmentation est inoffensive lorsque des routers intelligents combinés à la protection contre les trade-through recousent les fragments entre eux. Foucault and Menkveld (2008), « Competition for Order Flow and Smart Order Routing Systems » (Journal of Finance 63(1), 119–158), ont montré le mécanisme sur le marché néerlandais : lorsqu'un second carnet d'ordres à cours limité (le LSE's EuroSETS) est entré en concurrence avec Euronext, la profondeur consolidée a augmenté, et l'offre de liquidité sur une venue était directement amortie par son taux de trade-through — les routers qui ignorent une venue tuent son incitation à coter.

Même dans ce monde réglementé, la vue consolidée est un mensonge aux horizons courts. Ding, Hanna, and Hendershott (2014), « How Slow Is the NBBO? A Comparison with Direct Exchange Feeds » (Financial Review 49(2), 313–332), ont mesuré le NBBO du SIP par rapport à un NBBO construit à partir de flux directs des bourses dans le même data center, et ont trouvé des dislocations plusieurs fois par seconde sur les valeurs actives, durant typiquement une à deux millisecondes — pure latence d'agrégation et de transport. Gardez ce chiffre en tête : c'est la version actions d'un problème qui est un à deux ordres de grandeur pire en crypto.

Maintenant, effacez tout cela. La crypto n'a pas de NBBO parce qu'il n'y a pas de SIP. Pas de règle de trade-through : une venue vous exécutera avec plaisir à un prix cinq ticks à travers la cotation d'une autre venue, et personne ne dépose de plainte. Pas de plafond de frais : les frais taker vont de tiers négociés inférieurs au point de base à des grilles retail de 10 pb, si bien que le classement par prix affiché et le classement par prix net divergent couramment. Et pas de compensation consolidée : chaque bourse est son propre silo avec des soldes préfinancés. Vous êtes à la fois le SIP, le router et la chambre de compensation.

Construire le carnet consolidé, et pourquoi le routage naïf au meilleur prix échoue

La base d'ingénierie n'a rien de glamour : N flux WebSocket L2, gestion des trous de numéro de séquence par venue, normalisation des symboles et des pas de cotation, et normalisation de la devise de cotation (un carnet BTC-USD et un carnet BTC-USDT diffèrent du taux USDT/USD, qui n'est pas identiquement égal à 1,0 et occasionnellement très loin de l'être). Fusionnez les carnets normalisés en une échelle unique triée par prix, en taguant chaque niveau avec sa venue et — c'est essentiel — l'âge du snapshot dont il provient. Si votre carnet fusionné ne porte pas l'âge de cotation par venue comme champ de première classe, vous avez construit un économiseur d'écran, pas un router.

Le router naïf parcourt cette échelle fusionnée de façon gloutonne : le meilleur prix net d'abord. Il échoue pour trois raisons distinctes, et il vaut la peine de les garder distinctes car les corrections sont différentes.

Cotations obsolètes et décalage de latence. Vos venues ne délivrent pas les données avec la même latence. Un flux colocalisé peut avoir 3 ms d'âge quand vous agissez dessus ; un WebSocket public d'une venue sur un autre continent peut avoir 300 ms d'âge. Le top of book fusionné est donc un composite de passés différents. Quand le BTC bouge de 10 pb en 200 ms — ce qui est routinier — les cotations de la venue obsolète semblent systématiquement attractives exactement du mauvais côté. Router vers elles vous fait acheter une course que vous avez déjà perdue : la cotation a disparu, votre IOC revient vide ou partiellement exécuté, et le temps que vous re-routiez, les venues fraîches se sont repricées. C'est le problème de dislocation SIP de 1 à 2 ms de Ding–Hanna–Hendershott, sauf que vos dislocations durent des centaines de millisecondes et que personne n'est obligé d'honorer quoi que ce soit.

Liquidité fantôme. Sommer la taille affichée entre venues surestime, car le même inventaire de market maker est coté à plusieurs endroits simultanément. Van Kervel (2015), « Competition for Order Flow with Fast and Slow Traders » (Review of Financial Studies 28(7), 2094–2127), a documenté cela sur les actions fragmentées : une transaction sur une venue est suivie en quelques millisecondes par des annulations massives d'ordres limites sur les venues concurrentes, exactement comme le prédit un modèle où des fournisseurs de liquidité rapides cotent partout des tailles dupliquées et retirent les copies dès qu'une est touchée. Les market makers crypto appliquent le même playbook sur Binance/OKX/Bybit, si bien que la profondeur consolidée accessible est nettement inférieure à la profondeur consolidée affichée, et le manque à gagner croît avec le degré de séquentialité (plutôt que de simultanéité) avec lequel vous touchez les venues. Si votre router envoie les ordres enfants une venue à la fois, en attendant la confirmation d'exécution de chacune, vous vous auto-cannibalisez : chaque exécution signale au reste de la place d'annuler.

Les frais réordonnent l'échelle. Une venue affichant le meilleur prix brut avec un frais taker de 7,5 pb est souvent le pire prix net du carnet. Cela paraît trop évident pour être énoncé, et pourtant c'est exactement ce qu'implémentent la plupart des routers crypto de première génération (et plusieurs produits de fournisseurs) : le routage au « meilleur prix affiché ». La comparaison nette de frais est le minimum requis ; l'article jumeau sur les frais et rebates maker-taker couvre le calcul des frais par venue, la dynamique des paliers VIP, et pourquoi votre palier de frais marginal — pas l'étiquette affichée — a sa place dans le router.

L'optimisation du routage

Formalisons le problème de l'ordre enfant. Vous devez acheter une quantité $Q$ maintenant, de façon marketable, à travers des venues $v = 1,\dots,V$. Soit $A_v(x)$ le prix ask marginal de la venue $v$ après avoir consommé $x$ unités de son carnet (une fonction en escalier non décroissante issue du snapshot L2), $f_v$ son frais taker, et $\lambda_v$ une pénalité par unité pour l'obsolescence et la sélection adverse sur la venue $v$ (calibrée plus loin, à partir de vos propres markouts). L'allocation $q = (q_1, \dots, q_V)$ résout

Chaque $C_v$ est convexe (intégrale d'une fonction non décroissante, plus un terme linéaire), donc le problème est convexe, et les conditions KKT racontent toute l'histoire : il existe un seuil $\mu$ tel que

et $C_v'(0) \ge \mu$ pour les venues ne recevant rien. En clair : déversez l'ordre à travers les venues comme de l'eau, en égalisant le coût marginal all-in partout où vous tradez. Une venue est exclue exactement quand sa première unité — meilleur prix, plus frais, plus pénalité d'obsolescence — est pire que l'unité marginale ailleurs.

Pour des carnets en fonction en escalier, la solution de water-filling se calcule par un parcours glouton de l'échelle fusionnée ajustée des frais et pénalités — le parcours glouton en profondeur n'est donc pas faux en soi ; c'est la solution exacte à condition de parcourir de façon gloutonne les coûts marginaux nets avec des tailles décotées, et non les prix bruts affichés. Cette distinction fait toute la différence entre un router et un économiseur d'écran.

Le traitement canonique du problème général se trouve chez Cont and Kukanov, « Optimal order placement in limit order markets » (Quantitative Finance 17(1), 21–39, 2017 ; arXiv:1210.1625). Ils formulent le placement d'ordres entre venues — y compris la répartition entre ordres limites et ordres au marché, les frais et rebates, et une pénalité pour le risque d'exécution — comme une optimisation convexe, dérivent une forme fermée explicite pour la répartition limite/marché sur une seule venue, et fournissent un algorithme d'approximation stochastique pour le cas multi-venues qui calcule une allocation sur douze bourses en moins de 200 ms. Le cadre précède la crypto mais se transpose presque sans modification, car il n'a jamais supposé de NBBO au départ — il ne supposait que des carnets par venue, des frais par venue, et une incertitude sur les exécutions, ce qui est précisément la situation crypto.

Une esquisse minimale et honnête du côté marketable (le water-fill convexe avec décotes d'obsolescence) :

import math
from dataclasses import dataclass

@dataclass
class Venue:
    name: str
    asks: list[tuple[float, float]]  # (price, displayed size), sorted
    taker_fee: float                 # fractional, e.g. 0.0002 = 2 bps
    quote_age_ms: float
    kappa: float                     # phantom-liquidity decay rate, 1/ms
    lam: float                       # staleness/toxicity penalty, $ per unit

def allocate(venues: list[Venue], Q: float):
    ladder = []  # (marginal all-in cost, accessible qty, venue)
    for v in venues:
        surv = math.exp(-v.kappa * v.quote_age_ms)  # P(level still there)
        for price, size in v.asks:
            cost = price * (1.0 + v.taker_fee) + v.lam
            ladder.append((cost, size * surv, v.name))
    ladder.sort()

    fills, remaining = {}, Q
    for cost, qty, name in ladder:
        take = min(qty, remaining)
        fills[name] = fills.get(name, 0.0) + take
        remaining -= take
        if remaining <= 1e-12:
            break
    return fills, remaining  # remaining > 0 => book too thin: slice parent

Seize lignes de logique ; toute l'intelligence réside dans les inputs. $\kappa$ (la vitesse à laquelle la taille affichée s'évapore avec l'âge de la cotation) est calibré à partir de vos propres ratios d'exécution IOC en fonction de l'âge de la cotation au moment de l'envoi. $\lambda_v$ provient des markouts par venue (dernière section). Les deux sont mesurés, pas devinés.

Un exemple chiffré. Acheter $Q = 10$ BTC sur trois venues :

La tape brute dit que C a le meilleur ask (86 990), puis B. Ajustez des frais et l'échelle se réordonne complètement : le niveau supérieur de C net donne $86\,990 \times 1{,}00075 = 87\,055$, la pire liquidité à l'écran. Le sommet de B net 87 004, celui de A net 87 017. Appliquez une décote d'obsolescence de 30 % à la taille affichée de B ($e^{-\kappa \cdot 250\text{ms}} \approx 0{,}7$) et faites le water-fill : 1,05 BTC du premier niveau de B, 3,0 du premier de A, 1,4 du second de B, 4,0 du second de A, 0,55 du troisième de A. Moyenne all-in : **87 022,2 $par BTC**. Le router naïf au meilleur prix affiché — C d'abord, puis B à taille faciale, puis le second niveau de C — paie 87 038,8$ : 1,9 pb de plus, soit environ 166 $ sur un seul ordre enfant de 10 BTC, qui se compose sur chaque enfant de chaque parent, toute la journée. Et notez la chute : la venue au meilleur prix affiché sur la tape n'a reçu aucun flux du router optimisé. En crypto, personne ne vous force à trader là-bas — router à travers une « cotation protégée » n'est pas un concept — et l'allocation correcte ignore fréquemment le meilleur prix apparent purement et simplement.

Ce que le programme convexe ignore encore : la simultanéité (tirer tous les enfants de toutes les venues dans la même milliseconde, sinon les annulations de van Kervel repriceront les venues en cours d'exécution), les tailles de lot discrètes et les notionnels minimums (arrondir la solution continue, corriger de façon gloutonne), et l'option de ne pas croiser le spread du tout — c'est le sujet de la section 5. Pour la question plus profonde de savoir comment de gros ordres parents doivent être découpés dans le temps avant que toute cette logique de venue n'intervienne, voir Almgren–Chriss optimal execution ; le SOR décide où va un enfant, pas quand les enfants surviennent.

La contrainte de capital : le SOR est de la gestion de trésorerie

Tout ce qui précède a implicitement supposé que vous pouvez trader $q_v$ sur la venue $v$. En actions, cette hypothèse est gratuite : un seul prime broker, un règlement netté, on trade maintenant et on déplace l'argent plus tard. En crypto, c'est la contrainte contraignante de tout le système. Les bourses exigent des soldes préfinancés — vous ne pouvez pas lever l'ask de Kraken avec de l'USDT qui se trouve sur Binance. Le vrai problème est donc

où $B_v$ est votre solde disponible sur la venue $v$ (dans l'actif de cotation pour les achats, l'actif de base pour les ventes). Les conditions KKT s'écrivent désormais $C_v'(q_v^*) = \mu - \eta_v$ avec $\eta_v \ge 0$ le multiplicateur associé au plafond de solde. Sur les venues plafonnées, $\eta_v = \mu - C_v'(B_v) > 0$ : le dollar marginal s'y exécute moins cher que le niveau d'eau du marché global, et vous êtes forcé de pousser du flux vers des venues plus chères. Ce multiplicateur n'est pas une abstraction — $\eta_v$ représente littéralement les dollars par unité que vous économiseriez si une unité de solde supplémentaire existait sur la venue $v$ à cet instant précis. Sommé sur votre flux prévisionnel, c'est votre disposition à payer pour un transfert de rééquilibrage, et la décision de rééquilibrage devient une comparaison que n'importe quel système de trésorerie peut exécuter : déplacer l'inventaire quand

Le membre de droite n'est ni petit ni constant. Le BTC on-chain nécessite 2 à 6 confirmations (20 à 60 minutes) avant que les bourses ne le créditent ; les transferts ERC-20 prennent des minutes plus un gas qui s'envole précisément quand les marchés sont agités ; les rails TRC-20 et Solana sont plus rapides et moins chers mais pas universellement supportés ; et chaque bourse ajoute sa propre file de traitement des retraits, qui s'étire de quelques minutes à plusieurs heures précisément pendant les épisodes de volatilité, au moment où votre router a le plus besoin de déplacer l'inventaire. L'arithmétique complète du coût de transfert — frais, distributions de latence, et risque de prix porté en cours de vol — est développée dans l'article sur le funding-rate arbitrage, et se transpose telle quelle : un rééquilibrage SOR est le même objet qu'un transfert de jambe d'arbitrage, coûts compris.

C'est pourquoi le résultat académique à intérioriser ici n'est pas un article d'exécution mais Makarov and Schoar (2020), « Trading and Arbitrage in Cryptocurrency Markets » (Journal of Financial Economics 135(2), 293–319). Ils ont documenté des déviations de prix inter-bourses qui persistent pendant des jours voire des semaines — y compris la « prime kimchi » coréenne qui a dépassé 40 % début 2018 — et ont montré que les coûts de transaction ne peuvent pas les expliquer ; un capital d'arbitrage lent et soumis à des contrôles de capitaux, si. Les venues crypto ne sont pas le « marché virtuel unique avec de multiples points d'entrée » d'O'Hara–Ye. Ce sont des bassins partiellement segmentés reliés par des tuyaux lents et coûteux, et votre router vit à l'intérieur de cette segmentation. Un SOR crypto sans modèle de trésorerie n'est qu'un SOR actions qui se déguise.

En pratique, cela devient un contrôleur à deux échelles de temps. La boucle rapide (millisecondes) résout le water-fill contraint au sein des soldes courants, à chaque ordre enfant. La boucle lente (minutes à heures) surveille la série temporelle des prix fantômes $\eta_v$ et le flux prévisionnel, et programme des transferts quand la composante persistante de $\eta_v$ franchit le seuil du coût de transfert — avec de l'hystérésis, car faire faire des allers-retours à l'inventaire entre venues sur du bruit revient à offrir votre edge au réseau Tron. Les desks institutionnels compriment le problème avec du règlement hors bourse (Copper ClearLoop, Ceffu MirrorX) : le collatéral reste chez un dépositaire et est reflété vers les venues, ce qui réduit drastiquement la latence de transfert pour les venues supportées — cela réduit la contrainte, mais ne la supprime pas, et introduit sa propre ligne de risque de contrepartie.

Routage maker-aware et jeux de file d'attente inter-venues

Un router qui ne fait que croiser les spreads laisse de côté la liquidité la moins chère : la vôtre. Le cadre de Cont–Kukanov contient déjà la réponse — leur forme fermée sur une seule venue répartit un ordre entre poster et taker en fonction des frais, de la position dans la file et de l'aversion au risque d'exécution — et la version multi-venues la généralise : poster passivement sur les venues où (frais maker, longueur de file, probabilité d'exécution dans le délai de l'ordre enfant) dominent, taker sur les venues où l'immédiateté est bon marché, et traiter le reliquat passif non exécuté comme un flux qui rentre dans l'optimisation taker à l'échéance.

Deux particularités propres à la crypto rendent ceci plus riche que la version actions.

La chasse aux frais est un piège mesuré. Battalio, Corwin, and Jennings (2016), « Can Brokers Have It All? On the Relation between Make-Take Fees and Limit Order Execution Quality » (Journal of Finance 71(5)), ont montré que les brokers américains routant les ordres limites vers les venues offrant les meilleurs rebates délivraient des exécutions mesurablement moins bonnes — taux d'exécution plus faibles, qualité réalisée moindre — parce que la venue au rebate le plus élevé est celle où se trouve aussi l'ordre de tous les autres chasseurs de rebate : file la plus longue, exécutions les plus adverses. L'analogue crypto est exact. La venue payant le meilleur rebate maker attire les cotations passives de tous les market makers ; votre ordre rejoint une file profonde et s'exécute majoritairement quand le prix est sur le point de traverser votre niveau. L'économie maker nette de markout par venue (section suivante) classe régulièrement les venues à l'opposé de leurs grilles de frais.

Le décalage de latence est un jeu à double sens. Le même flux d'information inter-venues que van Kervel a documenté comme des annulations défensives est, vu de l'autre côté, un signal offensif : une transaction au sommet du carnet de Binance prédit des transactions et des annulations au niveau correspondant d'OKX dans les millisecondes qui suivent. Un router maker-aware doit donc (a) reprice ses ordres résiduels en fonction des événements des autres venues — en se calant sur un microprix inter-venues, pas sur le mid local — sinon il devient la contrepartie lente que les arbitragistes inter-venues viennent cueillir ; et (b) il peut jouer le jeu délibérément : poster sur la venue qui traîne, se couvrir sur la venue qui mène au moment de l'exécution. C'est de l'arbitrage de file d'attente inter-venues, et c'est la même structure de latence exploitée dans l'exécution d'arbitrage inter-bourses, simplement intégrée dans un mandat d'exécution plutôt que dans un book de stat-arb. L'exigence opérationnelle est identique : l'événement d'exécution sur la venue A et l'ordre de couverture vers la venue B doivent vivre dans le même chemin de code à un chiffre de milliseconde, sinon l'edge appartient à quelqu'un d'autre.

Mesurer la qualité du routage : markouts et classements

Les routers actions sont disciplinés par la divulgation Rule 605/606. Rien ne discipline le vôtre à part votre propre TCA — le cadre de implementation shortfall et TCA est le tableau de bord ; voici la tranche spécifique au router.

La mesure atomique est le markout par venue : pour chaque exécution, enregistrez le mid (consolidé, corrigé de la latence) à $t + \Delta$ pour $\Delta \in \{100\text{ms}, 1\text{s}, 10\text{s}, 1\text{min}\}$, signé de sorte qu'une valeur négative signifie que le marché a bougé contre votre exécution. Agrégez dans un classement all-in :

La colonne des frais dit que B est la venue bon marché. La colonne all-in dit que B est la venue chère : ses cotations obsolètes vous exécutent sélectivement quand le marché est déjà en train de les traverser, et le markout à 1 seconde en collecte la facture. Cette inversion — classement par frais contre classement par coût effectif — est le constat le plus systématique lorsque les desks construisent ce tableau pour la première fois, et c'est exactement le chiffre qui doit revenir dans le router : la pénalité $\lambda_v$ du programme convexe est le déficit de markout persistant par venue, mesuré, lissé, et mis à jour. Le router et la TCA forment une boucle fermée, ou aucun des deux ne fonctionne.

Un piège méthodologique : les classements construits à partir d'un router en production sont contaminés par un biais de sélection. Si le router envoie déjà le flux difficile et informé vers la venue profonde et le flux facile vers la venue bon marché, les markouts de la venue profonde paraissent injustement mauvais. La correction propre est une randomisation délibérée — router quelques pour cent des enfants de façon uniformément aléatoire (un router $\varepsilon$-greedy, que les quants reconnaîtront comme un bandit avec un a priori d'optimisation convexe) — de sorte qu'un contrefactuel existe. Cela coûte quelques points de base sur la tranche randomisée, et c'est la seule façon de prouver que les 95 % restants du flux sont bien routés.

La pile, donc : un carnet consolidé honnête en matière de latence ; un water-fill convexe sur les coûts marginaux nets avec des paramètres d'évaporation et de toxicité mesurés ; une boucle rapide contrainte par les soldes dont les prix fantômes pilotent une boucle lente consciente du coût de transfert ; un placement passif qui respecte les files d'attente et le flux d'information inter-venues ; et une TCA randomisée basée sur les markouts qui réinjecte chaque paramètre. Aucun de ces composants n'est individuellement complexe. C'est le système qui l'est — parce qu'en crypto, contrairement aux actions, aucun régulateur n'a construit la moindre couche pour vous, et le marché facture 2 pb par ordre enfant, pour toujours, jusqu'à ce que vous le fassiez vous-même.