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.

Framework generation of FinRep

Level of aggregation, application of hierarchies

Please note that the BIRD process does not explicitly create all the levels of aggregation (sum, of-which positions) that are necessary in order to extract the values for each data point but rather generates the most granular data that may be aggregated in order to derive the required data points.

The main reasons for this limitation (of explicit transformation rules) are

Convention for the member Not applicable / all (x0)

Non-disjoint output requirements

The first point is based on a misalignment of dictionaries. In the reference dictionary the member Not applicable (0) means that a concept is not applicable in this particular case while for a member comprising all other members would be represented by a different member than Not applicable (0) due to the fact that all other members represent a different concept than not applicable. In the future we may adapt our mappings (from the non-reference to the reference cubes) and take this misalignment into account, for the time being however this limitation stays in place.

The second item is mainly presented by overlapping “of-which” positions but also other overlapping concepts. This implies a stepwise derivation of the underlying combinations of a cube taking into account the application of relevant member hierarchies before each step. For further details please consider the following example.

Example: Application of member hierarchies & aggregation for “Breakdown of non-trading loans and advances to non-financial corporations by NACE codes (F 06.01)”

Setup

This example describes the necessary steps that are indicated by the function TRANSFORMATION_SCHEME. For the sake of simplicity we’ll only consider the following combinations:

Table 1: relevant combinations for the given example (represented in the non-reference codification system)

Please note that this is a representation of the (so called) non-reference cube F_06_01 while we describe the generation of the reference cube F_06_01_REF in this example.

Initial situation

The (unfolded) reference representation of the cube F_06_01 is generated by the transformation scheme G_F_06_01_REF_UNFLDD_FINREP. It takes into account Loans and advances per debtor, applies member hierarchies on the variables Type of instrument, Institutional sector and Economic Activity in order to comply with the level of granularity (w.r.t. those variables) and applies filters regarding the variables Institutional sector, Is held for sale, Type of accounting item and Type of instrument. Finally it produces a cube having the following structure:

Breakdown of non-trading loans and advances to non-financial corporations by NACE codes – Reference (unfolded) (F_06_01_REF_UNFLDD)
Role Variable Subdomain
Dimension Accounting classification (ACCNTNG_CLSSFCTN) No restriction
Dimension Reference date (DT_RFRNC) {Generic subdomain date (DT)}
Dimension Economic activity (ECNMC_ACTVTY) No restriction
Dimension Institutional sector (INSTTTNL_SCTR) {Non financial corporations (S11)}
Dimension Is held for sale (IS_HFS) {FALSE (F)}
Dimension Observed agent internal identifier (OBSRVD_AGNT_INTRNL_ID) {Generic subdomain strings (STRNG)}
Dimension Performing status (PRFRMNG_STTS) No restriction
Dimension Type of accounting item (TYP_ACCNTNG_ITM) {Financial instruments. Creditor (40)}
Dimension Type of instrument (TYP_INSTRMNT) {Loans and advances (149)}
Observation Accumulated changes in fair value due to credit risk – negative (ACCMLTD_CHNG_NGTV_FV_CR) {Monetary amount without further specification (MNTRY)}
Observation Accumulated impairment (ACCMLTD_IMPRMNT) {Monetary amount without further specification (MNTRY)}
Observation Gross carrying amount (GRSS_CRRYNG_AMNT) {Monetary amount without further specification (MNTRY)}

Table 2: Cube structure resulting from the transformation scheme {[link:/transformation_scheme?TRANSFORMATION_SCHEME_ID=G_F_06_01_REF_UNFLDD_FINREP_1]}

For the sake of simplicity we will omit all variables that are not related to members (i.e. Observed agent internal identifier (OBSRVD_AGNT_INTRNL_ID) and Reference date (DT_RFRNC)) as they are irrelevant for our aim and also variables that may only take one value (e.g. Institutional Sector).

Records of the data set (described by this cube) may look as follows:

Accounting classification (ACCNTNG_CLSSFCTN) Economic activity (ECNMC_ACTVTY) Performing status (PRFRMNG_STTS) Carrying amount (CRRYNG_AMNT) Accumulated impairment (ACCMLTD_IMPRMNT) Accumulated changes in fair value due to credit risk – negative (ACCMLTD_CHNG_NGTV_FV_CR)
IFRS: Financial assets at amortised cost (6) AGRICULTURE, FORESTRY AND FISHING (A) Non-performing (1) 7 3 0
IFRS: Financial assets at fair value through other comprehensive income (8) AGRICULTURE, FORESTRY AND FISHING (A) Performing (11) 13 0 5
IFRS: Non-trading financial assets mandatorily at fair value through profit or loss (41) AGRICULTURE, FORESTRY AND FISHING (A) Performing (11) 11 0 3

Table 3: real data example for the cube indicated in table 2

We observe that the values of the variable ACCNTNG_CLSSFCTN are not in line with the required output values (i.e. ACCNTNG_CLSSFCTN_54, ACCNTNG_CLSSFCTN_60 and ACCNTNG_CLSSFCTN_61) due to the fact that they reflect the values that are allowed in the input layer. Consequently we need to apply member hierarchies on this variable such that we may derive the required output values but unfortunately the values for the columns Gross carrying amount (010) and Accumulated negative changes in fair value due to credit risk on non-performing exposures (022) are different. Subsequently we need to apply two different member hierarchies on the same data set resulting in two different (non-disjoint) views on the data.

Application of first member hierarchy

First we apply the member hierarchy AccPor60 resulting in the following view:

Accounting classification (ACCNTNG_CLSSFCTN) Economic activity (ECNMC_ACTVTY) Performing status (PRFRMNG_STTS) Carrying amount (CRRYNG_AMNT) Accumulated impairment (ACCMLTD_IMPRMNT) Accumulated changes in fair value due to credit risk – negative (ACCMLTD_CHNG_NGTV_FV_CR)
Financial assets other than Held for trading and Trading Financial Assets (60) AGRICULTURE, FORESTRY AND FISHING (A) Non-performing (1) 7 3 0
Financial assets other than Held for trading and Trading Financial Assets (60) AGRICULTURE, FORESTRY AND FISHING (A) Performing (11) 13 0 5
Financial assets other than Held for trading and Trading Financial Assets (60) AGRICULTURE, FORESTRY AND FISHING (A) Performing (11) 11 0 3

Table 4: real data example after application of AccPor60

Which allows us (via aggregation) to generate the combinations EBA_152499_REF and EBA_152500_REF, resulting in the following situation:

Table 5: combinations created based on application of AccPor60 and following aggregation

The associated VTL statements would look like this:

/*Apply filter criteria in order to identify the records contributing to the combination EBA_152499_REF*/EBA_152499_REF := F_06_01_REF [filter(ACCNTNG_CLSSFCTN = "60" and ECNMC_ACTVTY = "A" and INSTTTNL_SCTR = "S11" and IS_HFS = "F" and TYP_ACCNTNG_ITM = "40" and TYP_INSTRMNT = "149")];

/*Keep only relevant observation*/ EBA_152499_REF := EBA_152499_REF [keep(GRSS_CRRYNG_AMNT)];

for the combination EBA_152499_REF, and

/*Apply filter criteria in order to identify the records contributing to the combination EBA_152500_REF*/EBA_152500_REF := F_06_01_REF [filter(ACCNTNG_CLSSFCTN = "60" and ECNMC_ACTVTY = "A" and INSTTTNL_SCTR = "S11" and IS_HFS = "F" and PRFRMNG_STTS = "1" and TYP_ACCNTNG_ITM = "40" and TYP_INSTRMNT = "149")];

/*Keep only relevant observation*/ EBA_152500_REF := EBA_152500_REF [keep(GRSS_CRRYNG_AMNT)];

for the combination EBA_152500_REF.

Please note that these statements may be extracted from the database (by selecting the combination items related to the combination of interest and omitting all variable, member combinations where the member takes the value “Not applicable (0)”).

Application of second member hierarchy

As a second step we apply the member hierarchy AccPor54 on the original data set (and consequently creating a non-disjoint data set w.r.t. the one that was previously generated), resulting in the following view:

Accounting classification (ACCNTNG_CLSSFCTN) Economic activity (ECNMC_ACTVTY) Performing status (PRFRMNG_STTS) Carrying amount (CRRYNG_AMNT) Accumulated impairment (ACCMLTD_IMPRMNT) Accumulated changes in fair value due to credit risk – negative (ACCMLTD_CHNG_NGTV_FV_CR)
Accounting portfolios for financial assets subject to impairment (54) AGRICULTURE, FORESTRY AND FISHING (A) Non-performing (1) 7 3 0
Accounting portfolios for financial assets subject to impairment (54) AGRICULTURE, FORESTRY AND FISHING (A) Performing (11) 13 0 5
IFRS: Non-trading financial assets mandatorily at fair value through profit or loss (41) AGRICULTURE, FORESTRY AND FISHING (A) Performing (11) 11 0 3

Table 6: real data example after application of AccPor54

Again we may apply filter statements in order to extract the values for the combinations: EBA_150946_REF and EBA_150858_REF. This time however not all of the records contribute to the result as the third record does not fulfil the filter criteria.

Table 7: combinations created based on application of AccPor54 and following aggregation

The associated VTL statements take the following form:

/*Apply filter criteria in order to identify the records contributing to the combination EBA_150946_REF*/EBA_150946_REF := F_06_01_REF [filter(ACCNTNG_CLSSFCTN = "54" and ECNMC_ACTVTY = "A" and INSTTTNL_SCTR = "S11" and IS_HFS = "F" and TYP_ACCNTNG_ITM = "40" and TYP_INSTRMNT = "149")];

/*Keep only relevant observation*/ EBA_150946_REF := EBA_150946_REF [keep(GRSS_CRRYNG_AMNT)];

for the combination EBA_150946_REF, and

/*Apply filter criteria in order to identify the records contributing to the combination EBA_150858_REF*/EBA_150858_REF := F_06_01_REF [filter(ACCNTNG_CLSSFCTN = "54" and ECNMC_ACTVTY = "A" and INSTTTNL_SCTR = "S11" and IS_HFS = "F" and MTRCS = ACCMLTD_IMPRMNT and TYP_ACCNTNG_ITM = "40" and TYP_INSTRMNT = "149")];

/*Keep only relevant observation*/ EBA_150858_REF := EBA_150858_REF [keep(ACCMLTD_IMPRMNT)];

for the combination EBA_150858_REF.

Application of third member hierarchy

As a last step we apply the member hierarchy AccPor61 and follow the above describe procedure resulting in the following view:

Accounting classification (ACCNTNG_CLSSFCTN) Economic activity (ECNMC_ACTVTY) Performing status (PRFRMNG_STTS) Carrying amount (CRRYNG_AMNT) Accumulated impairment (ACCMLTD_IMPRMNT) Accumulated changes in fair value due to credit risk – negative (ACCMLTD_CHNG_NGTV_FV_CR)
IFRS: Financial assets at amortised cost (6) AGRICULTURE, FORESTRY AND FISHING (A) Non-performing (1) 7 3 0
Financial assets at fair value other than Held for trading and Trading Financial Assets (61) AGRICULTURE, FORESTRY AND FISHING (A) Performing (11) 13 0 5
Financial assets at fair value other than Held for trading and Trading Financial Assets (61) AGRICULTURE, FORESTRY AND FISHING (A) Performing (11) 11 0 3

Table 8: real data example after application of AccPor61

Again we apply the relevant filter criteria resulting in the last combination (i.e. EBA_ 152369_REF) of this row:

Table 9: combinations created based on application of AccPor61 and following aggregation

And the associated VTL statements:

/*Apply filter criteria in order to identify the records contributing to the combination EBA_152369_REF*/EBA_152369_REF := F_06_01_REF [filter(ACCNTNG_CLSSFCTN = "61" and ECNMC_ACTVTY = "A" and INSTTTNL_SCTR = "S11" and IS_HFS = "F" and PRFRMNG_STTS = "1" and TYP_ACCNTNG_ITM = "40" and TYP_INSTRMNT = "149")];

/*Keep only relevant observation*/ EBA_152369_REF := EBA_152369_REF [keep(ACCMLTD_CHNG_NGTV_FV_CR)];

Conclusion

As we have seen throughout this example the generation of the relevant combinations not only requires aggregation, but due to the structure of the output layer, also requires the application of member hierarchies on the granular data set which results in a duplication of data. Unfortunately our machine is (currently) not smart enough to derive all those transformations automatically (mostly due to the convention of Not applicable / all (x0) and the fact that this member is currently mapped into Not applicable (0) in the reference dictionary). Therefore, at least for the time being, we leaf the explicit generation of each individual combination open for active implementations of the BIRD.

Framework generation of AnaCredit

Please note that we do not consider the assignment of Null explanatory values due to the fact that the specification is subject to national reporting requirements (i.e. primary reporting).


  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).