Your risk data rules are written. With Soda, they get executed before every report.

BCBS 239 is the Basel Committee on Banking Supervision's Principles for effective risk data aggregation and risk reporting, published in January 2013. It sets 14 principles: 11 for banks, on governance and infrastructure, aggregating risk data and reporting it, and 3 for supervisors. It was written after the financial crisis that began in 2007 showed that many banks could not aggregate their risk exposures fully, quickly and accurately.

It is addressed first to systemically important banks. Banks named global systemically important banks (G-SIBs) in 2011 or 2012 had to meet the principles by January 2016, and banks named later have three years from their designation. The Basel Committee strongly suggests that national supervisors apply the principles to domestic systemically important banks three years after their designation, and supervisors may apply them to other banks in proportion to their size and complexity.

Governance and infrastructure: 1 Governance, 2 Data architecture and IT infrastructure. Risk data aggregation: 3 Accuracy and integrity, 4 Completeness, 5 Timeliness, 6 Adaptability. Risk reporting: 7 Accuracy, 8 Comprehensiveness, 9 Clarity and usefulness, 10 Frequency, 11 Distribution. Supervisory review: 12 Review, 13 Remedial actions and supervisory measures, 14 Home/host cooperation.

Few. In its November 2023 progress report, its latest, the Basel Committee found that of the 31 G-SIBs it assessed, only two were fully compliant with all the principles, and that no single principle had been fully implemented across all banks. In November 2025, the European Central Bank reported no improvement in the average risk data score of the banks it supervises, compared with the year before.

The European Central Bank uses the BCBS 239 principles as its benchmark when it assesses the banks it supervises directly. Its Guide on effective risk data aggregation and risk reporting, published in May 2024, names seven areas where it expects substantial progress. One is data quality: controls on accuracy and integrity, completeness and timeliness, automated where appropriate, periodic reconciliation, and a register of data quality issues with their remediation.

No. Compliance is your bank's, and most of the principles are decisions on governance, architecture and reporting. Soda covers the part that is tests on the data: accuracy and reconciliation (Principles 3 and 7), completeness (4) and timeliness (5). It runs those checks before each report, records every result, and tags each check with the principle it serves.

Not when you run Soda self-hosted. The runner executes every check inside your network, and the Diagnostics Warehouse keeps failed rows in your own warehouse. Soda Cloud receives metadata, aggregated check results and monitoring metrics: each check's name and logic, the dataset name, what the check measured and whether it passed. Showing samples of failed rows in Soda Cloud is a separate option, off by default. If you use Soda's hosted runner instead, the checks run from Soda's infrastructure.

The history of every run: each check, its result, when it ran and on which version of the data contract, and who proposed and who approved each change to a check. For checks that test single rows, and with the Diagnostics Warehouse turned on, failed rows are kept in your warehouse with their check, so a failure can be traced to the records behind it.

Yes. Soda publishes each check's result to Collibra, Alation, Atlan, Microsoft Purview or data.world, next to the dataset it tests, on a schedule. With Collibra it also brings owners, tags and business terms into Soda. Your team sets the integration up together with Soda.