Framework Generation

Different reporting requirements are described in different ways, with different methodologies. At present, there are mainly two standardised methodologies in use: the Data Point Model (DPM) and Statistical Data and Metadata Exchange (SDMX) methodologies.

A precondition for effective and efficient data integration in BIRD is to describe all the datasets with the same methodology.

The BIRD methodology can accommodate the DPM and SDMX methodology using the SMCube methodology that contains all the substantive details present in the existing modelling methodologies and is compatible with the existing methodologies so that the translation process can be automated for the most part and serves to describe all existing reporting frameworks. The benefit of having a common information model, compatible with all other models, is that different kinds of datasets can be stored, managed and retrieved in a common way regardless of the model/standard used for the actual data exchange.

The process to import the original data model into the SMCube model is called methodological integration.

The AnaCredit framework was included in BIRD without any methodological integration because AnaCredit metadata were directly developed within the SMCube methodology.

To integrate FinRep the BIRD has translated the DPM into the SMCube. In Particular the content of EBA’s DPM has been imported into the SMCube methodology automatically from the XBRL taxonomies. All the DPM content remains untouched, only a translation between methodologies is performed.

Once the issue of integrated modelling methodology is solved, the problem of semantical integration still persists.

The semantic integration means that all concepts for describing statistical and supervisory data should have a single and unambiguous codification. In the followings, we refer to the integrated dictionary as the reference dictionary. These single unambiguous codifications should be suited for use in all data models.

In order to use the unambiguous codification a process of mapping has been implemented to match the FinRep Concept and SHS concept into the unique codification that is used in BIRD (called reference dictionary).

Mappings provide a way to establish that two concepts created by different maintenance agencies are equivalent. The concepts we are interested in are the variables and the members, which are the building blocks for datasets.

In an ideal world mappings would be very simple: One table with two columns could suffice to express mappings.

SOURCE MEMBER

DESTINATION MEMBER

SOURCE VARIABLE

DESTINATION VARIABLE

a 1 x 7
b 2 y 8
c 3 x 9

But, unfortunately, the reality is much more complex, and this implies the need for more complex mappings. There are two main sources of complexity: (i) Use of different classification systems, and (ii) errors.

As an illustrative example, let’s take the European System of Accounts (ESA) classification of financial instruments. This classification is done with a specific purpose, and mixes different concepts within the same classification. For instance, in the ESA classification of instruments there are two values for log-term debt securities and short-term debt securities. So the data frameworks that follow ESA classification tend to have one variable where two possible values are long-term debt securities and short-term debt securities. But in other frameworks, like FinRep, this classification is not followed, and therefore there are two separate variables: The type of instrument and the original maturity.

The SMCube methodology provides a model able to address complex (n to m) mappings. In the SMCube, one full mapping points to one mapping of variables and, eventually, one mapping of members.

One full mapping points only to a variable when the variable is not enumerated. For example, if we want to map the variable Carrying amount, with code mi53 in the DPM, to the same concept with code CRRYNG_AMNT in the reference dictionary.

If the mapping is for enumerated variables, then it needs also to point to the member mappings. The MAPPING_DEFINITION table contains the full mappings. It includes one field with the mapping type. The most relevant types of mappings have the value ‘E’ and ‘A’. ‘E’ mappings imply that a member mapping is required, while ‘A’ mappings imply that an algorithm is required. The algorithm in the latter case serves to add operations, if needed to the values in the non-enumerated variables. In most cases it will not have any value, meaning that no operation has to be done.

VARIABLE_MAPPING and VARIABLE_MAPPING_ITEM tables provide the variable mappings, while MEMBER_MAPPING and MEMBER_MAPPING_ITEM provide the member mappings.

The two previous examples would be described (for illustrative purposes, the tables are simplified and only the enumeration tables are shown):

Note that:

  • Given that mappings are n to m, the number of source and destination elements is unknown. This is the reason for having one record per element, and not per mapping.

  • Each mapping maps 1 set of variables, but several sets of members. That is why the MEMBER_MAPPING_ITEM table has the field MEMBER_MAPPING_ROW.

  • The first mapping is 1 to 2, so when coming to the mappings, there is no need to specify the variable for the source member (it can only be one: ESA_ INSTR_CLASS), but the specification of the destination variable is required, because if, for instance, only ‘1’ was specified, there would be doubts on whether that 1 would apply to TYP_INSTRMNT or ORGNL_MTRTY.

As a consequence of this semantic integration in the DB for FinRep and SHSGroup reporting two different output cubes are present, the original cubes and the translation to the reference codes. The original cubes describe the information to be transmitted, as described in the original documentation. The translated cubes are created automatically from the original cubes, by applying the mappings.

The technical choice made in order to achieve this goal is to consider a FinRep normalised template as a cube with several combination, each combination within a non-reference cube is considered a data point described by the Data Point Model. The FinRep reference cube then are a normalised template described by reference codes and reference combinations.

Therefore is should be possible to link a non-reference combination – a datapoint – to a reference combination.1

With reference mappings is possible to generate a FINREP report by feeding from the BIRD input layer, via transformation rules, the translated cubes.


  1. The non-reference combination ID are coded with the DataPointVID of DPM database. Reference combination ID are structured in the same way ending with _REF subscript. (i.e. EBA_100 == EBA_100_REF, and identify DataPointVID = 100).