BIRD Methodology

Introduction

The BIRD methodology refers to the way in which the BIRD data model is stored and documented. This information comprises:

  • A description of the datasets;
  • The transformation process;
  • Technical guidelines on how to populate the datasets and implement transformations.

The BIRD documents a dynamic data process in which data are inputted, validated and subsequently transformed in order to generate the final datasets. These datasets reflect the secondary reporting requirements, i.e. the information that national central banks need to provide to the authorities (e.g. the ECB or the European Banking Authority (EBA)). The following section describes the high-level BIRD data process.

The BIRD provides a formal description of the datasets and the validation and transformation rules. The Single Multidimensional Metadata (SMCube) Information Model introduces the methodology for the formal description of the BIRD datasets and the section on transformations provides additional information about the validation and transformation language (VTL), including how it is used in the BIRD.

High-level BIRD data process

The BIRD data process can be divided into four layers and three phases separating those layers. The four layers are:

  • The Input Layer (IL)
  • The Enriched Input Layer (EIL)
  • The Reference Output Layer (ROL)
  • The Non-reference Output Layer (NROL)

The three phases are:

  • Phase 1 (IL → EIL)
  • Phase 2 (EIL → ROL)
  • Phase 3 (ROL → NROL)

The layers are described by cubes while the phases are described by transformations and mappings in the BIRD database.

A system that uses the BIRD process starts by feeding the Input Layer from banks’ internal IT systems, following the structure of the Input Layer cubes defined in the BIRD. The system then applies the first phase of transformations to the Input Layer data in order to generate the Enriched Input Layer.

Layers

The Input Layer

This layer is a harmonised entity relationship model (ERM) that contains the information required from a bank’s internal systems in order to generate the output layer(s). Among other things, this layer contains information about entities (e.g. debtors and protection providers), commitments (e.g. credit facilities), instruments (e.g. loans, securities and deposits) and protections (e.g. financial protection or physical protection such as real estate protection) as well as aggregated information.

The Enriched Input Layer

The Enriched Input Layer is another ERM and acts as an intermediate layer between the Input Layer and the Reference Output Layer. It consists of the information from the Input Layer and some additional information (such as the results of particular derivations where the input parameters of the derivation may no longer be needed and are therefore not present in the Enriched Input Layer).

The Reference Output Layer

The Reference Output Layer describes the Non-reference Output Layer using reference codes (i.e. the codes used in the Input Layer). The relationship between the Reference Output Layer and the Non-reference Output Layer is represented by mappings (see also the non-technical introduction to the SMCube methodology).

The Non-reference Output Layer

The Non-reference Output Layer describes the reporting requirements as defined in the related documents (e.g. regulations, directives, guidelines and manuals), sometimes using different codification systems (e.g. EBA ITS and Statistical Data and Metadata eXchange SDMX).

Although the output layer is part of the BIRD process, defining the output requirements (e.g. regulations) does not fall within the scope of the BIRD. Instead, the reporting requirements are translated into the language of the BIRD (i.e. in the SMCube methodology) and are therefore represented as cubes (e.g. the EBA’s Implementing Technical Standards related to FINREP, which are described in the data point model (DPM)/XBRL, are (automatically) extracted and included in the dictionary).

Additional information can be found in the section “EBA DPM translation”

Phases

All of the phases may involve validations, such as validations that ensure the integrity of the Input Layer, validations that ensure the consistency of the Enriched Input Layer and validations that apply (external) validation rules to the Non-reference Output Layer.

Phase 1

Transformations are applied to the Input Layer in order to generate the Enriched Input Layer. These transformations are used to prepare and enrich the data in a structure that can be easily used to generate specific reporting requirements.

Phase 2

Transformations generate the Reference Output Layer based on the Enriched Input Layer. This phase may also involve technical adjustments necessary in order to comply with the Non-reference Output Layer.

Phase 3

The third phase involves applying mappings that describe the relationship between the Reference Output Layer and the Non-reference Output Layer.

Description of the datasets

The description of the datasets in the BIRD follows the SMCube methodology, which has been developed with a view to:

  • Combining the description of all types of datasets (registries, dynamic data for supervisory or statistical purposes) in a single dictionary;
  • Combining dictionaries developed with different methodologies (such as DPM/XBRL or SDMX) in a single dictionary, while maintaining a high degree of compatibility with the other methodologies.

Transformation rules in the BIRD model

Transformation rules are descriptions of operations that are applied to objects in the BIRD database in order to obtain new/additional information.

Transformations rules are organised according to the VTL model, which consists of transformation schemes, functions, rulesets and procedures. One transformation scheme may contain one or several transformations.

Transformations are the most basic element of the calculations, and consist of a statement assigning the outcome of an expression to a VTL element. Transformations (except for procedure calls) therefore have the following structure:

transformationResult := expression

Transformations are grouped into transformation schemes, which are sets of transformations designed to provide meaningful results for the user. Transformation schemes group transformations that share some functional or business purpose. An example of a transformation scheme is the derivation of enterprise size, which involves several different transformations that provide the user with the final enterprise size.

Transformations are defined verbally and formally. The verbal description (“natural language”) represents the business perspective without referring to the technical implementation. The formal description is based on the VTL with minor changes to improve usability/readability for the end user and aims to provide a technical description of the transformation rules, separate from the technical implementation.

Transformation schemes can be grouped into the following four types of rule:

  1. Validation rules: Transformations used to verify the quality of the data according to specific rules. Validations are subdivided into:
    1. Consistency validations: these check the consistency between variables (for instance, the inception date has to be earlier than the reference date);
    2. Completeness validations: these check that all relevant information has been provided (for instance, for each loan there should be at least one debtor);
    3. Integrity validations: these check that, for one instance of an object, there is a related instance in another object and also include referential integrity validations (for example, if there is an issuer of a security, this issuer has to exist in the Counterparties Cube);
    4. Uniqueness validations: these check that identifiers used in separate cubes are unique (for instance, that an instrument unique identifier is used for one instrument).
  2. Derivation rules: Transformations that create new variables from existing data
  3. Generation rules: Transformation used to prepare the data according to each reporting framework.
  4. Technical rules: Transformations required for technical purposes to provide a complete description of the transformation process, but which are not relevant for business users.

The section on transformations provides a technical description of the model used in the database to represent VTL and an overview of the most important VTL functionality used in BIRD transformations.