Using Soda, large banks turn governance policies into automated, actionable controls that can be seamlessly embedded into existing workflows.

The BCBS 239 Data Quality Gap

BCBS 239 sets strict principles for risk data aggregation and reporting, requiring banks to prove that data is accurate, complete, timely, adaptable, and reconciled across systems and reports.

The regulation applies to all Global Systemically Important Banks (G-SIBs) and, in many jurisdictions, has been extended to Domestic Systemically Important Banks (D-SIBs).

Yet more than a decade after the regulation took effect, supervisors continue to flag weaknesses in data quality, reconciliation, and governance. Fewer than 10% of G-SIBs are fully compliant. The stakes are high: supervisory pressure, potential capital surcharges, and reputational damage.

The gap isn’t about awareness of the principles — it’s about operationalizing them. Compliance isn’t a one-time milestone but a continuous discipline that banks must demonstrate every day, with evidence.

How Soda Closes This Gap

Traditionally, BCBS 239 compliance has meant fragmented controls, manual checks, and long audit trails. Soda changes this by turning regulatory principles into operational, automated, and auditable practices — centralized in one platform and tied into existing operational workflows.

By embedding data quality checks and controls into every step of the risk data lifecycle, Soda ensures that risk data is demonstrably accurate, complete, timely, and reconciled.

With Soda, G-SIBs can:

• Monitor data quality at scale across accuracy, completeness, timeliness, and reconciliation.

• Automate cross-system reconciliation between accounting, risk, and reporting systems.

• Enforce collaborative data contracts that establish shared data quality agreements between producers and consumers.

• Shift data governance left by enforcing policies at the point of data production to resolve issues before they flow downstream.

• Provide audit-ready evidence with complete metadata on every check result.

• Integrate bi-directionally with data catalogs, turning documented governance rules into enforceable controls.

BCBS 239 Principles Operationalized

How Soda puts principles into practice.

Operationalization of BCBS 239 in Practice

The table above shows Soda capabilities mapped to each BCBS 239 principle. In practice, many controls span multiple requirements.

Soda's data contracts provide a unifying way to enforce data quality expectations across sources, pipelines, and reports. A data contract defines what “good data” looks like—covering accuracy, completeness, timeliness, and reporting validation—and makes those expectations executable and auditable.

Contracts can be written as code for engineering teams or authored directly in Soda’s UI, making them accessible to risk managers, data owners, and governance stakeholders.

To illustrate, here are two examples of data contracts that operationalize key BCBS 239 principles in practice:

Example 1: Reconciling Exposures with Accounting Data

What this data contract does:

• Reconciles exposure totals with accounting balances and raises alerts if discrepancies exceed €1,000

• Validates that LEI codes follow the required 20-character format

• Flags counterparties missing from the official master list

Which BCBS 239 principles does it affect:

• Accuracy & Integrity (P3)

• Completeness (P4)

• Reporting Accuracy (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)"

Example 2: Ensuring Timeliness and Adaptability

What this data contract does:

• Monitors that daily exposures are delivered within 4 hours of the reference date.

• Ensures pipeline latency stays below 60 minutes.

• Validates scenario IDs against the approved reference list, while variables allow flexible time windows for ad-hoc reporting.

Which BCBS 239 principles does it affect:

• Addresses Timeliness (P5)

• Adaptability (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

Get a demo of collaborative data contracts, see how to create them in Soda's UI, and learn how they can operationalize BCBS 239 principles at scale.

Be Audit-Ready, Always

Soda equips the world's leading banks with the controls, reconciliations, and audit trails to demonstrate continuous compliance.

Large banks rely on Soda to:

• Prove compliance with BCBS 239 through automated data quality and reconciliation.

• Reduce regulatory risk with continuous monitoring and exception management.

• Simplify audits by generating evidence and traceable records on demand.

• Accelerate change with flexible controls that adapt to new supervisory requests.

Meet our team of experts and get a demo of Soda for BCBS 239 compliance.