BCBS 239 and the data that never made it into a system

BCBS 239 is the Basel Committee’s set of principles for risk data aggregation and risk reporting. Most of the attention goes to the big systems: the data warehouse, the risk engine, the reporting platform. This guide is about the data those systems depend on but do not own.

Background: What BCBS 239 is

BCBS 239 was published by the Basel Committee on Banking Supervision in January 2013. The full title is Principles for effective risk data aggregation and risk reporting. The number 239 is the Committee’s publication number.

The principles came out of the financial crisis that began in 2007. The Committee concluded that banks’ IT and data architectures were inadequate to support the management of financial risks. Many banks could not aggregate their risk exposures and identify concentrations quickly and accurately across the group, its business lines and its legal entities.

There are fourteen principles in four groups:

• Overarching governance and infrastructure (principles 1 and 2)
• Risk data aggregation capabilities (principles 3 to 6)
• Risk reporting practices (principles 7 to 11)
• Supervisory review, tools and cooperation (principles 12 to 14)

Global systemically important banks have had to meet the principles since January 2016. National supervisors are expected to apply them to domestic systemically important banks three years after designation. Other banks often use them as a benchmark for good risk data.

The data BCBS 239 quietly assumes is under control

Every risk report rests on a layer of business-maintained data. Account mappings that decide which ledger lines roll into which exposure class. Counterparty classifications. Reporting hierarchies. Limits and thresholds. Parameters that feed a calculation. Reference data such as industry codes and currencies, used by everyone and owned by no one.

None of this originates in a core system. The business creates it, maintains it, and changes it. In many institutions it lives in a spreadsheet on SharePoint, a table somebody in IT updates on request, or a hardcoded list inside an ETL job. BCBS 239 does not name this data separately. It applies to all risk data, and this data is part of it. In practice, it is often the least controlled part.

Four principles that land on this data

Of the fourteen principles, four go straight to the business-maintained layer.

Principle 2, data architecture and IT infrastructure. Banks should have integrated data taxonomies, with single identifiers and unified naming conventions for legal entities, counterparties, customers and accounts. Roles and responsibilities for the ownership and quality of risk data should be set for both the business and IT. A spreadsheet has an author, not an owner. When the person who built it leaves, so does the accountability.

Principle 3, accuracy and integrity. Risk data should be aggregated on a largely automated basis to minimise errors, and reconciled with the bank’s sources. Where a bank relies on manual processes and desktop applications such as spreadsheets, it should have effective mitigants in place. Manual edits in Excel with no validation are exactly what the principle asks banks to control.

Principle 5, timeliness. A bank should be able to produce aggregated, up-to-date risk data in a timely manner, including in times of stress. A change that waits in an IT queue is a change that is not in the report.

Principle 6, adaptability. A bank should be able to meet ad hoc requests, changing internal needs and supervisory queries. When a reporting structure changes, the data behind it has to follow quickly and consistently. If the change is made in one file and emailed around, some reports get it and some do not.

Underneath all four sits reconciliation. Principle 3 asks that risk data can be reconciled with its sources, and principle 7 asks that reports are reconciled and validated. In practice, that means being able to answer who changed a value, when, and from what. If the answer is “someone, in the file, probably last quarter”, reconciliation becomes guesswork.

What this looks like in practice

The pattern repeats across institutions we talk to.

• The business creates data in Excel because no system has a place for it. Excel becomes a system of record without ever being designed as one.
• Several people work in the same file, or make copies. Nobody can say which one is the master.
• There is no validation, no history and no rollback. A moved cell is found when a report is wrong, not when the cell moved.
• The data is needed downstream, in other files, reports and the warehouse, but Excel was never built to be integrated from.

These are not exotic failures. They are the default state of business-maintained data in most reporting chains.

Where Grunddata fits

The fix is not to move this data into the core systems. They were not built for it, and IT rarely has the budget or appetite to extend them. The fix is to give the data a home of its own, and to let the business keep maintaining it.

That is what Grunddata does. The business defines the tables it needs and maintains them in Excel, Google Sheets or the web app. Every save is validated against the rules the table defines, and recorded as a commit with author, timestamp and message. Every record keeps its full history. Downstream systems, reports and the warehouse read the same data through API and OData, so a change made once reaches everything that depends on it.

Mapped to the principles: ownership is explicit, because every table has an owner and every change has an author (principle 2). The spreadsheet becomes the interface, not the store, and validation runs at save time, which is the kind of control principle 3 asks for around spreadsheets. Downstream systems read the same version through the API, so a change reaches every report at once (principles 5 and 6). And every value can be traced back to the change that created it, which makes reconciliation possible (principles 3 and 7).

Responsibility for BCBS 239 stays with the bank. Grunddata supports the principles for the data you maintain in it.

Grunddata is not an MDM tool and does not replace one. Master data in the narrow sense, parties, products, organisation, sits in MDM or the core systems. Grunddata is for the layer next to it: the reference data and supplementary master data the business adds on top.

Where to start

Pick one report and one dataset it depends on that lives in a spreadsheet today. Bring it into a trial environment, let the team that maintains it keep working in Excel, and connect the report. Then ask the question the auditor will ask: who changed this, and when. If the answer is on screen, that dataset is no longer a gap in your reporting chain. Then take the next one.

Get in touch if you want to walk through your reporting chain and find where this data lives today.

Source

Basel Committee on Banking Supervision, Principles for effective risk data aggregation and risk reporting, January 2013.