BIRD and IReF - Towards an Integrated Reporting System
Photo by Sergio. R. Ortiz auf Unsplash.com, Download am 13.6.22
Current development
Both the ECB (European Central Bank) and the EBA (European Banking Authority) are currently working in parallel on the topic of an integrated reporting system. This shall allow financial institutions to provide comparable, uniform and redundancy-free data in the form of individual data records and reporting formats within the framework of supervisory, resolution and statistical reporting requirements. In addition to a general overview of the topic in this article, we also explain the application using specific examples.
The EBA describes the goal of an integrated reporting system as simplifying and standardising the reporting process for both sides, i.e. the institutions and the supervisory authorities, so that the workload on both sides can be reduced and the data consistency between institutions is going to be increased. The basis for this is a uniform "language" for regulatory reporting: the BIRD (Banks' Integrated Reporting System) approach (see below). The current state of regulatory reporting is summarised by the EBA as follows, citing negative developments in recent years:
- Different European reporting approaches for different data collection purposes (reports, resolution, statistics);
- Different national data requests;
- Different ad hoc requests from individual supervisory authorities in the respective reporting frameworks;
- Decentralised approach of functional definitions and data collection within the EU.
The core idea of the integrated reporting approach is: data is defined only once and reported only once.
Figure 1 illustrates this approach of the EBA by contrasting the current reporting process with the target picture:
Figure 1: Reporting process in the current and in the target picture
The EBA is currently examining possible options for the design of this integrated reporting approach with the involvement of market participants, assessing advantages and disadvantages as well as their effects.
In essence, three fields of action have been identified:
1. establishment of a uniform data dictionary (see BIRD);
2. placement of a central data reporting point for all institutions and supervisory authorities; and
3. optimisation of the coordination process between supervisory authorities in order to standardise the data collection process.
In a cost-benefit analysis (as of 12/2021), the ECB and ESCB (European System of Central Banks) also address essential technical aspects in addition to aggregated quality assessments and thus already concretise the above-mentioned goals, as can be seen in the following list by way of example:
1. extension to the reporting of loans below the limit of 25,000 EUR;
2. collection of securities investment data of securities without ISINs;
3. baseline scenario on certain single transaction information to be reported by financial institutions without redundancy (see BIRD);
4. baseline scenario on the submission of reports by sectors in the euro area no longer directly via the sector, but at the level of the legal entity/parent institution.
To this end, the ECB is examining the possible positive effects on institutions and supervisors by sharing these proposals and inviting them to engage in a dialogue. The basis for this is Art. 430c of the CRR2.
Against this background of ECB and EBA activities, the implementation of the IReF (Integrated Reporting Framework) reporting, which covers statistical reporting, using the BIRD methodology is expected to last until the end of 2027. The immediate next step is to create an IReF regulatory framework, which will then be discussed publicly. After the IReF regulatory framework is going to be finalised, the corresponding reporting is expected to be implemented from 2024 onwards. Figure 2 summarises the current timeline.
Figure 2: Schedule and next steps on BIRD and IReF
Structure of BIRD and use of the SMCube
BIRD forms the basis for harmonising the reporting system. The BIRD methodology comprises the BIRD process, which explains the intended working method from data input to data output (end-to-end). This process includes the BIRD components, which make up the data structures and the connection components. The following figure shows the basic components:
Figure 3: BIRD process and methodology
As illustrated in figure 3, the two levels of the BIRD process are the logical level and the technical level.
The logical level includes the Logical Data Model (LDM) and the Enriched Logical Data Model (ELDM). These data models are normalised entity relationship models (ERM), which means that they are in the form of database entities with a table structure, divided into attributes and connected in several relations according to predefined normalisation rules.
The LDM is the basis for generating the BIRD layers and financial institutions can use the data model to design their own physical implementations or visualise logical dependencies. Derived from the data of the LDM, the ELDM is generated. Here, mainly business concepts are applied, such as the classification of a company size, which consists of the number of employees and the annual turnover as well as the balance sheet.
The technical layer includes the Input Layer (IL), the Enriched Input Layer (EIL), the Reference Output Layer (ROL) and the Non-Reference Output Layer (NROL). The BIRD layers are the data structure components that describe the steps from input to output and are built based on the SMCube (Single Multidimensional Metadata Model) (see below for an explanation of the SMCube). Just like LDM and ELDM (logical level), IL and EIL (technical level) also represent entity-relationship models, but they are less normalised. In addition, the content of the LDM is the same as that of the IL and that of the ELDM is the same as that of the EIL.
The data structures of the IL and the EIL have fewer entities than the LDM and the ELD, respectively, which is a good feature for an interface to connect the internal IT systems of financial institutions. It could be the starting point for the technical implementation of the BIRD.
Both the ROL and the NROL describe the reporting data, e.g. for AnaCredit. However, in the ROL, the regulatory reporting requirements are described using "reference codes" derived from the BIRD lexicon. The same is described in the NROL, but with the use of "non-reference codes" from the EBA DPM (Data Point Model). The "reference codes" are used as a uniform language by all BIRD layers except the NROL. The NROL uses the concepts and codes that are adapted according to the respective regulatory reporting requirements. The different NROLs are always generated from one ROL, which ensures that the BIRD layers are semantically integrated.
The connection components have the task of using logical and semantic transformation rules as well as mappings ("forward engineering") to create a connection between the two layers and link the BIRD layers together. In addition, there are further validation components such as business and structural validation rules, which ensure the consistency, integrity, and quality of the data.
Figure 4: BIRD components
Each BIRD layer is built with the SMCube Information Model, which means that the data is built in the form of tables with rows and columns, structured as multidimensional cubes. The SMCube can have more than three dimensions.
Figure 5: Visualisation of the SMCube
In order to gain a deeper insight into the SMCube methodology, an example will be used to explain how it is structured. In the example, it is assumed that a financial institution uses the SMCube methodology and wants to enter data records in a table for the collateral of certain financial instruments, which could look as follows:
Figure 6: SMCube data example
According to the SMCube methodology, the columns of the tables are called variables and are defined independently of the cube. This has the advantage that variables are defined once and can be contained in several cubes. Each variable is defined in a domain that specifies the allowed values of the variable. Domains can be enumerations if they have a list of allowed values. If domains have a data type, they are defined as non-enumerations. Examples of non-enumerations would be "ISIN" (String Domain), "Contract Start Date" (Date Domain) or "Fair Value" (Monetary Domain). Enumerations include, for example, "Type of collateral" because this information is based on a list of predefined values. However, a variable can have different allowed records. For example, the list of the variable "type of security" could also increase if the number of financial instruments were to increase. The same is true for variables defined as non-enumerations. In the context of collateral, one would only allow positive values in the variable "fair value".
A relevant aspect in the structure of the data set is the identifier of the data set. This can be unique, which in the case of the variable "ISIN" would mean that only one record may have a special ISIN code. However, if there are multiple currencies in the collateral context, the same "ISIN" may appear several times with different currencies.
According to the SMCube methodology, the variables that act as identifiers take a dimension role. Assuming that "ISIN" is the only variable with a dimension role, the remaining variables would be assigned a different role depending on which variables they add information to. If "Currency" is to be assigned a role, there are two possible interpretations: The variable "Currency" adds information to the variable "ISIN", which has a dimension role, and would therefore take the observation value role. Variables that only add information to a variable - not a dimension - take the attribute role. In addition, a variable can take different roles in different data sets.
The objective of BIRD is to unify statistical and supervisory requirements such as AnaCredit, Securities Holdings Statistics (SHS), Balance Sheet Items (BSI) and Monetary Financial Institutions Interest Rate Statistics (MIR). Banks always face the challenge of having to comply with different reporting requirements for each regulatory report and having to provide the same information for different reports. The figure below shows this problem as an example for the information on collateral in SHS and Centralised Securities Database (CSDB). The column names of the reports differ and are available in different formats. For example, two columns are required for the ISIN in the SHS report and the information is only entered in one column in the CSDB report. This procedure is redundant and leads to additional time expenditure.
Figure 7: Data example without semantic integration
The next figure shows what the future situation of the banks with regard to the processed reported financial data records could look like using the example of SHS and CSDB within the framework of BIRD and the underlying SMCube methodology. The data is semantically integrated with the reference code of the BIRD approach. The column names are now the same for both reports. It can be clearly seen that one has a unified data basis for different reports without loss of information and therefore the information does not have to be searched for and entered anew for another report.
Figure 8: Data example with semantic integration
Challenges
Financial institutions, alongside supervisors, are facing significant changes in terms of their reporting processes. For years, it has been noticeable that banks and supervisors have been working with, collecting, evaluating and analysing increasingly redundant and inconsistent data. Different reporting requirements refer to similar or identical data collections. Each institution reports the supposedly same data requirement with partly different interpretations and conventions. Supervisory authorities receive innumerable, meanwhile quite complex reporting schemes and search for the information relevant to them with considerable effort. Institutions report more and more and increasingly complex reporting templates over time and try to maintain consistency in their data with the help of cross-validations. Reconciliation calculations reveal differences in the respective reporting frameworks that are costly to rectify.
With the development towards an integrated reporting system and a uniform and coordinated reporting process, these current undesirable developments could be remedied. This requires above all that the financial institutions tackle the planned standardisation of the data models and revise their reporting data semantically, syntactically and infrastructurally within the framework of BIRD on the basis of the specifications in order to provide the relevant reporting data to the supervisory authorities in such a way that reports can be created by authorities in a redundancy-free, uniform and consistent manner.
Achieve your target with Finbridge
Finbridge is happy to support you in implementing the requirements for the BIRD data model and on the way to an integrated reporting framework. Our experts have worked for the Bundesbank, the SRB (Single Resolution Board) and reporting software providers. They are active in the market in preliminary studies and implementation projects in the context of the introduction of data models and data warehouses as well as in supervisory law, statistical reporting and resolution planning with many years of experience and can provide you with value-added support in all these challenges with their sound experience and knowledge. Due to our comprehensive expertise in overall bank management, coupled with extensive implementation-oriented practical experience in all aspects of regulatory reporting, we can flexibly respond to your wishes and institution-specific requirements and accompany you until the expectations of the supervisory authorities are met.
Do you have questions about the functional and technical changes in detail? Our Finbridge experts will be happy to assist you with their professional know-how in planning and implementation.
