Quelle solution de reporting pour EMIR ?

À l’initiative du G20, la nouvelle réglementation européenne des dérivés OTC, EMIR, a franchi le 12 février dernier un cap important avec l’entrée en vigueur de l’obligation de reporter des transactions financières.

En effet, il s’agit là d’un jalon majeur de la réglementation européenne qui, comme son équivalent américain, le Dodd Frank Act (DFA) déjà en vigueur depuis quelques mois, oblige les contreparties de contrats dérivés à déclarer leurs transactions à un référentiel central.

Certains établissements financiers se sont posé la question de la nécessité de lancer un projet en interne visant à la création d’une plateforme de reporting dédiée à EMIR ou de sous-traiter ces déclarations par le biais d’une solution externe pouvant traiter la globalité de leur périmètre déclaratif de manière transparente pour eux.

Quelle démarche permet de rationaliser la production de ces déclarations réglementaires ? Si elles sont réalisées de manière dispersée (par classe d’asset) et non consolidée (par outil front- ou back-office), quel service industrialisé, global et sécurisé peut-on imaginer pour couvrir ces besoins avec le minimum d’adhérence avec des systèmes d’information toujours en surcharge ?

À ce stade, il semble difficile d’évaluer de façon précise le nombre de firmes ayant répondu à ces nouvelles exigences, même si le nombre d’enregistrements constaté de la part des entités semble bien inférieur à celui escompté.

Des exigences réglementaires quantitatives et qualitatives

Le traitement des extractions de données dans un contexte réglementaire de plus en plus pressant dans ses exigences quantitatives et qualitatives est un défi majeur pour les opérateurs financiers, tant sur le plan opérationnel que sur le plan technique. Les réponses apportées à ces exigences diffèrent selon la taille des établissements assujettis et selon la complexité des instruments financiers qui y sont traités. La variété de ces réponses s’exprime en termes de savoir-faire spécifiques et de moyens techniques devant assurer le bon déroulement du cycle de vie d’une opération.

Par cycle de vie de vie d’une opération, nous entendons :

• l’évaluation de sa valeur et de ses risques ;
• la confirmation de son exécution et sa comptabilisation ;
• le traitement des différents événements pouvant modifier ses caractéristiques ;
• la réalisation de contrôles internes et externes associés à sa gestion.

Ces différentes tâches sont primordiales puisqu'elles doivent aboutir à la réalisation matérielle d’un gain. Elles peuvent néanmoins faire l’objet de nombreux imprévus. Afin de réduire certains de ces risques structurels et opérationnels, les législateurs demandent dans le cadre des réglementations Dodd-Frank et EMIR que ces opérations soient déclarées dès leur création auprès de juridictions « certificatrices », afin qu’elles puissent être rapprochées et contrôlées.

Des difficultés opérationnelles le jour J

En Europe, l’Esma, l’autorité des marchés financiers, a approuvé quatre sociétés comme référentiels centraux (GTR) :

• DTCC Derivatives Repository Ltd ou DDRL, basé à Londres et aux Pays-Bas ;
• Regis-TR (détenu par Clearstream et Iberclear) ;
• UnaVista (lancé par le LSE) ;
• ou encore le registre polonais, KDPW.

DTCC apparaît comme leader, car très majoritairement sélectionné par les plus grands intervenants des marchés des dérivés OTC, appuyé par sa présence historique dans ces domaines, notamment sur des activités de clearing. Après un démarrage mitigé notamment, le jour J, c’est-à-dire 12 février, du fait d’incidents opérationnels entravant l’acquittement de la bonne transmission des reporting soumis par les entités émettrices, DTCC est parvenu à intégrer une volumétrie de transactions historique liée entre autres au reporting des backloadings des opérations déjà en vie au 16 août 2013.

De plus, certains témoignages des corporate « retardataires » dans le processus d’enregistrement auprès du référentiel central DTCC, évoquent des difficultés à finaliser leur action la première semaine qui a suivi la date effective de l’obligation. Certains experts anglo-saxons ayant attentivement observé le déroulement des premières journées de reporting parlent quant à eux de manque de communication de la part de DTCC. Il a clairement été noté un manque de fluidité dans l’acquittement des données transmises par les entités, et DTCC est apparu, pour certains, lors de la phase de démarrage comme en quelque sorte victime de son succès.

Des traitements complexes

Ces déclarations sont nouvelles pour beaucoup d’établissements et ne reposent sur rien de préexistant. Leur caractère « temps réel » et les nouvelles informations demandées (Universal Swap Identifier, Universal Trade Identifier, Legal Entity Identifier, etc.) posent des problèmes de collecte et de consolidation. Ces traitements d’extraction et de mise en forme doivent être considérés comme des traitements complexes, car la déclaration d’une opération ne peut être considérée comme complète qu’après plusieurs envois.

Le LEI a été défini via la norme de codification ISO 17 422 qui permet d’établir sur 20 caractères alphanumériques un code auquel sont rattachées des données additionnelles publiques (nom, adresse, statut de l’identifiant…) et des données privées (formes juridiques, entités « parents »). À l’initiative du FSB, le LEI vise à répondre au besoin d’identifier de façon univoque les entités juridiques (autres que des personnes physiques) impliquées dans les transactions financières. L’obtention du LEI nécessite un enregistrement auprès de l’INSEE (désigné comme Local Operating Unit « LOU » français).

Or, d’après une étude réalisée par Risk Magazine auprès de 6 LOU européens, le nombre de pre-LEI réclamés par les contreparties s’élevait au 12 février à environ 75 200, alors que les estimations réalisées évaluaient le nombre total de LEI nécessaires dans une fourchette située entre 105 000 et 165 000, en incluant notamment les plus petites entités. Ce constat laisse supposer que bon nombre d’entités directement concernées par cette obligation ne sont pas en mesure, ou du moins, prêtes à assurer le reporting de leurs opérations. En effet, si l’ensemble des grands acteurs de la finance de marché, comme les BFI européennes, ont déployé les moyens nécessaires à leur mise en conformité et ce, depuis plusieurs années déjà, il n’en est pas de même pour tous les intervenants. Les corporate notamment ne sont pas, à la base, systématiquement dotés de l’infrastructure nécessaire à la génération de reporting de cette importance et de cette complexité.

Système interne ou délégation

De récentes enquêtes/sondages prouvent d’ailleurs que les obligations imposées par EMIR demeurent encore assez méconnues de certaines entités entrant pourtant dans la catégorie des NFC [1] . En outre, la possibilité de déléguer le reporting à une entité tierce, telle que prévue par EMIR n’a pas été suffisamment explorée par les acteurs étant pourtant le moins à même de répondre à ces nouvelles exigences. D’autres acteurs ne souhaitent pas déléguer le reporting de leurs transactions arguant qu’in fine, la responsabilité de leur firme est engagée, et qu’il demeure donc plus prudent de conserver ce processus considéré comme sensible.

Des stratégies différentes sont possibles pour les établissements lorsqu’ils veulent procéder aux extractions. Elles peuvent être réalisées soit :

• depuis un système de front office, c’est-à-dire au moment du booking de l’opération ;
• ou depuis un système de back-office, c’est-à-dire au moment de la certification interne de l’opération.

Cela revient pour l’établissement déclarant à développer un système interne du type « Gateway » assurant la sélection des opérations éligibles, les transformations des données au format attendu et le suivi des envois à la juridiction en adéquation avec le périmètre fonctionnel traité.

L’alternative serait un système externe du type « plateforme de traitement » assurant :

• la sélection des opérations éligibles, les rapprochements et les réconciliations nécessaires ;
• les transformations des données au format attendu et la gestion des taxonomies ;
• et le suivi des envois à la juridiction en adéquation avec le périmètre fonctionnel traité et la gestion des avenants.

Cependant, devant l’importance de l’investissement nécessaire à la mise en place d’une architecture IT et opérationnelle en mesure de produire de tels reporting, de nombreuses contreparties cherchent désormais, dans la hâte, à déléguer le reporting, aux BFI par exemple. Des institutions telles que BNP Paribas, Lloyds Banking group, HSBC, CitiBank, UBS, Nomura, Crédit Suisse ou encore Barclays Bank proposent le service de « reporting on behalf » à leurs clients. La délégation de reporting s’opère dans un cadre légal défini avec l’aide de l’ISDA, qui est d’ailleurs à l’origine d’un modèle de contrat standard. Ainsi, l’entité en charge du reporting pour le compte d’un tiers se substitue à son client en assurant la transmission du reporting de transactions aux référentiels centraux.

Pour de nombreux acteurs de taille plus réduite, certains asset managers ou corporates, qui ont recours à ces produits pour des besoins de faibles volumétries, ces reportings apparaissent complexes. Ils requièrent notamment des mécanismes d’automatisation. C’est aussi le constat d’un nombre important de firmes de l’industrie des Commodities (pétrole, énergie…). Ces derniers ont donc tendance à se trouver vers des solutions externes par le biais de la délégation de reporting.

La délégation de reporting semble une alternative confortable pour les firmes ne souhaitant pas investir dans une infrastructure et donc subir des coûts fixes conséquents.

 

---