Smart Order Routing nel crypto: un ordine, dodici venue, nessun NBBO

Devi comprare 400 BTC. Binance ha la profondità maggiore. OKX e Bybit mostrano entrambi una size decente un tick più larga. Coinbase quota un prezzo headline migliore, ma in USD, non in USDT. Il top of book di Kraken sembra fantastico ed è stale di 400 millisecondi. Upbit è ancora meglio, ma la tua approvazione compliance per la Corea non esiste, e nemmeno i tuoi KRW. Un trader azionario di fronte a questo caos prenderebbe uno smart order router e smetterebbe di pensarci, perché in ambito azionario le parti difficili del routing sono state regolamentate dentro l'infrastruttura vent'anni fa. Nel crypto l'infrastruttura sei tu. Non c'è consolidated tape, non c'è order-protection rule, non c'è fee cap, non c'è settlement netted — e, cosa più fondamentale, non hai la capacità di tradare dove il tuo capitale non è già posizionato.

Questo articolo parla di costruire comunque il router: il book consolidato e il motivo per cui il routing naive al best price contro di esso perde denaro, il problema dell'allocazione come programma convesso risolvibile entro la deadline di un child order, il vincolo di capitale che rende lo SOR crypto inseparabile dalla gestione della tesoreria, il routing maker-aware tra venue, e il feedback loop di TCA che dice se tutto questo funziona davvero. È il fratello ingegneristico di Complex Arbitrage Execution in Rust — quell'articolo copre i nanosecondi; questo copre le decisioni.

Cosa lo SOR azionario ottiene gratis

Vale la pena essere precisi su cosa il routing azionario US eredita dalla regolamentazione, perché ogni voce dell'elenco è qualcosa che devi ricostruire o consapevolmente vivere senza.

Regulation NMS (SEC, 2005) ha fatto tre cose rilevanti qui. La Rule 611, la Order Protection Rule, proibisce di eseguire a un prezzo peggiore di una quota protetta mostrata su un altro exchange — un "trade-through" — il che costringe ogni broker o a instradare verso il miglior prezzo mostrato o a "spazzarlo" con intermarket sweep orders. La Rule 610 mette un tetto alla access fee che qualsiasi venue può addebitare per prendere una quota protetta a $0.003 per azione, così i prezzi mostrati sono comparabili tra venue entro 30 mils. E il consolidated tape (i SIP) pubblica un National Best Bid and Offer, un'unica risposta ufficiale alla domanda "qual è il mercato".

Il verdetto accademico su questa architettura è che funziona sorprendentemente bene. O'Hara e Ye (2011), "Is market fragmentation harming market quality?" (Journal of Financial Economics 100(3), 459–474), hanno esaminato azioni US a diversi livelli di frammentazione e trovato che le azioni più frammentate avevano costi di transazione più bassi ed esecuzioni più veloci, con prezzi più vicini a un random walk. La loro sintesi è la frase chiave: le azioni US si comportano come "un singolo mercato virtuale con più punti di accesso". La frammentazione è innocua quando router intelligenti più trade-through protection ricuciono insieme i frammenti. Foucault e Menkveld (2008), "Competition for Order Flow and Smart Order Routing Systems" (Journal of Finance 63(1), 119–158), hanno mostrato il meccanismo nel mercato olandese: quando un secondo limit order book (LSE's EuroSETS) è entrato in competizione con Euronext, la profondità consolidata è aumentata, e l'offerta di liquidità su una venue era direttamente smorzata dal suo tasso di trade-through — i router che ignorano una venue ne uccidono l'incentivo a quotare.

Anche in questo mondo regolamentato, la vista consolidata è una bugia agli orizzonti brevi. Ding, Hanna e Hendershott (2014), "How Slow Is the NBBO? A Comparison with Direct Exchange Feeds" (Financial Review 49(2), 313–332), hanno misurato l'NBBO del SIP contro un NBBO costruito da feed diretti degli exchange nello stesso data center e hanno trovato dislocazioni diverse volte al secondo nei nomi attivi, tipicamente della durata di uno-due millisecondi — pura latenza di aggregazione e trasporto. Tieni a mente questo numero: è la versione azionaria di un problema che nel crypto è uno-due ordini di grandezza peggiore.

Ora cancella tutto questo. Il crypto non ha NBBO perché non c'è un SIP. Nessuna trade-through rule: una venue ti eseguirà volentieri a un prezzo cinque tick oltre la quota di un'altra venue, e nessuno deposita alcuna segnalazione. Nessun fee cap: le taker fee vanno da tier negoziati sub-basis-point a schedule retail di 10 bps, quindi l'ordinamento per prezzo mostrato e l'ordinamento per prezzo netto disaccordano regolarmente. E nessun clearing consolidato: ogni exchange è un proprio silo con saldi prefinanziati. Tu sei il SIP, il router, e la clearing firm, simultaneamente.

Costruire il book consolidato, e perché il routing naive al best price fallisce

La base ingegneristica non è affascinante: N feed WebSocket L2, gestione dei gap di sequence-number per venue, normalizzazione di simbolo e tick-size, e normalizzazione della valuta di quotazione (un book BTC-USD e un book BTC-USDT differiscono per il tasso USDT/USD, che non è identicamente 1.0 e occasionalmente molto lontano da esso). Unisci i book normalizzati in un'unica ladder ordinata per prezzo, taggando ogni livello con la sua venue e — cosa cruciale — l'età dello snapshot da cui proviene. Se il tuo book unito non porta l'età della quota per venue come campo di prima classe, hai costruito uno screensaver, non un router.

Il router naive percorre questa ladder unita in modo greedy: prima il miglior prezzo netto. Fallisce per tre ragioni distinte, ed è utile tenerle separate perché le correzioni sono diverse.

Quote stale e skew di latenza. Le tue venue non consegnano dati alla stessa latenza. Un feed colocato potrebbe essere vecchio di 3 ms quando agisci su di esso; un WebSocket pubblico da una venue su un altro continente potrebbe essere vecchio di 300 ms. Il top of book unito è quindi un composito di passati diversi. Quando il BTC si muove di 10 bps in 200 ms — cosa di routine — le quote della venue stale sembrano sistematicamente attraenti esattamente sul lato sbagliato. Instradare verso di esse ti fa comprare una gara che hai già perso: la quota è sparita, il tuo IOC torna vuoto o parzialmente eseguito, e nel momento in cui reinstradi, le venue fresche hanno già riprezzato. Questo è il problema di dislocazione SIP di 1-2 ms di Ding-Hanna-Hendershott, tranne che le tue dislocazioni durano centinaia di millisecondi e nessuno è obbligato a onorare alcunché.

Liquidità fantasma. Sommare la size mostrata tra venue sovraconta, perché lo stesso inventario di market maker è quotato in più posti contemporaneamente. Van Kervel (2015), "Competition for Order Flow with Fast and Slow Traders" (Review of Financial Studies 28(7), 2094–2127), ha documentato questo nelle azioni frammentate: un trade su una venue è seguito entro millisecondi da cancellazioni consistenti di limit order su venue concorrenti, esattamente come predetto da un modello in cui i liquidity provider veloci quotano size duplicata ovunque e ritirano le copie non appena una viene colpita. I market maker crypto seguono lo stesso copione tra Binance/OKX/Bybit, quindi la profondità consolidata accessibile è materialmente inferiore alla profondità consolidata mostrata, e il deficit cresce quanto più sequenzialmente (anziché simultaneamente) colpisci le venue. Se il tuo router invia child order una venue alla volta, aspettando la conferma di ogni fill, ti stai auto-sabotando: ogni fill segnala al resto della piazza di cancellare.

Le fee riordinano la ladder. Una venue che mostra il miglior prezzo grezzo con una taker fee di 7.5 bps è spesso il peggior prezzo netto del book. Sembra troppo ovvio da dire, eppure il routing "best displayed price" è esattamente ciò che implementano la maggior parte dei router crypto di prima generazione (e diversi prodotti vendor). Il confronto net-of-fee è il minimo indispensabile; l'articolo gemello su maker-taker fees e rebate copre la matematica delle fee per venue, le dinamiche dei tier VIP, e perché il tuo tier di fee marginale — non quello nominale — appartiene al router.

L'ottimizzazione di routing

Formalizziamo il problema del child order. Devi comprare quantità $Q$ ora, marketable, tra venue $v = 1,\dots,V$. Sia $A_v(x)$ il prezzo ask marginale della venue $v$ dopo aver consumato $x$ unità del suo book (una funzione a gradini non decrescente dallo snapshot L2), $f_v$ la sua taker fee, e $\lambda_v$ una penalità per unità per staleness e selezione avversa sulla venue $v$ (calibrata più sotto, dai tuoi stessi markout). L'allocazione $q = (q_1, \dots, q_V)$ risolve

Ogni $C_v$ è convessa (integrale di una funzione non decrescente, più un termine lineare), quindi il problema è convesso, e le condizioni KKT raccontano tutta la storia: esiste una soglia $\mu$ tale che

e $C_v'(0) \ge \mu$ per le venue che non ricevono nulla. In parole: versa l'ordine tra le venue come acqua, equalizzando il costo marginale all-in ovunque tu tradi. Una venue è esclusa esattamente quando la sua prima unità — prezzo migliore, più fee, più penalità di staleness — è peggiore dell'unità marginale altrove.

Per book a funzione a gradini, la soluzione water-filling si calcola con un percorso greedy sulla ladder unita aggiustata per fee e penalità — quindi il depth-walk greedy non è sbagliato di per sé; è la soluzione esatta a condizione che tu percorra greedy i costi marginali netti con size scontate, non i prezzi grezzi mostrati. Quella distinzione è l'intera differenza tra un router e uno screensaver.

Il trattamento canonico del problema generale è Cont e Kukanov, "Optimal order placement in limit order markets" (Quantitative Finance 17(1), 21–39, 2017; arXiv:1210.1625). Formulano il posizionamento degli ordini tra venue — inclusa la ripartizione tra ordini limit e market, fee e rebate, e una penalità per il rischio di esecuzione — come un'ottimizzazione convessa, derivano una forma chiusa esplicita per la ripartizione limit/market su singola venue, e forniscono un algoritmo di approssimazione stocastica per il caso multi-venue che calcola un'allocazione tra dodici exchange in meno di 200 ms. Il framework precede il crypto ma si trasferisce quasi intatto, perché non ha mai assunto un NBBO in primo luogo — assumeva solo book per venue, fee per venue, e incertezza sui fill, che è precisamente la situazione crypto.

Uno schizzo minimale e onesto del lato marketable (il water-fill convesso con haircut di staleness):

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

Sedici righe di logica; tutta l'intelligenza vive negli input. $\kappa$ (quanto velocemente la size mostrata evapora con l'età della quota) è calibrato dai tuoi stessi tassi di fill IOC in funzione dell'età della quota al momento dell'invio. $\lambda_v$ proviene dai markout per venue (sezione successiva). Entrambi sono misurati, non indovinati.

Un esempio lavorato. Compra $Q = 10$ BTC tra tre venue:

Il tape grezzo dice che C ha il miglior ask (86,990), poi B. Aggiusta per fee e la ladder si riordina completamente: il top level di C netta $86{,}990 \times 1.00075 = 87{,}055$, la peggior liquidità sullo schermo. Il top di B netta 87,004, quello di A netta 87,017. Applica un haircut di staleness del 30% alla size mostrata di B ($e^{-\kappa \cdot 250\text{ms}} \approx 0.7$) ed esegui il water-fill: 1.05 BTC dal primo livello di B, 3.0 dal primo di A, 1.4 dal secondo di B, 4.0 dal secondo di A, 0.55 dal terzo di A. Media all-in: **$87,022.2 per BTC**. Il router naive al best-displayed-price — prima C, poi B a size nominale, poi il secondo livello di C — paga$87,038.8: 1.9 bps peggio, circa $166 su un singolo child da 10 BTC, che si accumula su ogni child di ogni parent per tutto il giorno. E nota il punchline: la venue con il miglior prezzo mostrato sul tape ha ricevuto zero flow dal router ottimizzato. Nel crypto, nessuno ti costringe a tradare lì — instradare attraverso una "quota protetta" non è un concetto — e l'allocazione corretta ignora frequentemente del tutto il prezzo migliore apparente.

Cosa ignora ancora il programma convesso: la simultaneità (spara tutti i child di venue nello stesso millisecondo, o le cancellazioni di van Kervel riprezzeranno le venue a metà esecuzione), le lot size discrete e i notional minimi (arrotonda la soluzione continua, sistema greedy), e l'opzione di non attraversare affatto lo spread — che è l'argomento della Sezione 5. Per la domanda più profonda su come i parent di grandi dimensioni debbano essere affettati nel tempo prima che tutta questa logica di venue entri in gioco, vedi Almgren-Chriss optimal execution; lo SOR decide dove va un child, non quando i child accadono.

Il vincolo di capitale: lo SOR è gestione della tesoreria

Tutto quanto sopra ha silenziosamente assunto che tu possa tradare $q_v$ sulla venue $v$. Nelle azioni quell'assunzione è gratuita: un prime broker, settlement netted, tradi ora e sposti il denaro dopo. Nel crypto è il vincolo vincolante dell'intero sistema. Gli exchange richiedono saldi prefinanziati — non puoi colpire l'ask di Kraken con USDT che siede su Binance. Quindi il vero problema è

dove $B_v$ è il tuo saldo disponibile sulla venue $v$ (nell'asset di quotazione per gli acquisti, nel base per le vendite). Le condizioni KKT ora leggono $C_v'(q_v^*) = \mu - \eta_v$ con $\eta_v \ge 0$ il moltiplicatore sul cap di saldo. Sulle venue vincolate, $\eta_v = \mu - C_v'(B_v) > 0$: il dollaro marginale lì esegue più a buon mercato del livello dell'acqua a livello di mercato, e sei costretto a spingere flow verso venue più costose. Quel moltiplicatore non è un'astrazione — $\eta_v$ è letteralmente i dollari per unità che risparmieresti se esistesse un'unità di saldo in più sulla venue $v$ in questo momento. Sommato sul tuo flow previsto, è la tua disponibilità a pagare per un trasferimento di ribilanciamento, e la decisione di ribilanciamento diventa un confronto che qualsiasi sistema di tesoreria può eseguire: sposta l'inventario quando

Il membro destro non è piccolo né costante. Il BTC on-chain richiede 2-6 conferme (20-60 minuti) prima che gli exchange lo accreditino; i trasferimenti ERC-20 richiedono minuti più gas che schizza esattamente quando i mercati sono attivi; i rail TRC-20 e Solana sono più veloci ed economici ma non universalmente supportati; e ogni exchange aggiunge la propria coda di elaborazione dei prelievi, che si allunga da minuti a ore proprio durante gli eventi di volatilità, quando il tuo router vuole di più che l'inventario sia spostato. L'aritmetica completa dei costi di trasferimento — fee, distribuzioni di latenza, e il rischio di prezzo che porti a metà volo — è sviluppata in l'articolo sul funding-rate arbitrage, e si trasferisce parola per parola: un ribilanciamento SOR è lo stesso oggetto di un trasferimento di gamba di arbitraggio, costi inclusi.

Ecco perché il risultato accademico da interiorizzare qui non è un paper di esecuzione ma Makarov e Schoar (2020), "Trading and Arbitrage in Cryptocurrency Markets" (Journal of Financial Economics 135(2), 293–319). Hanno documentato deviazioni di prezzo cross-exchange che persistono per giorni o settimane — incluso il "kimchi premium" coreano che ha superato il 40% all'inizio del 2018 — e hanno mostrato che i costi di transazione non possono spiegarle; il capitale di arbitraggio lento e soggetto a controlli di capitale sì. Le venue crypto non sono il "singolo mercato virtuale con più punti di accesso" di O'Hara-Ye. Sono pool parzialmente segmentati collegati da tubature lente e costose, e il tuo router vive dentro quella segmentazione. Uno SOR crypto senza un modello di tesoreria è uno SOR azionario travestito.

In pratica questo diventa un controller a due scale temporali. Il loop veloce (millisecondi) risolve il water-fill vincolato entro i saldi correnti, per ogni child order. Il loop lento (minuti-ore) osserva la serie temporale dei prezzi ombra $\eta_v$ e il flow previsto, e programma i trasferimenti quando la componente persistente di $\eta_v$ supera la soglia del costo di trasferimento — con isteresi, perché far rimbalzare l'inventario tra venue sul rumore è il modo in cui doni il tuo edge alla rete Tron. I desk istituzionali comprimono il problema con settlement off-exchange (Copper ClearLoop, Ceffu MirrorX): il collaterale siede presso un custode ed è specchiato verso le venue, il che riduce drasticamente la latenza di trasferimento per le venue supportate — restringe il vincolo, ma non lo elimina, e introduce una propria voce di rischio controparte.

Routing maker-aware e giochi di coda cross-venue

Un router che attraversa solo gli spread lascia inacquistata la liquidità più economica: la tua stessa. Il framework Cont-Kukanov contiene già la risposta — la loro forma chiusa a singola venue ripartisce un ordine tra posting e taking in base a fee, posizione in coda, e avversione al rischio di esecuzione — e la versione multi-venue la generalizza: posta passivamente sulle venue dove (maker fee, lunghezza coda, probabilità di fill entro la deadline del child) dominano, prendi sulle venue dove l'immediatezza è economica, e tratta il residuo passivo non eseguito come flow che rientra nell'ottimizzazione taker alla deadline.

Due peculiarità specifiche del crypto rendono questo più ricco della versione azionaria.

L'inseguimento delle fee è una trappola misurata. Battalio, Corwin e Jennings (2016), "Can Brokers Have It All? On the Relation between Make-Take Fees and Limit Order Execution Quality" (Journal of Finance 71(5)), hanno mostrato che i broker US che instradavano limit order verso le venue con il rebate più alto ottenevano esecuzioni misurabilmente peggiori — tassi di fill più bassi, qualità realizzata peggiore — perché la venue del rebate è dove siede anche l'ordine di ogni altro cacciatore di rebate: coda più lunga, fill più avversi. L'analogo crypto è esatto. La venue che paga il miglior rebate maker attrae le quote passive di ogni market maker; il tuo ordine si unisce a una coda profonda e si esegue prevalentemente quando il prezzo sta per attraversarti. L'economia maker net-of-markout per venue (sezione successiva) classifica regolarmente le venue in modo opposto ai loro schedule di fee.

Lo skew di latenza è un gioco a due lati. Lo stesso flusso di informazioni cross-venue che van Kervel ha documentato come cancellazioni difensive è, dall'altro lato, un segnale offensivo: un trade al top of book di Binance predice trade e cancellazioni al livello corrispondente di OKX entro millisecondi. Un router maker-aware deve quindi (a) riprezzare i propri ordini in attesa sugli eventi di altre venue — agganciandosi a un microprice cross-venue, non al mid locale — o diventa la controparte lenta che gli arbitraggisti cross-venue vanno a colpire; e (b) può giocare la partita deliberatamente: posta sulla venue che è in ritardo, copri sulla venue che guida al momento del fill. Questo è l'arbitraggio di coda cross-venue, ed è la stessa struttura di latenza sfruttata in cross-exchange arbitrage execution, semplicemente incorporata dentro un mandato di esecuzione anziché in un libro di stat-arb. Il requisito operativo è identico: l'evento di fill sulla venue A e l'ordine di copertura verso la venue B devono vivere nello stesso code path a singola cifra di millisecondi, o l'edge appartiene a qualcun altro.

Misurare la qualità del routing: markout e classifiche

I router azionari sono disciplinati dalla disclosure Rule 605/606. Nulla disciplina il tuo tranne la tua stessa TCA — il framework di implementation shortfall e TCA è il tabellone; ecco la fetta specifica del router.

La misurazione atomica è il markout per venue: per ogni fill, registra il mid (consolidato, corretto per latenza) a $t + \Delta$ per $\Delta \in \{100\text{ms}, 1\text{s}, 10\text{s}, 1\text{min}\}$, con segno tale che negativo significhi che il mercato si è mosso contro il tuo fill. Aggrega in una classifica all-in:

La colonna delle fee dice che B è la venue economica. La colonna all-in dice che B è la venue costosa: le sue quote stale ti eseguono selettivamente quando il mercato le sta già attraversando, e il markout a 1 secondo incassa il conto. Questa inversione — classifica per fee contro classifica per costo effettivo — è il risultato più costante quando i desk costruiscono questa tabella per la prima volta, ed è esattamente il numero che appartiene di nuovo al router: la penalità $\lambda_v$ del programma convesso è il deficit di markout persistente per venue, misurato, smussato, e aggiornato. Il router e la TCA formano un ciclo chiuso, o nessuno dei due funziona.

Una trappola metodologica: le classifiche costruite da un router live sono contaminate da bias di selezione. Se il router invia già il flow difficile e informato alla venue profonda e il flow facile a quella economica, i markout della venue profonda sembrano ingiustamente cattivi. La correzione pulita è la randomizzazione deliberata — instrada una piccola percentuale di child in modo uniformemente casuale (un router $\varepsilon$-greedy, che i quant riconosceranno come un bandit con un prior di ottimizzazione convessa) — così esiste un controfattuale. Costa basis point sulla fetta randomizzata ed è l'unico modo per dimostrare che il restante 95% del flow è instradato bene.

Lo stack, dunque: un book consolidato onesto sulla latenza; un water-fill convesso sui costi marginali netti con parametri di evaporazione e tossicità misurati; un loop veloce vincolato dal saldo i cui prezzi ombra guidano un loop lento consapevole del costo di trasferimento; un posizionamento passivo che rispetta le code e il flusso di informazioni cross-venue; e una TCA randomizzata basata sui markout che retroalimenta ogni parametro. Nessuno di questi componenti è individualmente profondo. Il sistema lo è — perché nel crypto, a differenza delle azioni, nessun regolatore ha costruito per te alcuno strato di tutto questo, e il mercato addebita 2 bps per child order, per sempre, finché non lo fai tu.