BIRD Methodology

Overview

The BIRD is an integrated dictionary for banks, which includes step-by-step descriptions on how, from a redundancy-free input, multiple outputs can be created to meet regulatory reporting requirements (i.e. statistical, prudential, and resolution).

The BIRD methodology provides the basis for understanding the end-to-end BIRD process and its components. It consists of:

• The BIRD process (i.e. the workflow showing how the BIRD is designed to function)
• The BIRD components (e.g. data structures and connecting components)

Technical, explanatory, and documenting material is provided to help users understand and use the BIRD.

BIRD process

The BIRD process describes the envisaged workflow from input to output and consists of data structure components (i.e. blue boxes) that are linked to each other via connecting components (i.e. yellow arrows). Please see Figure 1.

Data structure components are called BIRD layers, e.g. the (Enriched) Logical Data Model and the Input Layer. They describe the various steps from input to output.

Connecting components are the forward engineering, logical/semantic transformation rules, and mappings. They define procedures and methods that allow elements to be linked across BIRD layers along the overall process.

Additionally, validating components are business and structural validation rules that ensure the consistency, integrity, and quality of the data. These are developed for the BIRD layers if resources are available.

The BIRD process can be divided into two levels, a logical level and a technical level. The connecting components not only connect BIRD layers within each level, but also create the bridge between the two levels (i.e. through forward engineering).

Please see the following sections for a detailed explanation of the components of the BIRD process.

BIRD components

As indicated above, the BIRD consists of data structures and connecting components. This section describes each component individually.

• Data structure components
  • BIRD layers, e.g. Logical Data Model and Input Layer
• Connecting components
  • Forward engineering procedure
  • Transformation rules
  • Mappings
• Validating components
  • Validation rules (i.e. business and structural validation rules)

BIRD layers

The BIRD layers contain the information needed to produce regulatory reporting (i.e. output) from a defined input. These layers represent the various steps of the process; input layers are described by entity relationship models, and output layers by the structures defined by the regulatory reporting (e.g. by single tables). All the BIRD layers are considered fundamental components of the BIRD.

The BIRD layers can be allocated to a level, i.e. logical or technical, depending on their purpose and the concern they address. Across both the logical and technical levels, the BIRD is semantically consistent as it provides an integrated dictionary of definitions that originally come from different regulations, and it describes calculations using a logical/ semantic language.

• Logical level
  • The Logical Data Model (LDM)
  • The Enriched Logical Data Model (ELDM)
• Technical level
  • The Input Layer (IL)
  • The Enriched Input Layer (EIL)
  • The Reference Output Layer (ROL)
  • The Non-Reference Output Layer (NROL)

All the BIRD layers, except the Non-Reference Output Layer, are described using the same language (i.e. “reference” metadata codification) and are therefore fully integrated. The Non-Reference Output Layer uses the descriptions, concepts, and codes as defined by the owner of the regulatory reporting requirements. In this way, the BIRD layers are semantically integrated as for each original “non-reference” metadata they provide a “reference” one.

The formal description of the BIRD layers follows the SMCube Information Model (see also non-technical introduction to the SMCube methodology), which is built upon a foundation of cubes (i.e. tables). This methodology was developed with a view to combining dictionaries originally developed with different methodologies into one dictionary. The resulting dictionary syntactically and semantically integrates data descriptions originally modelled following other methodologies, e.g. the EBA’s Data Point Model (DPM), and therefore sets the standards for the BIRD.

Logical level

The Logical Data Model (LDM)

The Logical Data Model (LDM) is a highly normalised entity relationship model (i.e. ERM) that describes the primary business concepts relevant for fulfilling the regulatory reporting requirements covered by the BIRD. The LDM is implementation agnostic and can be used by banks and other interested parties to design their own physical implementation layers or visualise logical dependencies.

Given its highly normalised structure and harmonised definitions, it provides the basis for the creation of the other BIRD layers in a consistent way.

The Enriched Logical Data Model (ELDM)

The Enriched Logical Data Model (ELDM) is similar to the LDM and describes the primary business concepts already present in the LDM together with additional derived information that is needed to fulfil the regulatory reporting requirements. For example, the enriched concept of small and medium enterprise classification is derived from primary concepts contained in the LDM, such as the number of employees and annual turnover.

Given its highly normalised structure, it is used to derive the other enriched BIRD layer, the Enriched Input Layer.

Technical level

For a better understanding of the layers at the technical level, Figure 2 provides a high level illustration of the BIRD process, including the connecting components.

The Input Layer (IL)

The Input Layer (IL) is a less normalised ERM fully based on the LDM and its definitions of primary concepts. The IL therefore encompasses the same content as the LDM but in a data structure with fewer entities. This characteristic makes it a good candidate to be used as an interface for banks’ internal IT systems and it could be the starting point for a technical implementation of the BIRD, although ultimately this depends on banks’ internal approaches. Moreover, the less normalised structure could allow for an easier understanding of the content for BIRD users that are not too familiar with complex data modelling applications.

The IL is created by a “forward engineering” procedure (see below for more details).

The Enriched Input Layer (EIL)

The Enriched Input Layer (EIL) is a less normalised ERM fully based on the ELDM and its definitions of primary concepts and enriched information. The EIL is created by the same forward engineering procedure as the IL, with the result that the EIL resembles the IL but includes the enriched information. The same considerations hold true on its use as an implementation layer or for easy understanding of the content by BIRD users.

The Reference Output Layer (ROL)

The Reference Output Layer (ROL) describes the original regulatory reporting requirements, using the “reference” codes of the BIRD dictionary. The ROL is a syntactically and semantically integrated version of the original reporting requirements. However, this layer still reflects the way data are originally organised, e.g. DPM report-like layout.

Although in some cases the ROL describes the original regulatory reporting requirements, e.g. AnaCredit, the definition of such output requirements does not fall within the scope of the BIRD project. Only the modelling to the BIRD Information Model, in line with the BIRD Methodology, falls within the BIRD scope.

The Non-Reference Output Layer (NROL)

The Non-Reference Output Layer (NROL) describes the original regulatory reporting requirements using “non-reference” codes, and thus using the codification systems of the related regulation (e.g. from the EBA’s DPM).

Although the NROL is part of the BIRD, defining the output requirements (e.g. regulations) does not fall within the scope of the BIRD project. Only the mapping of metadata to the BIRD “reference” dictionary and the modelling to the BIRD Information Model, in line with the BIRD Methodology, falls within the BIRD scope.

Forward engineering procedure

The forward engineering procedure defines the methods used as a combination of denormalization and additional validation rules that ensure semantic equivalence between the LDM and the IL and between the ELDM and the EIL. The forward engineering procedure comes into play in the phases that bridge logical level with technical level and is used to derive the IL and EIL from the LDM and ELDM.

Transformation rules

Transformation rules in the BIRD describe operations to enrich information and create reports. They can be written in semantic language, e.g. natural language, or in technical language, e.g. VTL, SQL. In the BIRD, transformation rules are primarily written in logical/semantic language to support business users and provide the business perspective in an easy, yet formal, language. Logical/semantic transformation rules can also form the underlying basis for technical solutions without restricting potential options, e.g. technical language, and allowing for tailormade solutions based on the applied technology. Given their user-friendliness towards business users, logical/semantic transformation rules are deemed a fundamental component of the BIRD, while technical transformation rules can be added if resources are available.

Logical/semantic transformation rules can be split into derivations and generations.

• Derivations describe operations to enrich information derivable from primary concepts already available in the LDM and in the IL and are needed to fulfil the regulatory reporting requirements. Ideally these are redundancy-free operations that are reusable for multiple reporting requirements.
• Generations are transformations that create the output by filtering, selecting, and performing simple mathematical operations on the content of the EIL.

Mappings

Mappings in the BIRD represent a specialised type of transformation rules that are needed to translate dictionaries that are not semantically integrated into the “reference” dictionary of the BIRD. The “non-reference” dictionaries of the NROL use different definitions, concepts, and codes, which need to be mapped to the “reference” dictionary of the BIRD. Mappings are a fundamental BIRD component as they make it possible to semantically integrate and use a single dictionary in a world in which reporting requirements are currently still described using multiple different dictionaries which have been independently developed.

Validation rules

Via its logical structure, the BIRD LDM embeds numerous dependencies that reflect indirectly the first set of validation rules in the BIRD. Additional checks can then be introduced in the BIRD via explicit validation rules. These can be applied on the structure of the BIRD layers to improve the consistency and integrity (structural validation rules), or on the business logic to improve the quality of the input data and provide additional insights to business users (business validation rules). Structural validation rules are particularly relevant to ensure the consistency of de-normalised layers, such as the IL/EIL. Business validation rules describe additional validations that are not covered by the normalised structure of the LDM (e.g. the Legal final maturity date needs to be greater than the Inception date) and may be described for the LDM/ELDM and for the IL/EIL. Validations may also involve (external) validation rules that would be applied to the NROL. Finally, validation rules may differ in nature and complexity.

The future definition and development of additional sets of validation rules is subject to the priorities of the BIRD project and the resources it has available. The development and maintenance of validation rules is subject to the completion of the fundamental components of the BIRD.