BJF TRADING GROUP · SHARPTRADER OPTIMIZER
La maggior parte dei backtest di arbitraggio di latenza pubblicati sembra spettacolare sulla carta e crolla non appena passa al live. Il motivo non è una cattiva logica di strategia: è che i backtester retail standard presuppongono silenziosamente esecuzioni a latenza zero. Questa guida spiega esattamente come il tempo di esecuzione al millisecondo cambia i conti e che cosa il tuo backtest deve modellare per produrre risultati che puoi davvero tradare.
La redditività dell’arbitraggio di latenza vive dentro una finestra di 50–200 millisecondi. È il tempo per cui la discrepanza di prezzo tra un feed veloce e un broker lento resta tipicamente aperta prima che la quotazione del broker lento si aggiorni. Se il tuo tempo di esecuzione round-trip effettivo — dal rilevamento del segnale all’esecuzione confermata — consuma gran parte di quella finestra, non ti resta quasi nessun margine. I backtester retail standard presuppongono che gli ordini vengano eseguiti istantaneamente al prezzo visualizzato, il che cancella del tutto questo problema dalla simulazione. Il risultato: un backtest che sembra una macchina da soldi e un’operatività live che perde su ogni trade dopo lo spread.
Questo articolo quantifica il divario, analizza dove finiscono davvero i millisecondi e spiega come modellare il tempo di esecuzione all’interno di un backtest, in modo che i numeri che ottieni corrispondano a quelli che vedrai su un conto live.
Guarda: come il tempo di esecuzione cambia un backtest di arbitraggio di latenza — la stessa strategia con latenza di esecuzione di 0 ms, 50 ms e 150 ms, analizzata tick per tick.
In un sistema di arbitraggio di latenza, la strategia confronta due feed di prezzi: un feed veloce (tipicamente un aggregatore tier-1 o il feed di un LP) e un feed lento (il broker contro cui fai trading). Quando il feed veloce anticipa quello lento di più dello spread più una soglia configurata, la strategia invia un ordine sul lato lento, aspettandosi che il prezzo lento converga.
L’opportunità esiste solo finché i due prezzi sono disallineati. Nel momento in cui il motore di quotazione del broker si allinea — di solito entro 50–200 millisecondi — il vantaggio scompare. Il tuo ordine deve essere sul mercato prima che ciò accada.
In questo contesto il “tempo di esecuzione” non è un singolo numero. È una somma di latenze, ognuna delle quali aggiunge qualche millisecondo:
Per una strategia in esecuzione su un VPS standard in un data center diverso da quello del broker, il round-trip realistico raramente scende sotto 80–100ms. Per una strategia in co-location con il broker tramite cross-connect, può scendere a 1–5ms. Quella differenza di un ordine di grandezza è tutta la partita.
Immagina un segnale pulito: il feed veloce salta di 1,5 pip. Il broker lento non si è ancora aggiornato. Hai, in media, tra 80 e 150 millisecondi prima che il motore di quotazione del broker lento rifletta il nuovo prezzo. All’interno di quella finestra accadono due cose contemporaneamente:
Se il tuo round-trip consuma 50ms, arrivi quando la discrepanza è ancora intatta per circa il 70% e ne catturi la maggior parte. Se il tuo round-trip consuma 150ms, arrivi quando la discrepanza si è già ridotta a circa il 10% — e dopo spread e slippage probabilmente sei in perdita.
Il rapporto tra latenza round-trip e PnL dell’arbitraggio non è lineare. Sotto la finestra di esecuzione, la redditività è alta e stabile. Sopra, la redditività crolla a zero o diventa negativa. La maggior parte dei trader retail si trova dalla parte sbagliata di questo precipizio senza saperlo, perché il loro backtest lo nasconde.
Ecco lo stesso segnale teorico di arbitraggio di latenza con un vantaggio di 1,5 pip, simulato con quattro diverse latenze di esecuzione round-trip. I numeri sotto sono tipici di quanto vedrai su EUR/USD durante una sessione di Londra con liquidità normale e uno spread di 0,6–0,9 pip.
| Esecuzione round-trip | Vantaggio catturato | Slippage in entrata | PnL netto per trade | Verdetto |
|---|---|---|---|---|
| ~5ms (co-location) | ~95% del segnale | 0,0–0,2 pip | da +0,6 a +1,0 pip | Redditizio |
| ~50ms (VPS vicino) | ~70% del segnale | 0,2–0,5 pip | da +0,2 a +0,6 pip | Redditizio, con margini più sottili |
| ~120ms (media distanza) | ~30% del segnale | 0,5–1,0 pip | da −0,3 a +0,1 pip | Marginale / in perdita |
| ~200ms (lunga distanza) | ~10% del segnale | 1,0–1,8 pip | da −1,0 a −0,5 pip | Perde su ogni trade |
Nota lo schema: da 5ms a 50ms, la redditività cala moderatamente. Da 50ms a 120ms, precipita. Oltre 150ms, la strategia è un lancio di moneta con aspettativa negativa dopo i costi. Questo precipizio è invisibile per un backtester che presuppone esecuzioni istantanee.
I backtester retail standard sono stati costruiti per sistemi trend-following e basati su indicatori — strategie con periodi di detenzione da minuti a giorni, in cui pochi secondi di slippage di esecuzione sono un errore di arrotondamento. La loro architettura lo riflette:
Per una strategia che mantiene le posizioni per ore, va bene così — il costo di queste semplificazioni è ben al di sotto dell’1% del PnL. Per una strategia di arbitraggio di latenza che guadagna 1–3 pip per trade e vive o muore in una finestra di 100ms, ognuna di queste semplificazioni è fatale:
Una discrepanza di prezzo di 100ms è invisibile all’interno di una barra M1 — la barra mostra OHLC, non il flusso di tick intra-barra. I backtester a barre non riescono nemmeno a rilevare correttamente i segnali di arbitraggio di latenza.
Se gli ordini vengono eseguiti al prezzo visualizzato nel momento in cui vengono inviati, l’intera finestra di esecuzione di 50–200ms si riduce a zero. Il backtest cattura il 100% di ogni segnale, ogni volta. La realtà ne cattura dal 30% al 95% a seconda dell’infrastruttura.
Le vere opportunità di arbitraggio si concentrano attorno a notizie, rollover e finestre di scarsa liquidità — proprio quando lo spread si allarga di 3–5 volte. I backtest a spread fisso contano profitti che in condizioni reali non esisterebbero.
L’arbitraggio di latenza chiude le posizioni con la stessa rapidità con cui le apre. I backtester standard ignorano completamente lo slippage in chiusura oppure applicano lo stesso spread fisso, raddoppiando l’ottimismo irrealistico.
Per produrre un backtest che sopravviva al contatto con un broker live, il simulatore deve modellare esplicitamente ogni tratto del round-trip. Ecco la scomposizione di cui ha bisogno un serio backtest di arbitraggio di latenza:
| Componente | Intervallo tipico | Che cosa rappresenta |
|---|---|---|
| 1. Latenza segnale-invio | 0.5–20 ms | Tempo dalla ricezione del tick di attivazione all’emissione di un ordine. Dipende dal linguaggio, dal percorso del codice e dalla CPU. C++ compilato <1ms; script di alto livello 5–20ms. |
| 2. Round-trip di rete (andata) | 1–80 ms | Tempo di trasmissione dal tuo host di trading al broker. Co-location = 1–3ms; stessa area metropolitana = 5–15ms; tra regioni diverse = 30–80ms. |
| 3. Latenza di matching del broker | 3–100 ms | Tempo trascorso all’interno del motore di gestione ordini e di matching del broker. Broker ECN tier-1: 3–15ms. Broker retail standard: 30–100ms. Broker STP con gestione manuale: oltre 100ms. |
| 4. Round-trip di conferma (ritorno) | 1–80 ms | Speculare al tratto di rete in uscita. Finché non ricevi la conferma dell’esecuzione, non conosci il tuo prezzo di esecuzione — un aspetto rilevante per la gestione del rischio e per la tempistica della chiusura. |
Per un tipico deployment retail di arbitraggio di latenza da un VPS generico tramite un broker retail standard, le quattro componenti sommano circa 80–180ms — in piena zona di pericolo, dove la cattura del segnale scende sotto il 50%. Per un deployment in co-location tramite un broker ECN veloce, le stesse componenti sommano 5–20ms — ben al di sotto del precipizio.
Ogni backtest onesto di una strategia di arbitraggio di latenza dovrebbe permettere al trader di configurare queste latenze e vederne l’impatto. SharpTrader Optimizer modella la latenza di esecuzione come un unico parametro configurabile (in millisecondi), applicato a ogni ordine in fase di simulazione, sopra dati tick storici reali.
Servono tre elementi. Ciascuno è necessario; nessuno, da solo, è sufficiente.
I backtester retail standard generano dati “tick” interpolando tra i valori OHLC delle barre. I tick sintetici che producono toccano il massimo e il minimo della barra in punti casuali, scorrendo in modo uniforme tra apertura e chiusura. I mercati reali non si muovono così: saltano. Il segnale di arbitraggio di latenza da 1,5 pip che cerchi di catturare è un salto che i dati tick interpolati appiattiscono fino a farlo sparire.
Un backtest serio riproduce i tick bid/ask effettivamente registrati dal motore di matching del broker (o da un feed di riferimento pulito, come i dati istituzionali di origine londinese). Ogni tick ha un timestamp, un bid e un ask. La strategia li vede nello stesso ordine e con la stessa tempistica con cui li vedrebbe un deployment live.
Il trader configura il tempo di esecuzione round-trip T (in millisecondi) che si aspetta di vedere in live. Quando la strategia emette un ordine, il simulatore fa avanzare l’orologio della porzione relativa al tratto di richiesta — tipicamente T/2, poiché solo il tempo tra il segnale e il matching lato broker influisce sul prezzo di esecuzione (il tratto di risposta comunica soltanto alla strategia ciò che è già accaduto). Se T = 80ms, il simulatore guarda il flusso di tick 40ms dopo il segnale e usa il bid/ask di quel tick — non del tick che ha generato il segnale — come prezzo di esecuzione.
Questa singola modifica — far avanzare l’orologio tra segnale ed esecuzione — riproduce il precipizio alle latenze realistiche. Rende inoltre il backtest deterministico: la stessa strategia con T = 50ms rispetto a T = 150ms sullo stesso flusso di tick produce risultati misurabilmente diversi, e il trader può vedere esattamente dove la strategia smette di funzionare.
Lo slippage realizzato su ogni esecuzione è quello prodotto dal percorso dei tick — è un output della simulazione, non un numero che il trader deve indovinare. Alcune esecuzioni avvengono a prezzi favorevoli (slippage positivo), altre peggiori (negativo), e l’entità segue la volatilità effettiva dei tick in quei millisecondi. È questa la distribuzione realistica che manca in tutti i backtester retail standard.
L’arbitraggio di latenza chiude con la stessa rapidità con cui apre. L’uscita avviene 200–800ms dopo l’entrata, su un prezzo in convergenza. Se il simulatore applica lo stesso spread fisso a entrata e uscita, perde due cose: (1) lo slippage in entrata dovuto alla finestra di latenza e (2) lo slippage in uscita dovuto al prezzo che torna indietro durante il round-trip di chiusura. Un modello reale ti permette di configurare il tempo di esecuzione in modo indipendente su apertura e chiusura — rispecchiando il comportamento reale dei broker, dove le uscite passano spesso per un percorso di instradamento più lento — e calcola automaticamente lo slippage su ciascun lato dal flusso di tick.
Ecco un risultato rappresentativo di una strategia di arbitraggio di latenza SharpTrader testata su 30 giorni di dati tick EUR/USD, con gli stessi parametri ma tre diverse configurazioni di latenza di esecuzione. I numeri sono tipici di quanto osserviamo nei backtest con BJF Feed (Londra / Tokyo / NY).
| Metrica | 0ms (fittizio) | 50ms (VPS vicino) | 150ms (lunga distanza) |
|---|---|---|---|
| Segnali generati | 2,847 | 2,847 | 2,847 |
| Segnali eseguiti con vantaggio | 2,847 (100%) | 1,983 (70%) | 854 (30%) |
| Pip medi catturati | 1.42 | 0.98 | 0.21 |
| Slippage realizzato in entrata (output del percorso dei tick) | 0,0 pip | 0,3 pip | 0,9 pip |
| PnL netto per trade | +0,82 pip | +0,48 pip | −0,31 pip |
| Rendimento mensile (1 lotto) | +233% | +137% | −88% |
La colonna 0ms è la “fantasia da backtest” prodotta dagli strumenti standard. La colonna 50ms è l’aspetto reale di una strategia di arbitraggio di latenza ben implementata. La colonna 150ms è ciò che la maggior parte dei trader retail esegue senza accorgersene quando avvia una strategia su un VPS generico e fa trading tramite un broker standard senza rendersi conto di dove si colloca il proprio round-trip rispetto al precipizio.
La stessa strategia può essere estremamente redditizia, marginalmente redditizia o una perdita garantita — a seconda unicamente di un numero che nessun backtester standard modella.
La latenza di esecuzione è la variabile meno modellata nei backtest retail di arbitraggio di latenza, ma non è l’unica. Un backtest affidabile combina tre elementi, e ciascuno amplifica gli altri:
Rivela il precipizio. Ti dice di quale infrastruttura la strategia ha realmente bisogno per essere redditizia e in quale punto il tuo vantaggio scompare.
Coglie il fatto che le opportunità di arbitraggio si concentrano proprio quando lo spread si allarga. Un backtest a spread fisso conta profitti che in quei momenti non possono fisicamente esistere.
Individua le strategie che sembrano buone in-sample perché l’ottimizzatore ha trovato un set di parametri che si adatta al rumore del periodo in-sample. Senza walk-forward, il tuo backtest è solo un curriculum del passato.
Un trade di arbitraggio di latenza ha due eventi di slippage — apertura e chiusura. La maggior parte dei backtest ne modella uno (o nessuno) e raddoppia l’ottimismo.
Quando tutti e quattro sono presenti, il backtest smette di essere uno strumento di marketing e diventa uno strumento di previsione. I numeri che produce smettono di divergere del 50–200% dai risultati live e iniziano a cadere entro il 10–20% — abbastanza vicino da poter basare sul backtest le decisioni di dimensionamento del rischio, allocazione del capitale e scelta del broker.
Regola empirica del settore: aspettati un drawdown live pari a 1,5–2 volte il drawdown del backtest. Per le strategie di arbitraggio di latenza testate con backtester standard, questo rapporto è più vicino a 5–10 volte — perché il backtest non ha modellato la latenza di esecuzione, lo spread variabile o lo slippage su entrambi i lati. Una volta inclusi questi elementi, vale la regola dell’1.5–2x; prima, il backtest non ha alcun valore predittivo.
Esegui l’ottimizzazione su almeno tre configurazioni di latenza: 10ms (caso migliore, co-location), 50ms (VPS vicino) e 150ms (VPS generico, broker lontano). Se la strategia è redditizia solo a 10ms, hai un problema di deployment — ti serve un piano di co-location prima di poterla tradare. Se è redditizia a 50ms ma non a 150ms, la scelta del VPS e del broker diventa tutta la partita.
Tre livelli: (1) esegui un ping dell’endpoint di inserimento ordini del tuo broker dal tuo host di trading — questo ti dà il round-trip di rete grezzo; (2) invia un piccolo ordine di prova in un momento tranquillo e registra il timestamp dell’emissione del segnale e della conferma dell’esecuzione — la differenza include la latenza di matching del broker; (3) ripeti in più sessioni — la latenza varia con il carico del broker, l’ora del giorno e il percorso. Il valore realistico per il tuo deployment è la mediana su molte misurazioni, non il ping nel caso migliore.
Sì — con finestre ancora più strette. Le finestre del news trading possono essere ampie 10–50ms. Il problema del divario del tempo di esecuzione è identico, solo compresso in una finestra più piccola. Serve la stessa infrastruttura di backtest (tick reali, latenza di esecuzione configurabile, spread variabile) e la tolleranza alla latenza è ancora meno indulgente.
Entrambi i fenomeni hanno la stessa causa: i fornitori di liquidità diventano incerti sul prezzo e ritirano le quotazioni. Quando il feed veloce salta, gli LP che forniscono il broker lento allargano brevemente le quotazioni per proteggersi dal rischio di essere colpiti. Così il momento in cui si apre la discrepanza è anche il momento in cui si allarga lo spread necessario per catturarla. Un backtest a spread fisso non lo vede e sovrastima il vantaggio netto del 30–50%.
Per l’arbitraggio di latenza in stile istituzionale contro broker ECN tier-1, sì — il campo di gioco si è spostato su round-trip inferiori a 5ms, e ciò richiede cross-connect o hosting di prossimità. Per l’arbitraggio di latenza in stile retail contro broker retail più lenti, no — round-trip di 30–80ms possono ancora produrre un vantaggio, perché la finestra del broker lento è più ampia. La domanda giusta non è “la co-location è necessaria?” ma “il mio round-trip rientra nella finestra del broker contro cui faccio trading?”. È esattamente la domanda a cui risponde un backtest che tiene conto della latenza di esecuzione.
Per le strategie trend-following che mantengono le posizioni per ore o giorni, qualche centinaio di millisecondi di latenza di esecuzione è un errore di arrotondamento. Per l’arbitraggio di latenza, quegli stessi millisecondi sono l’intero segnale. La normale infrastruttura di backtesting Forex è progettata per il primo caso e produrrà silenziosamente risultati inutili per il secondo. Ecco perché gli strumenti dedicati al backtesting dell’arbitraggio esistono come categoria a sé.
Cambiano la strategia ottimale, non l’analisi. I broker che usano plugin anti-arbitraggio (esecuzione ritardata, last-look, requote in caso di profitto, hold-then-fill) introducono di fatto una latenza di esecuzione artificiale in aggiunta a quella naturale. Un backtest con latenza di esecuzione configurabile ti permette di simulare il comportamento anti-arbitraggio del broker e di decidere se la strategia è ancora praticabile contro quel broker — o se devi cambiare piattaforma.
Per una strategia di arbitraggio di latenza con 5–8 parametri, una griglia tipica conta 30.000–100.000 combinazioni — incluse 3–5 impostazioni del tempo di esecuzione come una delle dimensioni esplorate. L’obiettivo è trovare cluster di redditività — intervalli in cui la strategia è redditizia per molti valori dei parametri, non singoli picchi “fortunati”. I picchi isolati sono curve fitting; i cluster sono robustezza. Come riferimento realistico su una tipica workstation retail, una griglia di 30.000 combinazioni su 1 settimana di dati tick XAUUSD con una CPU a 4 core termina in circa 12 ore; la stessa griglia richiede circa 3 ore con 16 core. SharpTrader Optimizer gestisce oltre 100.000 combinazioni per esecuzione su hardware multi-core.
È un’osservazione empirica nel trading algoritmico istituzionale: anche un backtest ben modellato sottostima il drawdown live di circa il 50–100%, perché alcuni attriti del mondo reale (rifiuti del broker, gap del fine settimana, cambi di regime) non possono essere modellati in modo pulito. La regola presuppone che il backtest includa già una latenza di esecuzione realistica, lo spread variabile e lo slippage su entrambi i lati. Se mancano, il moltiplicatore è molto più alto — da 5x a 10x, nello specifico per l’arbitraggio di latenza.
Concettualmente è identico. La finestra del tempo di esecuzione nell’arbitraggio cripto tra exchange è tipicamente di 200ms–2s (più lenta del Forex perché gli exchange sono più distanti e gli order book sono più profondi ma più lenti ad aggiornarsi). Gli stessi tre ingredienti — replay dei tick, latenza di esecuzione configurabile, spread variabile — producono backtest onesti. Gli strumenti di arbitraggio cripto di BJF usano la stessa architettura, adattata alle API degli exchange e alla profondità degli order book.
SharpTrader Optimizer è l’unico backtester accessibile ai trader retail che modella tempo di esecuzione configurabile, replay di tick reali, spread variabile per tick e slippage risolto a livello di tick su entrambi i lati — le quattro variabili che decidono se una strategia di arbitraggio di latenza è reale o fittizia. L’ottimizzazione a griglia multi-core su oltre 100.000 combinazioni di parametri termina in ore, non in giorni.