Who does what? Data owner, data producer and delegation by the management body

Among the 308 comments received by the ECB during the public consultation on its RDARR Guide, two questions come up with particular insistence: who, very concretely, is the "data owner"? And can the management body delegate its RDARR responsibilities without being relieved of them? The feedback statement, published by the ECB alongside the final version of the Guide, answers both in a level of detail absent from the final text itself.

"Data owner": a function, not someone at the top

Several banking federations (EBF, EACB, DZ BANK, among others) asked the ECB to clarify exactly what it means by "data owner" — a central term in the Guide, particularly in its section 3.3 on the data governance framework. The ECB's answer is unambiguous: the data owner, as understood by the Guide, is the function responsible for entering information into the bank's IT system, while the data producer is the employee who actually performs that entry. The data owner is normally situated within the function responsible for capturing data in front-end systems — and should not be positioned too high up in the organisation. (ECB consultation feedback statement, May 2024 — Table 4, comments 7 and 9)

This clarification is not trivial: several respondents worried that a data owner defined too broadly would end up bearing an untenable responsibility for an entire "end-to-end" process. The ECB explains why it keeps responsibility as close to the source as possible: if data corrections are pushed up to roles that do not themselves capture the information in the systems, errors end up being fixed further down the chain rather than at the source — requiring recurring manual interventions, precisely what the Guide seeks to eliminate. (ECB consultation feedback statement, May 2024 — Table 4, comment 7)

The case of derived data

One respondent raised a concrete case: is the person who calculates a final indicator such as value-at-risk (VaR) responsible for data quality from the recording of the transaction all the way to the VaR calculation? The ECB answers no. Where data is recalculated and then stored — "derived data" — the function responsible for the calculation becomes the owner of that new stored information, but not of the underlying data used for the calculation. Different data owners, each focused on one section of the chain, therefore have their own responsibility for the data they capture or generate — the whole held together by service-level agreements between data owners, and between data owners and data users, which define the quality requirements at each stage. (ECB consultation feedback statement, May 2024 — Table 4, comment 9)

"Data steward": a term ultimately dropped

The draft Guide used the term "data steward" in places, as an alternative. One respondent (EBF) suggested a finer split: the data owner would define the data, its use, and the quality requirements per use; the data steward would operationally drive data quality within their scope. The ECB's response goes the other way: it does not intend to define further roles and responsibilities in the Guide — as a result, the term "data steward" was removed from the final version. (ECB consultation feedback statement, May 2024 — Table 4, comment 14 — amendment made)

The term "key risk data", considered a source of confusion with plain "risk data", met the same fate and was also removed from the final version. (ECB consultation feedback statement, May 2024 — Table 4, comment 3 — amendment made)

Who classifies data as "critical"?

Another disputed point: the Guide places the data owner at the centre of the classification of critical data — an approach one respondent (EBF) considered questionable given the diversity of possible uses of the same data within a large bank. The ECB clarifies its position: the Guide refers to a "contribution" from the data owner, meaning that the data owner, as the party primarily responsible for data quality, must be involved and informed — without ruling out a potentially broader role for data users or the data governance unit. When classifying data, data owners must therefore ensure alignment with other relevant stakeholders, such as data users or report owners. (ECB consultation feedback statement, May 2024 — Table 4, comment 11 — amendment made)

The management body: a responsibility that cannot be fully delegated

The second major point of friction concerns the management body's room for manoeuvre. The Guide (section 3.1) asks the management body to select at least one of its members to bear responsibility for RDARR. Several respondents (ESBG, UniCredit Spa) feared that individual responsibility assigned to one or two members would harm the overall view and artificially fragment a responsibility that should remain collective, while unduly limiting banks' ability to organise themselves as they see fit.

The ECB maintains its position, but explains it in detail: BCBS 239 is a topic that concerns the bank as a whole and implies collective responsibility on the part of the management body. Designating one or two specific members of the management body, in its management function, facilitates implementation in practice and ensures that sufficient attention is paid to data governance at management body level. Appointing the Chief Risk Officer (CRO) — alone or together with the Chief Financial Officer (CFO) — is presented as a pragmatic solution when that appointment is made at management body level. Where it is not possible to appoint a member of the management body in its management function, one or two senior managers may be designated, provided they have a direct reporting line to, and access to, the management body in its management function. (ECB consultation feedback statement, May 2024 — Table 2, comment 4 — amendment made)

The most important point, however, is this: whatever solution is chosen, this delegation in no way relieves the management body of its collective responsibility. In line with general governance principles, the effectiveness of an institution's internal data governance framework must continue to be subject to periodic, independent assessment. (ECB consultation feedback statement, May 2024 — Table 2, comment 4)

And delegation to committees?

A related question concerned delegation to board committees (a risk committee, for example) rather than to individual members. The ECB answers that this is a matter of general governance, not specific to RDARR, and that delegation to committees is in principle considered adequate: committees are meant to support and advise the management body on specific areas, and to facilitate the development of sound governance arrangements. Institutions simply need to ensure a clear division of tasks between specialised committees, with well-defined, consistent and documented reporting lines and allocation of responsibilities. Here too, the ECB restates the limit: delegating to committees in no way releases the management body, in its supervisory function, from its obligation to collectively fulfil its duties and responsibilities. (ECB consultation feedback statement, May 2024 — Table 2, comment 5)

What these clarifications actually change

None of these clarifications changes the architecture of the Guide as described across its 7 sections. But for an institution building or adjusting its RDARR framework, they answer very concrete questions that the final text, on its own, does not explicitly settle: where does a data owner's responsibility end for data recalculated downstream? Can a senior manager be appointed instead of a board member? Is delegation to a committee sufficient? On these specific points, the consultation feedback statement is the most authoritative source after the Guide itself — since it documents the ECB's position at the very moment it was decided.

This article is based on three documents: the Basel Committee's 14 BCBS 239 principles (January 2013), the ECB's RDARR Guide (May 2024), and the ECB's feedback statement on the RDARR Guide's public consultation (May 2024).