The BIRD methodology refers to the technique used to provide a formal documentation of the BIRD proposed data model. The description of the BIRD proposed data model is composed of:

– Description of datasets
– Transformation process
– Technical guidelines on how to populate the datasets and implement transformations.

The BIRD is documenting a dynamic data process, where some data are provided as input, validated and subsequently transformed into other datasets until the final datasets, which are those that need to be reported to the authorities, are generated. Section 2 of this document describes the high-level BIRD data process.

The BIRD provides a formal description of both the datasets and the validation and transformation rules. Section 3 introduces the methodology for the formal description of the BIRD datasets, while Section 4 deals with the validation and transformation language.

The technical guidelines on how to populate datasets, which include the conceptual model of the relation between the cubes in the form of an Entity Relationship Model, constitute a separate document, which is included in the BIRD website.

High-level BIRD data process

A system following the BIRD process would normally start by feeding the input cubes from banks’ internal IT systems, following the structure of the input cubes defined by the BIRD. The system would then run the validations of the input cubes, and depending on the output of the validations, it would create enriched cubes. The enriched cubes contain the relevant information for generating the final reports, including input information but also new information derived from that input.

From the enriched cubes, all reporting requirements would be generated. The validation, enrichment and generation would be guided by the transformation rules (further explained in Section 4 “Transformation rules in the BIRD model”). The reporting requirements are also part of the BIRD documentation, in the form of output cubes, although their definition is out of the scope of the BIRD; the BIRD simply includes the translation of the output cubes into its data model.

The process described in the BIRD is divided in three phases, of which two are common to all output frameworks to be generated, and one will be specific for each reporting framework.

The enrichment phase finishes when writing the enriched input layer. The enriched input layer is also described in the BIRD dictionary as a group of datasets.
The detailed sub-phases of the transformation process are further described in Annex III.

Description of the datasets

The description of the datasets in the BIRD is provided following the SMCube methodology, which is a methodology developed with the objectives of:

  • • Enabling the description within one dictionary of all types of datasets (registries, dynamic data for supervisory purposes, for monetary purposes…)
  • • Facilitating the integration of dictionaries developed with different methodologies (like DPM/XBRL or SDMX) in one single dictionary by keeping a high degree of compatibility with the other methodologies

The version 1.0 of the SMCube methodology is finalised. The SMCube information model will be provided as soon as possible. A non-technical introduction to the main concepts of the methodology is provided in Annex I of this handbook.

The BIRD pilot is using a simplified version of the methodology, where some artefacts (like those in the rendering and provisioning packages) and features (like historicizing and extensibility) have been removed, since for the time being they are not going to be used. The formal description of the BIRD datasets is provided in an Access database, which can be downloaded in the BIRD website.

Transformation rules in the BIRD model

Transformation rules represent a description of logical operations applied to objects of the BIRD database to create new / additional information.

Transformations rules are organised, following the VTL model, consisting of Transformation schemes, Functions, Rulesets and procedures. One Transformation scheme can contain one or many transformations.

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

transformationResult := expression

Transformations are grouped into transformation schemes, which are sets of transformations aimed at obtaining some meaningful results for the user. Transformation schemes group transformations that share some functional or business purpose. An example of transformation scheme is the derivation of enterprise size. This transformation scheme is formed by several different transformations aimed to give as a result the final enterprise size.
Transformations are defined in verbal and formal form. The verbal description (“Natural language”) represents the business perspective trying to avoid specifications regarding the technical implementation. The formal description is based on the Validation and Transformations Language (VTL) with minor adaptions to improve usability / readability by the end user and aims at a technical description of the transformation rules independent of the technical implementation.

Regarding the formal description, please note that due to the ongoing developments in the Task force for the Validation and Transformation Language (VTL) and the publication of VTL version 1.1 at the end of June 2017, changes to the syntax are possible. Currently the VTL task force is reviewing the comments received before the final release.

Transformation schemes are classified in the following four types:

  • I) Validation rules: Transformations that evaluate a logical condition that data should comply with. Validations are subdivided in:
    • • Consistency: Check the consistency among variables (for instance, the inception date has to be earlier than the reference date)
    • • Completeness: Check that all related information exists (for instance, for each loan there should be at least one debtor).
    • • Integrity: Check that, for one instance of one object, there is a related instance in another object. This includes referential integrity validations (for instance, if there is an issuer of a security, this issuer has to exist in the Counterparties cube).
    • • Uniqueness: Checks that identifiers used in separate cubes are unique (for instance, that an Instrument unique identifier can only be used for one instrument).
  • II) Derivation rules: Transformations that create new variables from existing data.
  • III) Generation rules: Transformations focused on the data preparation based on the formalities described for each output framework.
  • IV) Technical rules: Transformations required for technical purposes, in order to have a complete description of the transformation process, but are not relevant for business users.

Annex II provides a technical description of the model used in the database to represent VTL as well as an overview of the most important VTL functionality used in BIRD transformations.