BCBS 239 principles and which banks they apply to

The financial crisis exposed gaps in group risk reporting

During the 2007-2008 financial crisis, some banks could not aggregate their exposures quickly enough to support decisions. The data existed, but fragmented systems made a reliable group view difficult to produce. In January 2013, the Basel Committee published its Principles for effective risk data aggregation and risk reporting, known as BCBS 239. Basel Committee, January 2013.

Consider an audit request about a figure in a risk report. Finding the DB2 table that feeds it only answers part of the question. The reviewer also needs to understand the transformations and confirm which exposures were included. The version of the process that produced the figure matters too.

The 14 BCBS 239 principles fall into four groups

The first eleven principles address banks. The final three address supervisors. They cover governance and infrastructure, data aggregation, risk reporting and supervisory review. BCBS 239, January 2013.

Governance and infrastructure

1. Governance. The board and senior management are accountable for the arrangements.
2. Data architecture and IT infrastructure. Systems should support aggregation and reporting in normal conditions and during a crisis.

Risk data aggregation

1. Accuracy and integrity. Produce reliable data, supported by reconciliation and appropriate automation.
2. Completeness. Capture all material exposures, including off-balance-sheet positions.
3. Timeliness. Produce sufficiently current data within the required timescales.
4. Adaptability. Respond to ad hoc requests, including those arising during a crisis.

Risk reporting

1. Accuracy. Reconcile and validate the data presented in reports.
2. Comprehensiveness. Cover material risks at a depth appropriate to the bank and its recipients.
3. Clarity and usefulness. Provide understandable information that supports decisions.
4. Frequency. Match reporting frequency to users’ needs and changes in risk.
5. Distribution. Deliver reports to the relevant recipients on time, while maintaining confidentiality.

Supervisory review

1. Review. Supervisors periodically assess banks’ implementation.
2. Remedial actions and supervisory measures. Supervisors have the means to require deficiencies to be addressed.
3. Home/host cooperation. Authorities coordinate their supervision of cross-border groups.

These descriptions summarise the principles. Assessments need to refer to the full text and the expectations of the relevant supervisor. BCBS 239, principles 1 to 14.

Which banks are in scope?

The original January 2016 deadline applied to global systemically important banks, or G-SIBs, identified in November 2011 or 2012. The text gives subsequently designated G-SIBs three years from designation.

The Committee also recommends that national supervisors apply the principles to domestic systemically important banks, or D-SIBs, three years after designation. National supervisors may extend their application to other banks, proportionately to the size, nature and complexity of their operations. That extension is a supervisory decision. BCBS 239, paragraphs 13 to 15.

Banks under ECB supervision

The ECB’s May 2024 guide sets out expectations for significant institutions under its direct supervision. It draws on BCBS 239 when assessing risk data aggregation and risk reporting, or RDARR, using a proportionate approach. ECB Guide on effective RDARR, sections 1 and 2.

UK banks and building societies

UK firms should assess their position against the PRA’s expectations and their own supervisory feedback. In its January 2026 priorities letter, the PRA asks UK banks and building societies to benchmark their practices against recognised standards, including BCBS 239 where relevant. PRA, UK Deposit Takers Supervision priorities for 2026.

A group operating in both jurisdictions should record the expectations relevant to each entity. Being outside the G-SIB population does not settle the question.

The programme scope also needs to be written down. It should identify the reports and entities covered, together with the critical data used in calculations. Risk and IT can then check that they are working to the same scope.

The 2023 progress report documented unfinished work

The Basel Committee’s November 2023 progress report found that significant work remained at most of the G-SIBs assessed. Fragmented systems and persistent manual processes were among the difficulties. Some programmes also lacked sufficient resources or attention from boards and senior management. These findings concern the assessed banks, rather than the banking sector as a whole. Basel Committee, 2023 progress report.

Consider a data catalogue maintained by hand. An application changes, but its documentation does not. Before answering an auditor, the team has to check which transformations still match the system. The lineage diagram from the last review may describe an earlier version.

Partial technology coverage can leave another gap. Suppose a database is mapped, but the Cobol programme feeding it is not. Someone must reconstruct that step before the calculation can be explained. If the answer stays in emails between teams, the next review may require the same investigation.

Where Risk, Finance and IT each hold part of the explanation, the review also needs their input. Dated documentation can establish which code was examined. Comparing it with production records helps identify what has actually been verified.

Data lineage helps document four principles

The ECB’s May 2024 guide expects complete and current lineage at data attribute level for the risk indicators and critical data elements within scope. ECB Guide on effective RDARR, section 3.4.

The examples below illustrate how lineage can support principles 2, 3, 4 and 6. They are hypothetical, rather than client case studies.

For architecture, trace a reported figure back to the code

Take a credit exposure figure in a risk committee report. Tracing it to source columns identifies the programmes that transform the data. A connection between two applications does not explain the calculation. Reviewers need to inspect how inputs become outputs.

For accuracy, inspect the transformation and check execution

Suppose a currency conversion is split across two Cobol programmes. Code analysis shows the transformations in the version examined. Explaining a published figure also requires checking the version that ran, its parameters and any manual adjustments.

The calculation still needs testing. Reconciliation between expected and actual results provides further evidence.

For completeness, compare the mapped sources with the expected population

A missing table may indicate an omission. Yet a lineage map only shows the sources it knows about. The identified flows must be compared with the exposures expected in the report. An unbroken path cannot establish that every relevant exposure has been included.

For adaptability, prepare an unfamiliar data request

A supervisor may ask for exposures grouped in a new way. Knowing the dependencies helps identify suitable columns and transformations that need changing. The response capability must then be tested by producing the result, checking its quality and measuring the time taken.

A declared link records business knowledge. A link found in code identifies a technical dependency. Comparing them helps expose discrepancies, which can then be checked against the process that ran.

Start the review with one reported figure

Choose a figure from a board risk report or regulatory return. Trace it to its source and inspect a transformation. Then check the version that ran and the control results. Include any manual adjustments made before submission or publication.

Vokse draws on 25 years of R&D in reverse engineering. It analyses existing code, including Cobol, JCL, Copybooks and DB2, to establish column-level lineage linked to business processes and reports. It distinguishes links found in code from declared links. Reviewers can open transformations down to the relevant lines of code and trace an anomaly through to the affected report. Vokse also provides continuous controls and auditor access.

These capabilities supply evidence for the review. To substantiate a reported figure, the bank must connect that evidence to the data used and the execution records. The product alone does not establish compliance.

The free BCBS 239 self-assessment takes three minutes and covers eight questions. Results are immediate, with no email required.

FAQ

What are the 14 BCBS 239 principles?

Governance, data architecture and IT infrastructure, accuracy and integrity, completeness, timeliness, adaptability, reporting accuracy, comprehensiveness, clarity and usefulness, frequency, distribution, review, remedial actions and supervisory measures, and home/host cooperation. Basel Committee, 2013.

Which banks does BCBS 239 apply to?

The framework directly addresses G-SIBs. The Committee also recommends application to D-SIBs three years after designation. National supervisors may extend its application to other banks on a proportionate basis. BCBS 239, paragraphs 13 to 15.

Is BCBS 239 mandatory?

Applicable obligations depend on the jurisdiction and supervisory measures. The ECB guide states that it introduces no new requirements. UK firms should consider PRA expectations, including its 2026 call to benchmark against BCBS 239 where relevant. ECB Guide, PRA 2026 priorities.

What is the difference between BCBS 239 and RDARR?

BCBS 239 refers to the Basel Committee’s fourteen principles. RDARR stands for Risk Data Aggregation and Risk Reporting. The ECB’s May 2024 guide sets out supervisory expectations in this area. ECB Guide on effective RDARR.