Templates

BCBS 239

Data Contract Template

Ensure accounting data is complete, consistent, and reconcilable to support BCBS 239-compliant risk reporting.

Data contract description

This data contract enforces key BCBS 239–aligned controls on the exposures dataset by reconciling total exposure amounts with accounting balances within a defined tolerance, validating the format of Legal Entity Identifiers (LEIs), and ensuring referential integrity with the official counterparty master. It proactively flags missing or inconsistent counterparties and material reconciliation differences between risk and finance data, helping ensure exposure reporting is complete, accurate, and consistent across systems used for regulatory, risk, and financial reporting.

Dataset

Defines the dataset this contract applies to, including its source and scope. This is the single point of reference for what data is being validated and protected.

Dataset checks

Validations that apply to the dataset as a whole, including schema stability and systemic completeness controls. This contract includes a schema check to detect unexpected changes to the exposures structure early. It also includes a completeness control that identifies any counterparties present in the counterparty master but missing from exposures, ensuring population coverage and reducing reporting gaps that can undermine risk aggregation.

Column checks

Column-level rules to ensure completeness and validity of critical identifiers used for aggregation and reporting. This contract enforces that lei_code and counterparty_id are not missing, validates the LEI format, and verifies that every counterparty_id in exposures exists in the counterparty master via a reference data check. These controls support BCBS 239 principles by improving data integrity, preventing broken joins across reference/master data, and ensuring consistent identification of counterparties across risk and finance.

bcbs239_data_contract.yml

dataset

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) 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)"

Data contract description

Dataset

Defines the dataset this contract applies to, including its source and scope. This is the single point of reference for what data is being validated and protected.

Dataset checks

Column checks

bcbs239_data_contract.yml

dataset

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) 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)"

Data contract description

bcbs239_data_contract.yml

dataset

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) 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)"

How to Enforce Data Contracts with Soda

Embed data quality through data contracts at any point in your pipeline.

# pip install soda-{data source} for other data sources

pip install soda-postgress

# verify the contract locally against a data source

soda contract verify -c contract.yml -ds ds_config.yml

# publish and schedule the contract with Soda Cloud

soda contract publish -c contract.yml -sc sc_config.yml

Check out the CLI documentation to learn more.

How to Automatically Create Data Contracts.
In one Click.

Automatically write and publish data contracts using Soda's AI-powered data contract copilot.

Make data contracts work in production

Business knows what good data looks like. Engineering knows how to deliver it at scale. Soda unites both, turning governance expectations into executable contracts.

Make data contracts work in production

Business knows what good data looks like. Engineering knows how to deliver it at scale. Soda unites both, turning governance expectations into executable contracts.

Make data contracts work in production

Business knows what good data looks like. Engineering knows how to deliver it at scale. Soda unites both, turning governance expectations into executable contracts.

Book a demo