opinion > [BCBS 239], jouer la carte de l'automatisation ?

[opinion] > 

BCBS 239, jouer la carte de

                 l'automatisation ? 

Introduction  

Un rapport du comité de Bâle du mois d’avril 2020 indique que malgré des progrès certains, les banques ne parviennent pas toujours à mettre en œuvre les 14 principes de BCBS 239. 
C'est souvent très largement lié à la complexité des Systèmes d’Information en place qu'on appelle "legacy systems", 
 
Pourquoi  ? :
Les "legacy systems" embarquent de (trop) nombreuses technologies :
> Pour stocker l'information (diverses bases de données, "on prem'", Cloud),
> Pour transporter l’information (ELT/ETL, code de procédure), avec d'innombrables "black box",
> Pour l’exposer (BI statique, outils de dataviz, de data exploration,…).
 
Les impacts :
Comment dans ces conditions "garantir un dispositif solide sur les données de risque" (art.1 :  Gouvernance) ? : 
> "Garantir des Données exactes et fiables sur les risques" (art 3 : Exactitude et Intégrité),
> "Pouvoir rapidement produire, agréger et mettre à jour" ces données (art 5 : Actualité).

Eléments  de contexte  : 

La crise débutée en 2007, a mis en avant des difficultés importantes pour les banques à piloter les risques en s’appuyant sur des reporting pertinents et fiables. Des systèmes d’information et des architectures de données peu homogènes qui rendent complexe la capacité à consolider les risques par axes d’analyse pertinents, dans des délais appropriés.

Objectifs et enjeux de BCBS239 

Les objectifs  

1. Améliorer l’agrégation des données risques
2. Améliorer les pratiques de reporting

les enjeux 

1. Décliner le nouveau statut du Système d'Information (actif stratégique) dans l’organisation de la banque,
2. Mieux répondre aux contraintes réglementaires et renforcer le pilotage interne des risques,
3. Dépasser un fonctionnement en silo. Une approche collaborative, avec des processus, des outils et des référentiels partagés,
4. Un reporting repensé et simplifié 

Les 14 points de BCBS 239 

> on pourrait résumer ces 14 points en 3 phrases : 

1. Mes rapports de risques sont ils robustes et fiables ? 
2. Leurs alimentations sont elles robustes et fiables ? 
3. Suis-je capable d'en valider la qualité et de le partager à des tiers ? 

- 

Notre approche techniques 

> Nous pensons que l'automatisation de l'instrospection de ces "legacy systems" est la seule méthode sérieuse qui puisse permettre de répondre aux exigences techniques de BCBS 239 tant il existe de points de blocage - nous en avons listés quelques uns - ils sont innombrables et causent bien des soucis aux équipes IT :)  

Les technologies que nous analysons : 

L'essentiel des technologies "Analytics" présentes dans les "legacy systems" dans le monde bancaire : 

> Reporting  : SAP BO, Qlik, Power BI, SSRS, Tableau, Cognos...

 > Code de procédure :  SQL (dont vues SQL, et dynamic SQL), PL/SQL, T-SQL, Teradata Bteq, Cobol...

 > ETL/ELT : Genio, BODS, DataStage, SSIS, ODI, Stambia... 

> Schedulers :  DollarU, Autosys....

Nous analysons par ailleurs RiskAnalyst (RA) de Moody's qui permet d'adresser des régles prudentielles et qui est une véritable "black box". 

=> Réponse technique #1 

> Data Lineage dynamique, granulaire, Multi Techno - 

Pour comprendre comment la donnée circule dans les "legacy systems" complexes. 

 

=> Réponse technique #2 

 > Identification de tous les points durs du système : Rapports ou Traitements inopérants, tables ou fichiers inutilisés, brèches de sécurité...etc.

 Pour pouvoir réellement cartographier les systèmes dynamiquement,  et identifier l'essentiel des "pathologies". 

 Réponses fonctionnelles #1 :

 

 => Bloc "Gouvernance & Infrastructure".

 

 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."

 

Nos réponses :

 

Nous proposons de simplifier,  rationaliser les  DWH, et la couche reporting par :

1. Détection des « branches mortes » du DWH (tables, procédures, job ETL… ),
2. Calcul de la « distance » dans le DWH pour identifier les procédures, jobs ETL  à risque,
3. Identification de la réplication dans le DWH (tables, procédures, job ETL).
4. Analyse des requêtes adhoc tiers sur données les données Risque du DWH,
5. Suppression de tous le Rapports surnuméraires (obsolètes, cassés, pollués, répliqués...),
6. Analyse de l'hyper complexité des formules dans les rapports de risque. 

> Nous sommes capables d'identifier en continu tout ce qui fonctionne mal ou pas du tout dans les "legacy systems" complexes, que ce soit au niveau "alimentation" ou au niveau "reporting", de façon à pouvoir évincer les sources d'imprécision, d'inexactitude. 

 

Réponses fonctionnelles #2 :  

=>  Bloc "Capacités d’agrégation des données risques".

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".

Nos réponses : 

Nous proposons de scorer les données en source et les Rapports de Risque, sur quelques critères qualitatifs :

1. L'unicité des Rapports de risque,
2. La qualité des formules,
3. La complexité acceptable des Rapports de Risque,
4. La qualité de la documentation technique constitutive des Rapports de Risque.

 

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)"

Nos réponses : 

Nous proposons de vérifier automatiquement la "fraîcheur" de l’information :

1. Validation de la qualité de l'ordonnancement des Rapports de Risque ("schedule"),
2. Analyse des temps d'execution ("run") des chaînes d'alimentation des Rapports de Risque. 

 > Ainsi, nous sommes capables de scorer des rapports de risque, intrinsèquement, c'est à dire par rapport à la qualité des formules qui les composent, à leur "fraicheur", à leur unicité ... etc, mais aussi et surtout par rapport à la qualité des toutes leurs alimentations. 

 

Réponses fonctionnelles #3 : 

=> Bloc "Pratiques de reporting des risques".

 Principe 7 : Exactitude

 "Les reporting risques doivent être fiables et refléter précisément les risques. Ils doivent être réconciliés, documentés et validés".

 Nos réponses : 

Nous proposons une retro documentation technique complète, automatisée de l'ensemble des Rapports de Risque :

1. De la génèse des données des Rapports de Risque (qualité des flux d'alimentation) 
2. Des Rapports de Risque en eux-même (unicité, qualité des formules...) 

Principe 11 : Distribution

"Les reporting de gestion des risques devraient être transmis aux parties concernées tout en préservant le caractère confidentiel des informations communiquée"

Nos réponses : 

Portabilité de l'information :

1. Possibilité de partager les informations à un tiers via une application portable ("Electron").
2. Possibilité d'export pdf, png, pour envoi, ou impression. 

> Nous permettons un partage simple et efficace des informations qui doivent l'être, que ce soit en interne, ou vers l'externe. 

Réponses fonctionnelles #4 :

=> Bloc : Supervision, outils et coopération.

 Principe 12 : Surveillance

"Les autorités de contrôle doivent examiner et évaluer périodiquement la conformité d’une banque aux 11 principes de BCBS 239".

 Nos réponses :

Nous avons pris le parti de l'automatisation : 

1. L'ensemble du scoring des Rapports de risque est schedulé, et historisé, pour mesurer l'évolution du scope. Il devient possible de viser l'excellence ! 
2. Ce scoring peut-être transmis aux autorités régulatrices.

> Ainsi, nos outils permettent un partage efficace de l'information vers les autorités régulatrices, si besoin en automatique. 

Conclusion 

BCBS 239 est un texte qui aurait du être décliné techniquement il y a longtemps dans les banques - pour les G-SIBS dès 2016 (!), pour les banques domestiques, en janvier 2019.  

Mais les innombrables écueils techniques ont largement retardé sa mise en œuvre. La principale difficulté étant que les "legacy systems" sont énormes,  hétérogènes, avec d'innombrables "black box" qui rendent une compréhension fine des choses difficile, voir impossible. 

Nous proposons d'automatiser le "reverse engineering" sur l'essentiel des technologies présentes :

> Pour qualifier dynamiquement la qualité intrinsèque d’un rapport de risque,

> Pour connaître, et qualifier en continu,  toutes les alimentations d'un Rapport de Risque (inventaire, origine des données, qualité des traitements opérés, ordonnancement...),

> Et enfin, nous permettons un partage simple de cette connaissance à des tiers (Régulateur, autres).

Qui nous sommes 

Ellipsys est une start up luxembourgeoise spécialisée dans le reverse engineering dynamique. Nous créons continuellement des parsers, sondes, pour "décomplexifier" la compréhension des legacy systèmes, et nous produisons des interfaces web pour interpréter les résultats et les rendre intelligibles. 

Notre règle cardinale est de toujours de tout automatiser !

Nous comptons les plus grandes banques luxembourgeoises parmi nos clients : BGL / BNP, Banque Européenne d'Investissement, Banque Internationale à Luxembourg, Royal Bank of Canada, Raiffeisen.... et nous travaillons sur les projets BCBS 239 pour certaines d'entre elles. 

Par ailleurs nous sommes présents dans d'autres secteurs d'activité dans d'autres pays. 

Site web : http://ellipsys-bi.com

Contact : Théophile Gros /Partner 

Mail : ellipsys@ellipsys-bi.com