Pronti per MiFID II?
La direttiva MiFID II, relativa al mercato degli strumenti finanziari, sarà attuato nei mercati finanziari a partire dal Gennaio 2018.
Nell'ambito della nuova regolamentazione, le sedi di negoziazione ed loro membri sono tenuti a sincronizzare le loro reti commerciali interne, mantenendosi entro definite tolleranze rispetto ad UTC (Universal Coordinated Time). Le sedi di negoziazione sono inoltre tenute a dimostrare, con cadenza annuale, la conformità, basata sulla documentazione del sistema di sincronizzazione, a questa nuova normativa.
QUALE PRECISIONE È NECESSARIA IN UNA RETE AD ALTA FREQUENZA DI TRADING PER MIFID II?Le norme RTS 25 specificano una deviazione di non più di 100 microsecondi da UTC negli ambienti High Frequency Trading (HFT) o una latenza di 1 millisecondo da UTC in tutti gli altri ambienti commerciali non umani. Una varianza stretta significa che la fonte principale del tempo deve essere il più accurato possibile per consentire qualsiasi jitter imprevisto sulla rete, che potrebbe aumentare il ritardo dei pacchetti di temporizzazione e quindi la sincronizzazione del client finale. È estremamente difficile soddisfare questo requisito 100 microsecondi utilizzando un server NTP, poiché il protocollo NTP non è abbastanza preciso negli ambienti di rete standard. Pertanto, per ridurre al minimo il margine possibile, è consigliabile utilizzare un orologio Grandmaster PTPv2, switch PTPv2 compatibili e server specifici per creare Time Stamp compatibili con MiFID II. Sincron Sistemi può fornire sia soluzioni flessibili per PTPv2 Grandmaster Clocks attraverso la gamma Meinberg Lantime IMS di server di tempo, che supportarvi nella fase di progetto di switches a bassa latenza attraverso la collaborazione con i nostri partner, in modo tale da fornirvi un servizio “chiavi in mano” per quanto riguarda l’aspetto relativo alla sincronizzazione. Tutti questi sistemi possono essere personalizzati individualmente in base ai requisiti dell'utente finale e della rete, permettendo la massima modularità e flessibilità.
QUALE TIPO DI PRECISIONE POSSO PREVEDERE DAL GRAND MASTER AL SERVER SE UTILIZZO PTPV2?
Non è possibile fornire un valore preciso relativo alla latenza globale del percorso di rete in quanto dipende da molte variabili indipendenti all'interno di ciascuna rete. Un caso potrebbe essere se l'intero percorso di rete è PTPv2 compatibile; Se gli switches non sono compatibili con PTPv2, si aggiungerà un ritardo sconosciuto allo slave finale, che il protocollo PTPv2 non sarà in grado di compensare per ridurre la deviazione dall'ora UTC. Altre variabili da considerare sono se i pacchetti PTPv2 seguiranno sempre lo stesso percorso di rete dal Grandmaster al gateway finale (ritardo simmetrico) piuttosto che diversi percorsi di rete da e verso il gateway finale (ritardo asimmetrico) e altri fattori come La larghezza di banda della rete e il tipo di profilo PTPv2 utilizzato.
COME SI PUÒ DIMOSTRARE CHE IL TEMPO È RINTRACCIABILE ALL'ORA UTC?
Il 10 ottobre 2016 L'ESMA ha confermato che la sincronizzazione con GNSS è accettabile, fintanto che la trasmissione di tempo è in UTC, secondo l'istruzione seguente: "L'impiego dell'origine temporale del sistema di posizionamento globale (GPS) statunitense o di qualsiasi altro sistema satellitare di navigazione globale, come il sistema satellitare russo GLONASS o europeo Galileo, quando sarà operativo, è altrettanto accettabile per registrare eventi dichiarabili a condizione che qualsiasi compensazione da UTC venga contabilizzata e rimossa dal timestamp. Il tempo GPS è diverso da UTC. Tuttavia, il messaggio di tempo GPS include anche un offset da UTC (secondi di salto) e questo offset dovrebbe essere combinato con il timestamp GPS per fornire un timestamp conforme ai requisiti di divergenza massima in RTS 25."
Cosa succede se la sincronizzazione GNSS viene persa? La rete sarebbe ancora conforme?
Ciò dipende dal rimanente budget di errore che è lasciato al termine della rete. I sistemi Meinberg possono essere forniti con diversi tipi di oscillatore che consentono all'Orologio Grandmaster di tenere il tempo per un certo periodo dopo la perdita della sincronizzazione GNSS. La scelta di quale oscillatore prevedere è difficile in quanto il rimanente "budget di errore" deve essere conosciuto per garantire che la deriva dell'oscillatore non influenzi l'ora sui pacchetti PTPv2 in una misura tale da mettere fuori rete le specifiche di conformità . Ad esempio, se un sistema Meinberg Lantime / M1000 / IMS fosse dotato di un oscillatore OCXO-HQ e sincronizzato solo con un segnale GNSS e installato in rete, nel "budget di errore" dovrebbero essere disponibili almeno 22 µSecondi per consentire al Grandmaster di fornire la sincronizzazione PTPv2 per 1 giorno in hold over mode. L'OCXO-HQ ha una deriva temporale massima di 22 µSecondi al giorno, dopo essere rimasto sincronizzato con un segnale GNSS per 24 ore. Gli oscillatori di qualità più elevata consentirebbero un hold over più lungo, ma anche un consistente incremento di costi; ad esempio un oscillatore di backup Rubidium offre un hold over di soli 1,1 22 µSecondi al giorno, ma a fronte di prezzo molto più elevato dell’ OCXO-HQ. Potete confrontare la tabella degli oscillatori Meinberg disponibili a questo link. Una possibile alternativa potrebbe essere quella d’aver una ulteriore sorgente PTPv2 di rimpiazzo in caso la connessione GNSS dovesse cadere.
QUALI ALTERNATIVE ESISTONO ALLA SINCRONIZZAZIONE GNSS?
Come accennato in precedenza, un'altra alternativa è quella di installare un altro Clock Grandmaster in una posizione separata (disaster recovery) e quindi fornire il servizio PTPv2 diretto come backup per il GPS, con entrambe le soluzioni totalmente ridondate, in modo tale da garantire la più totale sicurezza dell'intero sistema.
COSA SONO I LEAP-SECONDS E PERCHÉ SONO IMPORTANTI PER LE NORME RTS25?
I “leap-seconds” sono incrementi del tempo di correzione per correggere l'effetto della rotazione non standard della Terra. La rotazione della Terra infatti non è uniforme, e per evitare che la lunghezza del giorno si sposti, diventa necessario regolare l'ora UTC per corrispondere a questo offset, attraverso l'introduzione di leap-seconds. L'avvento dei leap-second è stabilito da un ente internazionale con sede a Parigi, chiamato INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS). I leap seconds sono importanti per RTS 25 perché, come detto sopra, è necessario che l'ora in rete sia fornita in UTC. Se un secondo aggiornamento di leap second non viene trattato correttamente attraverso l'apparecchiatura, la rete si scosterà di 1 secondo dall'ora UTC, provocando grossi problemi in rete. I sistemi Meinberg sincronizzati GNSS normalmente ricevono e gestiscono automaticamente le informazioni di leap second, in quanto tutti i secondi annunci di salto vengono trasmessi attraverso i satelliti GNSS con diversi mesi di anticipo. Tuttavia è importante verificare come la rete gestirà l'aggiunta di un leap second e se tutte le apparecchiature installate siano in grado di affrontare il leap second.
E LA VERIFICA DELLA RETE?
L'articolo 4 della MiFID II richiede una revisione annuale per dimostrare la conformità ai regolamenti MiFID II. Le norme non indicano la necessità di monitorare la rete tra le successive revisioni di conformità, tuttavia è altamente consigliabile che una soluzione di monitoraggio sia considerata ed attuata. Uno degli incentivi principali per l'attuazione di una soluzione di monitoraggio nella rete infatti è il caso in cui (per esempio) la revisione annuale risultasse non conforme ai requisiti. In questo caso il cliente dovrebbe essere in grado di dimostrare davanti agli enti competenti che la rete è stata conforme per tutta la maggior parte dell'anno e dimostrare anche le ragioni per cui non è stata in conformità al giorno della revisione. Se si può dimostrare che per il 99% dell'anno la rete è stata conforme questo significa che la normativa rispettata e di conseguenza sarà anche più facile dimostrare che il giorno della revisione c’è stato un qualsiasi tipo di malfunzionamento o di errore, come ad esempio a causa di un problema di sincronizzazione del segnale GPS che ha causato una perdita di sincronizzazione primaria e questo permetterà sicuramente di evitare eventuali sanzioni. In base a questo il monitoring diventa una vera e propria necessità delle reti dedicate alla finanza e per questo motivo Meinberg ha sviluppato una soluzione di monitoraggio per le normative MiFID II che incorpora un'estensione al protocollo PTPv2 esistente per misurare direttamente il ritardo dei clienti finali selezionati, piuttosto che affidarsi allo stato di auto-segnalazione dei clienti. Le informazioni di ritardo ottenute dai client monitorati possono essere visualizzate in formato grafico tramite l'interfaccia web del sistema Meinberg, consentendo un rapido elaborazione di informazioni per scopi di controllo o in alternativa scaricati e memorizzati in remoto per l'elaborazione e la valutazione.
