In parole semplici — Fra una decisione e il relativo report di fill intervengono piattaforma, rete, broker, controlli, router e venue. Un solo numero “click-to-fill” mescola ritardi tecnici, tempo di decisione e attesa della controparte. Per capire dove si trova il problema servono timestamp distinti e orologi coerenti.
La latenza di esecuzione è il tempo trascorso lungo una o più fasi del ciclo di vita dell'ordine. Non esiste un unico punto iniziale e finale valido per ogni analisi. Si possono misurare segnale-invio, invio-ricezione del broker, routing, ingresso al venue, acknowledgement, esecuzione e ritorno del report.
La parola “esecuzione” può inoltre indicare eventi differenti. Un acknowledgement conferma normalmente ricezione o accettazione, non il fill. Un ordine può ricevere più fill parziali; un ordine limite non marketable può restare in coda per minuti pur attraversando l'infrastruttura in millisecondi. Il tempo di attesa della liquidità non è automaticamente latenza tecnica.
Le componenti del percorso
| Segmento | Esempio di intervallo | Che cosa può includere |
|---|---|---|
| Market data | evento al venue → dato ricevuto | feed, consolidamento, rete, parsing |
| Decisione | dato o segnale → ordine generato | logica, calcolo, intervento umano |
| Client/broker | invio client → ricezione broker | piattaforma, rete, gateway |
| Broker interno | ricezione → inoltro | validazioni, rischio, throttling, routing |
| Broker/venue | inoltro → ingresso al venue | rete, gateway e coda di ingresso |
| Venue | ingresso → ack o match | |
| Report | evento al venue → messaggio ricevuto | feed di esecuzione, broker e rete di ritorno |
Il tratto end-to-end dipende dalla domanda. Una strategia automatica può misurare dal timestamp del dato al report di fill; un audit di broker routing può partire dalla prima ricezione dell'ordine; un venue misura soltanto eventi nel proprio perimetro.
La SEC, nella Rule 605, definisce il tempo di ricezione come il momento in cui l'ordine è catturato per la prima volta dal sistema automatizzato del soggetto che lo riceve. Questa scelta serve a rendere comparabili benchmark e statistiche nel perimetro statunitense coperto. Non coincide necessariamente con il click del cliente o con l'ingresso nel matching engine.
Orologio, timestamp e sequenza
Un timestamp è utile soltanto se si conoscono:
- orologio che lo ha generato;
- punto preciso del sistema in cui viene applicato;
- fuso o riferimento temporale;
- granularità e accuratezza;
- correzioni, drift e metodo di sincronizzazione;
- trattamento di eventi con lo stesso timestamp.
Per misurare un intervallo all'interno della stessa macchina è preferibile un orologio monotono, non soggetto a salti dell'ora civile. Per ricostruire eventi fra sistemi diversi serve invece una base temporale comune e tracciabile. Il Regolamento delegato (UE) 2025/1155 prescrive per le entità comprese nel proprio perimetro MiFIR la sincronizzazione degli orologi di business con UTC e livelli di accuratezza differenziati per attività e sistemi. Gli articoli 11–16 si applicano dal 2 marzo 2026. È un requisito regolamentare specifico, non la prova che ogni timestamp commerciale sia perfettamente sincronizzato.
Sottrarre il timestamp del venue da quello del client senza conoscere l'offset fra gli orologi può perfino produrre una latenza negativa. Una misura round-trip sullo stesso client evita la sottrazione fra clock diversi, ma include percorso di andata, elaborazione e ritorno; dividerla per due non fornisce necessariamente la latenza one-way, perché i percorsi possono essere asimmetrici.
Esempio di lettura corretta
Sul clock monotono del client:
- il segnale nasce a 0 ms;
- l'ordine parte a 2 ms;
- l'ack viene ricevuto a 24 ms;
- il primo report di fill arriva a 80 ms.
Si possono calcolare con sicurezza 2 ms di decisione locale, 22 ms da invio ad ack ricevuto e 78 ms da invio a report di fill. Non si può dedurre da questi soli dati in quale punto siano trascorsi i 22 ms né assumere che il match sia avvenuto a 80 ms: il report può essere arrivato dopo l'evento al venue.
I 56 ms fra ack e report possono comprendere attesa in coda, assenza di controparte, matching e trasmissione del messaggio. Se l'ordine era un limite passivo, tale intervallo descrive soprattutto il time-to-first-fill, non un ritardo di rete.
Per localizzare il tratto servono timestamp aggiuntivi del broker e del venue, con origine e sincronizzazione documentate, oppure misure controllate su ciascun segmento.
Metriche utili
Una media unica nasconde picchi e code. Un audit può riportare:
- mediana, p95, p99 e massimo per segmento;
- distribuzione per venue, strumento e fascia oraria;
- time-to-ack, time-to-first-fill e time-to-completion separati;
- tasso di timeout, rifiuti, retry e messaggi fuori sequenza;
- differenza fra timestamp evento e timestamp di ricezione;
- quantità eseguita a ciascun intervallo di tempo.
La SEC include velocità e quantità eseguita fra le dimensioni delle statistiche di execution quality. La velocità va però letta insieme a prezzo, fill rate e tipo di ordine: una venue che risponde rapidamente con un rifiuto non offre lo stesso esito di una che completa l'ordine, e un fill istantaneo a un prezzo peggiore non è automaticamente superiore.
Latenza, slippage e qualità
Latenza e slippage possono essere correlate, specialmente quando le quote cambiano rapidamente, ma non sono sinonimi e la correlazione non dimostra causalità. Durante il ritardo il prezzo può muoversi a favore, controparte può arrivare o l'ordine può restare invariato. Lo slippage dipende anche da spread, profondità, size, tipo di ordine e impatto.
Una latenza più bassa riduce alcuni rischi temporali, ma non garantisce:
- il miglior prezzo;
- esecuzione completa;
- corretto routing;
- assenza di selezione avversa;
- convenienza economica dell'infrastruttura;
- qualità della decisione di trading.
L'articolo 27 MiFID II elenca, nel suo perimetro, prezzo, costi, rapidità, probabilità di esecuzione e regolamento, dimensione e natura fra i fattori di best execution. La velocità è quindi una dimensione, non l'intera qualità.
Controlli e limiti
Per una misurazione riproducibile occorre definire gli eventi prima di analizzare i log. “Send” può essere il click, la chiamata API o l'uscita dal gateway; “fill” può essere il match al venue, il report del broker o l'aggiornamento dell'interfaccia. Cambiare definizione fra sistemi invalida il confronto.
Sono utili inoltre:
- identificativi univoci per collegare ordine, ack, modifiche e fill;
- sequenze oltre ai timestamp quando la granularità non distingue gli eventi;
- conservazione di errori, cancellazioni e quantità residue;
- controllo periodico di drift e perdita di sincronizzazione;
- segmentazione per tipo d'ordine e stato del mercato;
- separazione fra latenza di mercato, decisione e infrastruttura.
Errore tipico — Confrontare il timestamp locale del click con quello del venue come se provenissero dallo stesso orologio, oppure attribuire l'intero tempo al fill alla rete. Senza punti di misura e clock documentati, il numero non localizza alcuna causa.
Fonti
- SEC — Frequently Asked Questions: Rule 605 of Regulation NMS
- SEC — Release No. 34-43590, Disclosure of Order Execution and Routing Practices
- EUR-Lex — Commission Delegated Regulation (EU) 2025/1155, business-clock synchronisation
- ESMA — MiFID II, Article 27: Obligation to execute orders on terms most favourable to the client