BIRD Technical Guidelines [602915]
BIRD Technical Guidelines
(Release 0.3 )
February 2017
Contents
1 Introduction 4
2 BIRD General Instructions 5
3 BIRD input layer ERM 6
3.1 Counterparties and related entities 6
3.2 Instruments and related entities 8
3.3 Protections and related entities 9
3.4 Securities data 11
3.5 Credit transfer / Securitisations and other credit transfer 12
3.6 Relations between main entities 12
3.7 Process parameters 13
3.8 Entity Relationship Model – graphical illustration 13
4 Input instructions 15
4.1 Parameters (PRMTR) 15
4.2 Instruments 15
4.3 Credit facilities (CRD T_FCLTS) 17
4.4 Specific operations 18
4.5 Securities 21
4.6 Collateral and guarantees 22
4.7 Counterparties 25
4.8 Relationship between transactions and counterparties 27
4.9 Credit quality 28
4.10 Securitisations and other credit transfers 34
4.11 Other instructions 39
5 Validation rules 41
6 Derivation rules 42
6.1 Derivation of “Enterprise size” 42
6.2 Derivation of Carrying amount 61
February, 2017
3
7 Other aspects 66
7.1 Information about the BIRD database 66
7.2 The output layer 66
February, 2017
4
1 Introduction
The BIRD technical guidelines aim to provide technical instructions on how to use the content of the
BIRD database ( DB).
The BIRD DB describes the data which should be extracted from the banks’ internal IT systems ("input
cubes "), the transformation rules to be applied to the data extrac ted to derive reports and the specific
final regulatory figure (“output cubes ”).
These transformation rules are described using (i) “natural language” and (ii) the Validation and
Transformation Language (VTL). More detailed information on transformation rules in the BIRD model
can be found in the BIRD Handbook.
February, 2017
5
2 BIRD General Instru ctions
The BIRD input layer is intended to support credit institutions to generate reports as required by
regulatory authorities.
The unit populating the BIRD input layer may be:
a. A head office, including domestic branches
b. A foreign branch
c. A legal entity
d. A group or part of a group
Input data comprise the relationships between the head office and foreign branches, among foreign
branches and among subsidiaries .
The consolidation process is not envisaged to be managed by the BIRD, at this stage .
Example 1: An illustrative example from the points above
Suppose there are two legal entities A and B, where B is subsidiary of A. A is composed by a
Head office (the domestic branch) and a EU branch. The following chart shows the relations:
The BIRD input layer may refer to:
The legal entity A, in which case it contain s information on all the branches. The input
layer is built in such a way that it is also possible to generate the reports for the units
included in the legal entity.
The Head quarter alone or any of the foreign branches alone.
The Legal entity B .
The BIRD is not covering for this release the group composed by A-B.
The t ime dimension is for the time being not documented in the BIRD. This means that the document
BIRD input laye r is seen as a snapshot of the information at a certain moment.
February, 2017
6
3 BIRD input layer ERM
This chapter describes the Entity –relationship model (ERM ) for the input layer. For presentational
purposes, it is divided in sections, each one showing parts of the mo del.
3.1 Counterparties and related entities
CNTRPRTS [Counterparties]
PKCNTRPRTY_ID [Counterparty identifier]JNT_CNTRPRTS [Joint counterparties]
PK,FK1CNTRPRTY_ID [CNTRPRTY_ID]
PK JNT_CNTRPRTY_CMPNNT [JNT_CNTRPRTY_CMPNNT]
LNKD_ENTRPRSS [Linked enterprises]
PK,FK1CNTRPRTY_ID [CNTRPRTY_ID]
PK LNKD_ENTRPRS_ID [LNKD_ENTRPRS_ID]
PRTNR_ENTRPRSS [Partner enterprises]
PK,FK1CNTRPRTY_ID [Counterparty identifier]
PK PRTNR_ENTRPRS_ID [PRTNR_ENTRPRS_ID]GRP_DT [Group data]
PK,FK1CNTRPRTY_ID [CNTRPRTY_ID]
PK GRP_INTRNL_ID [Group internal identifier]
GRP_CNTRPRTY_RLTNSHP [Group counterparty relationship]
PK,FK1CNTRPRTY_ID [CNTRPRTY_ID]
*CNTRPRTY_CDS [Counterparty codes]
PK,FK1CNTRPRTY_ID [Counterparty identifier]
PK TYP_CNTRPRTY_EXTRNL_ID [Type of counterparty external identifier]
*
*
*
*ENTRPRS_SZ_PRVS_PRD [Enterprise size previous period]
PK,FK1CNTRPRTY_ID [CNTRPRTY_ID]*1..*
3.1.1 Counterparties
The central entity of this part of the model is the Counterp arties entity. Counterparties represent the
minimum unit to which an instrument can be associated, and therefore the level of granularity of the
counterparties shall be the minimum unit for which reporting requirement exists.
Counterparties are uniquely identified by an internal identifier (i.e. the Counterparty identifier
(CNTRPRTY_ID) ).
The entity Enterprise size (previous period) provides information on some values related to a
counterparty but referred to a previous period. These values are used for derivation purposes.
3.1.2 Counterpa rties codes
One Counterparty might have several different identifiers provided by different authorities, other than
the internal identifier . The identifiers for the counterparties required by reporting regulations are
represented in the Counterp arties entity itself (i.e. the variable National identifier (NTNL_ID) ), whereas
other possible identifiers used by the reporting institution are included into a separate entity,
Counterparty codes (CNTRPRTY_CDS) .
February, 2017
7
For each counterparty there might be several records (i.e. several Counterparty external identifiers
(CNTRPRTY_ EXTRNL_ ID)) distinguished by their Type of counterparty external identifiers
(TYP_CNTRPRTY_EXTRNL_ID ).
There is one input cube corresponding to the Counterparties codes entity:
CUBE _ID DESCRIPTION
CNTRPRTY_CDS Counterparty codes
3.1.3 Related counterparties
The counterparties listed in the Counterparties entity might have different kinds of relationships with
other counterparties
Three different entities show the different kinds of relationships:
CUBE_ID DESCRIPTION Main counterparty Associated counterparty
JNT_CNTRPRTS Joint counterparties CNTRPRTY_ID JNT_CNTRPRTY_COMPNNT
LNKD_ENTRPRSS Linked enterprises CNTRPRTY_ID LNKD_ENTRPRS_ID
PRTNR_ENTRPRSS Partner enterprises CNTRPRTY_ID PRTNR_ENTRPRS_ID
The main counterparty will be always represented in the counterparties main table (i.e. the cube
Counterparties ), while the associated counterparty may not necessarily be in the counterparties main
table.
3.1.4 Group
The group entity includes one cube with information related to th e groups involved in the calculation of
the enterprise size of the counterparty . The level of granularity of this entity is the group, uniquely
identified by an internal ID .
CUBE_ID DESCRIPTION
GRP_DT Group data
3.1.5 Group counterparty relationshi p
The group counterparty relationship entity serves to relate group data to the counterparties for which
they are used in the calculation of the enterprise size .
CUBE_ID DESCRIPTION
GRP_CNTRPRTY_RLTNSHP Group counterparty relationship
February, 2017
8
3.2 Instruments and related entities
3.2.1 Instruments
The instruments entity groups all the input cubes with the information about instruments. The level of
granularity o f these cubes is the single instrument, which is determined by the type of instrument. The
instruments are separated in different input cubes according to the type of instrument.
CUBE_ID DESCRIPTION
CRDT_CRD_DBT_CNVNNC_CRDT Credit card debt: convenience c redit
CRDT_CRD_DBT_EXTNDD_CRDT Credit card debt: extended credit
FCTRNG Factoring
INDRCT_FCTRNG Indirect factoring
FNNCL_LSS Financial leases
OTHR_DPSTS Other deposits
OTHR_LNS Other loans
OTHR_TRD_RCVBLS Other trade receivables
February, 2017
9
OVRDRFTS Overdrafts
RVRS_RPRCHS_LNS Reverse repurchase loans
TRNSFRBL_DPSTS Transferable deposits
PSTV_CRRNT_ACCNT Positive current accounts
Note that indirect factoring is linked to factoring, since one factoring instrument may have associated
several indirect factoring instruments.
3.2.2 Credit facilities
CUBE_ID DESCRIPTION
CRDT_FCLTS Credit facilities
3.2.3 Credit facilities -Instruments
CUBE_ID DESCRIPTION
CRDT_FCLTS_INSTRMNTS Credit facilities -Instruments
3.3 Protection s and related entities
February, 2017
10
3.3.1 Protection s
This entity includes all the items that may serve as protection received by the entity for risk mitigation
purposes. The level of granularity is the protection item. Protection s are represented in four cubes,
according to the nature of the protection and one cube Pool of items which contains protections
evaluated at pool level .
CUBE_ID DESCRIPTION
RL_ESTT_PRTCTN _CLM Real estate protection claim
OTHR_PHYSCL_PRTCTN Other physical protection
SCRTS_PRTCTN Securities protection
PL_ITM Pool of items
OTHR_FNNCL_PRTCTN Other finan cial protection
Real estate protection claims represent one specific claim on a real estate item, which will have its own
values associated.
February, 2017
11
3.3.2 Protection value
The different types of values that may be available for each protection item, as well as differen t
valuation dates, are represented in a separate entity, in order to have the possibility to provide the
valuation of a protection item at different dates. This entity may contain, for each protection item,
different types of values at different valuation dates.
CUBE_ID DESCRIPTION
PRTCTN_VL Protection value
3.4 Securities data
3.4.1 Registry table of securities
The master data for securities is included in a single cube, where the level of gr anularity is the security.
CUBE_ID DESCRIPTION
RGSTRY_TBL_SCRTS Registry table of securities
3.4.2 Owned securities
The data for securities characteristics that are depend ent to the reportin g agent evaluation, the level of
granularity is the combination of security ID, owner ID, accounting classification, prudential portfolio,
approach for prudential purposes, the impairment status and the source of encumbrance.
February, 2017
12
CUBE_ID DESCRIPTION
OWND_SCRTY Owned securities
3.5 Credit transfer / Securitisations and o ther credit transfer
This entity includes the information related to securitisations and other credit transfer. The level of
granularity is the credit transfer.
CUBE_ID DESCRIPTION
SCRTSTNS_OTHR_CRDT_TRNSFRS Securitisations and other credit transfers
3.6 Relations between main entities
The entities described in the previous paragraphs are related to each other by means of two linking
entities: Transactions -Counterparties and Instruments -Protections ; except for the securities registry
table , which is dir ectly linked to the counterparties.
3.6.1 Transactions –Counterparties
This entity serves to link the counterparties and all types on transactions, when many -to-many relations
are possible.
February, 2017
13
The level of granularity depends on four different variables. One counte rparty may be part of many
transactions, and one transaction may involve several counterparties. Besides that, for the same
transaction, one counterparty may have different roles. The transaction ID is not unique (but
instruments, credit facilities, credit transfer, and protection received have unique IDs at their respective
level), therefore the type of transaction is required as part of the primary key.
CUBE_ID DESCRIPTION
TRNSCTNS_CNTRPRTS Transactions -Counterparties
3.6.2 Instrument s–Protections
This entity serves to link the protection received to the instruments it is protecting.
CUBE_ID DESCRIPTION
INSTRMNTS_PRTCTNS Instruments -protections
3.7 Process parameters
These entities serve to introduce parameters necessary for generating the output information fr om the
input. They are not linked to other entities. For a detailed specification see “4.1 Parameters (PRMTR)”
3.8 Entity Relationship Model – graphical illustration
February, 2017
14
Please note that the entities “Instruments ” and “ Protection received ” act as containers for related cubes ,
as specified in the relevant sections.
February, 2017
15
4 Input instructions
This chapter provides further explanations on the content of the input cubes described in the section
dedicated to ERM.
4.1 Parameters (PRMTR )
The cube Parameters (PRMTR ) contains parameters that the institution pr ocessing the data h as to
provide and that will be used in BIRD transformation rules .
In particular the cube describes:
– The accounting framework for solo reporting .
– If the j oint liability is registered as a distinct counterparty or it is not.
– If the carrying amount is derived following the BIRD rules or if it is provided as an input .
– If the reporting agent is subject to cap ital requirements according to Regulation (EU) No
575/2013.
– The f rame of reference, at which level the data are processed (group, solo, etc.).
– The i dentifier of the institution that processes the data.
4.2 Instruments
The BIRD group has developed a classifica tion of the instruments for the input . This classification was
obtained by assess ing the information that banks have in their operational systems, with the aim of
creating a common classification to which banks can easily map their internal categories. The difficulty
to define detailed categories applicable at European level has led to a classification quite close to
output requirements. The input classification is described below in table 1 , with a mapping to AnaCredit
and FinRep (see Commission Implementi ng Regulation (EU) No 680/2014) requirements .
Each category is represented in a cube . The general distinction between “deposits” and “loans” as
defined in Regulation (EU) No 549/2013 is followed.
The present input classification is sufficient to pro duce t he types of instrument used in AnaCredit,
FinRep, Balance Sheet Items (BSI) and Monetary Interest Rates (MIR) of the monetary financial
institution sector (see Regulation (EU) No 1071/2013 of the European Central Bank and Regulation
(EU) No 1072/2013 of th e European Central Bank).
The categories of “revolving loans” and “credit lines other than revolving credit” are identified by two
specific variables : Is revolving loan (IS_RVLVNG_LN ) and Is credit line other than revolving credit
(IS_CRDT_LN_OTHR_RV _CRDT ), respectively .
February, 2017
16
Table 1
BIRD input layer
Name Item Type of link Item Type of link
Transferable depositsOn demand [call] and short
notice [current account]It is a part of the FinRep item.Deposits other than
reverse repurchased
agreementsIt is a part of the
AnaCredit item.
Other depositsOn demand [call] and short
notice [current account]
or
Other term loansClassification depends on the
short notice.Deposits other than
reverse repurchased
agreementsIt is a part of the
AnaCredit item.
OverdraftsOn demand [call] and short
notice [current account]It is a part of the FinRep item. Overdrafts Exact correspondence
Reverse repurchase
loansReverse repurchase loans Exact correspondenceReverse repurchase
agreementsExact correspondence
Credit card debt:
convenience credit
Credit card debt:
extended credit
Financial leases Finance leases Exact correspondence Financial leases Exact correspondence
Factoring Trade receivables It is a part of the FinRep item.Trade receivables
or
Revolving credit other
than overdrafts and
credit card debt
or
Credit lines other than
revolving creditClassification depends on
the two specific variables.
Other trade receivables Trade receivables It is a part of the FinRep item.Trade receivables
or
Revolving credit other
than overdrafts and
credit card debt
or
Credit lines other than
revolving creditClassification depends on
the two specific variables.
Other loans Other term loans It is a part of the FinRep item.Other loans
or
Revolving credit other
than overdrafts and
credit card debt
or
Credit lines other than
revolving creditClassification depends on
the two specific variables.FinRep AnaCredit
Credit card debt Exact correspondence Credit card debt Exact correspondence
February, 2017
17
The institution shall ensure that each instrument is uniquely identified by the Instrument unique identifier
(INSTRMNT_UNQ_ID) . The Contract identifier (CNTRCT_ID) and Instrument identifier
(INSTRMNT_ID) , as defined in the AnaCredit Regulation, are present as separate variables. Practically
the institution may create the unique identifiers as the union of these two variables.
The cubes of instruments must normally be fed as from the moment when the loan is disbursed or the
money is deposited. However for some operations, such as credit card and overdraft, they have to be
fed from the moment when the credit is made available to the debtor. For some specific cases see
paragraph 4.4.
In some situations, in order to fulfil AnaCredit requireme nts, the cubes have to be kept in the input layer
beyond the natural life of the operations. In particular:
Written -off instruments (see AnaCredit Manual, part I, paragraph 5.2.2.2.1). The cubes must be
kept till the end of the reporting period (or longer if the client is above the threshold without
considering written off amounts).
Defaulted instruments that cease existing because of full repayment (see draft AnaCredit Manual,
part II, paragraph 3.5.15.1). The cubes must be kept till the end of the reporting period.
4.2.1 Specificities concerning factoring
Factoring transactions in the BIRD model are represented using the cubes Factoring (FCTRNG) and
Indirect factoring (INDRCT_FCTRNG) . Instances of the cube Factoring represent factoring operation s
between the “factor” (i.e. the entity buying invoi ces) and the “factoring client” (i.e. the entity selling the
invoices) while instances of the cube Indirect factoring represent the individual invoices of a factoring
operation if such detail of information is required by the output requirements .
As one fa ctoring transaction can contain multiple invoices and one invoice is always related to one
factoring transaction the relation between such a factoring transaction (i.e. an instance of the cube
Factoring ) and its invoices (i.e. instances of the cube Indirec t factoring ) is of the type one-to-many .
This relationship is established by the variable Connected factoring operation identifier (which contains
the Instrument unique identifier of the factoring transaction) in the cube Indirect factoring .
The distinction between factoring “with recourse ” and “without recourse ” is referred to the cube
“Factoring” .
4.3 Credit facilities (CRDT_FCLTS )
In a loan there are normally two elements: 1) the authorization, which is the decision of the bank to
grant credit to a c ustomer; and 2) the disbursement of money. The credit facility represents the first
element and i t is defined as follows:
“The commitment (revocable or irrevocable) made by a financial institution to make an amount of
money available to the customer (or a plurality of customers), or to assume for it an obligation to a third
party. The commitment is based on an agreement between the financial institution and the customer,
which originates from a request of the customer or an acceptance by the customer of a p roposal from
the financial institution. ”
February, 2017
18
Analogously to instruments, t he institution shall ensure that each credit facility is uniquely identified by
the Credit facility unique identifier (CRDT_FCLTY_UNQ_ID) . The connection between credit facilities
and in struments is described by the cube Credit facilities -Instruments (CRDT_FCLTS_INSTRMNTS) ,
which associates the Credit facility unique identifier and the Instrument unique identifier .
In general terms, c redit facilities c an be linked to one or many instrumen ts (belonging or not to the same
counterparty), the relation is many -to-many. The variable Type of facility (TYP_FCLTY) is equal to
“specific” (value “1”) when it can be linked to only one instrument , and “non -specific” (value “2”) when it
can be linked to more than one instrument . Some variables are typically applied to credit facilities , such
as Granted amount (GRNTD_AMNT) , Inception date (DT_INCPTN) , Commitment amount at inception
(CMMTMNT_INCPTN) and Revocable (RVCBL) . Other variables (currency, interes t rate, payment
frequency, etc.) normally present in the instrument cubes are also present in the credit facility cube ,
although at this stage they might not be necessary to satisfy AnaCredit requirements and in some
circumstances they are not applicable (e.g. the payment frequency may not be defined in the contract of
a non -specific credit facility).
In some cases a credit facility may not be present because of the nature of the instrument (e.g.
deposits) or it may have been revoked ; therefore, the varia bles Inception date and Commitment amount
at inception , required for AnaCredit, are present in the instrument cube s. These variables are applicable
to instruments when, in the context of non -specific credit facilities, the instrument is originated by a
specific contractual relationship, separated from the original contract of the credit facility.
The cube Credit facilities may be compiled from the moment the credit is authorized. However, before
the contract is signed by both parties, its compilation is not needed, because the related information
doesn’t need to be reported.
4.4 Specific operations
The BIRD group has analysed specific case studies, in order to give instructions concerning the
compilation of the input layer.
a) Instruments without a credit facilit y
Deposit account
General instructions
For deposit accounts that are not linked to a credit facility, the instrument cube must be fed if, at a
reference date, there is a debit balance, that is to say the observed agent holds some money in the
deposit accou nt. If the amount deposited is zero, it is not necessary to feed the instrument cube .
Instructions for specific variables
Inception date : the date on which the account is opened.
Settlement date : the date on which the first deposit of money on that account is done.
Commitment amount at inception : 0.
Off-balance sheet amount : 0.
February, 2017
19
Reverse repurchase loan
General instructions
For reverse repurchase loans that are not linked to a credit facility, the instrument cube must be fed
starting from the value date of t he operation.
Instructions for specific variables
Inception date : the date on which the agreement is signed.
Settlement date : the value date.
Commitment amount at inception : the spot price agreed on the inception date.
Off-balance sheet amount : 0.
Loan wh ose credit facility has been revoked
General instructions
If the credit facility is revoked (e.g. because of counterparty’s default), the instrument cube must be fed
as long as some amount is drawn .
Instructions for specific variables
Inception date : the s ame as before the revocation .
Settlement date : the same as before the revocation .
Commitment amount at inception : the same as before the revocation .
Off-balance sheet amount : 0.
b) Instruments with a specific credit facility
Mortgage loan
General instruction s
In case the money is disbursed after the stipulation of the contract (e.g. the bank waits for the legal
completion of the mortgage deed and the time limit for bankruptcy clawback actions), the instrument
cube must be fed when the loan is disbursed .
Instructions for specific variables
Inception date (on the credit facility) : the date on which the contract is stipulated .
Settlement date : the date on which the loan is disbursed .
Commitment amount at inception (on the credit facility) : the amount of the loan established by the
contract .
Off-balance sheet amount : 0.
Credit card
General instructions
February, 2017
20
If the credit card has been issued, the instrument cube must be fed even if the balance for the bank is
zero at the reference date or the client has not yet used th e credit card. The instrument ID and the
contract ID must remain the same, independently from the value of the balance.
Instructions for specific variables
Inception date (on the credit facility) : the date on which the contract is signed .
Settlement date : it is absent if, at the reference date, the balance for the bank (i.e. the outstanding
nominal amount) is zero. Otherwise it is the date on which the client uses the card for the first time .
Commitmen t amount at inception (on the credit facility) : the limit established by the contract.
Off-balance sheet amount : the difference between limit established by the contract and the debit
balance at the reference date .
Overdraft
General instructions
In case t he bank authorises a client to draw money from a current account, the instrument cube must
be fed once the credit facility is granted and the account is opened, even if the balance of the current
account is zero. If the balance of the current account is po sitive for the bank, then the cube Positive
current accounts (PSTV_CRRNT_ACCNT ) must be fed. This cube is symmetric to the cube Overdrafts
(OVRDRFTS) and for the same operation the same instrument unique identifier must be used,
independently from the sign of the balance.
Instructions for specific variables
Inception date (on the credit facility) : the date on which the contract is signed .
Settlement date : in the input cube Overdrafts it is absent if, at the reference date, the balance for the
bank (i.e. the Outstanding nominal amount ) is zero. Otherwise it is the date on which the debtor draws
funds under the credit limit for the first time . In this case it is absent in the input cube Positive curre nt
accounts .
Commitment amount at inception (on the credit facility) : the limit established by the contract.
Off-balance sheet amount : in the input cube Overdrafts it is the difference between the limit established
by the contract and the debit balance at the reference date. In the input cube Positive current accounts
it is the limit established by the contract.
c) Instruments with a non-specific credit facility
Export advances
Description
the bank grants a client a credit facility for export advances (amount 100); the uses of the credit facility
that can be made from time to time have a lower amount, which is related to the individual delivery
financed; at the reference date two loans (amounts 50 and 20) are present.
General instructions
The instrument cubes of the single loans must be fed starting from the date they are disbursed.
Instructions for specific variables
February, 2017
21
Inception date : for each loan it is the date of its own contract .
Settlement date : for each loan it is the date on which the loan is disbursed .
Commitment amount at inception : for each loan it is the amount disbursed at the settlement date.
Off-balance sheet amount : for each loan it is zero .
4.5 Securities
4.5.1 Registry table of securities
The Registry table of securities ( RGSTRY_TBL_SCRTS) contains regist ry information on securities,
characteristics of the securities that are stable over time. The cube is used mainly to feed the Security
Holding Statistics (SHS) reporting requirements and to describe specific protections in AnaCredit
reporting.
The cube k ey is the internal secu rity identifier , by which it is possible to uniquely identify the security ,
also in case of security without ISIN code.
4.5.2 Owned Securities
The cube Owned securities (OWND_SCRTY) contains information on th e securit ies owned by the
institution . The cube describe s the ownership of the securities and the characteristics of the securities
that depend on the reporting agent evaluation .
The cube has been created for the scope of SHS reporting. The dimensions of the cube are a first draft,
which can be revised.
4.5.3 Special characteristics for SHS reporting
Some information needed to satisf y SHS requirements will be derived by transformation rules .
In particular, the instrument classification according to ESA 2010 will be obtain ed by the variables Type
of security (TYP_SCRTY ), Is short term (IS_SHRT_TRM) and Is listed (IS_LSTD) , which are required in
the input cube Registry table of securities .
Moreover, the instrument seniority type will be derived by using three different input variables: Security
level (SCRTY_LVL) , Security rank level (SCRTY_RNK_LVL) and Security Guarantee level
(SCRTY_GRNT_LVL) .
Specific rules will also be developed to calculate the exposure class and the risk weight when the
standardised approach is adopted. The input information need ed for this calculation will be included in
the next release. The institution may also assign the exposure class and the risk weight directly as input
information .
February, 2017
22
4.6 Collateral and guarantees
4.6.1 Instruments -protections (INSTRMNTS_PRTCTNS)
The cube Instruments -protections provides the BIRD model with the functiona lity to connect instruments
and protections. Therefore the dimensions of this cube are the Instrument unique identifier
(INSTRMNT_UNQ_ID) and the Protection identifier (PRTCTN_ID) . As one instrument can be secured
by multiple protections, while one protect ion can be pledged to multiple instruments the relation
between instruments and protections is of the type many -to-many .
Additionally , this cube comprises variables which are connected to the instrument as well as the
protection. For example the Protectio n allocated value (PRTCTN_ALLCTD_VL) .
4.6.2 Protection cubes and the Protection value cube
A protection in the BIRD model is identified by its Protection identifier (PRTCTN_ID) . For each
protection the (reporting related) information is represented in one of the five protection cubes3.
Basically these five protection cubes can be categorised into financial protection cubes (i.e. Securities
protection and Other financial protection ) and physical protection cubes (i.e. Real estate protection and
Other phy sical protection ) and the Pool of (repo) items which could either be composed of securities or
other physical protections . The reason to decompose protections into four cubes is due to the
dependency of variables to a specific type of protection. For examp le, the variable Type of protection
(TYP_PRTCTN) is present in all protection cubes but is restricted to a specific subdomain for each of
those cubes. Another example is the variable Security identifier (SCRTY_ID) which is only meaningful
for protections w hich represent securities and therefore is placed in the Securities protection
(SCRTS_PRTCTN) cube.
Values corresponding to protections – the numerical value(s) as well as the variables specifying the
value(s) itself / themselves – are represented in the Protection value (PRTCTN_VL) cube. As one
protection can have multiple numerical (protection) values and each one of these values must always
correspond to a protection , the relation between a protection cube and the cube Protection value
(PRTCTN_VL) is of the type one-to-many . The dimensions enabling this one -to-many relationship are
the Protection valuation date (PRTCTN_VLTN_DT) and the Type of protection value
(TYP_PRTCTN_VL) in the Protection value (PRTCTN_VL) cube.
4.6.2.1 Securities protection (SCRTS_PRTCTN) & Registry table of securities
(RGSTRY_TBL_SCRTS)
The cubes Securities protection and Registry table of securities comprise (reporting related) information
about securities regardless the existence of an official ISIN. The cube Registry table of securities ’
purpose is to store the master data information about every security in the BIRD model. The Securities
protection cube enables the usage of such a security as a protection in the BIRD model.
3 The five “protection cubes” are: Other financial protection (OTHR_FNNCL_PRTCTN), Other physical protection
(OTHR_PHYSCL_PRTCTN), Securities protection (SCRTS_PRTCTN) , Real estate protection (RL_E STT_PRTCTN) and
Pool of items (PL_ITM) .
February, 2017
23
As one protection (identified by its Protection identifier ) can only represent one security (identified by its
Security identifier ) while one Security identifier can represent multiple protections the relation between
the Protection identifier and the Security identifier is of the type many -to-one.
4.6.2.2 Other financial pro tection (OTHR_FNNCL_PRTCTN)
The purpose of t his cube is to represent financial protections which do not qualify as securities.
4.6.2.3 Real estate protection item (RL_ESTT_PRTCTN) & Real estate protection
claim (RL_ESTT_PRTCTN_CLM)
The cube Real estate protection item contains protections representing real estate while the cube Real
estate protection claim contains claims related to such real estates. Therefore the cube Real estate
protection item is – in opposition to the other protection cubes – not linked direct ly with the cube
Instruments -protections but via the cube Real estate protection claim . As a consequence of this
structure the values of the variables Maturity date of the protection and Third party priority claims
against the protection for a relation bet ween an instrument and its real estate protection item are
derived by the minimum and the maximum (of the intermediate claim) respectively.
Please also note that the identifier of the cube Real estate protection item is the Protection item
identifier (in contrast to the Protection identifier in the other protection cubes).
4.6.2.4 Other physical protection (OTHR_PHYSCL_PRTCTN)
This cube contains protections which represent physical protections but do not qualify as a real estate
protection. For example this cube comprises protections which can be classified as “Gold” or “Other
physical collaterals”. The value “Other physical collaterals” (of the variable Type of protection ) can be
specified on a m ore granular level (for example “Motor vehicles” or “Aircraft collateral”) using the
attribute Subtype of protection (SBTYP_PRTCTN) .
4.6.2.5 Pool of (repo) items (PL_ITM) in a reverse repurchase agreement
In case it is sufficient to report protections on a pool le vel this cube provides (i) the functionality to
represent such pools in the BIRD model and (ii) additionally provides the (optional) functionality to store
the composition of such a pool (if known to the reporting agent). Currently this functionality is on ly used
for protection related to reverse repurchase agreements. The variable Protection identifier
(PRTCTN_ID) represents this cube ’s only dimension. It also contains the variable Type of protection
which is restricted to the members “Debt securities”, “Shares”, “Other equity”, “Investment fund shares
or units”, “Gold” and “Other physical protection ”. Therefore the cube Pool of items is limited to pools
representing either securities or physical protection.
The composition of such a pool can be establishe d using the variable Pool identifier (PL_ID) in the
cubes Securities protection or Other physical protection . The value of the variable Pool identifier in
these cubes refers to the Protection identifier in the cube Pool of items which establishes the one -to-
many relation between a pool and the underlying protections.
February, 2017
24
4.6.2.6 Protection value (PRTCTN_VL) & prioritization of the variable Protection
value
The cube Protection value contains the “numerical” (or numerical related) information for each
protection represen ted in one of the protection cubes. The numerical value itself is stored in the variable
Protection value (PRTCTN_VL) while the specification about what (kind of value), when (was the
valuation date) and who (did the valuation) / which (valuation method wa s used) is done via the
variables Type of protection value (TYP_PRTCTN_VL) , the Protection valuation date
(PRTCTN_VLTN_DT) and the Protection valuation approach (PRTCTN_VLTN_APPRCH) respectively.
As one protection can have multiple (types of) values and on e of those values is always related to one
protection the relation between a protection cube and the cube Protection value is of type one-to-
many . Due to the fact that (in most cases) the output requirements are limited to only one value the
BIRD model imp lements the following prioritization with respect to the Type of protection :
Type of protection Type of protection value Priority
Fair value 1
Types of protection values other than notional amount, market value, fair value or long-term sustainable value 2
Notional amount 3
Gold Fair value 1
Notional amount 1
Fair value 2
Fair value 1
Notional amount 2
Fair value 1
Notional amount 2
Types of protection values other than notional amount, market value, fair value or long-term sustainable value 3
Fair value 1
Types of protection values other than notional amount, market value, fair value or long-term sustainable value 2
Notional amount 3
Fair value 1
Types of protection values other than notional amount, market value, fair value or long-term sustainable value 2
Fair value 1
Types of protection values other than notional amount, market value, fair value or long-term sustainable value 2
Notional amount 3
Credit derivatives meeting the definition of financial guarantees Notional amount 1
Financial guarantees other than credit derivatives Notional amount 1
Guarantees other than financial guarantees and credit derivatives Notional amount 1
Market value 1
Long-term sustainable value 2
Market value 1
Long-term sustainable value 2
Market value 1
Long-term sustainable value 2
Notional amount 1
Fair value 2
Types of protection values other than notional amount, market value, fair value or long-term sustainable value 3
Notional amount 1
Fair value 2
Types of protection values other than notional amount, market value, fair value or long-term sustainable value 3Credit derivatives other than financial guarantees
Other financial protectionOther physical collaterals
Residential real estate collateral
Offices and commercial premises
Commercial real estate collateralDebt securities
Currency and deposits
Loans
Trade receivables
Shares, Other equity, Investment fund shares or units
Life insurance policies pledged
February, 2017
25
4.6.3 Specific cases
4.6.3.1 Reverse repurchase loans
The security bought in a reverse repurchase loan is considered as collateral. Similarly to securities
pledged for other types of instru ment, the cube Securities protection ( SCRTS_PRTCTN ) or Pool of
items (PL_ITM) (in case of a pool) must be compiled.
4.6.3.2 Financial leases
The leased asset in a financial lease is considered as collateral. Similarly to collateral pledged for other
types of inst rument, the cube of the collateral pertinent to the nature of the leased asset must be
compiled. At this stage, additional collateral covering a financial lease is not distinguished from the
leased asset.
4.7 Counterparties
4.7.1 Counterparty reference data
The cub e Counterparties (CNTRPRTS) contains information regarding all counterparties that are
relevant for reporting purposes. It includes the institution that processes the data , the components
(head office, foreign branches) of the legal entity to which it belongs and the issuer of the securities
described in the table Registry table of securities . The institution shall ensure that in the input layer
each counterparty is uniquely identified by its Counterparty identifier (CNTRPRTY_ID).
The structure of this cube include s several variables pertaining to each counterparty. As regards the
variable Institutional sector (INSTTTNL_SCTR) an input subdomain has been defined starting from the
lists of sectors currently used in the various countries . The definitions of the input members are mainly
based on Regulation (EU) No 549/2013 , with some additional subdivisions in a way that can support the
production of AnaCredit, FinRep, Balance Sheet Items (BSI) and Monetary Interest Rates (MIR) of the
monetary financial insti tution sector .
An additional variable named Institutional sector control (INSTTTNL_SCTR_CNTRL) has been created
to include in the sector classification the information on the control that is requested in ESA 2010
specific sectors as described by subsectors defined in ESA 2010 Chapter 2 . This input information,
combined with the Institutional sector is used to generate the sector classification required by the
Security Holding Statistics (SHS) reporting requir ements .
As regards the variable Country of resi dence (CNTRY) , the input subdomain does not include the codes
identifying international organisations. The latter are present in the subdomain of the variable
International organisations (INTRNTNL_ORGNSTNS) .
The BIRD group intends to work on a set of instructions to help banks classify international
organisations in the proper input institutional sectors.
February, 2017
26
Finally , the composition of the legal entity to which the institution processing the data belongs to is
described in the cube Composition of the legal ent ity (CMPSTN_LGL_ENTTY) .
4.7.2 Joint liabilities
Two approaches are currently followed by banks to handle joint liabilities:
1) the joint liability is treated as a specific counterparty;
2) only the components of the joint liability are considered as counterparties.
The solution adopted for the BIRD input layer is compatible with both approaches. Some i nformation is
related to both approaches . In particular for c ube Counterparties (CNTRPRTS) :
– Counterparty identifier
– Other variables related to the counterparty (name, i nstitutional sector, NACE, country, etc.)
– Note: in approach 1 the joint counterparty has got a specific identifier.
For all the cubes related to instruments:
– Instrument unique identifier
– Other variables related to the instrument (currency, purpose, intere st rate, outstanding nominal
amount, etc.)
For the c ube Transactions -Counterparties (TRNSCTNS_CNTRPRTS) :
– Counterparty identifier
– Transaction identifier
– Counterparty role in a transaction
– Note: in case of an instrument to a joint counterparty, for approach 1 there is only one record,
whereas for approach 2 there are several records.
Under approach 1 (the joint liability is treated as a specific counterparty) the following information has to
be provided.
For c ube Joint counterpart ies (JNT_CNTRPRTS) :
– Counte rparty identifier
– Joint counterparty component (JNT_CNTRPRTY_CMPNNT)
– Joint counterparty percentage (JNT_CNTRPRTY_PRCNTG) (by multiplying it by the
outstanding nominal amount, the joint liability amount can be obtained)
For approach 2 (only the components o f the joint liability are considered as counterparties) the following
information has to be reported.
For c ube Transactions -Counterparties (TRNSCTNS_CNTRPRTS) :
February, 2017
27
– Joint liability (JNT_LBLTY) , which can assume the values 0 (= no joint liability), 1 (= joint
liability – main counterparty), 2 (= joint liability – secondary counterparty)4
Joint liability amount (JNT_LBLTY_AMNT) : a schematic representation is displayed in the following
tables. Green parts refer to approach 1, whereas orange parts refer to approac h 2.
COUNTERPARTIES
INSTRUMENT
TRANSACTIONS -COUNTERPARTIES
JOINT LIABILITIES
4.8 Relationship between transactions and counterparties
For the cubes that refer to transactions in which one or more counterparties are involved, the
relationship between th em is generally described by the cube Transactions -Counterparties
(TRNSCTNS_CNTRPRTS) , which connects the Transaction identifier (TRNSCTN_ID) and the
Counterparty identifier (CNTRPRTY_ID) while specifying the Counterparty role in a transaction
(CNTRPRTY_RL ). This cube applies to four types of transaction: loan/deposit, credit facility, protection
and securitisation/transfer.
4 This variable is used to determine the counterparty’s features (institutional sector, NACE, country, etc.) needed to classify
the instrument. The possibility to classify the joint counterparty differently from its components cannot be handled in
approach 2.
Counterparty identifier NameInstitutional
sectorCountry ……..
A …… …… …… ……
B …… …… …… ……
AB …… …… …… ……
…… …… …… …… ……
Instrument
unique IDCurrency Purpose Interest rate Outstanding nominal amount ……..
InsID1 …… …… …… …… ……
InsID2 …… …… …… …… ……
InsID3 …… …… …… …… ……
…… …… …… …… …… ……
Counterparty identifier Transaction IdentifierCounterparty role in a
transactionJoint liability Joint liability amount ……..
A InsID1 Debtor 0 = no joint liability 0 ……
B InsID2 Debtor 0 = no joint liability 0 ……
AB InsID3 Debtor ……
A InsID3 Debtor 1 = main counterparty …… ……
B InsID3 Debtor 2 = secondary counterparty …… ……
…… …… …… …… …… ……
Counterparty identifier Joint counterparty component Joint counterparty percentage
AB A ……
AB B ……
…… …… ……
February, 2017
28
As regards the role of servicer, in case the instrument is serviced by the observed agent it is not
necessary to put the link between the observed agent identifier and the Instrument unique identifier in
the cube Transactions -Counterparties . In fact, this case is identified by the variable Is serviced by the
observed agent (IS_S RVCD_OBSRVD_AGNT ), which is present in the structure of instrument cubes.
4.9 Credit quality
4.9.1 Legal sources
4.9.1.1 Default
Article 178 of Regulation (EU) No 575/2013 (Capital Requirements Regulation – CRR) defines the
concept of “ default of an obligor” , to be used in the context both of the IRB approach and o f the
standardised approach to credit risk (see article 127). The definition specifies that a default shall be
considered to have occurred “when either or both of the following have taken place :
a) the institution considers that the obligor is unlikely to pay its credit obligations to the institution, the
parent undertaking or any of its subsidiaries in full, without recourse by the institution to actions
such as realising security;
b) the obligor is past due more than 90 days on any material credit obligation to the institution, the
parent undertaking or any of its subsidiaries […].”
The materiality threshold of a credit obligation past due is defined by the competent authorit ies and it
reflects a level of risk that the competent authority considers to be reason able. EBA has adopted draft
regulatory technical standards on materiality threshold of credit obligation past due and it has submitted
them to the European Commission . Their contents are not taken into consideration in the present
analysis .
EBA has issued guidelines on the application of the definition of default . They w ill apply from 1 January
2021 , but EBA encourages institutions to implement the changes prior to this date in order to build the
necessary time series .
4.9.1.2 Impaired
According to IFRS 96, a fina ncial asset is credit -impaired “when one or more events that have a
detrimental impact on the estimated future cash flows of that financial asset have occurred. Evidence
that a financial asset is credit -impaired include observable data about the following events:
(a) significant financial difficulty of the issuer or the borrower;
(b) a breach of contract, such as a default or past due event;
(c) the lender(s) of the borrower, for economic or contractual reasons relating to the borrower’s
financial difficulty, having gr anted to the borrower a concession(s) that the lender(s) would not
otherwise consider;
6 IFRS 9 has been adopted by Commission Regulation (EU) 2016/2067.
February, 2017
29
(d) it is becoming probable that the borrower will enter bankruptcy or other financial reorganisation;
(e) the disappearance of an active market for that financial asset because of financial difficulties; or
(f) the purchase or origination of a financial asset at a deep discount that reflects the incurred credit
losses. ”
4.9.1.3 Non-performing
Implementing Regulation (EU) No 680/2014 states (Annex V, Part 2, paragraph 29) that “non-
performin g exposures are those that satisfy any of the following criteria:
(a) material exposures which are more than 90 days past due;
(b) the debtor is assessed as unlikely to pay its credit obligations in full without realisation of collateral,
regardless of the existe nce of any past -due amount or of the number of days past due. ”
This categori sation “shall apply notwithstanding the classification of an exposure as defaulted for
regulatory purposes in accordance with Article 178 of CRR or as impaired for accounting purpo ses”.
“Exposures in respect of which a default is considered to have occurred in accordance with Article 178
CRR and exposures that have been found impaired in accordance with the applicable accounting
framework shall always be considered as non -performing exposures. ”
“Exposures shall be considered to have ceased being non -performing when all of the following
conditions are met:
(a) the exposure meets the exit criteria applied by the reporting institution for the discontinuation of the
impairment and default cl assification;
(b) the situation of the debtor has improved to the extent that full repayment, according to the original
or when applicable the modified conditions, is likely to be made;
(c) the debtor does not have any amount past -due by more than 90 days.
An expo sure shall remain classified as non -performing while those conditions are not met, even though
the exposure has already met the discontinuation criteria applied by the reporting institution for the
impairment and default classification ”.
“When forbearance measures are applied to non -performing exposures, the n exposures shall be
considered to have ceased being non -performing only when all the following conditions are met:
(a) the application of forbearance measures does not lead to the recognition of impairment or default;
(b) one year has passed since the forbearance measures were applied;7
(c) there is not, following the forbearance measures, any past -due amount or concern regarding the full
repayment of the exposure according to the post -forbearance conditions. The ab sence of concerns
shall be determined after an analysis of the debtor’s financial situation by the institution . Concerns
may be considered as no longer existing when the debtor has paid, via its regular payments in
accordance with the post -forbearance cond itions, a total equal to the amount that was previously
7 EBA has clarified (Q&A 2015_2145) that , in case the exposure has b een reclassified into “non -performing forborne
category” after forbearance measures were applied, the one year probation period starts from the date of reclassification in
non-performing forborne exposure .
February, 2017
30
past-due ( where there were past -due amounts) or that has been written -off (where there were no
past-due amounts) under the forbearance measures or the debtor has otherwise demonstrated its
ability to comply with the post -forbearance conditions.”
4.9.1.4 Forbearance
Implementing Regulation (EU) No 680/2014 defines (Annex V, Part 2, paragraph 30) f orborne
exposures as “debt contracts in respect of which forbearance measures have been extended.
Forbearance measur es consist of concessions towards a debtor that is experiencing or about to
experience difficulties in meet ing its financial commitments ( ‘financial difficulties ’).”
“A concession refers to either of the following actions:
(a) a modification of the previous te rms and conditions of a contract that the debtor is considered
unable to comply with due to its financial dif ficulties ( ‘troubled debt ’) resulting in insufficient debt
service ability and that would not have been granted had the debtor not been experiencin g financial
difficulties;
(b) a total or partial refinancing of a troubled debt contract, that would not have been granted had the
debtor not been experiencing financial difficulties.
A concession may entail a loss for the lender. ”
“Exposures shall be regarded as forborne where a concession has been made, irrespective of whether
any amount is past -due or of the classification of the exposures as impaired in accordance with the
applicable accounting framework or as defaulted in accordance with Article 178 of CRR . Exposures
shall not be treated as forborne whe re the debtor is not in financial difficulties. Nevertheless the
following shall be treated as forbearance measures:
(a) a modified contract that has been classified as non -performing before the modification or would in
the absence of modification be classified as non -performing;
(b) the modification that has been made to a contract involves a total or partial cancellation by write –
offs of the debt;
(c) the institution approves the use of embedded forbearance clauses for a debtor who is non –
performing or who would be considered as non -performing without the use of th ose clauses;
(d) simultaneously with or close in time to the concession of additional debt by the institution, the
debtor made payments of principal or interest on another contract with the institution that was non –
performing or would in the absence of refinancing be classified as non -performing. ”
“The classification as forborne shall be discontinued when all of the following conditions are met:
(a) the contract is cons idered to be performing, including where it has been reclassified from the non –
performing category after an analysis of the financial condition of the debtor showed that it no
longer met the conditions to be considered as non -performing ;
(b) a minimum two year probation period has passed from the date the forborne exposure was
considered to be performing;
(c) regular payments of more than an insignificant aggregate amount of principal or interest have been
made during at least half of the probation period;
February, 2017
31
(d) none o f the exposures to the d ebtor is more than 30 days past due at the end of the probation
period. ”
When the se conditions “are not met at the end of the probation period, the exposure shall continue to
be identified as performing forborne under probation unti l all the conditions are met. The conditions
shall be assessed on at least a quarterly basis. ”
“A forborne exposure may be considered as performing from the date the forbearance measures were
applied where either of the following conditions is met:
(a) that extension has not led the exposure to be classified as non -performing;
(b) the exposure was not considered to be a non-performing exposure at the date the forbearance
measures were extended. ”
Where additional forbearance measures are applied to a performing forb orne contract under probation
or it becomes more than 30 days past due, it shall be classified as non -performing.
4.9.2 Information in the input layer
4.9.2.1 Credit quality status
As they have relevant overlapping areas, the two definitions of “non -perfo rming” and “default” have
been managed with a single input variable named Credit quality status (CRDT_QLTY_STTS) . It is
present in the cube Counterparties (CNPRTS) and in the cubes of instruments. It may ass ume the
following values:
0 = not applicable;
11 = performing;
19 = d efault because unlikely to pay ;
20 = d efault because more than 90/180 days past due ;
18 = default because both unlikely to pay and more than 90/180 days past due ;
2 = n on-performing but not in default .
The accounting concept of “ impaired ” is identified in a different way as it corresponds to the value
“Stage 3 (IFRS) ” of the variable Impairment status (IMPRMNT_STTS) . Such va lue is normally
associated with one of the values related to default of the above variable , but in some particular cases it
can refer to the status of non -performing but not in default.
PERFORMING
Implementing Regulation (EU) No 680/2014 has to be followed .
DEFAULT BECAUSE UNLIKELY TO PAY
The criteria described in Article 178 of Regulation (EU) No 575/2013 have to be followed. In particular,
paragraph 3 contains some elements to be taken as indications of unlikeliness to pay.
EBA Guidelines provide clarif ication regarding the application of each indication of unlikeliness to pay
(see paragraph 5).
DEFAULT BECAUSE MORE THAN 90/180 PAST DUE
February, 2017
32
The criteria described in Article 178 of Regulation (EU) No 575/2013 have to be followed. In particular,
paragraph 2 gi ves some specifications regarding how to apply the definition of past due.
However, various approaches have been adopted across institutions and jurisdictions8. EBA Guidelines
(see paragraph 4) clarify some aspects regarding the counting of days past due, the technical past due
situation , the exposures to central governments, local authorities and public sector entities , factoring
and trade receivables and the materiality threshold. Further and more specific indications on the
materiality threshold are cont ained in the related RTS.
DEFAULT BECAUSE BOTH UNLIKELY TO PAY AND MORE THAN 90/180 PAST DUE
The criteria described in Article 178 of Regulation (EU) No 575/2013 have to be followed. This value
has to be provided when both the conditions have taken place.
NON -PERFORMING BUT NOT IN DEFAULT
This value can be used w hen an exposure is treated as credit -impaire d under IFRS 9 , but it does not
meet the definition of default (e.g. exposures where 180 days past due are used instead of 90 days on
the basis of the d iscretion provided in Article 178 of the CRR).
This value can also be used for cases in which the obligor has not net the conditions to cease being
non-performing while it meets the exit criteria for the discontinuation of default classification.
******
In the case of retail exposures the CRR states that institutions may apply the definition of default at the
level of an individual credit facility rather than in relation to the total obligations of a borrower. Similarly,
paragraph 154 of Implementing Regula tion (EU) No 680/2014 says that exposures shall be assessed
as non -performing on an individual basis (“transaction approach”) or by considering the overall
exposure to a given debtor ( “debtor approach”).
The input variable Assessment approach for credit qu ality status ( APPRCH_CRDT_QLTY_STTS) ,
which is present in the cubes of instruments, indicates the approach chosen by the institution. It may
assume the following values:
1 = debtor based ;
2 = transaction based.
The approach may be transaction base d only if the input variable Is retail exposure ( IS_RTL_EXPSR) is
equal to “true”. If all instruments of a counterparty are assessed according to the transaction based
approach, it is not needed to feed the credit quality status in the cube Counterparties .
For counterparties and instruments where a credit quality status is provided, the Date of default status
(DT_DFLT_STTS) and the Date of performing status (DT_PRFRMNG_STTS) have to be provided too.
The two dates may be different . For example, if a bank uses the transaction approach to assess a retail
exposure and the credit quality status changes from “default because more than 90/180 days past due ”
to “n on-performing but not in default ”, the reporting agent has to keep track of the date in which this
reclassification has occurred (Date of default status ) but it does not have to modify the Date of
performing status because the instrument is still non-performing.
The date of the status at a given reporting reference date must not be later than the reportin g reference
date. For instruments that have been performing (or n ot in default) since the inception, the inception
date of the instrument must be used.
8 Inter alia, according to Article 178 (1) (b) of the CRR , “competent authorities may replace the 90 days with 180 days for
exposures secured by residential property or SME commercial immovable property in the retail exposure class, as well as
exposures to public sector entities. The 180 days shall not ap ply for the purposes of Article 127 ”, which regards the
standardised approach to credit risk.
February, 2017
33
4.9.2.2 Forbearance and renegotiation
Modifications of the instrument ’s terms and conditions are capture d by the input variable Forbearance
and renegotiation status (FRBRNC_STTS) . It is present in the cubes of instruments and i t may assume
the following values:
4 = forborne: instruments with modified interest rate below market conditions ;
5 = forborne: instruments with other modified terms and conditions ;
3 = forborne: totally or partially refinanced debt ;
9 = renegotiated instrument without forbearance measures ;
8 = not forborne or renegotiated .
For the definition of the members see the same name variable in AnaCredit Regulation, which in turn
refers to Implementing Regulation (EU) No 680/2014 for what concerns the definition of forbearance
measures (see above par agraph 4.8.1.4 ). In particular , banks can refer to Annex V, Part 2.164, point
(a), for values 4 and 5 and to point (b) for value 3. As regards value 9, the AnaCredit Manual states that
it must be used “if any “price” element of a revolving instrument is ch anged for reasons other than
forbearance […]. A renegotiation of the interest rate (or spread) in response to a lower rate offered by
other banks should be considered as a sufficient reason for such a qualification ”.
The input variable Date of the forbeara nce and renegotiation status (DT_FRBRNC_STTS) has to be
filled in with the date on which the current status of forbearance and renegotiation is considered to have
occurred.
4.9.2.3 Other
Banks adopting IRB approaches for the calculation of the risk -weighted exposu re amounts for credit risk
have to provide the variable Probability of default (PD) in the cube Counterparties (CNTPRTS) , only for
debtors and those protection providers which are at the same time the issuers of the protection (in
particular, if the protec tion item is a financial guarantee as defined in the Implementing Regulation (EU)
No 680/2014). T he PD is determined in accordance with the CRR and it is a number from 0 to 1.
In order to check the presence of the PD, institutions are required to provide t he input variable
Approach for prudential purposes ( APPRCH_PRDNTL_PRPSS) in the cube Counterparties (CNPRTS) .
It may assume the following values:
0 = not applicable;
42 = s tandardised approach ;
66 = a dvanced IRB ;
67 = foundation IRB.
This variable must be compiled in accordance with the CRR. In particular, Article 107 states that
“institutions shall apply either the Standardised Approach provided for in Chapter 2 or, if permitted by
the competent authorities in accordance with Article 143, the Internal Rati ngs Based Approach provided
for in Chapter 3 to calculate their risk -weighted exposure amounts for the purposes of points (a) and (f)
of Article 92(3) ”.
February, 2017
34
4.10 Securitisations and other credit transfers
4.10.1 Registry cube Securitisations and other credit transfers
(SCRTSTNS_OTHR_CRDT_TRNSFRS )
Input information on securitisations and other credit transfers is based on a registry cube where all data
concern each operation. In this way data redundancy is avoided and the consistency of the information
produced is ensured.
This cube comprises information on securitisations, as defined in Article 4.1(61) of Regulation No
575/2013, and other sales of assets. It must be filled:
a) when the securitisation or the credit transfer originates from the institution and the transferred
assets are recognised in its balance sheet; or
b) when the transferred assets are serviced by the institution, both in the case the securitisation or
the credit transfer originates from the institution and in the case it originates from another
entity.
The str ucture of the cube is composed of the following variables9:
Securitisation/transfer identifier (SCRTSTN_TRNSFR_ID )
It univocally identifies each securitisation or credit transfer.
Type of risk transfer (TYP_RSK_TRNSFR )
– 1 = traditional securitisation (as de fined in Article 241(10) of Regulation No 575/2013);
– 2 = synthetic securitisation (as defined in Article 241(11) of Regulation No 575/2013);
– 3 = other credit transfer.
Treatment of securitised/ transferred assets in balance sheet
(TRTMNT_TRNSFRRD_ASSTS_BLNC _SHT )
– 0 = not applicable (operation originated by another entity);
– 1 = entirely recognised;
– 2 = recognised to the extent of the institution’s continuing involvement;
– 3 = entirely derecognised.
Is re-securitisation (IS_RSCRTSTN )
It identifies re -securitisat ions according to Regulation No 575/2013, article 4.1(63).
– 0 = not applicable ( for other credit transfers );
– T = true;
– F = false.
4.10.2 Variables in the cubes of instruments and credit facilities
The following variables must be compiled in the cub es of loans/deposits and credit facilities:
9 If a partial transfer occurs, the information refers to what is transferred.
February, 2017
35
Securitisation/transfer identifier (SCRTSTN_TRNSFR_ID )
– See above.
Relationship with securitisation or credit transfer (RLTNSHP_SCRTSTN_CRDT_TRNSFR )
– 0 = not applicable (no relationship);
– 1 = securitised/ transferre d asset;
– 2 = exposure to a securitisation or to a credit transfer ;
– 3 = credit to the vehicle deriving from the reimbursement of securitised assets ;
– 4 = exposure to a securitisation subject to re -securitisation .
Value 3 must be used for the credit that aris es when , if the originator recognises the transfer red assets
in its balance sheet, a part of securitised assets are reimbursed before the ABS and there are no
associated liabilities (e.g. in case of self -securitisations) and the vehicle deposits the liquid ity at another
institution10.
Value 4 is present only for owned securities.
Percentage transferred11 (PRCNTG_TRNSFRRD )
Percentage of the Outstanding nominal amount that has been transferred (sold). It is used to derive the
transferred amount, as defined by t he AnaCredit Regulation.
Original s ecuritisation identifier (ORGNL_ SCRTSTN_ID )
It univocally identifies the original securitisation in case of re -securitisations where the institution is the
originator . It is present only in the cube of Owned securities .
4.10.3 Information to be provided in the cube Transactions –
Counterparties (TRNSCTNS_CNTRPRTS)
In the cube Transactions -Counterparties each securitisation/transfer is a transaction, whose identifier is
expressed by the Securitisation/transfer identifier . For a trad itional securitisation the originator and the
transferee must be provided. The servicer of the securitisation can also be provided; however, if the
transferred instruments are individually serviced by different servicers, this role has to be linked to the
single instruments. Consequently these entities have to be registered in the cube Counterparties .
4.10.4 Specific instructions for some operations
Traditional securitisation where the reporting institution is the originator and it entirely
recognises securitised loans
Cubes of instruments
The bank includes the securitised assets (variable Relationship with securitisation or credit transfer =
“securitised/ transferred asset”) and securitisation positions (variable Relationship with securitisation or
10 This piece of information is mainly needed for CoRep. AnaCredit and SHS framework s don ’t require a separate
identification of this credit.
11 This variable is not present in the cube Credit facilities .
February, 2017
36
credit transfer = “exposure to a securitisation or to a credit transfer”), if any, and in every instance of
them it provides the Securitisation/transfer identifier .
For securitised assets the variable Percentage transferred is fed.
The variable Sources of encumbrance is “deposits other than repurchase agreements” fo r securitised
assets; it is “no t applicable” for securitisation positions if they are entirely derecognised .
Cube Securitisations and other credit transfers
The features of the securitisation are provided. In p articular:
the variable Type of risk transfer is “traditional securitisation”;
the variable Treatment of securitised/ transferred assets in balance sheet is “entirely recognised”.
Cube Transactions -Counterparties
With the securitisation/transfer identifier as Transaction identifier and the Type of transaction =
“Securitisation/Transfer”, the bank provides the Counterparty identifier of the following instances of the
variable Counterparty role in a transaction:
the “Originator”, which is the bank itself;
the “Transferee”, which is the vehicle to which the assets have been transferred;
the “Servicer”, which is the servicer of the securitisation12 .
Traditional securitisation where the reporting institution is the originator and it entirely
derecognises securitis ed loans
The variable Treatment of securitised/ transferred assets in balance sheet in the cube Securitisations
and other credit transfers is “entirely derecognised”.
If the bank is the servicer, it has to provide the same information13 described for traditi onal
securitisations where loans are entirely recognised. The same cubes of recognised assets have to be
fed.
If the bank is not the servicer, only information concerning securitisation positions has to be fed in the
input layer.
The variable Sources of en cumbrance is “not applicable ” for securitised assets; it is “no encumbranc e”
for securitisation positions unless they are encumbered in other transactions .
Traditional securitisation originated by another entity where the reporting institution is the
servi cer
For traditional securitisations where the bank is not the originator the variable Treatment of
securitised/ transferred assets in balance sheet in the cube Securitisations and other credit transfers is
“not applicable”.
The bank has to provide the same information described for traditional securitisations where loans are
entirely derecognised, including the variable Percentage transferred . The same cubes of recognised
assets have to be fed.
The variable Sources of encumbrance is “not applicable” for se curitised assets.
Self-securitisation
12 In case the transferred instruments are individually serviced by different servicers, this role has to be linked to the singl e
instrum ents.
13 At the present stage the variables that are not required to produce AnaCredit ( see Annex II of AnaCredit Regulation ) may
not be provided.
February, 2017
37
Self-securitisations are not distinguished from traditional securitisations where transferred assets are
entirely recognised .
The variable Sources of encumbrance is “no encumbrance ” for securitised assets if the ABS a re not
encumbered in other transactions.
Loan transfer aimed at issuing covered bonds
Cubes of instruments
The bank includes the sold assets (variable Relationship with securitisation or credit transfer =
“securitised/ transferred asset”) and in every insta nce of them it provides the Securitisation/transfer
identifier. The variable Percentage transferred is fed.
If the bank is financing the operation, it also has to include the loan to the vehicle for the purchase of
the assets (variable Relationship with se curitisation or credit transfer = “exposure to a securitisation or
to a credit transfer”).
The variable Sources of encumbrance is “debt securities issued – covered bonds securities ” for
transferred assets; it is “not applicable” for the exposures to the cr edit transfer if they are entirely
derecognised.
Cube Securitisations and other credit transfers
The features of the operation are provided. In particular:
the variable Type of risk transfer is “other credit transfer”;
the variable Treatment of securitised /transferred assets in balance sheet is “entirely recognised”.
At this stage, it is not needed to distinguish the case where the bank is financing from the case where
another institution is financing .
Cube Transactions -Counterparties
With the securitisatio n/transfer identifier as Transaction identifier and the Type of transaction =
“Securitisation/Transfer”, the bank provides the Counterparty identifier of the following instances of the
variable Counterparty role in a transaction :
the “Transferee”, which is the vehicle to which the assets have been transferred;
the “Servicer”, if there is a servicer of the whole operation different from the bank itself.
Warehousing
The bank must feed the input variables related to securitisations (“percentage transferred” in cluded)
also when the operation is in the warehousing phase.
At this stage, it is not needed to identify warehousing and to distinguish the case where the bank is
financing from the case where another institution is financing.
Securitisation with two vehi cles
In a securitisation where securitised assets are sold to a vehicle, which in turn sells them to another
vehicle that issues ABS, the following criteria must be followed to feed the cube Transactions –
Counterparties:
the second vehicle has the role of “ transferee”;
the original seller has the role of “originator”.
February, 2017
38
Securitisation with resale of loans
In a securitisation where securitised assets are sold to a financial intermediary, which in turn sells them
to a vehicle that issues ABS, the following crit eria must be followed to feed the cube Transactions –
Counterparties :
the vehicle has the role of “transferee”;
the financial intermediary has the role of “originator”.
Synthetic s ecuritisation originated by the reporting institution
Cubes of instruments
The bank includes the securitised assets (variable Relationship with securitisation or credit transfer =
“securitised/transferred asset”) and securitisation positions (variable Relationship with securitisation or
credit transfer = “exposure to a securitisati on or to a credit transfer”), if any, and in every instance of
them it provides the Securitisation/transfer identifier .
For securitised assets the variable Percentage transferred is zero.
Cube Securitisations and other credit transfers
The features of the securitisation are provided. In particular:
the variable Type of risk transfer is “synthetic securitisation”;
the variable Treatment of securitised/ transferred assets in balance sheet is “entirely recognised”.
Cube Transactions -Counterparties
With the sec uritisation/transfer identifier as Transaction identifier and the Type of transaction =
“Securitisation/transfer”, the bank provides its own Counterparty identifier as “originator” if it follows the
definition contained in Regulation (EU) No 1075/2013. If the transfer of risk is achieved by the use of an
instrument that qualifies as protection, the bank has also to provide the Counterparty identifier of the
“protection provider”. In this case, information concerning the protection has to be provided in the cubes
pertaining to the protection received, the protection valuation and the link between protection and
instruments.
A case study is described below, with some specific indications on the compilation of the input layer.
CASE STUDY
Description
The bank s igns a contract with an investor in order to partially transfer the risk of a pool of loans (1,000
loans for a total amount of 5 million euros). At the beginning of the transaction loans are performing.
The investor deposits cash collateral of 200,000 at t he bank. Any time that for each loan there is a
triggering event of default and the bank has to make a provision, the bank itself can use the cash
collateral for 95% of the provision (5% is the percentage of loss retained by the bank).
Example: if the loan is 100,000, it is defaulted since 1 of June, and the provision that the bank has
booked at the end of June is 5,000 euros, an amount of 4,750 euros (95% of 5,000) will be withdrawn
by the bank from the cash collateral deposited within the bank.
Note: in C oRep the cash collateral is used in the credit risk mitigation; in FinRep it is considered as
collateral received in all related information.
Input layer
Cubes of instruments
February, 2017
39
1,000 records with:
Relationship with securitisation or credit transfer = securit ised/transferred asset
Securitisation/transferred identifier = SEC1
Percentage transferred = 0
Cube Securitisations and other credit transfers
1 record with:
Securitisation/transferred identifier = SEC1
Type of risk transfer = synthetic securitisation
Treatment of securitised/transferred assets in balance sheet = entirely recognised
Cube Transactions -Counterparties
The same records as before the securitisation, plus 1 new record with:
Counterparty identifier = ID of the investor
Counterparty role in a trans action = protection provider
Transaction identifier = PROTID1
Type of transaction = protection
Cube Other financial protection
1 record with:
Protection identifier = PROTID1
Type of protection = currency and deposits
Cube Protection value
1 record with:
Protection identifier = PROTID1
Protection valuation date = ddmmyyyy
Type of protection value = notional amount
Protection value = 200,000
Protection valuation approach = other type of valuation
Cube Instruments -protections
1,000 records with:
Protection i dentifier = PROTID1
Instrument unique identifier = the ID of each loan
Protection allocated value = the result of the allocation of 200,000 to the loans, which should take
into account the loss retained by the bank
4.11 Other instructions
– Off-balance sheet amou nt. The difference between the granted amount of a credit facility and the
outstanding amount of related instruments generally generates an off -balance sheet amount . At this
stage, the BIRD does not manage the allocation of the granted amount on the instru ments.
Consequently, the off -balance sheet amount is not calculated by BIRD transformation rules; it is
instead an input variable Off-balance sheet amount (OFF_BLNC_SHT_AMNT) . In case of a
specific credit facility, this variable may be filled in the c ube Credit facilities if the instrument cube is
not present (e.g. a loan signed but not yet disbursed); otherwise it must be filled in the instrument
cube. In case of a non -specific credit facility, the institution may fill this variable both in the cube
Credit facilities and in the instrument cubes.
– Protection allocated value . For banks t his piece of information is a result of the allocation of
collateral and guarantees on the instruments. At this stage, the BIRD does not manage this
February, 2017
40
allocation. Consequent ly, the protection allocated value is an input variable Protection allocated
value (PRTCTN_ALLCTD_VL) , which is required in the cube Instruments -protections .
– Debt financing . In the AnaCredit output “debt financing” is a member of the domain Purpose
(PRPS) . In the BIRD input layer it is considered as a separate variable Is debt financing
(IS_DBT_FNNCNG) , which is in line with the way in which banks generally manage it.
February, 2017
41
5 Validation rules
This chapter describes the quality checks implemented for the BIRD i nput cubes.
The quality checks are mainly related to the consistency among value reported in different variables
that have specific relationships (consistency checks) and checks related to the absence of values in
different cubes . The absence check is abl e to identify the case in which the absence of a specific value
is admitted because of the nature of the variable or because the information i s not requested by
regulation ( e.g. Annex II and III of the Anacredit regulation).
The present release describes only the consistency checks , the checks are described , also in non –
formal language , in the BIRD DB, transformation cube. The validation rules have a SCHEME_ID with a
V as starting letter .
February, 2017
42
6 Derivation rules
6.1 Derivation of “Enterprise siz e”
6.1.1 Introduction
The AnaCredit regulation defines the variable Enterprise size (ENTRPRS_SZ) in accordance with the
Annex to Commission Recommendation 2003/361/EC14.
The bank may decide, counterparty by counterparty, to feed this piece of information dir ectly in the input
or to execute the transformation rule “Derivation of "Enterprise size" (see the BIRD database
SCHEME_ID = D_ENTRPRS_SZ_ CLCLTD1 ).
Input data needed to calculate the enterprise size comp rise:
– the date to which the calculation refers (see article 4, paragraphs 1 and 3);
– information concerning the staff headcount and financial ceilings (see article 2);
– the type of enterprise (see article 3);
– the possible control of the enterprise by public bodies (see article 3, paragraph 4);
– information on possible exception due to merge or acquisition by a larger group (annex to the
Commission decision (2012/838/EU) par. 1.1.3.1 6.e);
– data coming from consolidated accounts, where they exist (see article 6 );
– the data referred to partner enterprises (see article 3, paragraph 2) and linked enterprises (see
article 3, paragraph 3), in case they are not included in the counterparty accounts through
consolidation, which shall be used for the calculation (see art icle 6);
– the data related to the previous period, which shall be kept by the reporting bank (see article 4,
paragraph 2).
The absence of the data necessary for the calculation may implicate the classification of the
counterparty as “large enterprise”.
6.1.2 Description of input information
6.1.2.1 Cube Counterparties (CNTRPRTS)
14 All following quotations of articles and paragraphs refer to this legal text, unless otherwise specified. Counterp
arty ID … Date of
enterpris
e size Number
of
employe
es Balance
sheet
total Annual
turnover Type of
enterpris
e Control
by public
bodies Enterpris
e size
choice Enterpris
e size
(input) Exceptio
n due to
merge or
acquisitio
n
February, 2017
43
For Number of employees (NMBR_EMPLYS) , Balance sheet total (BLNC_SHT_TTL) and Annual
turnover (ANNL_TRNVR) see definitions in AnaCredit Regulation. Data are determined exclusively on
the basis of the indiv idual accounts of that enterprise.
Date of enterprise size (DT_ENTRPRS_SZ)
See definition in AnaCredit Regulation. It corresponds to the latest date of closure of the accounts (see
article 4, paragraph 1). In the case of newly established enterprises whose accounts have not yet been
approved, the data to apply is to be derived from a bona fide estimate made in the course of the
financial year (see article 4, paragraph 3).
Enterprise size choice (ENTRPRS_SZ_CHC)
It identifies the counterparties for which th e bank chooses to provide the enterprise size directly in the
input. It may assume the following values:
0 = the enterprise size is calculated by the BIRD derivation rule;
1 = the enterprise size is compiled directly in the input (the BIRD derivation rule is not run).
Type of enterprise (TYP_ENTRPRS )
It may assume the following values:
0 = not applicable;
1 = not an enterprise (see article 1);
2 = autonomous enterprise (see article 3, paragraph 1;
3 = enterprise having partner enterprises or linked enterpr ises (see article 3, paragraphs 2 and 3).
In case the variable Enterprise size choice = 1 the value 0 may be used. If Type of enterprise = 3 the
value of the variable Counterparty identifier (CNTRPRTY_ID) must be present in the cube Linked
enterprises or in the cube Group counterparty relationship as Counterparty identifier .
Exception due to merge or acquisition (EXCPTN_MRG_ACQSTN)
It identifies the case described in the annex to the Commission decision (2012/838/EU) par. 1.1.3.1
6.e, according to which the article 4(2) is not applicable if an SME is merged or acquired by a larger
group, in which case the SME shall lose its status immediately from the date of transaction. It may
assume the following values:
0 = not applicable;
1 = change in ownership due to a merge or acquisition;
2 = no change in ownership due to a merge or acquisition.
It is applicable only if Type of enterprise ≠ 1. In case the variable Enterprise size choice = 1 the value 0
may be used .
Control by public bodies (CNTRL_PBLC_BDS)
It identifies the case of article 3, paragraph 4, in which an enterprise cannot be considered an SME. It
may assume the following valu es:
0 = not applicable;
1 = true;
2 = false.
In case the variable Enterprise size choice = 1 the value 0 may be used .
February, 2017
44
Enterprise size (input) (ENTRPRS_SZ_ INPT )
Classification of enterprises by size, in accordance with the Annex to Commission Recommendatio n
2003/361/EC (for counterparties for which the bank provides the enterprise size directly in the input). It
may assume the following values:
0 = not applicable;
1 = large enterprise;
2 = medium enterprise;
3 = small enterprise;
4 = micro enterprise;
9 = not an enterprise.
In case the variable Enterprise size choice = 1 the value 0 may not be used .
6.1.2.2 Cube Linked enterprises (LNKD_ENTRPRSS)
It comprises all linked enterprises (see article 3, paragraph 3) to a counterparty, including the
counterparty itself, where the data are not included in the cube Group data . The data are derived from
their indi vidual accounts or their other individual data.
It is necessary to compile this cube only for the counterparties with Enterprise size choice = 0.
Counterparty ID Linked enterprise
ID Number of
employees Balance sheet
total Annual turnover
The variable Linked enterprise identifier (LNKD_ENTRPRS_ID) contains the identifier of the linked
enterprise.
6.1.2.3 Cube Partner enterprises (PRTNR_ENTRPRSS)
It comprises all partner enterprises (see article 3, paragraph 2) to a counterparty. It does no t comprise
the enterprises whose data are already included in the counterparty accounts through consolidation.
It comprises the partner enterprises of a linked enterprise to a counterparty unless it has already been
included in the consolidated accounts wi th a percentage at least proportional to the percentage interest
in the capital or voting rights (whichever is greater), in case of cross -holding the greater percentage
applies.
The data of the partner enterprises are derived from their accounts and their other data, consolidated if
they exist.
In case the partner enterprises has one or more linked enterprises , the 100% of the data of the linked
enterprises must be added to the partner enterprises data unless their accounts are already included
through co nsolidation16.
It is necessary to compile this cube only for the counterparties with Enterprise size choice = 0.
Counterparty Partner Number of Balance sheet Annual Percentage
16 The data of an enterprise are filled by following the criteria of article 6, paragraph 3 (subparagraph 1).
February, 2017
45
ID enterprise ID employees total turnover interest in the
capital or
voting righ ts
The variable Partner enterprise identifier (PRTNR_ENTRPRS_ID) contains identifies the partner
enterprise.
The variable Percentage interest in the capital or voting rights
(PRCNTG_INTRST_CPTL_VTNG_RGHTS) contains the p ercentage interest in the c apital or voting
rights (whichever is greater).
6.1.2.4 Cube Group data (GRP_DT)
It includes , where they exist , data originating from the consolidated accounts of the counterparty or from
the consolidated account s in which the counterparty is included through cons olidation.
It also includes , if they exist, data originating from the consolidated account s of linked enterprises ,
unless their accounts data are already included through consolidation.
Where in the consolidated accounts no staff data appear for a given e nterprise, staff figures (to be
included in this cube) are calculated by aggregating proportionally the data from its partner enterprises
and by adding the data from the enterprises to which the enterprise in question is linked .
As an example if the enterp rises A is linked with enterprises C and D and all of them are fully
consolidated in GROUP Z the GROUP Z data has to be provided in the following cube together with the
relation between Z and A in the cube “Group counterparty relationship” .
Group Internal
ID Number of
employees Balance sheet
total
Annual
turnover
The variable Group internal ID (GRP_INTRNL_ID) identifies the group whose consolidated data are
used in the calculation of the enterprise size.
6.1.2.5 Cube Group counterparty relationship (GRP_CN TRPRTY_RLTNSHP)
It connects all groups whose consolidated data are present in the cube Group data to the counterparties
for which these data are used in the calculation of the enterprise size.
Group Internal
ID Counterparty
ID
6.1.2.6 Cube Enterprise size (pr evious period) (ENTRPRS_SZ_PRVS_PRD)
It contains information on the enterprise size calculated for the previous accounting period.
February, 2017
46
Counterparty ID Enterprise size
(calculated) Enterprise size
(preliminary)
Enterprise size (preliminary) (ENTRPRS_SZ_ PRLMNRY )
Preliminary setting of the enterprise size as calculated for the previous accounting period “(see STEP 2
and STEP 3 of the derivation rule) . It may assume the following values:
2 = medium enterprise ;
3 = small enterprise;
4 = micro enterprise;
6 = large enterprise (from input data);
7 = large enterprise because of absence of input data.
Enterprise size (calculated) (ENTRPRS_SZ_ CLCLTD )
Enterprise size as calculated for the previous accountin g period “(see STEP 2 and STEP 4 of the
derivation rule) . It may assume the following values:
2 = medium enterprise;
3 = small enterprise;
4 = micro enterprise;
6 = large enterprise (from input data);
7 = large enterprise because of absence of input data.
6.1.3 VTL expression and illustrative examples
CNTRPRTS
CNTRP RTY_
ID … DT_ENTRPRS_
SZ NMBR_EMPL
YS BLNC_SHT_T
TL ANNL_TRN
VR TYP_ENTRP
RS CNTRL_PBLC_B
DS ENTRPRS_SZ_C
HC ENTRPRS_SZ_IN
PT EXCPTN_MRG_ACQS
TN
E 200 8000 9000 3 2 0 0 1
H 5 500 450 3 2 0 0 2
A 50 5000 5000 2 2 0 0 2
L 345 33214 32321 0 2 1 1 1
J 350 8000 8000 2 2 0 0 2
LNKD_ENTRPRSS
CNTRPRTY_ID LNKD_ENTRPRS_ID NMBR_EMPLYS BLNC_SHT_TTL ANNL_TRNVR
E G 60 3000 2500
E F 150 2000 6000
PRTNR_ENTRPRSS
CNTRPRTY_ID PRTNR_ENTRPRS_ID NMBR_EMPLYS BLNC_SHT_TTL ANNL_TRNVR PRCNTG_INTRST_CPTL_VTNG_RGHTS
E H 5 500 450 0.35
H G 60 3000 2500 0.35
GRP_DT
GRP_INTRNL_ID NMBR_EMPLYS BLNC_SHT_TTL ANNL_TRNVR
Y 3000 9000 4050
Z 2000 85000 98000
February, 2017
48
GRP_CNTRPRTY_RLTNSHP
GRP_INTRNL_ID CNTRPRTY_ID
Y H
Z E
ENTRPRS_SZ_PRVS_PRD
CNTRPRTY_ID ENTRPRS_SZ_CLCLTD ENTRP RS_SZ_PRLMNRY
E 2 2
H 6 4
A 2 2
/* CNTRPRTS_ATNMS contains the counterparties that are autonomous or not an enterprise, and for which the enterp rise size is
calculated */
CNTRPRTS_ATNMS := CNTRPRTS [filter(ENTRPRS_SZ_CHC=0 and TYP_ENTRPRS in (1, 2))] [keep(CNTRPRTY_ID, NMBR_EMPLYS,
BLNC_SHT_TTL,ANNL_TRNVR, TYP_ENTRPRS, CNTRL_PBLC_BDS, EXCPTN_MRG_ACQSTN)]
CNTRPRTY_ATNMS
CNTRPRTY_ID NMBR _EMPLYS BLNC_SHT_TTL ANNL_TRNVR TYP_ENTRPRS CNTRL_PBLC_BDS EXCPTN_MRG_ACQSTN
A 50 5000 5000 2 2 2
J 350 8000 8000 2 2 2
/* CNTRPRTS_PRVS contains the calculated values in the previous period. For those counterparties for which there was no value in
the previous period, a null value is assigned */
CNTRPRTS_PRVS := [left CNTR PRTS as "A", ENTRPRS_SZ_PRVS_PRD as "B" on A.CNTRPRTY_ID = B.CNTRPRTY_ID] {keep(A.CNTRPRTY_ID as
"CNTRPRTY_ID", B.ENTRPRS_SZ_CLCLTD as "ENTRPRS_SZ_CLCLTD", B.ENTRPRS_SZ_PRLMNRY as "ENTRPRS_SZ_PRLMNRY")}
CNTRPRTY_PRVS
February, 2017
49
CNTRPRTY_ID ENTRPRS_SZ_CLCLTD ENTRP RS_SZ_PRLMNRY
E 2 2
H 6 4
A 2 2
J
PRTNR_ENTRPRS:= get("PRTNR_ENTRPRSS")
PRTNR_ENTRPRS
CNTRPRTY_ID PRTNR_ENTRPRS_ID NMBR_EMPLYS BLNC_SHT_TTL ANNL_TRNVR PRCNTG_INTRST_CPTL_VTNG_RGHTS
E H 5 500 450 0.35
H G 60 3000 2500 0.35
LNKD_ENTRPRS := get(" LNKD_ENTRPRSS")
LNKD_ENTRPRS
CNTRPRTY_ID LNKD_ENTRPRS_ID NMBR_EMPLYS BLNC_SHT_TTL ANNL_TRNVR
E G 60 3000 2500
E F 150 2000 6000
GRP_ENTRPRS:= get(“GRP_DT”)
GRP_ENTRPRS
GRP_INTRNL_ID NMBR_EMPLYS BLNC_SHT_TTL ANNL_TRNVR
Y 3000 9000 4050
Z 2000 85000 98000
GRPRLT_ ENTRPRS:= get(“GRP_CNTRPRTY_RLTNSHP”)
GRP_ENTRPRS
February, 2017
50
GRP_INTRNL_ID CNTRPRTY_ID
Y H
Z E
/* CNTRPRTS_INPT contains the counterparties for which the enterprise size is provided as input already with the structure that
can be united with the calculations ("Counte rparty ID", "Enterprise size calculated", "Enterprise size choice") */
CNTRPRTS_INPT := CNTRPRTS[filter(ENTRPRS_SZ_CHC=1), keep (CNTRPRTY_ID, ENTRPRS_SZ as "ENTRPRS_SZ_CLCLTD", ENTRPRS_SZ_CHC)]
CNTRPRT_INPT
CNTRPRTY_ID ENTRPRS_SZ_CLCLTD ENTRPRS_SZ_CLCLT D
L 0 1
/* In order to aggregate the partner enterprises, the relevant figures have to be multiplied by the percentage of interest in th e
capital or voting rights */
PRTNR_ENTRPRS_AGG := PRTNR_ENTRPRS [calc(PRCNT G_INTRST_CPTL_VTNG_RGHTS * BLNC_SHT_TTL as "AGGRGBL_BLNC_SHT_TTL" role MEASURE,
PRCNTG_INTRST_CPTL_VTNG_RGHTS * NMBR_EMPLYS as "AGGRGBL_NMBR_EMPLYS" role MEASURE, PRCNTG_INTRST_CPTL_VTNG_RGHTS * ANNL_TRNVR as
"AGGRGBL_ANNL_TRNVR" role MEASURE)]
PRTNR_ENT RPRS _AGG
CNTRPRTY
_ID PRTNR_ENTRPR
S_ID NMBR_EMP
LYS BLNC_SHT_
TTL ANNL_TR
NVR PRCNTG_INTRST_CPTL_VTNG
_RGHTS AGGRGBL_NMBR_E
MPLYS AGGRGBL_BLNC_SH
T_TTL AGGRGBL_ANNL_T
RNVR
E H 5 500 450 0.35 1.75 175 157.5
H G 60 3000 2500 0.35 21 1050 875
/* For group enterprises, the relevant figures are taken from the group data */
GRP_ENTRPRS_AGG := [GRP_DT as "A", GRP_CNTRPRTY_RLTNSHP as "B" on (A.GRP_INTRNL_ID = B.GRP_INTRNL_ID )] {keep(B.CNTRPRTY_ID a s
"CNTRPRTY_ID", A.NMBR_EMPLYS as "AGGRGBL_NMBR_EMPLYS", A.BLN C_SHT_TTL as "AGGRGBL_BLNC_SHT_TTL", A.ANNL_TRNVR as
February, 2017
51
"AGGRGBL_ANNL_TRNVR")}
GRP_ENTRPRS _AGG
CNTRPRTY_ID AGGRGBL_NMBR_EMPLYS AGGRGBL_BLNC_SHT_TTL AGGRGBL_ANNL_TRNVR
H 3000 9000 4050
E 2000 85000 98000
/* The relevant figures for all counterparties have to be aggregated in order to have one single value for ea ch counterparty */
TTL_AGG :=
PRTNR_ENTRPRS_AGG[keep CNTRPRTY_ID, AGGRGBL_BLNC_SHT_TTL, AGGRGBL_NMBR_EMPLYS, AGGRGBL_ANNL_TRNVR] +
LNKD_ENTRPRS [keep CNTRPRTY_ID, NMBR_EMPLYS as "AGGRGBL_NMBR_EMPLYS", BLNC_SHT_TTL as "AGGRGBL_BLNC_SHT_TTL", ANNL_TRNVR a s
"AGGRGBL_ANNL_TRNVR"] +
GRP_ENTRPRS_AGG [keep CNTRPRTY_ID, AGGRGBL_BLNC_SHT_TTL, AGGRGBL_NMBR_EMPLYS, AGGRGBL_ANNL_TRNVR] +
CNTRPRTY_ATNMS [keep CNTRPRTY_ID, BLNC_SHT_TTL as "AGGRGBL_BLNC_SHT_TTL", NMBR_EMPLYS as "AGGRGBL_NMBR_EMPLYS", ANNL_TRNVR as
"AGGRGBL_ANNL_TRNVR"]
TTL_AGG
CNTRPRTY_ID AGGRGBL_NMBR_EMPLYS AGGRGBL_BLNC_SHT_TTL AGGRGBL_ANNL_TRNVR
E 2211.75 90175 106657.5
H 3001.75 10050 4925
A 50 5000 5000
J 350 8000 8000
/* Preliminary setting is th e pure calculation of enterprise size before considering the results in the previous period */
PRLMNRY_STTNG := FNL_AMNT[calc
if isnull(AGGRGBL_NMBR_EMPLYS) or (isnull(AGGRGBL_BLNC_SHT_TTL) and isnu ll(AGGRGBL_ANNL_TRNVR)) then 7
elseif AGGRGBL_NMBR_EMPL YS < 10 and (AGGRGBL_BLNC_SHT_TTL <= 2000000 or AGGRGB L_ANNL_TRNVR <= 2000000) then 4
elseif AGGRGBL_NMBR_EMPLYS < 50 and (AGGRGBL_BLNC_SHT_TTL <= 10000000 or AGGRGBL _ANNL_TRNVR <= 10000000) then 3
elseif AGGRGBL_NMBR_EMPLYS < 250 and (AGGRGBL_BLNC_SHT_TTL <= 43000000 or AGGRGBL _ANNL_TRNVR <= 50000000) then 2
else 6
as "ENTRPRS_SZ_PRLMNRY_T"]
February, 2017
52
ALL := [TTL_AGG as "A", CNTRPRTS_PRVS as "B", CNTRPRT as "C" on (A.CNTRPRTY_ID = B.CNTRPRTY_ID and A.CNTRPRTY_ID = C.CNTRPRTY _ID)]
{keep(A.CNTRPRTY_ID, A.ENTRPRS_SZ_PRLMNRY_T, B.ENTRPRS_SZ_CLCLTD, B.ENTRPRS_SZ_PRLMNRY, C.TYP_ENTRPRS, C.CNTRL_PBLC_BDS,
C.EXCPTN_MRG_ACQSTN as "MRGACQ")}
ALL
CNTRPRTY_ID ENTRPRS_SZ_PRLMNRY_T ENTRPRS_SZ_CLCLTD ENTRPRS_SZ_PRLMNRY TYP_ENTRPRS CNTRL_PBLC_BDS MRGACQ
E 6 2 2 3 2 1
H 6 6 4 3 2 2
A 2 2 2 2 2 2
J 6 2 2 2
/* The final setting takes into account: Whether: (i) The enterprise is not an enterprise (TYP_ENTERPRS=1); (ii) it is controlle d
by public bodies; (iii) There where no input data (ENTRPRS_SZ_PRLMNRY_T = 7); (iv) there was no information regarding previous
periods; (v) the mergers and acquisitions exception applies; and (vi) in any other case, the interaction between the result o f the
calculation for the current period plus the results for previous period applies */
FNL_STTNG := ALL[calc
(if TYP_ENTRPRS = 1 then 9
elseif CNTRL_PBLC_BDS = 1 then 6
elseif ENTRPRS_SZ_PRLMNRY_T = 7 then 7
elseif ENTRPRS_SZ_CLCLTD =null then ENTRPRS_SZ_P RLMNRY_T
elseif MRGACQ=1 then ENTRPRS_SZ_PRLMNRY_T
elseif ENTRPRS_SZ_PRLMNRY_T = 4 then
if ENTRPRS_SZ_CLCLTD = 4 then 4
elseif ENTRPRS_SZ_CLCLTD in (6,2,3,7) and ENTRPRS_SZ_PRLMNRY = 4 then 4
elseif ENTRPRS_SZ_CLCLTD = 3 and ENTRPRS_SZ_PR LMNRY in (6,2,3,7) then 3
elseif ENTRPRS_SZ_CLCLTD = 2 and ENTRPRS_SZ_PRLMNRY = 3 then 3
elseif ENTRPRS_SZ_CLCLTD = 2 and ENTRPRS_SZ_PRLMNRY in (6,2,7) then 2
elseif ENTRPRS_SZ_CLCLTD in (6,7) and ENTRPRS_SZ_PRLMNRY = 3 then 3
February, 2017
53
elseif ENTRPRS_SZ_CLCLTD in (6,7) and ENTRPRS_SZ_PRLMNRY = 2 then 2
else if ENTRPRS_SZ_CLCLTD in (6,7) and ENTRPRS_SZ_PRLMNRY in (6,7) then 6
else null
elseif ENTRPRS_SZ_PRLMNRY_T = 3 then
if ENTRPRS_SZ_CLCLTD = 3 then 3
elseif EN TRPRS_SZ_CLCLTD in (6,2,4,7) and ENTRPRS_SZ_PRLMNRY = 3 then 3
elseif ENTRPRS_SZ_CLCLTD = 4 and ENTRPRS_SZ_PRLMNRY = 4 then 4
elseif ENTRPRS_SZ_CLCLTD = 4 and ENTRPRS_SZ_PRLMNRY in (6,2,7) then 3
elseif ENTRPRS_SZ_CLCLTD = 2 and ENTRPR S_SZ_PRLMNRY = 4 then 3
elseif ENTRPRS_SZ_CLCLTD = 2 and ENTRPRS_SZ_PRLMNRY in (6,2,7) then 2
elseif ENTRPRS_SZ_CLCLTD in (6,7) and ENTRPRS_SZ_PRLMNRY = 4 then 3
elseif ENTRPRS_SZ_CLCLTD in (6,7) and ENTRPRS_SZ_PRLMNRY = 2 then 2
else if ENTRPRS_SZ_CLCLTD in (6,7) and ENTRPRS_SZ_PRLMNRY in (6,7) then 6
else null
elseif ENTRPRS_SZ_PRLMNRY_T = 2 then
if ENTRPRS_SZ_CLCLTD = 2 then 2
elseif ENTRPRS_SZ_CLCLTD in (6,3,4,7) and ENTRPRS_SZ_PRLMNRY = 2 then 2
elseif ENTRPRS_SZ_CLCLTD = 4 and ENTRPRS_SZ_PRLMNRY = 4 then 4
elseif ENTRPRS_SZ_CLCLTD = 4 and ENTRPRS_SZ_PRLMNRY = 3 then 3
elseif ENTRPRS_SZ_CLCLTD = 4 and ENTRPRS_SZ_PRLMNRY in (6,7) then 2
elseif ENTRPRS_SZ_CLCLTD = 3 and ENTRPRS _SZ_PRLMNRY = 4 then 3
elseif ENTRPRS_SZ_CLCLTD = 3 and ENTRPRS_SZ_PRLMNRY in (6,7) then 2
elseif ENTRPRS_SZ_CLCLTD = 3 and ENTRPRS_SZ_PRLMNRY = 3 then 3
elseif ENTRPRS_SZ_CLCLTD in (6,7) and ENTRPRS_SZ_PRLMNRY in (3,4) then 2
else if ENTRPRS_SZ_CLCLTD in (6,7) and ENTRPRS_SZ_PRLMNRY in (6,7) then 6
else null
elseif ENTRPRS_SZ_PRLMNRY_T = 6 then
if ENTRPRS_SZ_CLCLTD in (6,7) then 6
elseif ENTRPRS_SZ_CLCLTD in (2,3,4) and ENTRPRS_SZ_PRLMNRY in (6,7) then 6
elseif ENTRPRS_SZ_CLCLTD = 2 and ENTRPRS_SZ_PRLMNRY in (2,3,4) then 2
elseif ENTRPRS_SZ_CLCLTD = 3 and ENTRPRS_SZ_PRLMNRY = 2 then 2
elseif ENTRPRS_SZ_CLCLTD = 3 and ENTRPRS_SZ_PRLMNRY in (3,4) then 3
elseif ENTRPRS_SZ_CLCLTD = 4 and ENTRPRS_SZ_PRLMNRY = 2 then 2
elseif ENTRPRS_SZ_CLCLTD = 4 and ENTRPRS_SZ_PRLMNRY = 3 then 3
else if ENTRPRS_SZ_CLCLTD = 4 and ENTRPRS_SZ_PRLMNRY = 4 then 4
else null
February, 2017
54
else null
) as "ENTRPRS_SZ_CLCLTD_T"]
FNL_STTNG
CNTRPRTY_I D ENTRPRS_SZ_PRLMNRY_T ENTRPRS_SZ_CLCLTD ENTRPRS_SZ_PRLMNRY TYP_ENTRPRS CNTRL_PBLC_BDS ENTRPRS_SZ_CLCLTD_T
E 6 2 2 3 2 6
H 6 6 4 3 2 6
A 2 2 2 2 2 2
J 6 2 2 6
FNL_STTNG := FNL_STTNG [keep (CNTRPRTY_ID, ENTRPRS_SZ_CLCLTD_T as "ENTRPRS_SZ_CLCLTD"), c alc 0 as "ENTRPRS_SZ_CHC" role MEASURE]
FNL_STTNG
CNTRPRTY_ID ENTRPRS_SZ_CLCLTD ENTRPRS_SZ_CHC
E 6 0
H 6 0
A 2 0
J 6 0
D_ENTRPRS_SZ_CLCLTD1 := union(FNL_STTNG, CNTRPRTS_INPT)
D_ENTRPRS_SZ_CLCLTD1
CNTRPRTY_ID ENTRPRS_SZ_CLCLTD ENTRPRS_SZ_CHC
E 6 0
H 6 0
A 2 0
J 6 0
L 0 1
February, 2017
55
D_ENTRPRS_SZ_CLCLTD1 := D_ENTRPRS_SZ_CLCLTD1 [calc
(if ENTRPRS_SZ_CLCLTD in (0,9) then 0
else if ENTRPRS_SZ_CLCLTD in (1,6,7) then 7
else ENTRPRS_SZ_CLCLTD)
as "ENTRPRS_SZ"]
D_ENTRPRS_SZ_CLCLTD1
CNTRPRTY_ID ENTRP RS_SZ_CLCLTD ENTRPRS_SZ_CHC ENTPRRS_SZ
E 6 0 7
H 6 0 7
A 2 0 2
J 6 0 7
L 0 1 0
6.1.4 Illustrative examples on how to feed the cubes
Example 2: No consolidated data
A
Linked
B C
D E
F G
HLinked
Partner 25% Partner 30%
Linked Linked
Partner 35%
Counterparty A:
Cube “Counterparties”
Counter
party ID … Date
of
Enterp
rise
size Numbe
r of
employ
ees Bala
nce
sheet
total Annu
al
turno
ver Type
of
enterp
rise Contr
ol by
publi
c
bodie
s Enterp
rise
size
choice Enterp
rise
size
(input) Except
ion
due to
merge
or
acquisi
tion
A A data A data A
data A
data A data A
data A data A data A data
Cube “Linked enterprise s”
Counterparty ID Linked
enterprise ID Number of
employees Balance sheet
total Annual turnover
A B B data B data B data
A C C data C data C data
A A A data A data A data
Cube “Partner enterprises”
Counterparty
ID Partner
enterprise ID Number of
emplo yees Balance
sheet total Annual
turnover Percentage
interest in the
capital or
voting rights
A D D data D data D data 25%
A E E +F+G data E +F+G data E +F+G data 30%
February, 2017
57
Example 3: Consolidated data
Notice that in this case E is not included in A consolidated accounts.
A Group
E groupA
Linked
B C
D E
F G
HLinked
Partner 25% Partner 30%
Linked Linked
Partner 35%
Counterparty A:
Cube “Counterparties”
Counter
party ID … Date
of
Enterp
rise
size Numbe
r of
employ
ees Bala
nce
sheet
total Annu
al
turno
ver Type
of
enterp
rise Contr
ol by
publi
c
bodie
s Enterp
rise
size
choice Enterp
rise
size
(input) Except
ion
due to
merge
or
acquisi
tion
A A data A data A
data A
data A data A
data A data A data A data
Cube “Linked enterprises”
Counterparty ID Linked
enterprise ID Number of
employees Balance sheet
total Annual turnover
Cube “Partner enterprises”
Counterparty
ID Partner
enterprise ID Number of
employees Balance
sheet total Annual
turnover Percentage
interest in the
capital or
voting rights
A E group ID E group data E group data E grou p data 30%
February, 2017
58
Cube “Group data ”
Group Internal
ID Number of
employees –
Group Group Balance
sheet total Group Annual
turnover
A group ID A group data A group data A group data
Cube “Group counterparty relationship ”
Group Internal
ID Counterparty ID
A Group ID A
February, 2017
59
Example 4:
Counterparty G:
Cube “Counterparties”
Counter
party ID … Date
of
Enter
prise
size Numb
er of
emplo
yees Bala
nce
shee
t
total Annu
al
turno
ver Type
of
enterp
rise Cont
rol
by
publi
c
bodi
es Enter
prise
size
choice Enter
prise
size
(input) Excep
tion
due to
merge
or
acquis
ition
G G
data G data G
data G
data G
data G
data G
data G
data G data
Cube “Linked enterprises”
Counterparty ID Linked
enterprise ID Number of
employees Balance sheet
total Annual
turnover
Cube “Partner enterprises”
Counterparty
ID Partner
enterprise ID Number of
employees Balance
sheet total Annual
turnover Percentage
interest in the
capital or
voting rights
G A group ID A group data A group
data A group
data 30%
Cube “Group data ”
Group Internal
ID Number of
employees –
Group Group Balance
sheet total Group Annual
turnover
E group ID E group data E group data E group data
Cube “Group counterparty relationship ”
Group Internal
ID Counterparty
ID
E Group I D G
February, 2017
60
Example 5:
A
Linked
B C
D E
F G
HLinked
Partner 25% Partner 30%
Linked Linked
Partner 35%
Counterparty A:
Cube “Counterparties”
Counter
party ID … Date
of
Enter
prise
size Numb
er of
emplo
yees Bala
nce
shee
t
total Annu
al
turno
ver Type
of
enterp
rise Cont
rol
by
publi
c
bodi
es Enter
prise
size
choice Enter
prise
size
(input) Excep
tion
due to
merge
or
acquis
ition
A A data A data A
data A
data A
data A
data A data A data A data
Cube “Linked enterprises”
Counterparty ID Linked
enterprise ID Number of
employ ees Balance sheet
total Annual
turnover
A B B data B data B data
Cube “Partner enterprises”
Counterparty
ID Partner
enterprise ID Number of
employees Balance
sheet total Annual
turnover Percentage
interest in the
capital or
voting rights
A E E+F+G data E+F+G
data E+F+G
data 30%
Cube “Group data”
Group Internal
ID Number of
employees – Group Balance
sheet total Group Annual
turnover J GROUP
February, 2017
61
Group
J group ID J group data J group data J group data
Cube “Group counterparty relationship ”
Group Internal
ID Counterparty
ID
J Group ID A
6.2 Derivation of Carrying amount
6.2.1 Scope (applicability)
– The derivation rule applies only to banks that use IFRS .
– The derivation rule shall only apply if the variable Is carrying amount derived
(IS_CRRYG_AMNT_DRVD ) in the paramet ers cube has the value 1 .
6.2.2 Natural language
For instruments fair valued according to their accounting classification, the carrying amount is equal to
the fair value of the instrument.
For instruments at amortised cost according to their accounting classific ation, the carrying amount is
equal to their gross carrying amount excluding accrued interest plus their accrued interest minus their
accumulated impairment plus the fair value changes due to hedge accounting.
6.2.3 Involved elements
Accounting classification ( ACCNTNG_CLSFCTN ): Accounting portfolio where the instrument is
recorded in accordance with the accounting standard – IFRS or national GAAP –under Regulation (EU)
2015/534 (ECB/2015/13) applied by the observed agent's legal entity. Involved values:
ID DESCRI PTION DEFINITION
14 IFRS: Cash balances at central banks
and other demand deposits Cash balances at central banks and other demand
deposits in accordance with IFRS.
6 IFRS: Financial assets at amortised cost Financial assets measured at amortised cost in
accordance with IFRS.
8 IFRS: Financial assets at fair value
through other comprehensive income Financial assets measured at fair value through other
comprehensive income due to business model and
cash -flows characteristics in accordance with IFRS.
4 IFRS: Financial assets designated at fair
value through profit or loss Financial assets measured at fair value through profit
and loss and designated as such upon initial
recognition or subsequently in accordance with IFRS,
except those classified as financi al assets held for
trading.
February, 2017
62
2 IFRS: Financial assets held for trading Financial assets held for trading in accordance with
IFRS.
41 IFRS: Non -trading financial assets
mandatorily at fair value through profit or
loss Non-trading financial assets mandatori ly at fair value
through profit or loss in accordance with IFRS.
Fair value ( FV): Fair value as defined in IFRS 13.9.
Gross carrying amount excluding interest ( GRSS_CRRYNG_AMNT_E_INTRST ): Gross carrying
amount, as defined in IFRS 9 appendix A, excluding a ccrued interest
Accrued interest ( ACCRD_INTRST ): The amount of accrued interest on loans at the reporting reference
date as defined in Regulation (EU) No 1071/2013 (ECB/2013/33). In accordance with the general
principle of accruals accounting, interest rec eivable on instruments should be subject to on -balance
sheet recording as it accrues (i.e. on an accruals basis) rather than when it is actually received (i.e. on a
cash basis).
Accumulated impairment ( ACCMLTD_IMPRMNT ): The amount of loss allowances that a re held against
or are allocated to the instrument on the reporting reference date. This data attribute applies to
instruments subject to impairment under the applied accounting standard.
Fair value changes due to hedge accounting ( FV_CHNGS_HDG_ACCNTNG ): Changes in the fair
value of an instrument, which is a hedged item and measured at amortised cost, that are recognised in
the carrying amount due to the application of hedge accounting (IFRS 9.6)
6.2.4 VTL expression
create function D_CRRYNG_AMNT(ACCNTNG_CLSFCTN, FV, GRSS_CRRYNG_AMNT_E_INTRST,
ACCRD_INTRST, FV_CHNGS_HDG_ACCNTNG, ACCMLTD_IMPRMNT) {
returns
if (ACCNTNG_CLSFCTN in (2, 4, 8, 41)) then FV
elseif (ACCNTNG_CLSFCTN in (6, 14)) then (GRSS_CRRYNG_AMNT_E_INTRST + ACCRD_INTRST –
ACCMLTD_IMPRMNT + F V_CHNGS_HDG_ACCNTNG)
else null
}
6.2.5 }Further explanation
This deri vation rule aims to obtain the IFRS carrying amount from its basic building blocks. It can be
split in two parts: For instruments measured at fair value, the carrying amount is simply the fair value of
the instrument. For instruments measured at amortised cost, the carrying amount can be subdivided
into components that are requested to be reported separately in many frameworks (notably accrued
interest and accumulated impairment).
The following schema shows the relation between different values referred to in IFRS 9 or other
frameworks:
February, 2017
63
Carrying
amount Amortised
cost Gross
carrying
amount Gross carrying
amount excluding
interest
Accrued interest
(-) Accumulated impairment (l oss
allowance )
Fair value changes due to hedge accounting
The concepts in g reen show the concepts required in AnaCredit, while the cells in yellow show the
additional variables required in the input layer for instruments at amortised cost if the carrying amount is
to be derived.
The following IFRS 9 definitions are related to the concepts above:
Amortised cost of a financial asset or financial liability : The amount at which the financial asset or
financial liability is measured at initial recognition minus the principal repayments, plus or minus the
cumulative amortisation using t he effective interest method of any difference between that initial amount
and the maturity amount and, for financial assets, adjusted for any loss allowance.
Gross carrying amount of a financial asset : The amortised cost of a financial asset, before adjus ting
for any loss allowance.
Loss allowance : The allowance for expected credit losses on financial assets measured in accordance
with paragraph 4.1.2 (at amortised cost), lease receivables and contract assets, the accumulated
impairment amount for financia l assets measured in accordance with paragraph 4.1.2A (at fair value
through other comprehensive income) and the provision for expected credit losses on loan
commitments and financial guarantee contracts.
6.2.6 Illustrative examples
Let’s suppose we have a loan with the following characteristics:
Initial date 30/05/2016
Number of instalments (annual) 5
Initial principal amount 1000
Annualised agreed rate 3%
Fair value at inception 990
Transaction costs 8
The resulting contractual amortisation table would be :
Contractual amortisation table
Date Accrued interest in
the period
(contractual) Instalment
(contractual) Outstanding nominal
amount (after cash flow)
30/05/2016 -1000 1000
30/05/2017 30 218.35 811.65
February, 2017
64
30/05/2018 24.35 218.35 617.64
30/05/2019 18.53 218.35 417.81
30/05/2020 12.53 218.35 211.99
30/05/2021 6.36 218.35 0.00
The creditor classifies the loan as financial asset at amortised cost. For the application of the effective
interest rate method, a new amortisation table shall be calculated, con taining the figures to be used for
calculated the gross carrying amount, as defined in IFRS 9 Appendix A (The amortised cost of a
financial asset, before adjusting for any loss allowance)
The effective interest rate is, according to the IFRS 9, the rate th at exactly discounts estimated future
cash payments or receipts through the expected life of the financial asset or financial liability to the
gross carrying amount of a financial asset.
The resulting effective interest rate, assuming that the estimated fu ture cash receipts are the
contractual ones, would be 3.07%. With this rate, the resulting accounting amortisation table would be:
Accounting amortisation table
Date Accrued interest in
the period
(accounting) Cash flow
(estimated) Gross carrying amount
excluding accrued
interest (after cash flow)
30/05/2016 -998 998
30/05/2017 30.64 218.35 810.29
30/05/2018 24.88 218.35 616.81
30/05/2019 18.94 218.35 417.39
30/05/2020 12.81 218.35 211.85
30/05/2021 6.50 218.35 0.00
Note first that the gross carryi ng amount at inception is different to the Outstanding nominal amount.
This is due to the fact that the gross carrying amount excluding interest at inception is the initial
measurement amount, i.e. the fair value plus the transaction costs.
Case 1
Reportin g date 30/6/2016. The input variables (in blue) are provided by the operational systems. From
there, the rest of variables can be easily derived.
Carrying amount
= 1000.04 Amortised cost
= 1000.04 Gross carrying
amount =
1000.54 Gross carrying
amount exclu ding
interest = 998
Accrued interest =
2.54
(-) Accumulated impairment (loss
allowance) = 0.5
Fair value changes due to hedge accounting = 0
It is worth highlighting that:
The Gross carrying amount excluding interest can be obtained from the acco unting amortisation
table.
February, 2017
65
The accrued interest is calculated by applying the effective interest rate to the gross carrying
amount excluding interest for the relevant accrual period.
The Outstanding nominal amount in this case would be 1000. It is differen t to the Gross carrying
amount excluding interest or the Carrying amount , since it is obtained from contractual figures, not
accounting figures.
Case 2
Reporting date 30/06/2017, after the first instalment, which was duly paid.
Carrying amount
= 811.86 Amortised cost
= 811.86 Gross carrying
amount =
812.36 Gross carrying amount
excluding interest =
810.29
Accrued interest = 2.07
(-) Accumulated impairment (loss
allowance) = 0.5
Fair value changes due to hedge accounting = 0
It is worth highlight ing that:
The Gross carrying amount excluding interest can again be obtained from the accounting
amortisation table.
The Outstanding nominal amount would be in this case 811.65, as shown in the contractual
amortisation table.
Case 3
Reporting date 31/12/2 018. Let’s now suppose that the payment due on 30/05/2018 was not satisfied,
and that the loan is considered in stage 3 from 30/06/2018.
Carrying amount
= 650.16 Amortised cost
= 650.16 Gross carrying
amount =
850.16 Gross carrying amount
excluding interes t =
810.29
Accrued interest = 39.87
(-) Accumulated impairment (loss
allowance) = 200
Fair value changes due to hedge accounting = 0
It is worth highlighting that:
The Gross carrying amount excluding interest can again be obtained from the accoun ting
amortisation table. But, given that the payment due was not satisfied, the amount to be considered
is the one after the latest payment satisfied.
The Outstanding nominal amount is simply would be 836 , calculated as the sum of the contractual
outstand ing amount after the last instalment paid (811.65) plus the interest accrued in the period
until the instalment date, which can also be taken from the contractual amortisation table (24.35).
No additional interest is to be added to that amount, since the v ariable is calculated including
unpaid past due interest but excluding accrued interest .
February, 2017
66
7 Other aspects
7.1 Information about the BIRD database
Some information about the database, in addition to what explained in the “BIRD methodology”, is
provided here:
– Comb inations. In the data definition package there are some tables regarding combinations
(COMBINATION, COMBINATION_ITEM and CUBE_TO_COMBINATION). Combinations may be
used to restrict the possible combinations of the members of the various variables for a cert ain
cube. At present, we are not using this functionality; in other terms, all combinations are allowed . In
cases where some combinations are not possible, proper validation rules define the allowed
combinations.
– Input information not provided. There are s ome cases where the data may not be compiled. The
BIRD model assumes that all non -enumerated domains include the absence of data, whereas
enumerated domains have normally a member named “not applicable”, to which the code “0” is
generally assigned. As rega rds subdomains, non -enumerated ones include the absence of data
unless explicitly specified; enumerated domains always specify the admitted values.
– Data format. Non -enumerated domains don’t specify exactly the data format. They just indicates
the nature of the information (date, real, etc.).
7.2 The output layer
In the present version of the BIRD, the output layer comprises only AnaCredit cubes. Currently they
describe how the data will be collected by the European Central Bank from National Central Banks. As
NCBs, in turn, may collect the required information from banks in different ways, this definition of the
output layer may not correspond to what the banks will actually send to their national authority.
However, in order to define common transformation rule s, the BIRD assumes that the output of its
process is common to all banks; its definition is based on the AnaCredit requirements at European
level. Of course, the direct use of BIRD transformation rules , as metadata, by reporting banks may need
some nation al adaptations.
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: BIRD Technical Guidelines [602915] (ID: 602915)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.