MiFiD II : et vous, êtes-vous prêt ?

La dernière ligne droite approche pour MiFiD II. Toutes les forces doivent être jetées dans la bataille avant le 3 janvier 2018. Nombreux sont ceux qui se demandent ce qu’est exactement ce MiFiD II, ce qui fait trembler plus d’un chef de projet.

MiFiD II n’est autre que la suite de MiFiD I, une directive européenne entrée en application en novembre 2007 et qui avait pour ambition de construire un marché financier européen intégré en introduisant, entre autres, la concurrence entre les lieux de négociation, notamment pour diminuer le coût des transactions. Le bilan de cette première directive est aujourd’hui assez décrié, en particulier sur les effets attendus de cette concurrence. En effet, quand elle devait permettre de favoriser la concurrence entre les plateformes de négociation, elle a surtout fragmenté la liquidité et donc rendu plus difficile l’accès à l’information pour les petits investisseurs. L’Union européenne vient renforcer MiFiD I avec MiFiD II, dont les objectifs sont les suivants :

• Recentrer la négociation sur les marchés réglementés,
• Étendre la transparence pré et post-trade,
• Promouvoir une concurrence équitable entre les lieux d’exécutions,
• Encadrer les activités de trading algorithmique,
• Renforcer la protection des investisseurs.

En termes d’instruments financiers, la couverture est elle aussi totalement revue. Quand MiFiD ne couvrait que les actions, MiFiD II couvre les actions et assimilés (EFT, certificats, etc.), les produits dérivés (options, futures), les produits structurés, les obligations, etc. L’application de cette directive européenne prend forme en un certain nombre de RTS (Regulatory Technical Standards), expliquant le plus concrètement possible ce que les entreprises doivent mettre en place.

Transaction Reporting

La première (et la plus connue des RTS) est la RTS 22 qui vient définir le mode de reporting des transactions. Ce reporting, obligatoire à J+1 de chaque transaction, vise à envoyer au régulateur des informations sur la transaction dans un format défini. Il permet ainsi au régulateur une meilleure détection des abus de marchés en retraçant la vie complète d’un trade, que ce soit au sein d’une BFI, d’un broker puis sur la trading venue. Pour ce faire, il requiert en outre :

• Une identification précise des personnes physiques impliquées dans la transaction, ce qui implique la déclaration de codes pour identifier un trader de manière unique (un format CONCAT agrège la date de naissance du trader, son code pays, 5 lettres de son nom et autant de son prénom).,
• Une identification précise de la trading capacity : la banque traite-t-elle pour son propre compte (DEAL) pour un client (AOTC) ou en “matchant” 2 ordres clients (MTCH),
• L’identification de la personne morale avec laquelle on traite (via son code LEI),
• Le lieu exact de l’exécution (code MIC),
• Les identifiants éventuels reçus de la trading venue (TVTIC).

Ces informations sont donc à envoyer au régulateur à J+1 de chaque transaction (dans un scope de transactions reportables). D’un point de vue IT/système, cela sous-entend qu’un trade peut être entièrement tracé entre la demande du client ou la décision du trader jusqu’à la plateforme de négociation. Cela suppose donc une très bonne interopérabilité des systèmes. Cela peut paraitre simple, mais dans des grosses structures, cela s’avère très compliqué. MiFiD II s’accompagne d’obligations d’audit au sein de la banque (notamment une ribambelle de timestamps). Un système de type OMS est donc indispensable.

Architecture simplifiée d’un OMS centralisant la négociation OTC & organisée entre la banque et ses clients

Quelle est l’efficacité de la mesure ? Des giga-octets de données seront envoyés au régulateur, et chaque jour un peu plus. Quels systèmes a-t-il mis en place pour analyser les reports ? Des investissements Bigdata ont-ils été prévus ? Rien n’est clair. Dans tous les cas, un tel reporting n’est réellement efficace que si un investissement important en traitement automatisé est mis en place. De la même manière, des missions d’audit au sein des banques seront nécessaires pour aider, vérifier et corriger.

Post-Trade transparency

Envoyer des giga-octets de données ne va clairement pas révolutionner le marché sur le court terme. D’autres RTS existent pour encadrer la négociation OTC, dans l’objectif de recentrer la négociation sur les plateformes réglementées. Les principes sont assez simples : publier en temps réel ou quasi temps réel toute transaction OTC sur un instrument listé non réalisé sur une trading venue. Ceci afin d’afficher publiquement les transactions OTC et donner de la visibilité sur les prix échangés en OTC sur un instrument. Cette transparence existe depuis longtemps sur les dérivés listés, comme les options où chaque membre de marché est dans l’obligation de déclarer tout deal fait en OTC sur un instrument listé sur ce marché. Ainsi toute personne abonnée au flux du marché pourra voir à quel prix a été échangé l’instrument en OTC (on parle de block). Informations précieuses pour tout trader !

Ainsi, chaque banque devra envoyer à un organisme habilité (appelé APA), soit en temps réel, soit après un temps autorisé, la transaction OTC.

Négociation OTC d’un instrument listé

Négociation d’un instrument listé sur le marché

Ce flux, publié par les APAs, devrait être ensuite accessible à tous, “free of charge”. L’accès à cette donnée de marché va être un point critique : les APAs diffuseront certainement “free of charge” (comme demandé par MiFiD) le flux public via leur infrastructure actuelle dont l’accès est payant. CQFD. Le régulateur prévoit de la même manière un statut de CTP qui pourra agréger les données des APAs et les publier. Rien n’est clair pour le moment, mais on imagine que Reuters et Bloomberg doivent être déjà sur les rangs.

Cette transparence va révolutionner certains marchés particulièrement opaques. Actuellement, il est difficile de savoir quel est le prix réel de certains instruments peu traités sur les marchés (comme les obligations convertibles). On regrettera néanmoins que le régulateur confie cette tâche à des organismes certifiés (qui font payer leur service pour la publication) et qui limiteront l’accès à la donnée (car il faudra se connecter techniquement à un grand nombre de systèmes puisque chaque banque peut choisir son APA).

Pre-trade transparency

Les plus perplexes pourront penser que “connaître le prix c’est très bien, mais quand il est publié, il est déjà trop tard”. En effet. C’est pour cela que MiFiD II ajoute la pré-trade transparency, afin de publier non seulement les prix traités, mais aussi les prix fournis. Pour cela, MiFiD II revoit la notion d’internalisateur systématique (SI). La définition est la suivante : “Un système de négociation bilatéral, matérialisé par l’intervention d’un prestataire de services d’investissement agissant lors de l’exécution des ordres de ses clients en se portant contrepartie en compte propre de façon organisée, fréquente et systématique”. Tout réside dans le “organisé, fréquent et systématique”. Afin d’éviter le côté subjectif de la définition, des seuils ont été mis en place pour délimiter les critères.

Pour les entreprises d’investissement répondant à la définition, elles seront soumises à l’obligation de transparence pré-trade. Concrètement, cela signifie qu’elles doivent publier des prix acheteurs et vendeurs en continu. Ce mécanisme doit permettre de fournir une idée du prix proposé par un internalisateur systématique de manière publique. De la même façon que la post-trade transparency, cela devrait aider un investisseur peu informé de juger la qualité d’un prix qui lui est fourni par comparaison. À toute règle, il y a des exceptions que l’on appelle des waiver et qui permettent de ne pas fournir de prix (de la même manière que des “délais” sont accordés pour la post-trade transparency). Ce sujet entre en vigueur à la fin du 1er semestre 2018. Les solutions techniques tardent à se profiler.

Trading algorithmique

Sur les deux précédents sujets, MiFiD semble tenir un cap précis et cohérent dans les objectifs et les solutions. Pour celui qui suit, c’est beaucoup plus discutable. En effet, en lisant les différentes RTS publiées, on comprend vite que les équipes des régulateurs ont travaillé en silo, ne cherchant pas toujours la cohérence globale. Ceci crée donc des RTS de qualités et de pertinences différentes. L’encadrement du trading algorithmique est un exemple. Les mesures sont diverses :

• Tenir une description des algorithmes et automates à disposition du régulateur,
• Mettre en place en interne un système de contrôle efficace : seuils et limites, plans de continuité, tests, organisation. Cette mesure reste à l’état de grands principes sans obligations précises. Il faudra être capable de prouver que les algorithmes sont testés. Comment ? Rien n’est dit. Les banques feraient donc leur propre inspection. En tant que MOA spécialisé dans ces sujets, il est difficile de fournir un plan de tests compréhensible et vérifiable par un intervenant extérieur,
• Synchroniser les machines hébergeant l’algo et les machines du marché sur lequel elles interviennent afin d’avoir des temps de décisions et d’exécutions comparables avec une précision à la 100 micro secondes pour le trading Haute Fréquence. Toute action sans décision humaine étant considérée comme HF. Techniquement, les data centers hébergeant les marchés et automates (au même endroit, en colocation) ont dû s’équiper pour fournir une horloge synchronisée par satellite. Les cartes réseaux des machines doivent ensuite être capables de supporter cette synchronisation (protocole PTP par exemple),
• Déclarer au marché quel automate a pris la décision d’exécution ou d’investissement via un short code déclaré à l’avance.

Ces demandes sont un début, mais ne limiteront clairement pas le trading algorithmique. Elles permettront aux autorités de mieux auditer les banques, notamment en cas de soucis comme un flash crash. Il se dit que MiFiD III s’attaquera plus en profondeur aux dérives du trading algorithmique. Vaste sujet pour un prochain article.

Ce post aurait pu aborder également la best execution, qui ne va clairement pas assez loin dans la protection des clients. Les 4 sujets précédents sont les plus emblématiques de la directive et les plus proches du Front Office. Bien sûr, MiFiD ne s’arrête pas là. L’émulation, voire l’hystérie autour de ce sujet, s’explique par le timing et les dépendances marchés mais également car elles mettent en exergue le manque d’investissement chronique dans l’automatisation des process. MiFiD, en demandant une cohérence et un audit de la vie d’un deal, fait ressortir les problèmes de cohérence des systèmes. Par conséquent, elle oblige à un investissement IT important sur une courte période, dans un environnement réglementaire contraint, ce qui ne facilite pas les bonnes décisions.

Cette transparence oblige à ce que les processus métiers soient suffisamment automatisés. On ne peut plus (majoritairement) reposer sur l’oral et la mémoire humaine.

Dorénavant, je répondrai d’autant plus fort en citant MiFiD aux questions suivantes :

“ Un OMS, pas besoin ! Les traders et les sales peuvent se parler !”

Mauvaise idée !

 

“Rendre deux système inter-opérables ? Pas besoin, les sales face aux clients et les traders face au marché !”

Mauvaise idée !

 

“Se connecter pour récupérer les trades automatiquement depuis des systèmes externes ? Pas besoin, un stagiaire peut faire de la saisie !”

Mauvaise idée !

Bonne année 2018 !