Cosa significa “Last Look” nel Forex
Il Last Look è un meccanismo usato da alcuni liquidity provider in cui una richiesta di trade in arrivo non è immediatamente definitiva. Invece, il provider può eseguire controlli nel o vicino al momento in cui la richiesta viene ricevuta e poi accettare il prezzo per l’esecuzione oppure rifiutarlo.
Un modello semplice aiuta quando si considerano le implicazioni:
- Un cliente invia una richiesta di esecuzione.
- Il provider decide se la richiesta è ancora accettabile in base alle sue regole di Last Look.
- Il provider esegue (o conferma) la richiesta, oppure la rifiuta.
Un punto cruciale è che i “controlli” non fanno parte solo dell’intento inviato dal cliente. Dipendono dalle condizioni lato provider: se il mercato si è mosso rispetto a un momento di riferimento, se sono state superate soglie interne e come il provider confronta prezzi o tassi.
Poiché questo meccanismo è controllato dal provider, il “Last Look” può comportarsi in modo diverso tra sedi di esecuzione e provider. Quando leggi la documentazione o analizzi i log di esecuzione, trattalo come una famiglia di comportamenti, non come una singola regola fissa.
Considerazioni avanzate: dipendenze che devi separare
1) Meccaniche stabili vs condizioni variabili
Separa ciò che è stabile da ciò che è variabile:
- Meccaniche stabili: il Last Look introduce un passaggio di accettazione condizionale dopo che una richiesta di esecuzione è stata ricevuta.
- Condizioni variabili: la decisione del provider può dipendere dalla volatilità di mercato, dalla latenza, dagli spread, dai limiti di rischio interni e dalle policy di giurisdizione o sede.
Se non separi questi elementi, potresti attribuire in modo errato gli esiti alla logica lato cliente. Ad esempio, una richiesta rifiutata non implica automaticamente che la tua richiesta fosse “sbagliata”; potrebbe riflettere le regole interne di accettazione/rifiuto del provider nelle condizioni correnti.
2) Tempistiche e il significato di “ancora accettabile”
L’analisi avanzata spesso dipende dalle tempistiche. Devi capire quale “tempo di riferimento” usa il provider per il confronto e quanto tempo consente prima che la decisione debba essere presa.
Assunzioni che dovresti rendere esplicite per qualsiasi calcolo o esempio:
- Il timestamp dell’exchange o del feed lato cliente può differire dal timestamp interno del provider.
- La latenza di rete e il tempo di elaborazione possono essere significativi rispetto a qualsiasi finestra decisionale del Last Look.
- Un cambiamento rapido di prezzo può trasformare una richiesta inizialmente accettabile in una rifiutata.
3) Quale prezzo o tasso viene confrontato
Le decisioni di Last Look in genere richiedono di confrontare qualcosa della richiesta in arrivo con qualcosa di osservabile lato provider. Le incertezze comuni includono:
- Se il confronto usa bid/ask al momento della decisione o un mid di riferimento.
- Se il confronto include lo spread o il modello di pricing del provider.
- Se il provider usa una banda di tolleranza (per esempio, una deviazione massima) invece di un’uguaglianza rigorosa.
Se il provider non espone questi dettagli in modo trasparente, la verifica indipendente è limitata a ciò che mostrano i tuoi registri (tempi delle richieste, esiti di accettazione/rifiuto e eventuali reason code inclusi nei tuoi dati).
4) Costi ed effetti post-decisione
Anche quando il Last Look controlla solo accettazione/rifiuto, i risultati complessivi possono comunque essere influenzati da:
- Lo spread effettivo al momento dell’esecuzione.
- La presenza di eventuali commissioni o fee applicate da intermediari.
- Le differenze tra il prezzo che ti aspettavi e il prezzo effettivamente eseguito.
Per mantenere l’analisi autosufficiente, tratta “il costo” come una variazione osservata nei tuoi record di esecuzione (per esempio, la differenza tra il tuo prezzo di riferimento intenzionale e il prezzo eseguito), piuttosto che basarti su assunzioni sul comportamento futuro del mercato.
Evidenze ed esempi: come il Last Look si manifesta nei dati reali di esecuzione
Di seguito sono riportati esempi di pattern che puoi cercare senza assumere alcuna implementazione specifica del provider.
Esempio A: cluster di rifiuti durante movimenti rapidi
Assunzione per l’esempio:
- Hai log di esecuzione con timestamp per ogni richiesta e un esito accettazione/rifiuto.
Cosa controllare:
- Se i rifiuti aumentano durante periodi noti per una volatilità più elevata.
- Se il tempo tra la richiesta e la risposta finale è consistente.
Limite di questo approccio:
- La correlazione non prova la causalità. Una volatilità più alta può coincidere con altri fattori come limiti di rischio o regole di gestione degli ordini.
Esempio B: decisioni “tardive” creano aspettative non allineate
Assunzione per l’esempio:
- Il tuo sistema registra un prezzo o un prezzo di riferimento quando invii la richiesta.
Cosa controllare:
- La relazione tra il timestamp di invio e il livello di prezzo al momento in cui arriva la risposta registrata.
- Se accettazioni e rifiuti mostrano sistematicamente tempistiche diverse.
Incertezza chiave:
- Senza orologi sincronizzati tra il tuo sistema e il provider, “ciò che il provider ha visto” potrebbe non essere ricostruibile esattamente.
Esempio C: partial fill e più gambe
Se il meccanismo interagisce con i partial fill, potresti osservare:
- Alcune parti accettate e altre rifiutate.
- Esiti diversi tra tentativi ripetuti.
Assunzione:
- Il tuo dataset distingue fill, rifiuti e conferme parziali.
Cosa controllare:
- Se il tasso di rifiuto dipende dalla dimensione, dal numero di tentativi o dalla sequenza.
Modalità di fallimento:
- Se il tuo logging unisce più eventi in un singolo record di “tentativo”, potresti interpretare male come il Last Look abbia influenzato ciascun segmento.
Limitazioni e rischi: modalità di fallimento nella comprensione del Last Look
1) Trasparenza limitata
Una limitazione sostanziale è che potresti non ricevere informazioni dettagliate sul motivo per cui una richiesta è stata rifiutata. Senza reason code o soglie documentate, è difficile separare:
- Gli effetti dei movimenti di mercato dai controlli di rischio del provider.
- Le differenze di gestione tecnica dai filtri specifici del Last Look.
2) Vincoli nascosti e comportamento nei casi limite
I casi limite avanzati possono produrre esiti che sembrano incoerenti:
- Variazioni rapide di prezzo che avvengono tra l’invio della richiesta e la valutazione interna del provider.
- Momenti in cui gli spread si allargano rapidamente, cambiando ciò che è “accettabile”.
- Situazioni in cui i tuoi retry vengono trattati come decisioni separate, possibilmente con tempistiche diverse e quindi esiti diversi.
3) L’analitica può essere fuorviante senza definizioni accurate
La verifica richiede definizioni chiare. Errori comuni:
- Trattare “rifiuto” come “il prezzo era peggiore” senza confermare la regola decisionale del provider.
- Confrontare i prezzi di riferimento delle richieste con i prezzi di esecuzione senza considerare le differenze di timestamp.
- Sovradattare le conclusioni a un singolo regime di mercato.
Le relazioni storiche non stabiliscono risultati futuri, soprattutto in mercati con volatilità e liquidità variabili.
4) Variabilità di giurisdizione e sede
L’esecuzione e la gestione legale possono differire tra giurisdizioni e sedi. Questo crea un rischio di assumere che il comportamento di un provider si generalizzi. Per una comprensione accurata, fai affidamento sulla documentazione legale del provider, sulle spiegazioni ufficiali della sede e sui tuoi record di esecuzione osservati, e aspettati variabilità.
Come verificare il comportamento del Last Look e cosa chiedere dopo
Checklist di verifica indipendente
Per verificare in modo indipendente come il Last Look abbia influenzato le tue esecuzioni, concentrati sui dati che controlli:
- Per ogni richiesta: registra timestamp della richiesta, riferimento intenzionale (ciò che hai usato) ed esito accettazione/rifiuto.