Quel état des lieux faites-vous dans vos départements concernant les demandes du superviseur en termes de reporting et de données ?
Richard Vinadier (R. V.) : Concernant les demandes de la BCE en matière de reporting, il est clair que l’évolution récente, en résumé depuis la mise en œuvre du MSU en 2014, se caractérise par beaucoup plus de données, des délais plus courts et des fréquences accrues. Il nous faut par ailleurs non seulement répondre aux demandes de reportings qui reviennent régulièrement comme Corep, Finrep ou les reportings de liquidités, mais aussi à des demandes ponctuelles. Nous avons même expérimenté des « deep dives » (voir infra) et des « fire drills », c’est-à-dire la remise de reportings dans des délais très courts sur des données ne correspondant pas nécessairement à des fins de mois ou de trimestre… Autre tendance : les nouveaux reportings tels qu’Anacredit, Anatitres, les Liability Data Reports pour le SRB, qui sont très granulaires et descendent jusqu’au niveau du contrat.
Anne Sabot (A. S.) : Dans le cadre de la Thematic Review de 2016, l’une des priorités de la BCE a été d’évaluer la qualité des données des banques, conformément à la réglementation
R. V. : Par exemple, à partir d’une cellule du Finrep qui portait sur les NPL SME (prêts non performants aux petites et moyennes entreprises), nous avons dû expliquer tout le chemin de la donnée, c'est-à-dire comment passer de cette unique case d’un état du bilan Finrep aux contrats qui la constituent. Or, dans un groupe comme BPCE, il faut prendre en compte l’existence de plusieurs systèmes informatiques différents, avec parfois des ruptures de charge, et des données qui ne sont pas toujours disponibles nativement au niveau central. Pour une entité plus centralisée comme Natixis, l’information est généralement plus facilement accessible, même si ce type d'exercice ne s'y effectue pas non plus de façon très simple. La clef est de pouvoir disposer nativement de données à la maille contrat qui soient rapprochées comptablement, ce qui n’est pas toujours évident, dans la mesure où, de manière historique, les systèmes de consolidation centraux ont été construits pour véhiculer et traiter des données de synthèse.
Comment vous êtes-vous organisé pour répondre à ces évolutions ?
R. V. : Il a d’abord fallu prendre conscience de l’absolue nécessité d’évoluer en ce domaine et d’investir dans le développement de nos systèmes. À cet égard, l’AQR lancé en 2013 a constitué un tournant. Même s’il y a eu des prémices, l'AQR a été une des premières occasions où nous avons été confrontés à une demande portant sur un volume considérable d’informations, contrat par contrat, à fournir dans des délais très courts et nous avons parfois pu constater les limites de nos systèmes. Cet exercice a aussi conduit à rappeler les principes posés par BCBS239, qui a constitué la trame de fond de cet exercice d’AQR par le superviseur. L’industrie n’avait peut-être pas accordé autant d’importance qu’elle aurait dû à cette norme, parce qu’il s'agissait d’une réglementation basée sur des principes et non des règles (comme ce qui s'applique par exemple pour un calcul de RWA).
A. S. : Toutes les banques ont lancé post AQR, avec un délai plus ou moins long, des projets dits « BCBS239 » autour de la gouvernance et de la qualité des données, des pratiques de reportings et de l’infrastructure informatique associée. Les nouvelles technologies Big Data (comme Hadoop) nous ont aidés à répondre à ces enjeux, car elles permettent de brasser de très grandes masses de données, de les stocker, de croiser des sources d’information plus facilement ; elles nous ont affranchis, dans une certaine mesure, des limites de volumétrie que nous connaissions auparavant. Elles sont cependant encore relativement récentes et viennent en complément des systèmes d’information existants.
R. V. : Nous avons en effet beaucoup investi sur de nouveaux outils, parce qu’avec de tels volumes traités, il faut automatiser le plus possible. Cela conduit aussi à se redemander qui doit faire quoi ? Cela a suscité beaucoup de questions d’organisation auxquelles les banques n’ont d’ailleurs pas toutes donné la même réponse.
En outre, le superviseur a tendance, et on peut le comprendre, à ne pas considérer les reportings par catégorie : peu lui importe, par exemple, que ce soit un service qui remette des reportings sur la liquidité et un autre sur les risques de crédit. Le superviseur a une approche globale et va chercher à réconcilier les données de chacun de ces reportings. Nous devons en tirer les conséquences, pour établir un socle commun de données, quelle que soit l'utilisation qui en est ensuite faite…
A. S. : Nous nous sommes rendu compte que nos process étaient plutôt construits en silo, c’est-à-dire par expertise fonctionnelle, chacun ayant son système d’information propre et étant géré par des équipes différentes. Cela correspond aussi aux différentes étapes de déploiement de la réglementation : la solvabilité et les calculs de RWA, la liquidité, les travaux autour du risque de crédit et les prêts non performants, etc. Tous ces éléments contribuant in fine à l’établissement des différents reportings envoyés au superviseur, sans oublier la comptabilité qui reste le socle de référence. Il nous a fallu intégrer une vision plus cohérente et plus transversale et nous organiser différemment : par exemple, pour mutualiser autant que faire se peut les sources des données, consommées ensuite par les différents moteurs de calcul et pour les différents besoins de pilotage.
Pour répondre à ces évolutions, on a posé un certain nombre de principes qui ont été ensuite déclinés de façon opérationnelle dans un schéma directeur de l’ensemble du système d’information : alimentation et sources de données communes, partage des référentiels, gestion des corrections, traçabilité et piste d’audit… La façon dont le système d’information a été reconfiguré pour mettre en place ce schéma directeur d’ensemble constitue un chantier très important et qui continue d'évoluer.
Enfin, ce qui est étonnant, comme l’indiquait Richard, c’est que le superviseur pousse pour cette vision globale et intégrée, de la finance et des risques, à travers les reportings, alors même qu'il demande par ailleurs explicitement à ces départements de travailler de façon indépendante. La gestion de ces questions d’indépendance et de transversalité est assez compliquée.
Que pensez-vous du projet sur les données granulaires mis en avant par la division statistique de la BCE dont Anacredit est une des premières étapes ?
A. S. : Le projet de base de données granulaires présenté par la BCE est intéressant mais les banques ont déjà engagé beaucoup d’investissement pour rénover leur dispositif post AQR en fonction des principes BCBS239. Cela va reposer des questions fortes sur la capacité à réinvestir à nouveau, à remodifier un certain nombre d'éléments que nous n’avons même pas encore fini de mettre en œuvre, et globalement sur le ROI des montants investis ou à investir.
R. V. : Dans un monde idéal, on pourrait penser que les superviseurs disposant de données de qualité au niveau le plus fin, il ne serait plus nécessaire de remettre de multiples reportings de synthèse puisqu’ils seraient en mesure de réaliser leurs analyses par eux-mêmes. Une de mes craintes est toutefois qu'en dépit des intentions réelles de simplification, un tel schéma nécessite que nous continuions à produire les mêmes agrégats ne serait-ce que pour comparer les résultats obtenus. Cela serait d’ailleurs normal pour vérifier que ces derniers sont cohérents, mais cela ne va pas réduire notre charge de travail.
A. S. : La charge ne va diminuer à court terme en tout cas, parce que fournir des données plus granulaires peut aussi conduire à des besoins de contrôles supplémentaires. Et nous ne voyons pas de projet de décommissionnement de reporting…
R. V. : On a effectivement rarement vu un reporting décommissionné, c’est-à-dire qui ne soit plus demandé.
A. S. : De toute façon, le pilotage de la banque se fait à travers un certain nombre de métriques, dont celles que nous envoyons au régulateur. Ce n'est pas parce que nous enverrons des données plus granulaires que nous arrêterons de produire ces métriques.
Comment s’assurer de la qualité des données collectées ?
R. V. : Dans une banque, la qualité de la donnée part du front pour une banque d'investissement ou des agences pour une banque de détail. Il suffit qu'une donnée utilisée pour qualifier le crédit soit mal saisie, pour avoir des reportings de moins bonne qualité. Nous nous sommes penchés sur cet enjeu dans le cadre de BCBS239, mais, pour prendre un exemple, le cœur de métier des équipes en agence n’est peut-être pas d'alimenter les reportings à la BCE. C'est une difficulté, mais qui peut aussi se gérer par des formations et de la pédagogie. En outre, il existe beaucoup d'autres sources de mauvaise qualité : comme déjà évoqué, souvent, les systèmes d'information ne sont pas intégrés de bout en bout, ce qui nous oblige à travailler avec des tables de passage ou de transcodification ; une erreur dans ces dernières se répercutera ensuite dans toute la chaîne de traitement.
A. S. : Un des enjeux clé pour s'assurer de la qualité des données est d'arriver à identifier les données les plus importantes… mais dans la banque, ce ne sont pas les mêmes pour tout le monde. Pour les équipes commerciales, les coordonnées des clients (numéro de téléphone ou autre…) constituent souvent la donnée plus importante, plus importante probablement que le fait de bien renseigner d’autres informations relatives à ce client, comme son LEI
N'existe-t-il pas aussi certains problèmes d'homogénéïsation des définitions pour les données ?
R. V. : En effet, la question des référentiels est cruciale. À propos des définitions, la pierre se situe parfois très en amont, par exemple au niveau des régulateurs, avec des demandes d’informations portant sur des données de nature très proches avec des définitions différentes.
A. S. : Les banques seraient preneuses d'une simplification et d'une uniformisation de la définition des données, mais en s'assurant que cela couvre un socle suffisamment large. Natixis par exemple a des activités en Asie, en Europe et aux États-Unis, et nous sommes soumis aux différents régulateurs qui manient les mêmes concepts mais qui peuvent recouvrir des réalités parfois différentes en termes de données.
Le projet Bird n'est-il pas déjà une solution ?
A. S. : Bird est en effet un dictionnaire de données standardisées, mais qui s'applique uniquement dans le contexte européen.
Comment articuler les demandes du normalisateur prudentiel et du normalisateur comptable ?
R. V. : Les états Finrep ont été adaptés à IFRS 9 mais des problèmes subsistent en effet sur certaines définitions : par exemple les définitions prudentielle et comptable du trading book et du banking book ne sont pas les mêmes. De même les règles de compensation sont différentes, ce qui nous oblige à des retraitements sur la base des données comptables. Nous avons également un sujet en matière de valorisations où la prudent valuation se rajoute aux valorisations comptables. Le superviseur demande, à juste raison, qu'il y ait un rapprochement systématique avec la comptabilité… mais souhaite s’en démarquer, ou en tout cas, la compléter s’il considère qu’elle ne répond pas à ses exigences. Se profile en ce domaine, un important chantier sur les NPE/NPL et leur couverture par les provisions. Il faut déjà manier des notions d’encours douteux, dépréciés, en défaut, de NPL, de forbearance, ce qui peut s'avérer compliqué car les concepts sont proches mais pas identiques.
Une démarche pragmatique peut consister à aligner autant que possibles ces différentes notions, mais ce n’est pas toujours possible et cela peut changer avec l’introduction de nouvelles réglementations. À titre d’exemple, l’introduction de notions de seuil en matière d’impayés pour définir le NPL risque, au-delà des coûts de développement informatique, de ne plus permettre d’aligner certaines définitions.
Quels sont vos souhaits vis-à-vis du superviseur en termes de reporting ?
R. V. : Une pause… afin d’exploiter au mieux les milliers de données produites, de nous permettre d’améliorer nos systèmes et de renforcer encore nos dispositifs de contrôles.
A. S. : Les autorités européennes ont mis en place un outillage pour évaluer la qualité de données dans nos reportings, mais avons-nous eu tous les feedbacks sur ces éléments ? Les banques ont fait beaucoup d'efforts pour améliorer la transparence et la qualité de leurs données mais le message des régulateurs et superviseurs, même s’ils reconnaissent les efforts réalisés, est globalement négatif et insiste sur un niveau de conformité toujours non satisfaisant par rapport aux principes BCBS 239… Il serait évidemment souhaitable que tous nos process de reportings soient complètement automatiques, que nous éradiquions les spreadsheets excel, que nous ayons toujours plus de points de contrôle, etc. Nous essayons de tendre vers cela, mais nous le voyons plutôt comme un dispositif d’amélioration continue. Avec toujours plus de demandes de données et de reportings, cela fait beaucoup de sujets à traiter en même temps car, à peine a-t-on fini de traiter un sujet, qu'il y en surgit un nouveau, qui se traduit presque inévitablement par de nouvelles demandes de données et de reporting. D’ailleurs, le nombre de points de données que nous déclarons au régulateur est énorme ; post AQR, sur la seule partie réglementaire, il était déjà de l'ordre de 700 000… et il a fortement augmenté depuis !
