Can a merger break your data architecture? What BCBS 239 says

Few events put a data architecture to the test like a merger or acquisition. Overnight, two systems, two taxonomies, two sets of customer identifiers must coexist — or merge. BCBS 239 does not treat this as a special case: it built it into the data architecture requirement itself back in 2013.

BCBS 239 Principle 2: an architecture built to withstand change

Principle 2 (Data architecture and IT infrastructure) requires a bank to design, build and maintain data architecture and IT infrastructure that fully support its risk data aggregation capabilities and risk reporting practices — not only in normal times, but also during periods of stress or crisis, while still meeting the other principles. The text goes further: risk data aggregation capabilities and reporting practices must be directly factored into the bank's business continuity planning processes and be subject to a business impact analysis. A bank must establish group-wide integrated data taxonomies and architecture, including information on data characteristics (metadata), as well as the use of unique identifiers and/or unified naming conventions for legal entities, counterparties, customers and accounts. (BCBS 239, Principle 2)

No need for a single data model — the footnote that changes everything

One point in the text, tucked away in a footnote, takes on particular importance in a merger context: banks do not necessarily need a single data model — but there must be robust, automated reconciliation procedures where multiple models are used in parallel. (BCBS 239, Principle 2, footnote 16) In practice: the acquired entity does not have to have its systems forced into the acquiring group's mould overnight — but the absence of reliable, automated reconciliation between the two is not an option.

Who is responsible, according to the 2024 RDARR Guide

The ECB's Guide makes this requirement much more operational by explicitly naming mergers and acquisitions as an RDARR vigilance trigger. In particular, the central data governance function must be involved in change management processes with a material impact on RDARR — among which the Guide explicitly lists mergers or acquisitions of significant legal entities, alongside the outsourcing of functions to third parties, the launch of new products or tools, and other IT change initiatives. (ECB Guide, section 3.3)

The independent validation function is no exception: it must carry out regular assessments covering every component of RDARR processes — IT infrastructure, data traceability, data taxonomy — including oversight of mergers and acquisitions, on the same footing as outsourced functions, IT change initiatives and new product launches. (ECB Guide, section 3.3)

Taxonomies and traceability: what must be reassessed at the time of a merger

The public consultation gave the ECB the opportunity to clarify a point that had remained implicit in the text of the Guide: in the event of a merger, how the data taxonomy is implemented, the data lineage itself, and any need to adjust the data architecture in the new entity arising from the consolidation must all be assessed during the consolidation process, with the necessary changes made accordingly — not after the fact, once integration is complete. (ECB consultation feedback statement, May 2024 — Table 5, comment 5)

Responsibilities that multiply, not dilute

Principle 2 also requires that roles and responsibilities for the ownership and quality of risk data be clearly established, for both business and IT functions. Owners (business and IT functions), in partnership with risk managers, must ensure adequate controls throughout the data lifecycle and across every aspect of the technology infrastructure — the business owner's role including ensuring that data is correctly entered by the relevant front office unit, kept up to date and aligned with data definitions. (BCBS 239, Principle 2) After a merger, this is not a requirement that eases up: it is a requirement that applies to a mechanically higher number of data entry points — hence the RDARR Guide's insistence on active governance and validation from the consolidation phase onward, rather than a clean-up after the fact.

Key takeaway

BCBS 239 has never treated mergers and acquisitions as an exceptional case that temporarily exempts a bank from its requirements: data architecture must withstand restructuring just as it must withstand periods of market stress. The 2024 RDARR Guide draws a clear organisational conclusion from this: both the data governance function and the independent validation function must be involved as soon as a merger or acquisition of a significant entity is under way — not only after the systems have already started to coexist.

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).