BCBS 239, beaucoup de retard, la faute du « data lineage » ?



La crise de 2008

_______________________________________________________



La crise financière dite des « Subprimes » a débuté courant 2008. Elle a laissé place à celle des « Dettes Souveraines ». Cette crise a mis à mal les économies développées du monde entier. Certaines ont mis plus de 10 ans à s’en remettre.

Au-delà des causes racine de cet épisode, cette crise a mis en avant des difficultés importantes pour les banques à piloter les risques en s’appuyant sur un reporting pertinent et fiable. Les systèmes d’information et les architectures de données étaient alors peu homogènes, et surtout mal maîtrisés, ce qui rendaient complexes la capacité à consolider les risques par axes d’analyse pertinents, dans des délais appropriés.

De là est né « BCBS239 » - Basel Commitee for Banking Supervision

La naissance de BCBS239

______________________________________________
BCBS 239, c’est la Norme N° 239 du Comité de Bâle sur le contrôle bancaire, en somme la déclinaison IT d’un ensemble de normes prudentielles visant à éloigner le spectre d’une nouvelle crise du type de celle de 2008 !

BCBS 239 énonce les « principes pour une agrégation efficace des données de risque, et un reporting des risques ».

L'objectif global de la norme est de renforcer les capacités d'agrégation des données de risques des banques et les pratiques internes de reporting des risques, améliorant ainsi les processus de gestion des risques et de prise de décision dans les banques.

« La bonne information doit être à disposition pour les bonnes personnes et au bon moment ».

Les principes visent à présenter des données de risque exactes aux décideurs pour qu'ils prennent des décisions opportunes et éclairées. Simple !

Ces informations doivent également permettre au régulateur d’évaluer avec précision les risques d'une banque.

C’est une norme qui s’applique aux Global Systemically Important Banks (G-SIBs), i.e. les 30 plus grandes banques du monde, ce depuis… 2016.

Les Domestic Systemically Important Bank (D-SIBs) devaient prendre la suite, à horizon 2019.

Les points techniques structurants

______________________________________________







Les principes exigent de bien comprendre les flux de données, leurs sources, de pouvoir en valider l’exactitude, la fraicheur pour garantir la qualité du reporting de risque.

Dans ces 14 principes, trois d’entre eux retiennent notre attention.

Principe 2 : Infrastructure Informatique & Architecture de données

« Les Systèmes Informatiques devraient être conçus, déployés et maintenus pour permettre pleinement l'agrégation et le reporting des risques, en situation normale et en période de crise ».

Principe 3 : Exactitude et Intégrité

« Les données devraient être exactes et fiables. L'agrégation des données devrait largement reposer sur des processus automatisés pour réduire la probabilité d'erreurs. »

Principe 5 : Délais de production de l'information

« Les données risques doivent être les plus à jour, exhaustives, fiables et produites dans un délai qui tienne compte de la nature du risque (liquidité, grands risques) et de la situation (normale/crise). »

Ces trois principes sont les plus « techniques » du texte.

Et ils sont tous trois en lien avec le concept de « Data Lineage », c’est-à-dire la capacité de « tracer » l’information de façon exhaustive dans le système d’information, des sources opérationnelles jusqu’à la couche de data visualisation.

Un échec relatif

______________________________________________

Force est de constater que les choses n’avancent pas nécessairement au rythme attendu.

Ainsi un rapport du Comité de Bâle 2020 indique que malgré des progrès certains, les banques ne parviennent pas toujours à mettre en œuvre les 14 principes de BCBS 239. 

Et globalement, c’est bien ce sujet du « data lineage », donc du tracking de la donnée à travers les systèmes qui est bien souvent à la source de ces difficultés.

Pourquoi :

Les "legacy systems" embarquent de (trop) nombreuses technologies depuis trop longtemps :

  • Pour stocker l'information (diverses bases de données, "on prem'",  Cloud),
  • Pour transporter l’information (ELT/ETL, code procédural),
  • Pour l’exposer (BI statique, outils de data visualisation, de data exploration, …).

Les Systèmes d’Information deviennent d’une complexité insondable.

Les effets sur la mise œuvre de points structurants du texte sont nombreux ;

  • Difficultés à "garantir un dispositif solide sur les données de risque" (Art.1 :  Gouvernance)
  • Difficultés à "garantir des données exactes et fiables sur les risques" (Art 3 : Exactitude et Intégrité),
  • Difficultés "Pouvoir rapidement produire, agréger et mettre à jour" ces données (Art 5 : Actualité).

Quelques pistes

______________________________________________
  • Il conviendra donc de mettre en œuvre un data lineage technique, non déclaratif autour des technologies de stockage, de processing, de scheduling, et de data visualisation du Système d’Information. Ces stacks techniques devront être analysés conjointement pour apporter une large palette d’axes d’analyse : source et devenir de l’information, fraicheur de la mise en œuvre des chaînes d’alimentation, détails des calculs dans la couche de data visualisation. La technique par « parsing » de l’ensemble de ces stacks techniques est incontestablement la plus à même d’apporter les réponses attendues.
  • Ce data lineage devra être rejoué en continue pour qu’il soit le reflet strict du Système d’Information.
  • Pour une compréhension partagée (métier, IT, régulateur) des arcanes de ces rapport de risque et de leurs alimentations, il faudra que les termes « métier » puisse être propagés de bout en bout dans les chaines d’alimentation. Ainsi, tous, chacun, pourra se figurer que la donnée investiguée a une source fiable et documentée.
  • Ces flux doivent pouvoir être scorés sur la base de critères objectifs, avec des warnings en cas de non complétudes : chaînes d’alimentation présentant des ruptures, scheduling imparfaits ou trop long, dashboards de risque présentant des erreurs dans les formules qui prévalent aux calculs des indicateurs de risque.

Tous les processus déclaratifs sont à proscrire. Les équipes sont sur-sollicitées, et elles sont dans l’incapacité de faire vivre ce texte précisément dans le temps. L’automaticité doit être la règle. Une règle d’or.

Conclusion

______________________________________________

BCBS239 est à la fois un défi pour les entreprises et une chance. Un défi, car la mise en œuvre de l’ensemble des points de ce texte demande des investissements importants. Et pas un investissement ponctuel.

Nous pensons que l’automatisation de tous les processus, leur capacité à « vivre » en parallèle du système analysé est la condition sine qua non pour que BCBS 239 soit un succès.

L’intérêt est que BCBS 239 peut bénéficier à l'ensemble de l'entreprise en renforçant l'importance de la qualité des données et de leur gouvernance. Cela peut améliorer les décisions, quelles qu’elles soient, et réduire leur délai de mise en œuvre.



www.ellipsys-bi.com

Commentaires

Posts les plus consultés de ce blog

La Data Observabilité, Buzzword ou nécessité ?

Migrer de SAP BO vers Power BI, Automatiquement, Au forfait !

BCBS 239 : L'enjeu de la fréquence et de l'exactitude du reporting de risque