Framework Generation

Table of Contents

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 the BIRD is to describe all the datasets with the same methodology.

The BIRD 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 these, so that the translation process can be largely automated 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 “frameworks defined in the DPM”.the BIRD has translated the DPM into the SMCube. In particular the content of the 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.

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. In order to use the unambiguous codification, a process of mapping has been implemented to match the DPM and SHS concepts 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 (e.g. the EBA and the ECB) are equivalent. The concepts we are interested in are the variables and the members, which are the building blocks for describing a dataset.

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 long-term debt securities and short-term debt securities. 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: type of instrument and 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 “frameworks defined in the DPM”

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 feed some 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:

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

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

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

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

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

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.

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

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

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. Therefore, at least for the time being, we leaf the explicit generation of each individual combination open for active implementations of the BIRD.

The BIRD process does not generate all FinRep output cubes – templates – starting from the input layer. The BIRD Expert Group decided to leave the generation of the following templates to the reporting agents. In this case the BIRD does not provide any kind of transformation for the following cubes:

  • With quarterly frequency

CUBE/TEMPLATE

DESCRIPTION

F_00_01

Nature of Report (FINREP)

F_01_03

Balance Sheet Statement [Statement of Financial
Position]: Equity

F_02_00

Statement of profit or loss

F_03_00

Statement of comprehensive income

F_11_03_1

Non-derivative hedging instruments

F_11_03

Non-derivatives – Hedge accounting: Breakdown by
accounting portfolio and type of hedge

F_11_04

Hedged items in fair value hedges

F_12_00

Movements in allowances for credit losses and
impairment of equity instruments

F_12_01_a

Movements in allowances and provisions for credit
losses (a)

F_12_01_b

Movements in allowances and provisions for credit losses
(b)

F_12_02

Transfers between impairment stages (gross basis
presentation)

F_16_01

Breakdown of selected statement of profit or loss
items: Interest income and expenses by instrument and counterparty sector

F_16_02

Realised gains and losses on financial assets and
liabilities not measured at fair value through profit or loss by instrument

F_16_03

Gains and losses on financial assets and liabilities
held for trading by instrument

F_16_04_1

Gains or losses on non-trading financial assets
mandatorily at fair value through profit or loss by instrument

F_16_04

Gains and losses on financial assets and liabilities
held for trading by risk

F_16_05

Gains and losses on financial assets and liabilities
designated at fair value through profit or loss by instrument

F_16_06

Gains and losses from hedge accounting

F_16_07_a

Impairment on financial and non-financial assets (a)

F_16_07_b

Impairment on financial and non-financial assets (b)

F_17_01

Reconciliation between IFRS and CRR scope of
consolidation: Assets

F_17_02

Reconciliation between IFRS and CRR scope of
consolidation: Off-balance sheet exposures – loan commitments, financial
guarantees and other commitments given

F_17_03

Reconciliation between IFRS and CRR scope of consolidation:
Liabilities

F_20_03

Geographical breakdown of main income statement items
by location of the activities

F_22_01

Fee and commission income and expenses by activity

F_22_02

Assets involved in the services provided

  • With half yearly frequency

CUBE/TEMPLATE

DESCRIPTION

F_30_01

Interests in unconsolidated structured entities

F_30_02

Breakdown of interests in unconsolidated structured
entities by nature of the activities

F_31_02

Related parties: expenses and income generated by
transactions with

  • With yearly frequency

CUBE/TEMPLATE

DESCRIPTION

F_43_00

Provisions

F_44_01

Components of net defined benefit plan
assets and liabilities

F_44_02

Movements in defined benefit plans and
employee benefits

F_44_03

Memo items [related to staff expenses]

F_45_01

Gains and losses on financial assets and
liabilities designated at fair value through profit or loss by accounting portfolio

F_45_02

Gains and losses on derecognition of
non-financial assets other than held for sale

F_45_03

Other operating income and expenses

F_46_00

Statement of changes in equity

CUBE/TEMPLATE

DESCRIPTION

Z_01_00

Organisational structure (ORG)

Z_02_00

Liability structure (only rows 500—600 are input-output)

Z_03_00

Own funds requirements

Z_07_01

Criticality assessment of economic functions

Z_07_02

Mapping of critical functions by legal entity

Z_07_03

Mapping of core business lines to legal entities

Z_07_04

Mapping of critical functions to core business lines

Z_08_00

Critical services

Z_09_00

FMI Services – providers and users – Mapping to Critical
Functions

Z_10_01

Critical Information Systems (general information)

Z_10_02

Mapping of Information Systems

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