Combler l'écart de qualité des données du BCBS 239

Combler l'écart de qualité des données du BCBS 239

17 oct. 2025

Maarten Masschelein

Maarten Masschelein

Maarten Masschelein

PDG et Fondateur chez Soda

PDG et Fondateur chez Soda

PDG et Fondateur chez Soda

Table des matières

En utilisant Soda, les grandes banques transforment les politiques de gouvernance en contrôles automatisés et exploitables qui peuvent être intégrés en toute transparence dans les flux de travail existants.

L'Écart de Qualité des Données BCBS 239

Le BCBS 239 établit des principes stricts pour l'agrégation et le reporting des données de risque, obligeant les banques à prouver que les données sont exactes, complètes, opportunes, adaptables et conciliées à travers les systèmes et les rapports.

La réglementation s'applique à toutes les Banques D'Importance Systémique Mondiale (G-SIBs) et, dans de nombreuses juridictions, a été étendue aux Banques D'Importance Systémique Nationale (D-SIBs).

Pourtant, plus d'une décennie après l'entrée en vigueur de la réglementation, les superviseurs continuent de signaler des faiblesses dans la qualité des données, la conciliation et la gouvernance. Moins de 10 % des G-SIBs sont entièrement conformes. Les enjeux sont élevés : pression réglementaire, surtaxes potentielles en capital et atteinte à la réputation.

L'écart ne réside pas dans la prise de conscience des principes, mais dans leur opérationnalisation. La conformité n'est pas une étape ponctuelle mais une discipline continue que les banques doivent démontrer chaque jour, avec des preuves.

Comment Soda Comble Cet Écart

Traditionnellement, la conformité au BCBS 239 signifiait des contrôles fragmentés, des vérifications manuelles et de longs historiques d'audit. Soda change cela en transformant les principes réglementaires en pratiques opérationnelles, automatisées et vérifiables — centralisées sur une seule plateforme et intégrées dans les flux de travail opérationnels existants.

En intégrant des vérifications et contrôles de qualité des données à chaque étape du cycle de vie des données de risque, Soda garantit que les données de risque sont démontrablement exactes, complètes, opportunes et conciliées.

Avec Soda, les G-SIBs peuvent :

  • Surveiller la qualité des données à grande échelle en termes d'exactitude, de complétude, d'opportunité et de conciliation.

  • Automatiser la conciliation inter-systèmes entre les systèmes comptables, de risque et de reporting.

  • Appliquer des contrats de données collaboratifs qui établissent des accords partagés de qualité des données entre producteurs et consommateurs.

  • Déplacer la gouvernance des données en amont en appliquant les politiques au point de production des données pour résoudre les problèmes avant qu'ils ne se propagent en aval.

  • Fournir des preuves prêtes pour l'audit avec des métadonnées complètes sur chaque résultat de vérification.

  • S'intégrer de manière bidirectionnelle avec les catalogues de données, transformant les règles de gouvernance documentées en contrôles applicables.

Principes BCBS 239 Opérationnalisés

Comment Soda met les principes en pratique.


Principes BCBS 239

Capacités de Soda

Conciliation des Données

Principe 3

  • Les données de risque doivent être conciliées avec les sources de la banque, y compris les données comptables lorsque cela est approprié, pour garantir que les données de risque sont exactes.


Principe 7

  • Exigences et processus définis pour concilier les rapports aux données de risque.

  • Les rapports doivent être conciliés et vérifiés.

  • Vérifications de Conciliation

    Confirmer que les données de risque restent cohérentes. Valider que les ensembles de données cibles s'alignent avec leurs ensembles de données sources.


  • Vérifications de Conciliation au Niveau des Lignes

    Valider les données enregistrements par enregistrements.


  • Vérifications de Conciliation au Niveau des Métadonnées

    Comparer les agrégats (totaux, moyennes, décomptes) entre les ensembles de données sources et cibles.

Validation des Données

Principe 7

  • Les superviseurs s'attendent à ce qu'une banque prenne en compte les exigences de précision basées sur les processus et résultats de validation, de test ou de conciliation.

  • Maintenir un inventaire de toutes les validations et vérifications, à la fois automatisées et manuelles, utilisées pour garantir que les données quantitatives sont exactes, avec une documentation claire de la logique derrière chacune.

  • Métriques de Validité

    Détecter les valeurs invalides ou inattendues au sein d'une colonne (par exemple, formats incorrects, entrées hors plage) avec une logique de validation configurable telle que des expressions régulières, des formats ou des listes de valeurs.


  • Contrats de Données

    Accords formels qui définissent ce que signifie des « bonnes données » et rendent ces attentes testables grâce à une validation automatisée.

Tests de Données

Principe 7

  • Les superviseurs s'attendent à ce qu'une banque prenne en compte les exigences de précision basées sur les processus et résultats de validation, de test ou de conciliation.

  • Vérifications de Conciliation, Vérifications de la Qualité des Données & Contrats de Données

    Définir les attentes, tester les données par rapport à celles-ci et assurer des résultats cohérents et fiables à travers les pipelines et les rapports.

Contrôles de Données

Principe 3

  • Les contrôles entourant les données de risque doivent être aussi robustes que ceux applicables aux données comptables.

  • Surveiller la précision des données et développer des canaux d'escalade et des plans d'action appropriés pour rectifier la mauvaise qualité des données.


Principe 4

  • Processus pour rectifier les problèmes de complétude.


Principe 5

  • L'agrégation des données de risque doit être opportune, tant dans des conditions normales que de stress.


Principe 7

  • Procédures intégrées pour identifier, signaler et expliquer les erreurs de données ou les faiblesses dans l'intégrité des données via des rapports d'exception.

  • Vérifications de Fraîcheur & Suivi des SLA

    S'assurer que les données ne sont pas plus anciennes que les seuils requis (par exemple, même jour, heure par heure) et que les pipelines respectent systématiquement les SLA de ponctualité. Les violations déclenchent automatiquement des alertes et une escalade, avec des pistes d'audit complètes pour la conformité.


  • Dépôt de Diagnostics

    Un enregistrement central auditable des vérifications échouées et des lignes, garantissant que les contrôles des données de risque sont aussi solides que les données comptables.


  • Incidents & Alertes

    Créer, assigner et suivre automatiquement les incidents à partir des vérifications échouées, avec des rapports et des intégrations (Slack, Teams, Jira) pour soutenir une escalade et une résolution rapides.


  • Intégration Bidirectionnelle de la Traçabilité des Données

    Transformer automatiquement les règles de gouvernance définies dans les catalogues de données en contrôles de qualité applicables.

Opérationnalisation du BCBS 239 en Pratique

Le tableau ci-dessus montre les capacités de Soda cartographiées vers chaque principe BCBS 239. En pratique, de nombreux contrôles couvrent plusieurs exigences.

Les contrats de données de Soda offrent une solution unifiante pour faire respecter les attentes en matière de qualité des données à travers les sources, les pipelines et les rapports. Un contrat de données définit ce à quoi ressemblent des « bonnes données » — couvrant l'exactitude, la complétude, l'opportunité et la validation des rapports — et rend ces attentes exécutables et vérifiables.

Les contrats peuvent être écrits sous forme de code pour les équipes d'ingénierie ou rédigés directement dans l'interface utilisateur de Soda, les rendant accessibles aux gestionnaires de risques, aux propriétaires de données et aux parties prenantes de la gouvernance.

Pour illustrer, voici deux exemples de contrats de données qui opérationnalisent les principaux principes BCBS 239 en pratique :

Exemple 1 : Conciliation des Expositions avec les Données Comptables

Ce que fait ce contrat de données :

  • Concilie les totaux des expositions avec les soldes comptables et déclenche des alertes si les écarts excèdent 1 000 €.

  • Valide que les codes LEI respectent le format requis de 20 caractères.

  • Signale les contreparties manquantes dans la liste maîtresse officielle.

Quels principes BCBS 239 cela affecte-t-il :

  • Exactitude & Intégrité (P3)

  • Complétude (P4)

  • Exactitude du Reporting (P7)

dataset: <datasource>/<db>/<schema>/exposures

checks:
  - failed_rows:
      name: counterparties_missing_in_exposures
      query: |
        SELECT m.counterparty_id
        FROM <datasource>/<db>/<schema>/counterparty_master m
        LEFT JOIN <datasource>/<db>/<schema>/exposures e
          ON e.counterparty_id = m.counterparty_id
        WHERE e.counterparty_id IS NULL
      threshold:
        must_be: 0
      attributes:
        bcbs239:
          - P4
        description: "Completeness: any counterparties 	
        	missing from exposures?"

columns:
  - name: lei_code
    data_type: string
    checks:
      - invalid:
          name: lei_code_format
          valid_format:
            name: LEI must be 20 alphanumeric
            regex: '^[A-Z0-9]{20}$'
          attributes:
            bcbs239:
              - P3
            description: LEI format is 20 uppercase alphanumerics

  - name: counterparty_id
    checks:
      - invalid:
          name: counterparty_id_in_master
          valid_reference_data:
            dataset: <datasource>/<db>/<schema>/counterparty_master
            column: counterparty_id
          attributes:
            bcbs239:
              - P3
            description: "Integrity: all counterparties in 
            	exposures exist in the master"

reconciliation:
  source:
    dataset: <datasource>/<db>/<schema>/accounting_balances
  checks:
    - metric_diff:
        name: total_exposures_vs_total_balance
        source_expression: SUM(balance_amount)
        target_expression: SUM(exposure_amount)
        threshold:
          must_be_less_than: 1000
        attributes:
          bcbs239:
            - P3
            - P7
          description: "Reconciliation vs accounting: 
          	Overall tolerance across the books (sum vs sum)"

Exemple 2 : Assurer l'Opportunité et l'Adaptabilité

Ce que fait ce contrat de données :

  • Surveille que les expositions quotidiennes sont livrées dans les 4 heures suivant la date de référence.

  • Assure que la latence du pipeline reste inférieure à 60 minutes.

  • Valide les IDs de scénario par rapport à la liste de référence approuvée, tandis que les variables permettent des fenêtres de temps flexibles pour des rapports ad hoc.

Quels principes BCBS 239 cela affecte-t-il :

  • Traite l'Opportunité (P5)

  • Adaptabilité (P6)

dataset: <datasource>/<db>/<schema>/agg_exposure_daily

filter: as_of_date BETWEEN ${var.START_TS} AND ${var.END_TS}
variables:
  BUSINESS_DATE:
    default: CURRENT_DATE()
  START_TS:
    default: DATEADD('day', -1, ${soda.NOW})
  END_TS:
    default: ${soda.NOW}

checks:
  - freshness:
      name: Timeliness
      column: as_of_date
      threshold:
        unit: hour
        must_be_less_than: 4
      attributes:
        bcbs239:
          - P5
        description: "SLA: max 4 hours old"

  - metric:
      name: pipeline_latency_minutes
      query: |
        SELECT DATEDIFF('minute', MIN(ingested_at), MAX(loaded_at))
        FROM <datasource>/<db>/<schema>/agg_exposure_daily
        WHERE CAST(as_of_date AS DATE) = ${var.BUSINESS_DATE}
      threshold:
        must_be_less_than: 60
      attributes:
        bcbs239:
          - P5
        description: "Pipeline latency < 60 minutes 
        	for the business day"

columns:
  - name: scenario_id
    data_type: string
    checks:
      - invalid:
          name: scenario_id_valid
          valid_reference_data:
            dataset: <datasource>/<db>/<schema>/ref_scenarios
            column: scenario_id
          attributes:
            bcbs239:
              - P6
            description

Obtenez une démonstration des contrats de données collaboratifs, voyez comment les créer dans l'interface utilisateur de Soda et apprenez comment ils peuvent opérationnaliser les principes BCBS 239 à grande échelle.

Être Toujours Prêt pour l'Audit

Soda équipe les principales banques mondiales des contrôles, des conciliations et des pistes de vérification pour démontrer une conformité continue.

Les grandes banques comptent sur Soda pour :

  • Prouver la conformité au BCBS 239 grâce à la qualité des données automatisée et à la conciliation.

  • Réduire le risque réglementaire avec une surveillance continue et la gestion des exceptions.

  • Simplifier les audits en générant des preuves et des enregistrements traçables à la demande.

  • Accélérer le changement avec des contrôles flexibles qui s'adaptent aux nouvelles demandes de supervision.

Rencontrez notre équipe d'experts et obtenez une démonstration de Soda pour la conformité BCBS 239.

En utilisant Soda, les grandes banques transforment les politiques de gouvernance en contrôles automatisés et exploitables qui peuvent être intégrés en toute transparence dans les flux de travail existants.

L'Écart de Qualité des Données BCBS 239

Le BCBS 239 établit des principes stricts pour l'agrégation et le reporting des données de risque, obligeant les banques à prouver que les données sont exactes, complètes, opportunes, adaptables et conciliées à travers les systèmes et les rapports.

La réglementation s'applique à toutes les Banques D'Importance Systémique Mondiale (G-SIBs) et, dans de nombreuses juridictions, a été étendue aux Banques D'Importance Systémique Nationale (D-SIBs).

Pourtant, plus d'une décennie après l'entrée en vigueur de la réglementation, les superviseurs continuent de signaler des faiblesses dans la qualité des données, la conciliation et la gouvernance. Moins de 10 % des G-SIBs sont entièrement conformes. Les enjeux sont élevés : pression réglementaire, surtaxes potentielles en capital et atteinte à la réputation.

L'écart ne réside pas dans la prise de conscience des principes, mais dans leur opérationnalisation. La conformité n'est pas une étape ponctuelle mais une discipline continue que les banques doivent démontrer chaque jour, avec des preuves.

Comment Soda Comble Cet Écart

Traditionnellement, la conformité au BCBS 239 signifiait des contrôles fragmentés, des vérifications manuelles et de longs historiques d'audit. Soda change cela en transformant les principes réglementaires en pratiques opérationnelles, automatisées et vérifiables — centralisées sur une seule plateforme et intégrées dans les flux de travail opérationnels existants.

En intégrant des vérifications et contrôles de qualité des données à chaque étape du cycle de vie des données de risque, Soda garantit que les données de risque sont démontrablement exactes, complètes, opportunes et conciliées.

Avec Soda, les G-SIBs peuvent :

  • Surveiller la qualité des données à grande échelle en termes d'exactitude, de complétude, d'opportunité et de conciliation.

  • Automatiser la conciliation inter-systèmes entre les systèmes comptables, de risque et de reporting.

  • Appliquer des contrats de données collaboratifs qui établissent des accords partagés de qualité des données entre producteurs et consommateurs.

  • Déplacer la gouvernance des données en amont en appliquant les politiques au point de production des données pour résoudre les problèmes avant qu'ils ne se propagent en aval.

  • Fournir des preuves prêtes pour l'audit avec des métadonnées complètes sur chaque résultat de vérification.

  • S'intégrer de manière bidirectionnelle avec les catalogues de données, transformant les règles de gouvernance documentées en contrôles applicables.

Principes BCBS 239 Opérationnalisés

Comment Soda met les principes en pratique.


Principes BCBS 239

Capacités de Soda

Conciliation des Données

Principe 3

  • Les données de risque doivent être conciliées avec les sources de la banque, y compris les données comptables lorsque cela est approprié, pour garantir que les données de risque sont exactes.


Principe 7

  • Exigences et processus définis pour concilier les rapports aux données de risque.

  • Les rapports doivent être conciliés et vérifiés.

  • Vérifications de Conciliation

    Confirmer que les données de risque restent cohérentes. Valider que les ensembles de données cibles s'alignent avec leurs ensembles de données sources.


  • Vérifications de Conciliation au Niveau des Lignes

    Valider les données enregistrements par enregistrements.


  • Vérifications de Conciliation au Niveau des Métadonnées

    Comparer les agrégats (totaux, moyennes, décomptes) entre les ensembles de données sources et cibles.

Validation des Données

Principe 7

  • Les superviseurs s'attendent à ce qu'une banque prenne en compte les exigences de précision basées sur les processus et résultats de validation, de test ou de conciliation.

  • Maintenir un inventaire de toutes les validations et vérifications, à la fois automatisées et manuelles, utilisées pour garantir que les données quantitatives sont exactes, avec une documentation claire de la logique derrière chacune.

  • Métriques de Validité

    Détecter les valeurs invalides ou inattendues au sein d'une colonne (par exemple, formats incorrects, entrées hors plage) avec une logique de validation configurable telle que des expressions régulières, des formats ou des listes de valeurs.


  • Contrats de Données

    Accords formels qui définissent ce que signifie des « bonnes données » et rendent ces attentes testables grâce à une validation automatisée.

Tests de Données

Principe 7

  • Les superviseurs s'attendent à ce qu'une banque prenne en compte les exigences de précision basées sur les processus et résultats de validation, de test ou de conciliation.

  • Vérifications de Conciliation, Vérifications de la Qualité des Données & Contrats de Données

    Définir les attentes, tester les données par rapport à celles-ci et assurer des résultats cohérents et fiables à travers les pipelines et les rapports.

Contrôles de Données

Principe 3

  • Les contrôles entourant les données de risque doivent être aussi robustes que ceux applicables aux données comptables.

  • Surveiller la précision des données et développer des canaux d'escalade et des plans d'action appropriés pour rectifier la mauvaise qualité des données.


Principe 4

  • Processus pour rectifier les problèmes de complétude.


Principe 5

  • L'agrégation des données de risque doit être opportune, tant dans des conditions normales que de stress.


Principe 7

  • Procédures intégrées pour identifier, signaler et expliquer les erreurs de données ou les faiblesses dans l'intégrité des données via des rapports d'exception.

  • Vérifications de Fraîcheur & Suivi des SLA

    S'assurer que les données ne sont pas plus anciennes que les seuils requis (par exemple, même jour, heure par heure) et que les pipelines respectent systématiquement les SLA de ponctualité. Les violations déclenchent automatiquement des alertes et une escalade, avec des pistes d'audit complètes pour la conformité.


  • Dépôt de Diagnostics

    Un enregistrement central auditable des vérifications échouées et des lignes, garantissant que les contrôles des données de risque sont aussi solides que les données comptables.


  • Incidents & Alertes

    Créer, assigner et suivre automatiquement les incidents à partir des vérifications échouées, avec des rapports et des intégrations (Slack, Teams, Jira) pour soutenir une escalade et une résolution rapides.


  • Intégration Bidirectionnelle de la Traçabilité des Données

    Transformer automatiquement les règles de gouvernance définies dans les catalogues de données en contrôles de qualité applicables.

Opérationnalisation du BCBS 239 en Pratique

Le tableau ci-dessus montre les capacités de Soda cartographiées vers chaque principe BCBS 239. En pratique, de nombreux contrôles couvrent plusieurs exigences.

Les contrats de données de Soda offrent une solution unifiante pour faire respecter les attentes en matière de qualité des données à travers les sources, les pipelines et les rapports. Un contrat de données définit ce à quoi ressemblent des « bonnes données » — couvrant l'exactitude, la complétude, l'opportunité et la validation des rapports — et rend ces attentes exécutables et vérifiables.

Les contrats peuvent être écrits sous forme de code pour les équipes d'ingénierie ou rédigés directement dans l'interface utilisateur de Soda, les rendant accessibles aux gestionnaires de risques, aux propriétaires de données et aux parties prenantes de la gouvernance.

Pour illustrer, voici deux exemples de contrats de données qui opérationnalisent les principaux principes BCBS 239 en pratique :

Exemple 1 : Conciliation des Expositions avec les Données Comptables

Ce que fait ce contrat de données :

  • Concilie les totaux des expositions avec les soldes comptables et déclenche des alertes si les écarts excèdent 1 000 €.

  • Valide que les codes LEI respectent le format requis de 20 caractères.

  • Signale les contreparties manquantes dans la liste maîtresse officielle.

Quels principes BCBS 239 cela affecte-t-il :

  • Exactitude & Intégrité (P3)

  • Complétude (P4)

  • Exactitude du Reporting (P7)

dataset: <datasource>/<db>/<schema>/exposures

checks:
  - failed_rows:
      name: counterparties_missing_in_exposures
      query: |
        SELECT m.counterparty_id
        FROM <datasource>/<db>/<schema>/counterparty_master m
        LEFT JOIN <datasource>/<db>/<schema>/exposures e
          ON e.counterparty_id = m.counterparty_id
        WHERE e.counterparty_id IS NULL
      threshold:
        must_be: 0
      attributes:
        bcbs239:
          - P4
        description: "Completeness: any counterparties 	
        	missing from exposures?"

columns:
  - name: lei_code
    data_type: string
    checks:
      - invalid:
          name: lei_code_format
          valid_format:
            name: LEI must be 20 alphanumeric
            regex: '^[A-Z0-9]{20}$'
          attributes:
            bcbs239:
              - P3
            description: LEI format is 20 uppercase alphanumerics

  - name: counterparty_id
    checks:
      - invalid:
          name: counterparty_id_in_master
          valid_reference_data:
            dataset: <datasource>/<db>/<schema>/counterparty_master
            column: counterparty_id
          attributes:
            bcbs239:
              - P3
            description: "Integrity: all counterparties in 
            	exposures exist in the master"

reconciliation:
  source:
    dataset: <datasource>/<db>/<schema>/accounting_balances
  checks:
    - metric_diff:
        name: total_exposures_vs_total_balance
        source_expression: SUM(balance_amount)
        target_expression: SUM(exposure_amount)
        threshold:
          must_be_less_than: 1000
        attributes:
          bcbs239:
            - P3
            - P7
          description: "Reconciliation vs accounting: 
          	Overall tolerance across the books (sum vs sum)"

Exemple 2 : Assurer l'Opportunité et l'Adaptabilité

Ce que fait ce contrat de données :

  • Surveille que les expositions quotidiennes sont livrées dans les 4 heures suivant la date de référence.

  • Assure que la latence du pipeline reste inférieure à 60 minutes.

  • Valide les IDs de scénario par rapport à la liste de référence approuvée, tandis que les variables permettent des fenêtres de temps flexibles pour des rapports ad hoc.

Quels principes BCBS 239 cela affecte-t-il :

  • Traite l'Opportunité (P5)

  • Adaptabilité (P6)

dataset: <datasource>/<db>/<schema>/agg_exposure_daily

filter: as_of_date BETWEEN ${var.START_TS} AND ${var.END_TS}
variables:
  BUSINESS_DATE:
    default: CURRENT_DATE()
  START_TS:
    default: DATEADD('day', -1, ${soda.NOW})
  END_TS:
    default: ${soda.NOW}

checks:
  - freshness:
      name: Timeliness
      column: as_of_date
      threshold:
        unit: hour
        must_be_less_than: 4
      attributes:
        bcbs239:
          - P5
        description: "SLA: max 4 hours old"

  - metric:
      name: pipeline_latency_minutes
      query: |
        SELECT DATEDIFF('minute', MIN(ingested_at), MAX(loaded_at))
        FROM <datasource>/<db>/<schema>/agg_exposure_daily
        WHERE CAST(as_of_date AS DATE) = ${var.BUSINESS_DATE}
      threshold:
        must_be_less_than: 60
      attributes:
        bcbs239:
          - P5
        description: "Pipeline latency < 60 minutes 
        	for the business day"

columns:
  - name: scenario_id
    data_type: string
    checks:
      - invalid:
          name: scenario_id_valid
          valid_reference_data:
            dataset: <datasource>/<db>/<schema>/ref_scenarios
            column: scenario_id
          attributes:
            bcbs239:
              - P6
            description

Obtenez une démonstration des contrats de données collaboratifs, voyez comment les créer dans l'interface utilisateur de Soda et apprenez comment ils peuvent opérationnaliser les principes BCBS 239 à grande échelle.

Être Toujours Prêt pour l'Audit

Soda équipe les principales banques mondiales des contrôles, des conciliations et des pistes de vérification pour démontrer une conformité continue.

Les grandes banques comptent sur Soda pour :

  • Prouver la conformité au BCBS 239 grâce à la qualité des données automatisée et à la conciliation.

  • Réduire le risque réglementaire avec une surveillance continue et la gestion des exceptions.

  • Simplifier les audits en générant des preuves et des enregistrements traçables à la demande.

  • Accélérer le changement avec des contrôles flexibles qui s'adaptent aux nouvelles demandes de supervision.

Rencontrez notre équipe d'experts et obtenez une démonstration de Soda pour la conformité BCBS 239.

En utilisant Soda, les grandes banques transforment les politiques de gouvernance en contrôles automatisés et exploitables qui peuvent être intégrés en toute transparence dans les flux de travail existants.

L'Écart de Qualité des Données BCBS 239

Le BCBS 239 établit des principes stricts pour l'agrégation et le reporting des données de risque, obligeant les banques à prouver que les données sont exactes, complètes, opportunes, adaptables et conciliées à travers les systèmes et les rapports.

La réglementation s'applique à toutes les Banques D'Importance Systémique Mondiale (G-SIBs) et, dans de nombreuses juridictions, a été étendue aux Banques D'Importance Systémique Nationale (D-SIBs).

Pourtant, plus d'une décennie après l'entrée en vigueur de la réglementation, les superviseurs continuent de signaler des faiblesses dans la qualité des données, la conciliation et la gouvernance. Moins de 10 % des G-SIBs sont entièrement conformes. Les enjeux sont élevés : pression réglementaire, surtaxes potentielles en capital et atteinte à la réputation.

L'écart ne réside pas dans la prise de conscience des principes, mais dans leur opérationnalisation. La conformité n'est pas une étape ponctuelle mais une discipline continue que les banques doivent démontrer chaque jour, avec des preuves.

Comment Soda Comble Cet Écart

Traditionnellement, la conformité au BCBS 239 signifiait des contrôles fragmentés, des vérifications manuelles et de longs historiques d'audit. Soda change cela en transformant les principes réglementaires en pratiques opérationnelles, automatisées et vérifiables — centralisées sur une seule plateforme et intégrées dans les flux de travail opérationnels existants.

En intégrant des vérifications et contrôles de qualité des données à chaque étape du cycle de vie des données de risque, Soda garantit que les données de risque sont démontrablement exactes, complètes, opportunes et conciliées.

Avec Soda, les G-SIBs peuvent :

  • Surveiller la qualité des données à grande échelle en termes d'exactitude, de complétude, d'opportunité et de conciliation.

  • Automatiser la conciliation inter-systèmes entre les systèmes comptables, de risque et de reporting.

  • Appliquer des contrats de données collaboratifs qui établissent des accords partagés de qualité des données entre producteurs et consommateurs.

  • Déplacer la gouvernance des données en amont en appliquant les politiques au point de production des données pour résoudre les problèmes avant qu'ils ne se propagent en aval.

  • Fournir des preuves prêtes pour l'audit avec des métadonnées complètes sur chaque résultat de vérification.

  • S'intégrer de manière bidirectionnelle avec les catalogues de données, transformant les règles de gouvernance documentées en contrôles applicables.

Principes BCBS 239 Opérationnalisés

Comment Soda met les principes en pratique.


Principes BCBS 239

Capacités de Soda

Conciliation des Données

Principe 3

  • Les données de risque doivent être conciliées avec les sources de la banque, y compris les données comptables lorsque cela est approprié, pour garantir que les données de risque sont exactes.


Principe 7

  • Exigences et processus définis pour concilier les rapports aux données de risque.

  • Les rapports doivent être conciliés et vérifiés.

  • Vérifications de Conciliation

    Confirmer que les données de risque restent cohérentes. Valider que les ensembles de données cibles s'alignent avec leurs ensembles de données sources.


  • Vérifications de Conciliation au Niveau des Lignes

    Valider les données enregistrements par enregistrements.


  • Vérifications de Conciliation au Niveau des Métadonnées

    Comparer les agrégats (totaux, moyennes, décomptes) entre les ensembles de données sources et cibles.

Validation des Données

Principe 7

  • Les superviseurs s'attendent à ce qu'une banque prenne en compte les exigences de précision basées sur les processus et résultats de validation, de test ou de conciliation.

  • Maintenir un inventaire de toutes les validations et vérifications, à la fois automatisées et manuelles, utilisées pour garantir que les données quantitatives sont exactes, avec une documentation claire de la logique derrière chacune.

  • Métriques de Validité

    Détecter les valeurs invalides ou inattendues au sein d'une colonne (par exemple, formats incorrects, entrées hors plage) avec une logique de validation configurable telle que des expressions régulières, des formats ou des listes de valeurs.


  • Contrats de Données

    Accords formels qui définissent ce que signifie des « bonnes données » et rendent ces attentes testables grâce à une validation automatisée.

Tests de Données

Principe 7

  • Les superviseurs s'attendent à ce qu'une banque prenne en compte les exigences de précision basées sur les processus et résultats de validation, de test ou de conciliation.

  • Vérifications de Conciliation, Vérifications de la Qualité des Données & Contrats de Données

    Définir les attentes, tester les données par rapport à celles-ci et assurer des résultats cohérents et fiables à travers les pipelines et les rapports.

Contrôles de Données

Principe 3

  • Les contrôles entourant les données de risque doivent être aussi robustes que ceux applicables aux données comptables.

  • Surveiller la précision des données et développer des canaux d'escalade et des plans d'action appropriés pour rectifier la mauvaise qualité des données.


Principe 4

  • Processus pour rectifier les problèmes de complétude.


Principe 5

  • L'agrégation des données de risque doit être opportune, tant dans des conditions normales que de stress.


Principe 7

  • Procédures intégrées pour identifier, signaler et expliquer les erreurs de données ou les faiblesses dans l'intégrité des données via des rapports d'exception.

  • Vérifications de Fraîcheur & Suivi des SLA

    S'assurer que les données ne sont pas plus anciennes que les seuils requis (par exemple, même jour, heure par heure) et que les pipelines respectent systématiquement les SLA de ponctualité. Les violations déclenchent automatiquement des alertes et une escalade, avec des pistes d'audit complètes pour la conformité.


  • Dépôt de Diagnostics

    Un enregistrement central auditable des vérifications échouées et des lignes, garantissant que les contrôles des données de risque sont aussi solides que les données comptables.


  • Incidents & Alertes

    Créer, assigner et suivre automatiquement les incidents à partir des vérifications échouées, avec des rapports et des intégrations (Slack, Teams, Jira) pour soutenir une escalade et une résolution rapides.


  • Intégration Bidirectionnelle de la Traçabilité des Données

    Transformer automatiquement les règles de gouvernance définies dans les catalogues de données en contrôles de qualité applicables.

Opérationnalisation du BCBS 239 en Pratique

Le tableau ci-dessus montre les capacités de Soda cartographiées vers chaque principe BCBS 239. En pratique, de nombreux contrôles couvrent plusieurs exigences.

Les contrats de données de Soda offrent une solution unifiante pour faire respecter les attentes en matière de qualité des données à travers les sources, les pipelines et les rapports. Un contrat de données définit ce à quoi ressemblent des « bonnes données » — couvrant l'exactitude, la complétude, l'opportunité et la validation des rapports — et rend ces attentes exécutables et vérifiables.

Les contrats peuvent être écrits sous forme de code pour les équipes d'ingénierie ou rédigés directement dans l'interface utilisateur de Soda, les rendant accessibles aux gestionnaires de risques, aux propriétaires de données et aux parties prenantes de la gouvernance.

Pour illustrer, voici deux exemples de contrats de données qui opérationnalisent les principaux principes BCBS 239 en pratique :

Exemple 1 : Conciliation des Expositions avec les Données Comptables

Ce que fait ce contrat de données :

  • Concilie les totaux des expositions avec les soldes comptables et déclenche des alertes si les écarts excèdent 1 000 €.

  • Valide que les codes LEI respectent le format requis de 20 caractères.

  • Signale les contreparties manquantes dans la liste maîtresse officielle.

Quels principes BCBS 239 cela affecte-t-il :

  • Exactitude & Intégrité (P3)

  • Complétude (P4)

  • Exactitude du Reporting (P7)

dataset: <datasource>/<db>/<schema>/exposures

checks:
  - failed_rows:
      name: counterparties_missing_in_exposures
      query: |
        SELECT m.counterparty_id
        FROM <datasource>/<db>/<schema>/counterparty_master m
        LEFT JOIN <datasource>/<db>/<schema>/exposures e
          ON e.counterparty_id = m.counterparty_id
        WHERE e.counterparty_id IS NULL
      threshold:
        must_be: 0
      attributes:
        bcbs239:
          - P4
        description: "Completeness: any counterparties 	
        	missing from exposures?"

columns:
  - name: lei_code
    data_type: string
    checks:
      - invalid:
          name: lei_code_format
          valid_format:
            name: LEI must be 20 alphanumeric
            regex: '^[A-Z0-9]{20}$'
          attributes:
            bcbs239:
              - P3
            description: LEI format is 20 uppercase alphanumerics

  - name: counterparty_id
    checks:
      - invalid:
          name: counterparty_id_in_master
          valid_reference_data:
            dataset: <datasource>/<db>/<schema>/counterparty_master
            column: counterparty_id
          attributes:
            bcbs239:
              - P3
            description: "Integrity: all counterparties in 
            	exposures exist in the master"

reconciliation:
  source:
    dataset: <datasource>/<db>/<schema>/accounting_balances
  checks:
    - metric_diff:
        name: total_exposures_vs_total_balance
        source_expression: SUM(balance_amount)
        target_expression: SUM(exposure_amount)
        threshold:
          must_be_less_than: 1000
        attributes:
          bcbs239:
            - P3
            - P7
          description: "Reconciliation vs accounting: 
          	Overall tolerance across the books (sum vs sum)"

Exemple 2 : Assurer l'Opportunité et l'Adaptabilité

Ce que fait ce contrat de données :

  • Surveille que les expositions quotidiennes sont livrées dans les 4 heures suivant la date de référence.

  • Assure que la latence du pipeline reste inférieure à 60 minutes.

  • Valide les IDs de scénario par rapport à la liste de référence approuvée, tandis que les variables permettent des fenêtres de temps flexibles pour des rapports ad hoc.

Quels principes BCBS 239 cela affecte-t-il :

  • Traite l'Opportunité (P5)

  • Adaptabilité (P6)

dataset: <datasource>/<db>/<schema>/agg_exposure_daily

filter: as_of_date BETWEEN ${var.START_TS} AND ${var.END_TS}
variables:
  BUSINESS_DATE:
    default: CURRENT_DATE()
  START_TS:
    default: DATEADD('day', -1, ${soda.NOW})
  END_TS:
    default: ${soda.NOW}

checks:
  - freshness:
      name: Timeliness
      column: as_of_date
      threshold:
        unit: hour
        must_be_less_than: 4
      attributes:
        bcbs239:
          - P5
        description: "SLA: max 4 hours old"

  - metric:
      name: pipeline_latency_minutes
      query: |
        SELECT DATEDIFF('minute', MIN(ingested_at), MAX(loaded_at))
        FROM <datasource>/<db>/<schema>/agg_exposure_daily
        WHERE CAST(as_of_date AS DATE) = ${var.BUSINESS_DATE}
      threshold:
        must_be_less_than: 60
      attributes:
        bcbs239:
          - P5
        description: "Pipeline latency < 60 minutes 
        	for the business day"

columns:
  - name: scenario_id
    data_type: string
    checks:
      - invalid:
          name: scenario_id_valid
          valid_reference_data:
            dataset: <datasource>/<db>/<schema>/ref_scenarios
            column: scenario_id
          attributes:
            bcbs239:
              - P6
            description

Obtenez une démonstration des contrats de données collaboratifs, voyez comment les créer dans l'interface utilisateur de Soda et apprenez comment ils peuvent opérationnaliser les principes BCBS 239 à grande échelle.

Être Toujours Prêt pour l'Audit

Soda équipe les principales banques mondiales des contrôles, des conciliations et des pistes de vérification pour démontrer une conformité continue.

Les grandes banques comptent sur Soda pour :

  • Prouver la conformité au BCBS 239 grâce à la qualité des données automatisée et à la conciliation.

  • Réduire le risque réglementaire avec une surveillance continue et la gestion des exceptions.

  • Simplifier les audits en générant des preuves et des enregistrements traçables à la demande.

  • Accélérer le changement avec des contrôles flexibles qui s'adaptent aux nouvelles demandes de supervision.

Rencontrez notre équipe d'experts et obtenez une démonstration de Soda pour la conformité BCBS 239.

Trusted by the world’s leading enterprises

Real stories from companies using Soda to keep their data reliable, accurate, and ready for action.

At the end of the day, we don’t want to be in there managing the checks, updating the checks, adding the checks. We just want to go and observe what’s happening, and that’s what Soda is enabling right now.

Sid Srivastava

Director of Data Governance, Quality and MLOps

Investing in data quality is key for cross-functional teams to make accurate, complete decisions with fewer risks and greater returns, using initiatives such as product thinking, data governance, and self-service platforms.

Mario Konschake

Director of Product-Data Platform

Soda has integrated seamlessly into our technology stack and given us the confidence to find, analyze, implement, and resolve data issues through a simple self-serve capability.

Sutaraj Dutta

Data Engineering Manager

Our goal was to deliver high-quality datasets in near real-time, ensuring dashboards reflect live data as it flows in. But beyond solving technical challenges, we wanted to spark a cultural shift - empowering the entire organization to make decisions grounded in accurate, timely data.

Gu Xie

Head of Data Engineering

4,4 sur 5

Commencez à faire confiance à vos données. Aujourd'hui.

Trouvez, comprenez et corrigez tout problème de qualité des données en quelques secondes.
Du niveau de la table au niveau des enregistrements.

Adopté par

Trusted by the world’s leading enterprises

Real stories from companies using Soda to keep their data reliable, accurate, and ready for action.

At the end of the day, we don’t want to be in there managing the checks, updating the checks, adding the checks. We just want to go and observe what’s happening, and that’s what Soda is enabling right now.

Sid Srivastava

Director of Data Governance, Quality and MLOps

Investing in data quality is key for cross-functional teams to make accurate, complete decisions with fewer risks and greater returns, using initiatives such as product thinking, data governance, and self-service platforms.

Mario Konschake

Director of Product-Data Platform

Soda has integrated seamlessly into our technology stack and given us the confidence to find, analyze, implement, and resolve data issues through a simple self-serve capability.

Sutaraj Dutta

Data Engineering Manager

Our goal was to deliver high-quality datasets in near real-time, ensuring dashboards reflect live data as it flows in. But beyond solving technical challenges, we wanted to spark a cultural shift - empowering the entire organization to make decisions grounded in accurate, timely data.

Gu Xie

Head of Data Engineering

4,4 sur 5

Commencez à faire confiance à vos données. Aujourd'hui.

Trouvez, comprenez et corrigez tout problème de qualité des données en quelques secondes.
Du niveau de la table au niveau des enregistrements.

Adopté par

Trusted by the world’s leading enterprises

Real stories from companies using Soda to keep their data reliable, accurate, and ready for action.

At the end of the day, we don’t want to be in there managing the checks, updating the checks, adding the checks. We just want to go and observe what’s happening, and that’s what Soda is enabling right now.

Sid Srivastava

Director of Data Governance, Quality and MLOps

Investing in data quality is key for cross-functional teams to make accurate, complete decisions with fewer risks and greater returns, using initiatives such as product thinking, data governance, and self-service platforms.

Mario Konschake

Director of Product-Data Platform

Soda has integrated seamlessly into our technology stack and given us the confidence to find, analyze, implement, and resolve data issues through a simple self-serve capability.

Sutaraj Dutta

Data Engineering Manager

Our goal was to deliver high-quality datasets in near real-time, ensuring dashboards reflect live data as it flows in. But beyond solving technical challenges, we wanted to spark a cultural shift - empowering the entire organization to make decisions grounded in accurate, timely data.

Gu Xie

Head of Data Engineering

4,4 sur 5

Commencez à faire confiance à vos données. Aujourd'hui.

Trouvez, comprenez et corrigez tout problème de qualité des données en quelques secondes.
Du niveau de la table au niveau des enregistrements.

Adopté par