BCBS 239 et ses 14 principes pour les banques concernées

La crise de 2008 a révélé les difficultés à consolider les risques

Pendant la crise financière de 2007-2008, certaines banques ne parvenaient pas à consolider leurs expositions assez vite pour décider. Les données existaient, mais leur dispersion empêchait une lecture fiable du risque à l’échelle du groupe. Le Comité de Bâle a publié en janvier 2013 les Principles for effective risk data aggregation and risk reporting, connus sous la référence BCBS 239. Comité de Bâle, janvier 2013.

Prenons une demande d’audit. Un montant est sélectionné dans un rapport. Retrouver la table DB2 qui l’alimente ne suffit pas. Il faut expliquer les transformations appliquées et vérifier que le périmètre retenu correspond au chiffre présenté. Il faut aussi établir quelle version du traitement a produit ce montant.

Les 14 principes BCBS 239 couvrent quatre familles

Les onze premiers principes concernent la banque. Les trois derniers s’adressent aux superviseurs. Ils couvrent la gouvernance et l’infrastructure, l’agrégation des données, les rapports de risques et la supervision. BCBS 239, janvier 2013.

Gouvernance et infrastructure

1. Gouvernance. Le conseil et la direction portent la responsabilité du dispositif.
2. Architecture des données et infrastructure informatique. Les moyens techniques doivent soutenir l’agrégation et les rapports, en fonctionnement normal comme en crise.

Agrégation des données de risque

1. Exactitude et intégrité. Produire des données fiables, avec des rapprochements et une automatisation adaptée.
2. Exhaustivité. Inclure toutes les expositions significatives, y compris hors bilan.
3. Actualité. Produire des données suffisamment récentes dans les délais nécessaires.
4. Adaptabilité. Pouvoir répondre à des demandes ponctuelles, notamment en période de crise.

Rapports de risques

1. Exactitude. Rapprocher et valider les données présentées dans les rapports.
2. Représentativité. Couvrir les risques significatifs avec une profondeur adaptée à la banque et aux destinataires.
3. Clarté et utilité. Fournir une information compréhensible qui éclaire les décisions.
4. Fréquence. Adapter la périodicité des rapports aux besoins et à l’évolution des risques.
5. Distribution. Transmettre les rapports aux destinataires concernés, dans les délais et sous confidentialité.

Supervision

1. Surveillance. Les superviseurs évaluent périodiquement l’application des principes.
2. Actions correctives et mesures prudentielles. Ils disposent des moyens nécessaires pour demander la correction des insuffisances.
3. Coopération entre autorités d’origine et d’accueil. Les autorités coordonnent leur supervision des groupes transfrontaliers.

Ces formulations résument les principes. Leur appréciation demande de consulter le texte complet et les attentes du superviseur compétent. BCBS 239, principes 1 à 14.

Quelles banques sont concernées ?

L’échéance de janvier 2016 concernait les banques d’importance systémique mondiale, ou G-SIB, identifiées en novembre 2011 ou 2012. Pour les G-SIB désignées ensuite, le texte prévoit trois ans après leur désignation.

Le Comité recommande aux superviseurs nationaux d’appliquer également les principes aux banques d’importance systémique nationale, ou D-SIB, trois ans après leur désignation. Ces autorités peuvent les appliquer à d’autres banques, proportionnellement à la taille, à la nature et à la complexité de leurs activités. Cette extension relève de leur décision. BCBS 239, paragraphes 13 à 15.

Dans le cadre de la supervision bancaire européenne, le guide BCE de mai 2024 précise les attentes envers les établissements importants sous sa supervision directe. Il s’appuie sur BCBS 239 pour apprécier leurs capacités d’agrégation et de reporting des données de risque, ou RDARR, selon une approche proportionnée. BCE, guide RDARR, sections 1 et 2.

Le statut prudentiel et les attentes adressées à chaque établissement doivent donc être examinés. L’absence de classement G-SIB ne suffit pas à conclure qu’une banque n’est pas concernée.

Le périmètre de travail mérite aussi d’être écrit. Il doit préciser les rapports et les entités retenus, ainsi que les données critiques utilisées dans les calculs. Risques et IT peuvent alors vérifier qu’ils travaillent sur le même ensemble.

Les difficultés documentées en 2023 restent un repère

Le rapport d’avancement du Comité de Bâle publié en novembre 2023 constatait qu’un travail important restait nécessaire dans la plupart des banques systémiques mondiales évaluées. Il relevait notamment des systèmes fragmentés et des traitements manuels persistants. Certains programmes manquaient aussi de moyens ou d’attention des instances dirigeantes. Ce constat porte sur les établissements examinés, pas sur toutes les banques. Comité de Bâle, rapport d’avancement 2023.

Prenons un catalogue renseigné manuellement. Si une application change sans mise à jour de sa documentation, l’équipe doit vérifier les transformations avant de répondre à l’auditeur. Le lignage présenté lors de la dernière revue peut alors décrire une version ancienne du traitement.

Une couverture technique partielle peut créer une autre difficulté. Supposons que le parcours soit documenté dans une base relationnelle, mais pas dans le programme Cobol qui l’alimente. Il faut reconstituer ce passage avant de pouvoir expliquer le calcul. Si cette connaissance reste dans les échanges entre équipes, la demande suivante risque de déclencher la même recherche.

Lorsque les responsabilités sont réparties entre Risques, Finance et IT, cette vérification demande aussi de réunir les bons interlocuteurs. Une documentation datée, reliée au code examiné et rapprochée de la production, permet de préciser ce qui a été vérifié et ce qui reste à confirmer.

Le lignage aide à documenter quatre principes

Le guide BCE de mai 2024 attend un lignage complet et actualisé au niveau des attributs de données, pour les indicateurs de risque et leurs données critiques inclus dans le périmètre. BCE, guide RDARR, section 3.4.

Les exemples ci-dessous illustrent des usages possibles pour les principes 2, 3, 4 et 6. Ils ne constituent pas des cas clients.

Pour l’architecture, suivre un montant jusqu’au code

Prenons un montant d’exposition au risque de crédit dans un rapport. Remonter jusqu’aux colonnes sources permet d’identifier les programmes qui les transforment. Une flèche entre deux applications ne décrit pas le calcul. Il faut examiner les transformations qui relient l’entrée à la sortie.

Pour l’exactitude, inspecter la transformation et vérifier son exécution

Supposons qu’une conversion de devise soit répartie entre deux programmes Cobol. L’analyse montre les transformations présentes dans le code examiné. Pour expliquer un montant publié, il faut aussi vérifier la version exécutée, ses paramètres et les éventuels ajustements manuels.

Le calcul reste à tester. Un rapprochement entre le résultat attendu et le résultat produit complète l’examen.

Pour l’exhaustivité, comparer les sources au périmètre attendu

Une table absente du parcours peut signaler une omission. Mais la carte ne montre que les sources qu’elle connaît. Il faut donc comparer les flux identifiés aux populations attendues. Un chemin sans rupture ne prouve pas, à lui seul, que toutes les expositions nécessaires sont présentes.

Pour l’adaptabilité, préparer une nouvelle extraction

Une demande peut porter sur un autre regroupement d’expositions. Connaître les dépendances aide à repérer les colonnes utilisables et les transformations à revoir. La capacité de réponse se vérifie ensuite en produisant le résultat, en contrôlant sa qualité et en mesurant le délai nécessaire.

Un lien déclaré consigne une connaissance métier. Un lien trouvé dans le code décrit une dépendance technique. Les rapprocher permet de repérer les écarts, puis de vérifier leur correspondance avec le traitement exécuté.

Partir d’un rapport pour examiner les preuves

Une revue peut commencer par un seul montant. Depuis la cellule du rapport, remonter à la source et inspecter une transformation. Vérifier ensuite la version exécutée et les résultats des contrôles. Tout ajustement manuel intervenu avant la publication doit aussi être examiné.

Vokse s’appuie sur 25 ans de R&D en rétro-ingénierie. Il analyse le code existant, notamment Cobol, JCL, Copybooks et DB2, pour établir un lignage colonne par colonne relié aux processus métier et aux rapports. Les liens trouvés dans le code se distinguent des liens déclarés. Les transformations s’ouvrent jusqu’aux lignes de code, et une anomalie peut être suivie jusqu’au rapport touché. Vokse propose également des contrôles continus et un accès pour les auditeurs.

Ces capacités fournissent des éléments vérifiables pour la revue. Pour justifier un montant publié, la banque doit les rapprocher des données utilisées et des conditions d’exécution. Elles ne garantissent pas, à elles seules, la conformité.

L’autodiagnostic BCBS 239 gratuit propose huit questions en trois minutes, avec un résultat immédiat, sans email.

FAQ

Quels sont les 14 principes BCBS 239 ?

Gouvernance, architecture des données et infrastructure informatique, exactitude et intégrité, exhaustivité, actualité, adaptabilité, exactitude des rapports, représentativité, clarté et utilité, fréquence, distribution, surveillance, actions correctives et mesures prudentielles, coopération entre autorités d’origine et d’accueil. Comité de Bâle, 2013.

Qui est concerné par BCBS 239 ?

Les G-SIB sont directement visées par le référentiel. Le Comité recommande aussi son application aux D-SIB trois ans après leur désignation. Les superviseurs nationaux peuvent étendre son application à d’autres banques de manière proportionnée. BCBS 239, paragraphes 13 à 15.

BCBS 239 est-il obligatoire ?

La portée des obligations dépend du cadre juridique applicable et des mesures du superviseur. Le guide BCE de mai 2024 précise les attentes de supervision et indique qu’il n’impose pas de nouvelles exigences. BCE, guide RDARR, sections 1 et 2.

Quelle différence entre BCBS 239 et RDARR ?

BCBS 239 désigne les quatorze principes publiés par le Comité de Bâle. RDARR signifie Risk Data Aggregation and Risk Reporting, soit l’agrégation des données de risque et leur reporting. Le guide BCE de mai 2024 précise les attentes de supervision dans ce domaine. BCE, guide RDARR.