Valutazione della Qualità dell’Esecuzione per l’Accesso API (Contesto Forex, Educativo)

Cosa significa “qualità dell’esecuzione” per l’accesso API

La qualità dell’esecuzione indica quanto efficacemente un ordine inviato tramite API produce il risultato desiderato rispetto a quanto previsto al momento dell’invio. In pratica, si giudica la qualità dell’esecuzione attraverso il comportamento osservabile del sistema: tempi, gestione degli ordini, corrispondenza tra esecuzioni richieste e effettive, e frequenza di errori o eventi inattesi.

L’accesso API modifica i punti in cui possono verificarsi problemi di esecuzione. Oltre al comportamento del mercato e della strategia, si deve considerare anche l’infrastruttura (“plumbing”) relativa all’invio degli ordini e al ciclo di vita degli ordini: come l’API riceve la richiesta, come conferma l’accettazione, come aggiorna lo stato dell’ordine e come riporta le operazioni al sistema.

Meccaniche fondamentali: ciò che è possibile misurare

Per valutare la qualità dell’esecuzione, definire prima alcuni termini.

• Tempo di richiesta: quando l’applicazione invia il messaggio d’ordine.
• Conferma/accettazione: quando l’API conferma che l’ordine è stato accettato per l’elaborazione.
• Tempo dell’evento di esecuzione: quando avvengono i riempimenti o le cancellazioni (come riportato dall’API).
• Risultati attesi vs. effettivi: se il prezzo, la quantità o i tempi di esecuzione corrispondono a quanto previsto dal sistema.

Una valutazione misurabile include generalmente:

1. Distribuzione della latenza (non solo una media). Registrare il tempo tra la richiesta e la conferma, e tra la conferma e il primo riempimento. Considerare i percentili (ad esempio, con quale frequenza è “abbastanza veloce”).
2. Affidabilità. Misurare i tassi di ordini rifiutati, timeout, richieste duplicate e aggiornamenti di stato mancanti.
3. Accuratezza del risultato dell’ordine. Confrontare prezzo/quantità/vincoli richiesti con quanto effettivamente eseguito o confermato (inclusi i riempimenti parziali).
4. Integrità degli eventi. Verificare che la sequenza degli stati dell’ordine ricevuti (accettato → parzialmente riempito → riempito/cancellato) sia coerente e completa.
5. Trasparenza dei costi. La qualità dell’esecuzione non può essere separata dai costi totali di transazione (spread, commissioni, fee e qualsiasi slippage implicato dalle differenze di esecuzione). Può essere valutata solo utilizzando i prezzi e le fee effettivamente applicati.

Un concetto chiave è confrontare l’esecuzione osservata con una base di riferimento sotto il proprio controllo. La base di riferimento può essere un test controllato con ordini di piccole dimensioni in condizioni costanti, con timestamp e input chiaramente registrati.

Evidenze ed esempio: un test di verifica

Si supponga di eseguire un test inviando ordini limite identici tramite API e registrando:

• il timestamp esatto della richiesta dall’applicazione,
• il timestamp di accettazione dell’API,
• il timestamp del primo e del completo riempimento,
• il prezzo e la quantità eseguiti,
• eventuali codici di errore o aggiornamenti mancanti.

Si calcolano quindi alcune sintesi su molteplici prove:

• Ritardo di conferma = tempo di accettazione − tempo di richiesta.
• Tempo al primo riempimento = tempo del primo riempimento − tempo di richiesta (o − tempo di accettazione, purché si scelga una definizione coerente).
• Deviazione di esecuzione = differenza tra il prezzo richiesto e il prezzo effettivamente eseguito (in senso direzionale e in valore assoluto).
• Completezza di esecuzione = (quantità eseguita ÷ quantità richiesta) per ogni ordine, e la percentuale di ordini che terminano con riempimento parziale.

Poiché le condizioni di mercato possono cambiare rapidamente, si separano due livelli di evidenza:

• Evidenza del comportamento del sistema: se ritardi, rifiuti e aggiornamenti mancanti si verificano con tassi prevedibili o stabili in condizioni comparabili.
• Evidenza di mercato e costi: se le differenze di esecuzione possono essere spiegate da variazioni di liquidità e costi di transazione piuttosto che dalla gestione API.

Si devono inoltre mantenere esplicite le assunzioni. Ad esempio, se il test utilizza lo stesso time-in-force o lo stesso tipo di ordine, va specificato; altrimenti l’interpretazione di accettazione e riempimenti parziali diventa ambigua.

Limitazioni e modi di errore da considerare

Anche quando le misurazioni sembrano positive, la qualità dell’esecuzione non è completamente prevedibile. Le limitazioni materiali comuni includono:

• Modo di errore: ordini rifiutati o in timeout. Un sistema può essere veloce quando funziona, ma avere comunque tassi inaccettabili di rifiuto quando cambiano carico o connettività.
• Modo di errore: dati di mercato obsoleti o incoerenti. Se l’applicazione basa le decisioni su dati in ritardo rispetto al momento dell’invio dell’ordine, si possono ottenere esecuzioni peggiori che non sono solo un problema di “latenza”.
• Modo di errore: riempimenti parziali e aggiornamenti post-esecuzione. I riempimenti parziali possono essere corretti, ma se l’applicazione gestisce male la quantità residua o le sequenze di stato, la qualità misurata dell’esecuzione può riflettere errori logici del software.
• Limite di misurazione: allineamento dei timestamp. Se si confrontano timestamp locali con quelli riportati dall’API senza comprendere la sincronizzazione degli orologi, le conclusioni sulla latenza possono essere distorte.
• Limite di evidenza: il passato non garantisce il futuro.