Are spreadsheets doomed by RDARR? What the Guide really says
Excel has a poor reputation in regulatory literature — associated with calculation errors, undocumented macros, files circulating by email. The common assumption is that BCBS 239 and the ECB's RDARR Guide are ultimately trying to phase spreadsheets out of risk reporting processes. The reality, as clarified by the public consultation, is more nuanced.
What BCBS 239 says from 2013
Principle 3 (Accuracy and Integrity) does not ban spreadsheets — it governs them. Where a bank relies on manual processes and desktop applications (spreadsheets, databases) and has specific risk units that use these applications to develop their own tools, it must put in place effective mitigants — for example end-user computing policies and procedures — as well as other effective controls applied consistently across the bank's processes. (BCBS 239, Principle 3(b))
"Full integration": a term that needed clarifying
The 2024 RDARR Guide goes further, requiring the full integration of end-user computing (EUC) or end-user-developed applications (EUDA) — including an inventory of these applications — into data quality management policies and processes. (ECB Guide, section 3.5) The EBF and ESBG asked what "full integration" means in practice. The ECB's answer clarifies the intent: it means applying the same data quality standards and expectations (and associated controls) from a functional and logical standpoint — not technically migrating every spreadsheet into a central system. (ECB consultation feedback statement, May 2024 — Table 5, comment 22)
Must every spreadsheet be treated the same way? No
One legitimate concern was about the scale of the task: does full integration mean identical controls for every spreadsheet and every data interface? The ECB answers no — quality controls should be expected to focus on the points most exposed to the risk of being affected, directly or indirectly (side effects), based on technical and functional analysis and experience gained. In other words: a risk-based approach, not a uniform control. (ECB consultation feedback statement, May 2024 — Table 5, comment 25)
Can a spreadsheet with no impact be excluded from scope?
The German Banking Industry Committee asked whether a group could exclude EUC applications with no significant impact on the collection, processing or transformation of data in BCBS 239-related reporting processes — noting that these applications are not inherently linked to data quality, but are often used to facilitate or shorten processes through automation. The ECB's answer sets a clear criterion: whenever an EUC application changes data or metadata (or allows a manual change) that then feeds into other reporting or risk management processes within the scope defined by the institution (as set out in section 3.2), data quality may be affected — and that application must therefore be subject to quality controls and reconciliations. Exclusion is therefore not automatic: it depends on the actual downstream impact, not the nature of the tool. (ECB consultation feedback statement, May 2024 — Table 5, comment 25)
The ECB does not require spreadsheets to disappear
The most reassuring point in this entire exchange comes from a dialogue with Raiffeisen Bank International AG. This respondent views EUC as an important tool for fostering innovation within the bank, ahead of implementing durable solutions, and asked the ECB to confirm that a reduction in EUC would not be specifically mandated as long as its lifecycle is properly managed. The ECB's answer is clear: in the context of RDARR, a reduction in the number of EUC applications is not expected, according to the text of the Guide. Even for innovative risk data, models, tools or technologies used in prototyping or research and development projects, data quality remains just as relevant — and therefore subject to the same expectations. (ECB consultation feedback statement, May 2024 — Table 5, comment 24)
The term "EUC" itself comes from BCBS 239
AFME considered the definition of "end-user computing" too broad and asked for it to be clarified and its scope narrowed. The ECB did not give ground on this point: it recalls that the term "end user computing" is itself mentioned in BCBS 239 Principle 3, in the example of desktop applications. Not a 2024 invention, then, but the reuse of a concept already present in the founding text. (ECB consultation feedback statement, May 2024 — Table 5, comment 17)
Key takeaway
Neither BCBS 239 nor the RDARR Guide wages a war on Excel. What they target is the undocumented, uncontrolled spreadsheet that nobody knows might be altering critical data before it reaches a risk report. An inventoried spreadsheet, whose actual impact is assessed, and whose controls are proportionate to that actual risk rather than uniform, remains perfectly acceptable — the ECB goes as far as explicitly recognising it as a legitimate innovation tool, as long as its lifecycle is properly managed.
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).