À qui s'applique BCBS 239 ?

Aux banques d'importance systémique mondiale (G-SIB) depuis 2016, et par extension des superviseurs nationaux aux banques systémiques locales (D-SIB). De nombreux établissements non systémiques l'adoptent comme bonne pratique, car il sous-tend le reste de leur reporting réglementaire.

Quel est le véritable défi technique ?

La traçabilité et la qualité de la donnée, et non le rapport final. Il faut pouvoir remonter chaque chiffre jusqu'à sa source, garantir la cohérence entre les sources et réagréger rapidement face aux demandes du superviseur ou aux scénarios de stress. C'est un problème d'architecture de données et de capacité de calcul.

Quel est son lien avec la FRTB, IFRS 9 ou les tests de résistance ?

BCBS 239 est la couche de données qui alimente tous ces calculs. Si l'agrégation des données de risque est faible, le risque de marché (FRTB), la dépréciation comptable (IFRS 9) et les stress tests héritent de cette faiblesse. C'est pourquoi il est généralement abordé comme socle transversal.

Glossaire · Réglementation · Données de risque

BCBS 239 (RDARR) — agrégation des données de risque et reporting

BCBS 239 désigne les 14 principes du Comité de Bâle (2013) destinés à ce qu'une banque agrège ses données de risque et produise ses rapports de manière précise, complète, en temps voulu et adaptable. Il s'applique aux banques systémiques mondiales (G-SIB) et, par extension nationale, aux banques systémiques locales. En pratique, ce n'est pas un problème de rapports : c'est un problème d'architecture et de qualité de la donnée.

Les 14 principes, en quatre blocs

Gouvernance et infrastructure — responsabilité du conseil d'administration et architecture de données capable de soutenir l'agrégation, y compris en situation de stress.
Capacité d'agrégation — exactitude et intégrité, exhaustivité, ponctualité et adaptabilité des données de risque.
Pratiques de reporting — exactitude, couverture, clarté, fréquence et diffusion des rapports.
Supervision — examen, outils et coopération des autorités.

Pourquoi c'est un projet de données (et de HPC)

L'obstacle réel n'est pas la mise en forme du rapport, mais le fait de disposer de la traçabilité, de la qualité et de la granularité de la donnée de risque et de pouvoir recalculer en situation de stress dans des délais courts. Cela exige une architecture de données unifiée (et non des silos par domaine), une traçabilité de bout en bout et une capacité de calcul permettant de réagréger des portefeuilles complets. Les cores fragmentés et les traitements batch rigides sont là où ces programmes s'enlisent.

Comment Vermont Solutions vous aide

Architecture de données de risque prête à réagréger

Nous modernisons le core et la couche de données pour soutenir l'agrégation avec traçabilité et qualité : extraction depuis les sources héritées, traçabilité de bout en bout et calcul capable de réagréger des portefeuilles en situation de stress.

Voir la modernisation du legacy et du core →

Fuentes

BCBS 239 — Comité de Bâle (BIS)

Dernière mise à jour : 2026-06-19. Contenu éditorial de Vermont Solutions, citable sous réserve d'attribution. Ne constitue pas un conseil réglementaire ; vérifiez la version en vigueur sur bis.org.