MiFID II — Synchronisation des horloges
Précision des horloges RTS 25

1. Périmètre : qui RTS 25 lie, et selon quelle table

« RTS 25 » désigne le règlement délégué (UE) 2017/574, la norme technique de réglementation sur le niveau de précision des horloges. Il complète la directive 2014/65/UE (MiFID II), dont l'article 50 exige que les horloges utilisées pour enregistrer la date et l'heure des événements à déclarer soient synchronisées.

Il lie deux populations distinctes, chacune régie par une table différente de l'annexe :

• Les opérateurs de plates-formes de négociation — marchés réglementés, MTF et OTF. Leur palier (annexe, table 1) est fixé par la latence passerelle-à-passerelle de chaque système de négociation.
• Les membres ou participants d'une plate-forme de négociation — les entreprises d'investissement qui y négocient. Leur palier (annexe, table 2) est fixé par le type d'activité de négociation.

2. L'obligation centrale — traçable au temps UTC, dans le palier

L'obligation a deux dimensions mesurables, fixées par palier applicable :

1. La divergence maximale par rapport au temps UTC — l'écart maximal de l'horloge par rapport au temps universel coordonné à l'instant où l'horodatage est appliqué.
2. La granularité de l'horodatage — la plus petite unité de temps que l'horodatage enregistré doit résoudre (1 seconde, 1 milliseconde ou 1 microseconde).

Les deux sont ancrées au temps UTC, et la référence est précisée à l'article 1 :

Deux conséquences directes. D'abord, une horloge en roue libre — aussi stable soit-elle — est non conforme : l'exigence porte sur la divergence par rapport au temps UTC, une référence externe, pas sur la stabilité interne. Ensuite, si vous tirez le temps du GNSS, l'écart GNSS-vers-UTC doit être documenté et éliminé, et non supposé nul.

3. Les deux tables de précision tiérées

Ces deux tables, issues de l'annexe du règl. (UE) 2017/574, sont le cœur de la norme. Trouvez votre ligne, et vous avez votre budget de divergence et votre granularité.

Table 1 — Opérateurs de plates-formes de négociation (critère : latence passerelle-à-passerelle)

La « latence passerelle-à-passerelle » est le temps que met le système d'appariement d'une plate-forme entre la réception d'un message à une passerelle et l'émission à une autre. Un moteur d'appariement sous la milliseconde fait basculer la plate-forme dans le palier des 100 µs.

Table 2 — Membres ou participants (critère : type d'activité de négociation)

4. Traçabilité au temps UTC et réexamen annuel

Atteindre le chiffre ne suffit pas ; vous devez pouvoir le prouver sur demande. L'article 4 fait de la traçabilité et de la documentation une obligation permanente :

En pratique, la « traçabilité au temps UTC » signifie une chaîne ininterrompue et documentée depuis votre horloge jusqu'à une réalisation reconnue du temps UTC — un UTC(k) tenu par un institut national de métrologie, par exemple UTC(OP) au LNE-SYRTE, Observatoire de Paris, ou UTC(PTB), UTC(NPL), UTC(NIST) — ou vers le temps UTC diffusé par GNSS avec l'écart documenté et éliminé. La chaîne, le point d'application de l'horodatage et la divergence mesurée doivent tous être écrits, et l'ensemble réexaminé au moins une fois par an.

5. Une topologie de référence conforme

L'architecture qui se projette proprement sur l'article 4 : une couche Stratum 1 disciplinée par GNSS et supervisée, une couche de distribution documentée, et un budget de précision enregistré de bout en bout :

        ┌───────────────────────────────────────────────┐
        │  Référence : réalisation du temps UTC          │
        │  ─────────────────────────────────────────────  │
        │  GNSS (multi-constellation) + PPS              │
        │  écart-vers-UTC documenté & éliminé            │
        │  recoupement vs UTC(k) labo national           │
        └─────────────────┬─────────────────────────────┘
                          │  disciplinée par PPS, supervisée
                          ▼
        ┌───────────────────────────────────────────────┐
        │  Serveurs Stratum 1 (redondants, pairés)       │
        │  ─────────────────────────────────────────────  │
        │  horodatage matériel pour le palier 100 µs     │
        │  NTS pour une distribution logicielle authentifiée│
        └─────────────────┬─────────────────────────────┘
                          │  distribution par palier
                          ▼
        ┌───────────────────────────────────────────────┐
        │  Points d'horodatage (l'horloge enregistrée)   │
        │  ─────────────────────────────────────────────  │
        │  moteur d'appariement / OMS / passerelle       │
        │  divergence mesurée & journalisée en continu   │
        └───────────────────────────────────────────────┘

C'est exactement le type d'infrastructure Stratum 1 supervisée qu'exploite et documente RDEM Systems — une référence disciplinée par GNSS, supervisée par PPS, avec un budget de précision enregistré. Le schéma de référence et le rôle du serveur sont décrits sur le hub : l'infrastructure de temps RDEM et la référence du serveur Stratum 1. Pour la couche de distribution authentifiée, voir NTS (RFC 8915).

6. Quel protocole pour quel palier (NTP, NTS, PTP, GNSS)

RTS 25 ne nomme aucun protocole. Il est volontairement neutre sur le plan technologique — il fixe un résultat (divergence + granularité) et exige une preuve. La question d'ingénierie est simplement : quelle méthode de distribution peut démontrer qu'elle tient votre palier ?

7. Dossier de preuves pour le régulateur

À constituer et tenir à jour — l'article 4 en fait un dossier vivant, réexaminé au moins une fois par an :

1. Document de conception du système. La chaîne de traçabilité complète depuis l'horloge jusqu'à une réalisation du temps UTC, avec le point d'application de l'horodatage identifié.
2. Détermination du palier. Pour chaque système/activité, la ligne applicable de la table 1 ou table 2 et la justification (latence passerelle-à-passerelle mesurée, ou classification de l'activité).
3. Preuve de la référence. La source UTC employée (labo UTC(k) ou GNSS) et — pour le GNSS — la documentation que l'écart au temps UTC est pris en compte et éliminé.
4. Mesure de la divergence. Relevés continus ou échantillonnés montrant que la divergence mesurée reste dans le palier, avec la méthodologie.
5. Preuve de granularité. Démonstration que les horodatages enregistrés résolvent l'unité requise (1 s / 1 ms / 1 µs).
6. Réexamen annuel. Trace datée du réexamen de conformité au moins annuel et des actions correctives.
7. Validation des sources. Sortie du Validateur NTP en ligne sur chaque source externe — stratum, offset, refID, joignabilité double pile — versée au dossier.

8. RTS 25 vs RTS 22 / RTS 24 — ne pas les confondre

Trois normes techniques MiFID II / MiFIR touchent au « temps », et le régulateur attend que vous les gardiez distinctes :

RTS 25 est le socle sur lequel reposent les deux autres : RTS 22 et RTS 24 prescrivent quel horodatage enregistrer et où l'envoyer, mais l'horodatage ne vaut que ce que vaut l'horloge qui l'a produit. Pour l'interprétation de tutelle des cas limites, les Q&A de l'ESMA sur les thématiques de structures de marché MiFID II/MiFIR font référence. Pour situer RTS 25 aux côtés d'ISO 27001, NIS 2, PCI-DSS et DORA en un seul endroit, utilisez la checklist d'audit NTP ; pour l'angle résilience du secteur financier, voir le guide compagnon DORA et synchronisation horaire.

Autre angle ? Le bon outil :

• Mesurer gigue, offset, latence → ntp-tester.eu
• Diagnostiquer pare-feu / port 123 / démon → check-ntp.net
• Architecture de référence entreprise → ntp.rdem-systems.com