Compte-rendu: France & Austria : Exploring different paths to maximized value creation in regulatory reporting Atelier EIFR – 20 septembre 2016

Maciej Piechocki

BearingPoint

 

Comment disposer d’un système de reporting à la fois utile et « économique » ?  

 

On observe 6 grandes tendances dans l’évolution de la réglementation bancaire :

1. Au niveau mondial, un flot sans fin de nouvelles normes, guidelines, bonnes pratiques et recommandations
2.  Au niveau européen, un recueil réglementaire, le Single Rulebook, toujours plus épais : Règlements/Directives (CRR/CRD IV, BRRD, …), standards techniques (RTS, ITS), Guidelines, Q&A, …
3. A des formats (templates) de reporting très imparfaits (données agrégées et de nature différente, format figé, analyse limitée, validation à la sortie), une substitution de « cubes de données » (data cubes) plus sophistiqués (données plus granulaires et cohérentes, format évolutif, usage multiple de mêmes informations, analyse sans limite, validation des données à l’entrée) ; c’est sur ce schéma que sont bâtis les initiatives européennes AnaCredit, ERF (European Reporting Framework) ou BIRD (Banks’ Integrated Reporting Dictionnary)
4. Une substitution d’obligations de reporting basées sur une réglementation (rule-based) par des obligations ad hoc
5. L’importance croissante de l’agrégation des données de risque et des reportings, demandant aux banques plus d’agilité dans leur système d’information et la révision de la gestion en silos de risques ; c’est ainsi que les « Principes aux fins de l’agrégation des données sur les risques et de la notification des risques » (BCBS 239) ont été posés par le Groupe de travail du Comité de Bâle sur la surveillance bancaire des établissements d’importance systémique pour aboutir à un renforcement de la capacité des banques à agréger leurs données de risque
6. Une réglementation qui contraint de façon croissante les business models des banques.

 

Il faut donc repenser la façon de concevoirles reportings réglementaires. Les banques doivent maintenant pratiquer une véritable gestion réglementaire active (regulatory management) en optimisant leur production de reportings. Les banques centrales ont également un rôle essentiel à jouer dans la promotion de nouveaux modèles de « coopétition « (collaboration-compétition) dans les services financiers par la mise en place de modèles de reporting de données granulaires, en lien étroit avec l’industrie bancaire.

 

Johannes Turner

Banque Nationale d’Autriche

 

La communauté bancaire autrichienne (Banque centrale et établissements bancaires) a initié il y a 5-6 ans une approche véritablement nouvelle.

 

A l’origine du projet se trouve le besoin de revoir le modèle de reporting face à une demande du régulateur plus importante, plus précise et donc plus complexe, et le constat d’une sous-optimisation des process (certaines données similaires de crédit sont par exemple collectées plus de 15 fois). Comment changer l’architecture du système ? En mutualisant l’information pour la rendre plus homogène, plus qualitative et donc plus sûre. Jusqu’alors, chaque institution bancaire avait sa propre définition et donc son propre reporting ; les reportings internes et externes ne correspondaient pas forcement.

 

Le besoin de données de qualité, homogènes et avec un coût abordable a conduit la Banque centrale autrichienne à repenser son modèle de reporting. C’est la construction de la plateforme AuRep commune à l’ensemble des banques autrichiennes, avec un système d’information construit en cubes, dans lesquels les données sont agrégées et analysées pour répondre à l’ensemble des demandes de reportings des superviseurs. Cela a nécessité de s’accorder sur des définitions communes avant même de parler de convergence des systèmes entre eux. Le dispositif, qui regroupait à l’origine 7 banques, couvre aujourd’hui plus 90% des banques autrichiennes.

 

Les avantages de la démarche sont multiples : 1) obtenir des données intégrées sur l’ensemble de l’industrie dans un temps considérablement réduit ; 2) permettre une centralisation des données quelque soit leur nature, qui facilite la vérification et les procédures de correction et aboutisse à une qualité de la donnée nettement meilleure ; 3) permettre de répondre à une granularité plus grande sans être obligé de redemander des reportings supplémentaires aux banques ; 4) constituer une seule interface pour la Banque centrale.

 

Le projet comportait tout de même différents risques, notamment un coût initial important, et la difficulté de définir un langage et des définitions communs aux établissements et à la banque centrale.

Un exemple concret d’utilisation est apparu avec la réglementation AnaCredit : les données de crédit sont collectées une seule fois et redistribuées via AuRep dans plusieurs reportings. Les définitions ont été harmonisées, et la granularité modelée selon les demandes. L’exercice AnaCredit n’est ainsi pas apparu en Autriche, à la différence de la plupart des autres pays européens, comme une difficulté sectorielle majeure : plus de 70 % de l’information demandée se trouvait déjà en effet dans le cube de crédit (loan cube).

On a abouti en Autriche à un système sans redondance : la cohérence et la possibilité de délivrer la même information autant de fois que nécessaire ont été les facteurs de réussite du projet, et ont donc conduit à moins de demandes de la part de la banque centrale. Il s’agit par ailleurs d’un projet commun entre l’industrie bancaire et la banque centrale, impliquant toute les parties pour créer un système plus efficace et moins coûteux pour la production des reportings réglementaires.

Cela a imposé aux banques de revoir leur organisation et leur process de reporting, sur la base de  spécifications d’implémentation imposées par l’organisme central (AuRep) fort d’une cinquantaine de personnes. Le coût explicite de cette infrastructure centrale apparaît à l’arrivée pleinement justifié par une diminution des coûts dans chaque établissement.

Il est encore difficile aujourd’hui de tirer des conclusions définitives, et de juger si toutes les attentes sont remplies. Toutefois, l’expérience AnaCredit et les premiers livrables montre clairement que c’est la route à suivre. Pour garantir ce qui est tout de même déjà considéré localement comme un succès, il a fallu la conjonction de plusieurs conditions : le support du Top management, des données à transférer standardisées, des définitions claires et partagés, une communication transparente, un projet en liaison avec les banques d’un bout à l’autre, et une transition bien planifiée avec une phase de test parallèle. Cela demande aussi bien pour la Banque Nationale d’Autriche que pour les banques impliquées un profond changement de la façon de concevoir les reportings, et même la réglementation bancaire en général : une maturité et une innovation quant à la qualité des données se sont construites en avançant.

 

 

Jacques Fournier

Banque de France

 

Quand on parle de reporting, la première chose à faire est de partager les mêmes définitions entre données de type statistiques et de données de type prudentiel (la définition du crédit à l’habitat est par exemple différente selon les deux usages). 

 

La Banque de France a initié un projet de « lac de données » (data Lake) prévu pour aboutir à l’horizon 2018. Il s’agit de pouvoir gérer de façon souple un ensemble croissant de données de plus en plus précises, que la donnée soit brute ou fine. Le statu quo de gestion des données conduirait en effet à une impasse.

La Banque de France est responsable de toutes les phases de la gestion des données, c’est-à-dire : collecte, surveillance, ordonnancement et analyse. Elle utilise ces données pour produire un certain nombre de rapports comme la balance des paiements ou les prévisions économiques mensuelles, et produire des statistiques monétaires et financières. La Direction des Statistiques a donc dans la gestion des données une réelle expertise qu’il s’agit de mobiliser expertise pour constituer ce data lake.

Il existe déjà un portail unique d’entrée des données que ce soit pour celles nécessaires aux superviseurs ou celles à visée statistique. Ce portail accepte tout type de format. Il a été déjà expérimenté pour le MMSR (Money Market Statistical Reporting) : pour la BCE, la Banque de France a développé une plateforme de collecte de l’ensemble des transactions journalières des plus grandes institutions de l’Eurozone ; fonctionnant depuis le 1er Avril 2016, elle couvre plus de 50.000 transactions par jour.

Une expertise importante également de la Direction des Statistiques de La Banque de France se situe dans le PS3 (Pooling and Sharing Statistical Series), autrement dit la capacité à mettre en commun et partager des séries statistiques. Plus de 400 millions de séries statistiques sont localisées dans une base de données unique et disponibles de façon instantanée. C’est la fin du travail en silo, avec l’idée que la donnée produite doit servir à un usage multiple.  

Mais la prochaine étape est le Data Lake. Les institutions financières (établissements de crédit, compagnies d’assurances, …) transmettront des données sur un portail unique. Ce portail délivrera les données vers les régulateurs, superviseurs et autres institutions européennes qui les demandent. Ce qui est en cours d’ajout, c’est une plateforme de concaténation de la donnée et une plateforme de qualité des données. Pour cette dernière, les données sont stockées d’une façon la plus flexible possible pour répondre à des demandes quel que soit l’organisme demandeur. Cela peut répondre aux demandes d’AnaCredit par exemple. Enfin une plateforme d’échange va être ouverte pour les chercheurs (bibliothèque ouverte de données). 

Une grande partie du data lake sera opérationnel dès 2017. Cela va bien sûr permettre d’améliorer la rapidité et la qualité des données produites.

 

Farid Djelid  / Matthieu  Le Guern	Société Générale

 

Le retour d’expérience d’un grand groupe bancaire sur les exigences de reporting.

 

Si la demande de régulation après la crise de 2008/2009 a été légitime pour restaurer la confiance dans le système bancaire, elle a conduit les banques à renforcer leurs équipes dédiées, investir dans leur outil informatique, et encourager la transformation en profondeur des départements Risques et Finance. Mais l’homogénéité visée par l’instauration du MSU reste difficile à atteindre en raison notamment :

• des exceptions nationales (140) qui rendent délicate aux superviseurs, investisseurs, actionnaires, … , la comparaison entre banques
• l’hétérogénéité des modèles de supervision et des reportings dans le monde, qui rend difficile pour les banques internationales la conformité à toutes les exigences
• l’hétérogénéité des règles comptables sous-jacentes qui complique l’objectif de convergence des superviseurs.

En toute hypothèse, le nouveau modèle de supervision de la Zone Euro apparaît tendanciellement de plus en plus intrusif.

 

L’année 2014 avait vu l’introduction de deux évolutions majeures supposées aller dans le sens d’une simplification de l’organisation de la supervision : l’implémentation des nouvelles règles prudentielles et de nouvelles exigences de reporting (au travers notamment d’aménagements aux reportings FINREP et COREP), et l’implantation d’un mécanisme de supervision unique dans l’Eurozone autour de la BCE. Le constat apparaît en fait  plutôt contrasté car :

• la montée en puissance de la BCE a alourdi considérablement le fardeau sur les banques 
• les reportings issus de la CRD IV n’ont en réalité constitué qu’une petite part des changements réglementaires en cours
• à peine mis en place, les nouvelles règles sont revues (Bâle IV, IFRS 9)
• au-delà de COREP et FINREP, de nouveaux reportings ont été demandés de façon récurrente sur une base quadrimestrielle par l’ECB ou le Comité de Bâle, avec en outre un enrichissement de ces demandes d’information.

 

De nombreux aspects de la mise en œuvre de la supervision réglementaire apparaissent critiquables sur le plan de :

• la coordination : des demandes des superviseurs grandissantes, mais mal coordonnées et conduisant à des requêtes différentes de plusieurs autorités sur les mêmes données
• la cohérence : des méthodologies parfois divergentes suivant le superviseur
• le foisonnement : une inflation de sujets traités qui rend leur traitement difficile tant pour les banques que pour les autorités de contrôle
• la stabilité : une instabilité de certaines normes, et leur interprétation divergente entre l’EBA et le Comité de Bâle par exemple
• le lien avec la comptabilité : des demandes du régulateur parfois en contradiction avec les procédures comptables en place.

 

La pression sur les banques est importante pour qu’elles se transforment à grande vitesse afin de se conformer aux demandes des superviseurs : elles doivent à la fois transformer leurs systèmes d’information, adapter les reportings en fonction du pays de localisation des filiales, faire évoluer en permanence leur organisation de suivi des risques, transmettre des données de plus en plus précises et en volume exponentiel, être capables d’agréger des données d’où qu’elles viennent et d’en garantir la qualité, et se conformer à des délais de production de plus en plus courts (30 jours pour COREP aujourd’hui).

 

Partant de ces constats, plusieurs pistes d’amélioration peuvent être envisagées :

• concernant le régulateur : donner une meilleure visibilité aux banques (feuille de route réglementaire à 3-5 ans), tenir compte des contraintes des banques en améliorant les deadlines de remise des reportings et stabiliser les normes et ratios, et éviter d’empiler les demandes de reportings sur le même sujet

• concernant les banques : apporter à la Direction une vue globale des impacts des sujets réglementaires, coordonner les équipes Risques et Finance sur la production de reporting pour une meilleure efficacité et un coût optimisé, renforcer la gouvernance de la qualité de la donnée à tous les niveaux ainsi que celle des indicateurs, standardiser les reportings et les définitions pour toutes les entités du groupe, et enfin améliorer l’agilité des systèmes d’information dédiés à la régulation pour produire des données au niveau le plus fin et au moment requis.