Regulatory expectations may be driving banks to strengthen risk data aggregation and risk reporting (RDARR), but the benefits extend far beyond compliance. Banks that build clear ownership, trusted data lineage, and measurable data quality can turn a supervisory requirement into a strategic capability that creates lasting business value.
Across banks, the same data challenges keep surfacing in different forms again and again. The bank’s risk reporting function is preparing another set of disclosures under a requirement that did not exist three years ago. Its finance team is still reconciling two versions of the same figure by hand. Meanwhile, the board of directors is asking how the bank can make practical use of AI and whether the data foundation is ready for it.
These are just a couple of examples of challenges that depend on the same thing: the data underneath your reporting and whether anyone can say with confidence where it came from. That is what the Basel Committee on Banking Supervision’s Principles for Effective Risk Data Aggregation and Risk Reporting, commonly known as BCBS 239, seek to address. The implementation of these principles under the mandate of the European Central Bank (ECB) is what the industry has come to call risk data aggregation and risk reporting (RDARR).
What makes this development particularly interesting is that the work needed to satisfy a banking supervisor also enables a bank to answer management questions faster, keep reporting pipelines running without relying on those who built them, and respond to the next requirement at a fraction of what the last one cost. The Basel Committee has noticed the same thing from the other end: banks are increasingly using these principles as the basis for enterprise-wide data governance rather than as a risk reporting exercise [1].
BCBS 239 is the standard, RDARR is the capability
The BCBS 239 standard exists because of a specific failure. During the 2008 financial crisis, boards asked how much money their banks could lose if a given counterparty defaulted. At several large institutions, the honest answer was that it would take days to find out. The data existed, but it was spread across systems that had grown up separately, with different definitions and no reliable way to bring it together.
The Basel Committee responded in 2013 by publishing the principles for effective risk data aggregation and risk reporting [2]. In simple terms, the standard sets the objectives, whereas RDARR refers to the capabilities needed to achieve them.
You may have noticed that recent publications, particularly from the ECB, increasingly use the term RDARR rather than BCBS 239. If you have been wondering whether you missed a regulation, you did not. The principles have remained largely unchanged since 2013. What has changed is the detail of supervisory expectations around data governance, data quality, ownership, and lineage, and how much evidence supervisors now ask for. The requirement is not new, but the level of evidence banks must provide to demonstrate and maintain these capabilities is.
Why RDARR matters for small and mid-sized banks
The principles were originally written for global systemically important banks, with national supervisors expected to apply them proportionately to banks designated as systemically important at the domestic level. It is worth considering how these banks have progressed.
The Basel Committee’s latest assessment, covering 2022, found only two of the thirty-one banks it examined to be fully compliant with all the principles [4]. The ECB also reported that in the 2025 Supervisory Review and Evaluation Process (SREP) the average score for RDARR had not improved from the previous year [3]. Hence, this remains a problem that even the largest banks, with the largest budgets and a decade of supervisory attention, have not yet solved.
These expectations are no longer confined to the largest banks. The ECB now treats effective RDARR as a fundamental component of sound governance, strategic decision-making, crisis management, and operational resilience. Meanwhile, national supervisors use these priorities to inform their own proportionate supervision of smaller institutions [3].
For mid-sized banks, these expectations often become concrete through internal audit or statutory auditor findings, as they assess the bank against applicable regulatory and supervisory expectations. As a result, the key question is not whether you need a comprehensive large-scale implementation program. Rather, it is whether you are developing the ownership, quality, and lineage capabilities you will need anyway for future regulatory requirements, management decisions, and technology initiatives.
What a practical RDARR foundation looks like
A practical RDARR foundation starts with scope. A bank first needs to identify the business terms that materially drive its key risk, management, and regulatory reports, agree what those terms mean, and identify their underlying data elements.
In a mid-sized bank, that is usually a focused set of business terms and data elements, rather than thousands of items. Keeping the scope limited to this critical set is what makes the work finite and focused.
The foundation then rests on three capabilities:
- Ownership
- Lineage
- Data quality
For each capability, the questions are simple: what does it require in practice, what do we usually find, and what does good look like? According to our experience at ALM Partners, the following patterns come up in bank after bank.
Ownership
What does it require? A named person in the business who is accountable for each critical business term, its definition, the underlying data elements and the metrics built on it. Accountability starts with the business terminology: someone must own what a term means before anyone can own the data representing it.
What do we usually find? Ownership assigned to the data team, IT, or a working group. On paper, that looks organized. In practice, the owner sits somewhere the number is not produced, with no authority over the process producing it. Often, ownership covers the number but not what it represents, allowing the same term to carry different meanings across the bank. When a figure turns out to be wrong, the discussion shifts to whose problem it is rather than how to fix it.
What does good look like? Every critical business term and number has a named person who owns its meaning, notices when it is wrong, and has the authority to fix it. A simple test is this: is it clear what the number means and who owns its definition? If the number is wrong on a Tuesday morning, who notices and fixes it? If the answer to either question is a team name, you do not have an owner.
Lineage
What does it require? A documented path from source to report, showing where the number came from, how it was transformed, and which systems and controls it passed through. The documentation should be maintained for the data elements in scope and for nothing else.
What do we usually find? Two common problems. First, lineage mapped by hand to meet a deadline may be accurate on the day it was finished but quietly become misleading two years later because keeping it updated was never anyone’s responsibility. Second, a material part of the chain runs through spreadsheets built and maintained by one or two individuals. Everyone knows about the spreadsheets, yet no one has documented them, and the informal plan is to replace them eventually.
What does good look like? The chain from source to report is documented for the numbers that matter, and it remains accurate over time. To keep it that way, updating lineage is a required step whenever a system changes, and the material end-user tools in the chain are registered rather than tolerated. These tools are registered first and then gradually removed, one at a time. The chain also needs to be accessible and transparent to all data producers and users.
Data quality
What does it require? Quality is measured against defined thresholds rather than assumed, and there is a clear point at which a deviation becomes someone’s problem to fix.
What do we usually find? Quality is assumed rather than measured, so inconsistencies go unnoticed. The most common example is the same metric showing different numbers in different reports. Non-performing exposure, for example, is often defined slightly differently in the regulatory report, the board pack, and the credit committee material, because each was built at a different time by different people. Each version is defensible on its own. Together, they undermine confidence in all three.
What does good look like? One definition, one calculation, one owner, documented in a single place. Where a metric genuinely has to differ between two reports, the difference is documented and explained. An explained difference is not a problem. An unexplained one always is.
The three areas displayed in the figure above are often treated as three separate initiatives. However, they are strongly dependent on one another. Quality monitoring without lineage tells you that a number looks wrong but not where it broke. Lineage without ownership produces documentation that no one maintains. Ownership without either is only an organization chart.
That is why the most common false start is buying a data quality or lineage tool. A tool is the most tangible of the available options and the easiest to get approved, but it is the one that depends on the framework, responsibilities and processes across abovementioned areas which are needed to be defined first.
Advisory material on this subject often ends in a tooling recommendation. We recommend starting with ownership instead. It is the cheapest and least technical of the three. At the end of the day, ownership is what moves everything forward.
The value: lower cost, faster change, better technology
Looking beyond the regulation, RDARR produces one thing of lasting value: a data foundation that the whole bank can rely on, where the same figures mean the same thing everywhere and their origin can be explained.
That pays back in three ways, and only the first one is about compliance.
The cost of every new requirement falls. Without a documented data foundation, much of the work involved in meeting a new reporting requirement goes into locating the data, agreeing what each field means and confirming that the figures can be relied upon. This can take weeks and is often repeated in full because the previous findings were not documented.
With the foundation in place, a new requirement becomes an extension rather than a fresh start. The first requirement costs full price, while the fifth costs a fraction of that because the same work does not have to be done twice. The ECB supports this argument: high-quality data lowers operational and IT costs over time, while the cost of poor data quality is often underestimated because the resulting losses are rarely recorded [5].
Everything new becomes easier to build. New products, reporting capabilities, analyses, and services all sit on the same data. A clean, owned, and explainable data foundation is what makes them quick to build, because each one starts from something that already works rather than becoming a project of its own. This value rarely appears in a compliance business case and is often worth considerably more.
Technology becomes usable. AI and advanced automation cannot be adopted effectively on top of a fragmented data estate because the quality of outputs depends heavily on the quality of inputs.
The same is true for agentic workflows, which require clear lineage and a documented data foundation to work reliably. The Basel Committee makes exactly the same point about emerging technologies [1], and the ECB has noted that only a few banks are currently applying data management standards adapted to AI requirements [6]. If your board is asking about AI, this is the bill attached to the answer.
Where to start?
The right starting point for most banks is clarity rather than a large transformation program.
Start with four things:
- Identify the critical business definitions and their underlying data elements that drive key management, risk, and regulatory reports.
- Assign an owner to each one.
- Document the path from source to report.
- Test whether the bank can actually produce ad hoc information on request.
Be explicit about what is, and is not, in scope. The goal is to build a data foundation that can support future requirements without repeatedly starting from zero.
An external perspective can help determine what to prioritize, how much is enough, and where the effort will create the greatest long-term value.
How can ALM Partners help?
At ALM Partners, we work within banks’ risk, reporting, and data teams across the Nordics and Europe. This experience gives us insight into how different banks approach similar challenges and how to build the practical capabilities needed to make RDARR work.
We assess where a bank stands against BCBS 239, brief the executives whose support is needed, and implement the required components. This includes ownership models, risk metric rulebooks, documented lineage, and reconciliation. Each part can stand alone or run as one engagement, as we work through focused and proportionate initiatives.
The aim is to ensure that critical information is trusted and explainable when the next requirement arrives.
Looking ahead, how prepared is your bank to meet the expectations of BCBS 239 and RDARR in a way that adds value to the business?
If you are unsure where you stand, we are happy to talk it through.
Q&A Summary
What is the difference between BCBS 239 and RDARR?
BCBS 239 is the regulatory standard that defines principles for risk data aggregation and risk reporting. RDARR refers to the capabilities, processes, and governance needed to meet those principles in practice. Banking supervisors increasingly use the term RDARR, but the underlying principles have not changed since 2013.
What is at the core of an effective RDARR foundation?
The three key capabilities are ownership, lineage, and data quality. Together, they help ensure critical data is trusted, explainable, and consistently used across the organization.
Do we need to buy a data lineage or data quality tool?
Usually, not at first. A tool is the most tangible of the available options and the easiest to get approved, but it depends on the two things that should come before it: knowing which business terms and underlying data elements matter and who owns them. A tool bought before ownership tends to document the wrong things thoroughly.
What is the business case for RDARR beyond compliance?
While RDARR supports regulatory compliance, it lowers the cost of every subsequent requirement, because the work of locating data, agreeing definitions, and confirming reliability does not have to be repeated. A documented and trusted data foundation also makes it faster to build new products and reporting capabilities and is a precondition for AI and automation.
Sources
[1] Basel Committee on Banking Supervision (2026), Implementation of the Principles for Effective Risk Data Aggregation and Risk Reporting (BCBS 239 Principles) https://www.bis.org/publ/bcbs_nl36.htm
[2] Basel Committee on Banking Supervision (2013), Principles for Effective Risk Data Aggregation and Risk Reporting (BCBS 239)
https://www.bis.org/publ/bcbs239.pdf
[3] ECB Banking Supervision (2025), Supervisory Priorities 2026–2028
https://www.bankingsupervision.europa.eu/framework/priorities/html/ssm.supervisory_priorities202511.en.html
[4] Basel Committee on Banking Supervision (2023), Progress in Adopting the Principles for Effective Risk Data Aggregation and Risk Reporting
https://www.bis.org/bcbs/publ/d559.pdf
[5] European Central Bank (2024), Guide on Effective Risk Data Aggregation and Risk Reporting https://www.bankingsupervision.europa.eu/ecb/pub/pdf/ssm.supervisory_guides240503_riskreporting.en.pdf [6] ECB Banking Supervision (2025), Sound Risk Data Reporting: Key to Better Decision-Making and Resilience
https://www.bankingsupervision.europa.eu/press/supervisory-newsletters/newsletter/2025/html/ssm.nl250219.en.html
[6] ECB Banking Supervision (2025), Sound Risk Data Reporting: Key to Better Decision-Making and Resilience
https://www.bankingsupervision.europa.eu/press/supervisory-newsletters/newsletter/2025/html/ssm.nl250219.en.html
