Come misurare la scadenza di un ordine pendente?

Risposta diretta

La scadenza di un ordine pendente può essere misurata registrando (1) il timestamp di creazione dell’ordine, (2) il timestamp quando l’ordine diventa idoneo all’esecuzione, (3) la regola di scadenza configurata e la sua ora di riferimento, e (4) il timestamp (e lo stato) con cui la piattaforma segna l’ordine come scaduto o annullato. Per misurarla con precisione, definisci cosa tratterai come ora di inizio, cosa tratterai come ora di scadenza e come gestirai i casi ambigui come “eseguito vicino alla scadenza” o “scaduto dopo la riconnessione”.

Meccanismo e definizione

Un “ordine pendente” è un ordine che non viene eseguito immediatamente; attende finché le condizioni di mercato corrispondono al suo trigger (ad esempio, il prezzo che raggiunge un determinato livello). “Scadenza” è la regola di terminazione che impedisce all’ordine pendente di rimanere attivo oltre un punto nel tempo prestabilito.

Per misurare la scadenza di un ordine pendente, usa campi misurabili invece di formulazioni informali. I campi comuni su cui puoi basare i calcoli sono:

1. Timestamp di inizio: il momento in cui consideri che inizi il conto alla rovescia. Spesso è l’ora di creazione dell’ordine, ma alcuni sistemi separano “creato”, “accettato” e “diventato attivo”.

2. Configurazione di scadenza: la regola che determina quando l’ordine deve smettere di essere attivo (ad esempio, un orario di fine fisso o una durata dalla collocazione). La configurazione è necessaria perché due ordini possono entrambi “scadere”, ma in momenti diversi.

3. Timestamp di scadenza target: l’ora di fine calcolata implicita dalla configurazione (ad esempio, ora di collocazione + durata, oppure un orario di clock specificato). È un valore pianificato che puoi calcolare.

4. Esito osservato: il timestamp e lo stato riportati dalla piattaforma che indicano cosa è accaduto realmente (ad esempio, lo stato diventa “scaduto”, “annullato” o “eseguito”). Questo è il valore misurato.

Una misurazione pratica è la differenza tra il timestamp osservato per lo stato terminale e lo timestamp di scadenza target, oppure la differenza tra il timestamp terminale osservato e il timestamp di inizio. Usa la stessa base temporale per entrambi i valori.

Evidenza o esempio

Esempio di approccio di misurazione (assunzioni dichiarate):

• Assumi che tutti i timestamp siano riportati nello stesso fuso orario, oppure che li converti in un unico fuso orario in modo coerente.
• Assumi che la piattaforma fornisca una voce di cronologia ordini che contenga un timestamp di scadenza con stato “expired”.

Passi per misurare:

1. Acquisisci il timestamp di creazione dell’ordine (inizio). Chiamalo T_start.

2. Acquisisci la configurazione di scadenza e ricava lo timestamp di scadenza target. Chiamalo T_target.

3. Individua l’evento terminale che corrisponde alla scadenza. Chiamalo timestamp della piattaforma T_observed e registra lo stato terminale.

4. Calcola due valori:

• Durata pianificata: Δ_planned = T_target − T_start
• Ritardo di scadenza realizzato: Δ_delay = T_observed − T_target

Interpretazione:

• Se Δ_delay è vicino a zero, la piattaforma ha segnato l’ordine come scaduto vicino all’ora prevista.
• Se Δ_delay è costantemente positivo, il tuo sistema potrebbe registrare la scadenza dopo un certo ritardo di elaborazione, un ritardo di riconnessione o un aggiornamento di fine ciclo.
• Se lo stato terminale non è “expired” (ad esempio, “filled”), allora la scadenza non è stato l’esito terminale per quell’ordine specifico; la misurazione resta valida perché risponde a una domanda diversa: “Quale stato terminale è avvenuto e a che ora?”

Questo approccio ti aiuta a verificare “scadenza” come proprietà del ciclo di vita dell’ordine nel tuo sistema, non come una supposizione basata su quotazioni esterne.

Limitazioni e rischi (modalità di guasto rilevanti)

Esistono diverse limitazioni che influenzano la misurazione:

1. Mancata corrispondenza di orologio e fuso orario Se T_start, T_target e T_observed provengono da sorgenti o fusi orari diversi, Δ_planned e Δ_delay possono risultare fuorvianti anche quando la piattaforma si comporta correttamente.

2. Stati terminali ambigui Vicino al momento di scadenza, un ordine può riempirsi, riempirsi parzialmente o essere marcato come scaduto dopo decisioni di esecuzione. La tua misurazione dipende dalle definizioni della piattaforma per le transizioni di stato e da come le timestamp.

3. Tempistiche dei dati e connettività Anche senza assumere dati di mercato in tempo reale, puoi comunque vedere un apparente “drift della scadenza” causato da aggiornamenti ritardati dello stato, tempi di refresh dell’applicazione o dall’ordine dei log di audit.

4. Condizioni di mercato variabili Le condizioni di trigger dell’ordine e il momento in cui sarebbe stato eseguito (se fosse rimasto attivo) possono cambiare rapidamente. Le relazioni storiche non garantiscono che gli ordini futuri si comporteranno in modo simile.

5. Regole di ciclo di vita specifiche del provider o della giurisdizione Diverse sedi di esecuzione, infrastrutture e regole operative possono influenzare cosa significa operativamente “expired” (ad esempio, quando la piattaforma smette di instradare l’ordine). La tua misurazione potrebbe quindi riflettere la policy della piattaforma piuttosto che una regola universale.

DOCUMENT END