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.

Schedule a Demo

BCBS 239 Principles Operationalized

How Soda puts principles into practice.

	BCBS 239 Principles	Soda Capabilities
Data Reconciliation	Principle 3 Risk data should be reconciled with the bank’s sources, including accounting data where appropriate, to ensure that the risk data is accurate. Principle 7 Defined requirements and processes to reconcile reports to risk data. Reports should be reconciled and validated.	Reconciliation Checks Confirm that risk data remains consistent. Validate that target datasets align with their source datasets. Row-level Reconciliation Checks Validate data record by record. Metric-level Reconciliation Checks Compare aggregates (totals, averages, counts) between source and target datasets.
Data Validation	Principle 7 Expect a bank to consider precision requirements based on validation, testing or reconciliation processes and results. Maintain an inventory of all validations and checks, both automated and manual, used to ensure quantitative data is accurate, with clear documentation of the logic behind each.	Validity Metrics Detect invalid or unexpected values within a column (e.g., wrong formats, out-of-range entries) with configurable validation logic such as regex, formats, or value lists. Data Contracts Formal agreements that define what “good data” means and make those expectations testable through automated validation.
Data Testing	Principle 7 Supervisors expect a bank to consider precision requirements based on validation, testing or reconciliation processes and results.	Reconciliation Checks, Data Quality Checks & Data Contracts Define expectations, test data against them, and ensure consistent, trustworthy results across pipelines and reports.
Data Controls	Principle 3 Controls surrounding risk data should be as robust as those applicable to accounting data. Monitor the accuracy of data and develop appropriate escalation channels and action plans to rectify poor data quality. Principle 4 Process to rectify completeness issues. Principle 5 Risk data aggregation should be timely, both under normal and stress conditions. Principle 7 Integrated procedures for identifying, reporting, and explaining data errors or weaknesses in data integrity via exceptions reports.	Freshness Checks & SLA Monitoring Ensure data is no older than required thresholds (e.g., same-day, hourly) and that pipelines consistently meet timeliness SLAs. Breaches automatically trigger alerts and escalation, with full audit trails for compliance. Diagnostics Warehouse Central, auditable record of failed checks and rows, ensuring risk data controls are as strong as accounting data. Incidents & Alerts Automatically create, assign, and track incidents from failed checks, with reporting and integrations (Slack, Teams, Jira) to support timely escalation and resolution. Bi-directional Data Lineage Integration Automatically turn governance rules set in data catalogs into actionable, enforceable quality checks.

Schedule a Demo

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: Adaptability via reference data

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.

Schedule a Demo

Closing The BCBS 239 Data Quality Gap

Trusted by leading global financial services institutions:

The BCBS 239 Data Quality Gap

How Soda Closes This Gap

BCBS 239 Principles Operationalized

Principle 3

Principle 7

Principle 7

Principle 7

Principle 3

Principle 4

Principle 5

Principle 7

Operationalization of BCBS 239 in Practice

Example 1: Reconciling Exposures with Accounting Data

Example 2: Ensuring Timeliness and Adaptability

Be Audit-Ready, Always.

Closing The BCBS 239 Data Quality Gap

Trusted by leading global financial services institutions:

The BCBS 239 Data Quality Gap

How Soda Closes This Gap

BCBS 239 Principles Operationalized

Principle 3

Principle 7

Principle 7

Principle 7

Principle 3

Principle 4

Principle 5

Principle 7

Operationalization of BCBS 239 in Practice

Example 1: Reconciling Exposures with Accounting Data

Example 2: Ensuring Timeliness and Adaptability

Be Audit-Ready, Always.

Sign Up

Stay Connected