Cos’è il Last Look, in termini misurabili
Il Last Look nel Forex è un meccanismo in cui un ordine può essere accettato provvisoriamente per l’esecuzione, ma successivamente rifiutato (o non eseguito) dopo un breve controllo da parte del liquidity provider. Per misurarlo, traduci il concetto in eventi osservabili e campi registrabili. Questo approccio separa meccaniche relativamente stabili (quali decisioni avvengono e quando) da condizioni variabili (movimento del mercato, costi e scelte di implementazione).
Un modo pratico per definirlo ai fini della misurazione è tracciare ogni ordine tentato come un evento con almeno questi campi:
- Timestamp dell’ordine (t_order): quando ritieni che la richiesta sia stata inviata.
- Timestamp della quotazione o della base prezzo (t_quote): quando il prezzo usato per la richiesta è stato osservato.
- Esito della decisione: accettato/eseguito oppure rifiutato/non eseguito.
- Latenza della decisione (Δt): il tempo tra la base prezzo rilevante e l’esito finale.
- Prezzo di esecuzione e commissioni (se eseguito): il prezzo di fill finale e qualsiasi costo direttamente attribuibile che puoi registrare.
Se non puoi osservare tutti questi campi dai tuoi log, dovresti misurare solo ciò che puoi verificare e indicare esplicitamente cosa manca.
Come misurarlo usando accettazione, timing e metriche di qualità del prezzo
Un obiettivo comune di misurazione è quantificare sia la frequenza sia la tempistica/qualità.
1) Tassi di accettazione e rifiuto
Per un campione di ordini tentati, puoi calcolare:
- Tasso di accettazione = ordini eseguiti / ordini tentati totali
- Tasso di rifiuto = ordini rifiutati / ordini tentati totali
Assunzione necessaria: definisci “tentato” in modo coerente (ad esempio, qualsiasi ordine che ha raggiunto il provider, non annullato localmente prima dell’invio). Senza questa coerenza, i tassi possono risultare fuorvianti.
2) Distribuzione della latenza
Per esiti eseguiti e/o rifiutati, calcola la latenza dai campi di cui ti fidi:
- Latenza della decisione (Δt) = t_outcome − t_quote (oppure − t_order, a seconda di ciò che puoi giustificare)
Poi riassumi usando i percentili (ad esempio, mediana, 90°, 99°). Questo misura se le decisioni si concentrano su intervalli brevi o si allungano in determinate condizioni.
Assunzione necessaria: t_quote e t_outcome devono provenire da orologi comparabili e da stadi di elaborazione comparabili. Se i timestamp sono prodotti da sistemi diversi con ritardi differenti, la tua Δt non rappresenta in modo accurato il timing interno del controllo del provider.
3) Confronto della qualità del prezzo al momento della decisione
Per misurare differenze di “qualità del prezzo” senza assumere prevedibilità futura, confronta come il prezzo di esecuzione (quando eseguito) si relaziona alla base prezzo usata al momento dell’input della decisione.
Un esempio di metrica è:
- Differenza di prezzo = prezzo_di_esecuzione − prezzo_di_riferimento
Assunzione necessaria: il prezzo_di_riferimento è definito e acquisito in modo coerente (stesso tipo di quotazione, stesso istante e stesse regole di arrotondamento). Poiché i mercati si muovono continuamente, anche un riferimento corretto può diventare obsoleto in pochi millisecondi; la tua metrica misura la relazione tra l’esecuzione e il tuo riferimento scelto, non il “fair value” del provider.
4) Confronti condizionali
Per ridurre la probabilità che il movimento del mercato faccia dipendere tutto, raggruppa gli eventi per condizioni osservabili che puoi misurare, come:
- la finestra temporale (esempio: prima/dopo una specifica sessione di mercato)
- proxy di volatilità che calcoli dal tuo feed prezzi
- bucket per la dimensione dell’ordine (se li registri)
Requisito di similarità: ogni bucket deve avere abbastanza eventi e i tuoi bucket devono usare le stesse definizioni di tempo di riferimento e di esiti.
Evidenze e modalità di fallimento: cosa può compromettere la misurazione
La misurazione può fallire in diversi modi materiali. Almeno una limitazione comune è la mancanza o incoerenza dei timestamp.
Limitazione: potresti non osservare lo stesso orologio decisionale
Se t_quote deriva da un feed e t_outcome dal tuo order management system, possono esserci ritardi in entrambe le direzioni. La tua Δt misurata riflette quindi la latenza della pipeline e del software, non il timing della decisione del Last Look del provider.
Limitazione: “rifiuto” può avere più significati
Un rifiuto apparente potrebbe derivare da:
- la decisione del Last Look
- un annullamento locale dovuto a timeout
- un rifiuto dovuto a vincoli di esecuzione o controlli di rischio che non hai modellato
Per trattare i rifiuti come esiti di Last Look, devi separarli usando definizioni dai tuoi log (ad esempio, codici di stato distinti). Altrimenti, i tassi di accettazione/rifiuto mescolano meccanismi diversi.
Limitazione: le condizioni di mercato dominano gli orizzonti brevi
Anche con timestamp corretti e definizioni chiare, i risultati su orizzonti brevi variano con le condizioni di mercato, i costi di trading e le sedi di esecuzione. I tassi storici di accettazione e le distribuzioni della differenza di prezzo non stabiliscono esiti futuri.
Verifica e prossima domanda per rendere la misurazione affidabile
La verifica indipendente deriva dall’audit delle tue definizioni e dalla ricostruzione della timeline dell’evento.