ANACREDIT Stage 1 represents regulatory reporting tool on total Bank exposure from lending-related products towards the Corporate segment. This initiative has been launched by European Central Bank and later on local regulators (incl. Czech National Bank) have come-up with some additional requirements. In this in-depth analysis you will find all necessary information incl. what and how is needed to be reported, in what granularity and in what connections to other atributtes.

1. Introduction and Background
2. ECB Regulation
3. CNB Requirements
4. RIAD
5. Rationale
6. Reporting structure
   • Counterparty_reference_data (PANACR 01)
   • Instrument table (PANACR 02)
   • Financial_instrument table (PANACR 03)
   • Counterparty instrument table (PANACR 04)
   • Joint_liabilities table (PANACR 05)
   • Accounting_instrument table (PANACR 06)
   • Protection_received table (PANACR 07)
   • Instrument_protection table (PANACR 08)
   • Counterparty_risk (PANACR 09)
   • Counterparty_default (PANACR 10)
   • Linked_contract_data table (PANACR 021)
   • Credit risk table (PANACR 022)
   • Group of connected clients (PANACR 023)
7. Why is AnaCredit necessary?

Introduction and Background

On June 1st, 2016 the European Central Bank (ECB) published the final version of the AnaCredit Regulation on the collection of granular credit and credit risk data as well as the related amending decision on the organization of preparatory measures for the collection of granular credit data by the European System of Central Banks. This regulation is only the first stage, concerning loans and deposits to legal entities (meaning corporate clients only, the retail customers will represent Stage 2 of ANACREDIT and is expected to be launched in 2020).

The Regulation sets out the reporting requirements and defines the reporting population and scope. In practical terms, the regulation defines how, when and what the impacted population will need to report to the relevant National Central Bank which will transmit it to the European Central Bank. Moreover, requirements of ECB represent the basic scope which can be adjusted according to the needs of the particular National Central bank. Czech National Bank (CNB) increased the level of information that will be requested as mandatory for reporting in terms of frequency and scope.

AnaCredit stands for analytical credit datasets. It is a project launched in 2011 by the ECB to set up a dataset containing granular credit and credit risk data about the credit exposure of credit institutions and other loan-providing financial firms within the Eurozone. The AnaCredit database will provide detailed information on individual bank loans in the euro area and will be based on harmonized concepts and definitions. The coverage for, at least and at first, the euro area, will ensure more comparability and significantly improve the statistical information basis for the Euro system. The new long-term framework under AnaCredit is also open to Member States outside the Eurozone.

Reporting to CNB

Recommendation ECB/2014/7 encourages NCBs of Member States whose currency is not the euro, but who are preparing to join the long-term framework, to apply the provisions of Decision ECB/2014/6. Based on this recommendation has Czech National Bank joined the reporting on the voluntary basis and defined set of additional requirements enhancing the scope requested by ECB.

In general, additional requirements can be summarized as scope requirements, frequency requirements and threshold requirements. CNB has included in scope of the AnaCredit reporting the strictly off-balance sheet items on top of the product types requested by ECB. Besides those, the frequency of reporting has been increased in several templates and finally, the threshold 25,000 Euro has been removed for authorized debits (for unauthorized low-threshold of 2,000 CZK has been set). Hence, all data is expected to be delivered to CNB according to the above-mentioned rules and CNB will ensure further data delivery to ECB (corresponding to the ECB scope).

Regardless of currently improved scope it is expected that CNB will adjust the national requirements again in the future and include also natural person and sole proprietors in the reporting scope. Currently, this request was not proceeded due to the GDPR regulation negative attitude of The Office for Personal Data Protection (OUUO). In case of the further enhancement of the scope, any change will not be effective sooner than in 2020.

First reporting date

First complete dataset within AnaCredit shall be reported for period ending June 2019 – during first weeks of July 2019; this requirement is applicable for referential data where basic information about the counterparties need to be provided in order to obtain the unique RIAD-IDK identifier and help CNB with tuning of the RIAD system as well. Identifier will be later used in AnaCredit templates to uniquely identify the particular mutual connected counterparties.

Majority of the data shall be reported on a monthly basis with exception on the Accounting and Credit risk data that are requested on a quarterly basis. Counterparty reference data are to be reported on “once and update” frequency (i.e. based on the decision of the particular credit institution however only with the following options – daily/weekly/monthly).

ECB Regulation

First of all, it needs to be pointed out that the ECB Regulation (i.e. AnaCredit Regulation) is binding primarily for European-based Head offices of all Czech banks. ECB has adopted the Regulation (EU) 2016/867 on the collection of granular credit and credit risk data (ECB/2016/13). Below attached are the official Guidlines approved by European Council.

ECB requires the data collection which meets the following conditions:

1. At least one debtor of the instrument is a legal entity or part of a legal entity as referred to in Article 1(5).
2. The instrument satisfies any of the conditions of Article 4(1)(a)(i) through to 4(1)(a)(iv);
3. Given exposure is reported on the single basis approach.
4. Qualifying instrument refers to an instrument is qualifying on a month-end date if it is eligible and the debtor’s total commitment amount to all the eligible instruments reaches or exceeds €25,000.
5. The instrument is one of the types of instrument under Article 1(23). The types are as follows:
6. Reverse repurchase agreements;
7. Deposits other than reverse repurchase agreements;
8. Overdraft;
9. Credit card debt;
10. Revolving credit other than overdrafts and credit card debt;
11. Credit lines other than revolving credit;
12. Trade receivables;
13. Financial leases;
14. Other loans.

ECB Act No.2016/13 has defined 95 Attributes that are divided into 10 different templates as follows:

CNB Requirements

First draft of national requirements of CNB was published in January, 2016. Until now, the document has been updated several times, with the most recent version published on September, 2017. In comparison to previous version(s) only minor changes were incorporated. Until publishing of the legislative Act draft versions need to be used for any kind of activities with regard to the local solutions.

No major changes are expected to be further incorporated, moreover the web sites of CNB for AnaCredit methodology have been already updated and are approachable via link: CNB ANACREDIT Web portal.

Anacredit reporting structure for all ECB/CNB parameters:

---

Last enhancement of the CNB is represented by defining of 55 completely new attributes created on top of the ECB requirements, thus the overall scope of AnaCredit was enhanced to final 150 attributes. Out of the full scope, 7 attributes are applicable for natural persons and sole proprietors only. Those attributes will not be part of the reporting scope in 2018 due to the GDPR legislation and negative attitude of The Office for Personal Data Protection (ÚOOÚ). However, the change would be expected in the future but it will not be effective sooner than on 2020 due to the two-year period between the application of the new regulation and its local incorporation by member states into legislation. For the upcoming period of at least two years (starting from 2018), each Czech Bank is obliged to provide the set of 143 attributes to the CNB. From this scope, 15 attributes represent a modification in terms of LoVs that are used.

Based on all above mentioned points, the current scope of CNB requirements can be simplified as follows:

• 95 attributes required by ECB out of which 15 were further modified by CNB;
• 55 completely new attributes out of which 7 are not applicable.

CNB is, besides the original scope requested by ECB, interested in attributes for which completely new templates have been created. Overview of main information about those templates/ sheets is summarized in the table below.

Note: Three new templates are covering the additional scope of 21 attributes. Remaining 22 attributes (besides the 7 that are not applicable) were published as an enhancement of templates originally populated by ECB.

RIAD – Counterparties data

Data that shall be provided in the AnaCredit reporting can be in terms of their delivery differentiated into two categories: credit data and referential data:

1. Credit data are further divided according to the subject, periodicity and debtors in the form of 12 separate templates. Those templates represent the base of the whole AnaCredit reporting.
2. Referential data are collected separately through the ČNB RIAD system and contain all information about the counterparty included in the template 1. Counterparty reference data.

Once the counterparty reference data are provided to the RIAD, system will provide unambiguous identifier RIAD-IDK which will be by CNB delivered back to the bank as a RESPONSE for REQUEST. This identifier shall be used for counterparty’s identification in the credit data reported in AnaCredit. Process of reporting flow for referential and credit data between the reporting agent and CNB and further delivery of those data to ECB is displayed on the picture below.

With regard to the valid ECB Regulation, all counterparties need to be registered on an institutional level. Specifically, the counterparties to be registered are:

• Creditors;
• Debtors;
• Protection providers;
• Originators;
• Servicers;
• Head offices of undertakings;
• Immediate parent undertakings
• Ultimate parent undertakings.

A single entity may be the counterparty in relation to several instruments or take different roles as a counterparty for the same instrument. However, each counterparty should only be registered once.

The scope of the data to be provided to RIAD-IDK is primarily determined by:

• The role of the counterparty;
• Counterparty’s residence.

Data are provided to RIAD in the form “once and update”. Practically, banks are obliged to report counterparties’ referential data during the birth of the contract between the bank and the counterparty and then only in case of the change in the data. Thus, banks are not expected to report counterparties’ referential data on a monthly basis. Main effort will be put in the first reporting to RIAD on March, 2019.

Rationale

So, the CNB requirements go well beyond the data scope to be sent to ECB and they will ask for more attention of reporting Banks due to complexity of the parameters to be included in dataset. While ECB would like to gather rather only static data for the credit products “as it is right now”, CNB go deeper and they would like to analyze the entire exposure also from collateral and risk point of view, which means that they are collecting also internal information of each Bank on assessing and calculating risk parameters incl. RWA, LGD, PD etc., and on the level of each credit instrument (meaning each draw-down). Delivering data in line with this requirement will actually reveal internal risk policy of each Bank whether the approach to calculating these risk parameters is proper or not? Or, at least in line with other Banks.

Another aspect for complexity of reporting to CNB is that in second stage of Anacredit project there will be also retail customers covered. As retail customers are considered not only private individuals, but also SME-like corporates and businessmen, which makes the whole project more complicated. Nevertheless the scope of parameters was already defined and this requires more attention from side of Banks to decide on which required parameter is focused on which type of customer. For instance, the whole risk approach to corporates is totally different then to individuals, as in corporate risk area there is usually only one Borrower rating relevant for all credit transactions (e.g. BBB-), while to individual customers different Borrower ratings may be assigned for each drawn product based on received collateral (for Credit cards it is usually worse than for mortgage loans). And this naturally translates to other parameters like Probability of Default (PD ratio), whereas retail clients are supposed to have reported PD on each instrument level, which on the contrary does not make sense in case of corporates.

Further, there are also entry-controls to be performed on final Dataset before sending to regulator, which means that data integrity will be key issue, as well. for instance, if there is collateral provided by 3^rd party and not by Borrower, this entity must be reported on the Counterparty list with all relevant details (legal form, segment, key financial figures like number of staff, total assets and sales, and many others). These internal checks are aimed to reveal the shortcomings in data collection processes in each Bank, or simply the Banks will be forced to buy such data from external vendor. And these data need to be uploaded in Banks core systems as well, naturally.

Based on that, it is clear that Bank staff involved on this project should include professionals from Finance, Risk and IT area.

Reporting structure

As mentioned earlier an enormous effort must be dedicated in compiling the Dataset in order to surpass all internal entry-checks and deliver reports to regulator.

In this section we will try to provide certain overview on main topics to be solved in each section of report. But to be noticed, that only real practice with delivering first complete Datasets will reveal the main shortfalls that still need additional attention.

Counterparty_reference_data (PANACR 01)

Base report depicting extensive statistic data on each Counterparty or Collateral provider in terms of business addresses, national registration IDs, LEI, Economic sector and activities, Enterprise segmentation, legal form and Enterprise size (Annual sales, Total Assets and Number of employees). This sheet is clearly focused on data quality issues, as Regulator will be able to verify how correctly the Banks collect data on their Counterparties. The process will be following, that Central Bank (CNB) will collect those data from the Banks and based on primary identification keys, it will assign each Counterparty with “centralized ID” in form of RIAD-IDK and this will be distributed to each Bank for further reporting, so that each Bank will report same entity under same ID.

And on top of that, potential mismatch may arise in terms of segmentation, whereas ECB applies 3 criteria for each entity to be classified under SME clients (Turnover < 50MEUR, Number of Employees below 250 and Balance sheet size < 43MEUR). However this may be slightly conflicting with internal guidelines applied by each Bank, so that Banks might have reported some clients under SME segment, but this may be a result of their clients treatment from Corporates portfolio view (Large, MidCorp, Micro, SME…), but it may not be fully compliant with ECB rules. This will need then some adjustments due to fact that incorrectly classified SME clients could lead to distorted RWA figures, which would then impact also capital requirements.   

For example a loan of 10 mio EUR, with PD 3%, LGD 40% and maturity 3 years, the impact will be in case Corporate exposure class following:

Medium sized                turnover 30 mio EUR   increase by 11% of RWA

Small company             turnover 10 mio EUR   increase by 27% of RWA

Micro company             turnover   2 mio EUR   increase by 34% of RWA

Link to CRR Article 501 and further explanations is to be found here.

Instrument table (PANACR 02)

This is practically the most comprehensive sheet on credit instruments, as it describes all relevant data like start of the deal, contractual maturity of the deal, type of pricing, reference rate (1M PRIBOR, 1M LIBOR etc.), interest margin, and whether there is concluded also the interest cap (max. rate) and floor (min. rate). The latter two parameters should be reflected in credit contracts in all cases, however they do not entirely enter into the core systems of the Bank depending of their systems availability for capturing such details, so it might be simplified to NTAP (Not applicable) value. This should be feasible at least from validation/ internal checks view, but another question is if such presented value is deemed as sufficient to regulator. In addition, amortization schedule, interest payment frequency and revocability of the commitment is herewith considered as minimum required standard.

Moreover, there is also possibility to highlight, whether any instrument is project finance deal, resp. whether it is a syndicated loan. This is very crucial for following controls, as syndicated loans should report some parameters as the very same for all participating Banks (counterparty, provider of collateral, shared value of collateral etc.). Connecting parameter is “Syndicated_contract_Identifier”, whereas the Agent is obliged to advise all participating Banks to share the same contract ID which will be derived from Agents SWIFT code combined with date of signing of respective syndicated contract (e.g. KOMBCZPP-31012016-001). This will provide regulator clear indication how to track the joint credit facilities among the all Banks and easy hint which data should be somehow corresponding. This table, as well as others to follow, are supposed to be updated each month.

Financial_instrument table (PANACR 03)

Instruments as defined per specific type (Overdraft, Term loans, REPOs or Fin.guarantees etc.) are described herewith incl. some more details which contain also agreed pricing, base rate reset date, past due amounts, outstanding principal amount, accrued interests etc. Off B/S-position is resulting from undrawn amount, which is reflected on the level of each product type. In principle, this means that each drawn Products are herewith recognized with their outstanding balance as quasi On B/S product in column Otstndng_Nmnl_Amnt, while under the OFF_BLNC_SHT_AMNT is only their undrawn equivalent. This is also referring to situation when the credit commitment has been signed, but not yet drawn, so this future commitment will be reported with zero outstanding balance and full limit amount under Off B/S position on the level of CREDITLINE or OTHCRECOMT. Basically, there is general rule, that Outstanding balance together with Off B/S amount should be equaling to total Credit line amount, which is reported within Table Instrument (PANACR 02) under Commitment at inception amount. Further, this table also recognizes parameters that are common for Credit cards products (Convenience credit and Extended credit), i.e. when the Bank provides quasi grace-period, during which the Client does not pay interest from drawn amounts etc. And finally, there is also Effective Interest rate, which requires more complicated calculation on received cash-flow from interest payments on annual basis (close to effective yields from Bonds). 

One note to deposits, these include also positive (CR) balances on Nostro A/C with other financial institutions. On the other hand, under the Overdrafts there will be included also current A/C with possibility for overdrawing into negative balance, which is quasi an overdraft. But in case when there is positive balance on client A/C, then this is reported with zero outstanding balance, but after this turns into negative (DR) balance, then real outstanding is shown. Above mentioned scope of products is not complete, it only contains most common categories. Above that, there are also financial leasing deals considered as a eligible subcategory within lending activities.

Counterparty instrument table (PANACR 04)

This sheet displays the Borrower and the reporting Bank in their primary key depiction in terms of their role (Creditor, Debtor, Intermediator and Other), their National ID code (local ICO, Funds registration No. or SWIFT code), which is further to be linked with respective instrument. The role Servicer is primarily designed for intermediary institutions that do not provide the loan (funding), but provide certain service to the financial transaction (like Agents under club loans resp. syndications etc.). Further, when reporting Bank transfers certain exposures out of its books, then these primary keys serve to describe which entity remains as Creditor and which is just Servicer (in terms of having the right to claim the receivable).

Basically, it means that if the Bank has in its credit portfolio 100 current instruments, this table will contain totally 300 rows showing the same instrument on each level (e.g. Creditor, Servicer, Debtor). The other tables will depict the instrument only on Borrower/Debtor level and provider of collateral depending on the scope of table.

Joint_liabilities table (PANACR 05)

This sheet might be considered as rather controversy in terms of its explanatory meaning, as this seems to be applicable to private individuals who act as a joint Borrowers for a single loan (e.g. husbands applying for mortgage loan), while they remain also liable for this debt, however only one person may be client of the bank.

In corporate lending world, this might be interpreted in misleading way. This is due to fact, that corporate clients are considered as co-Borrowers and co-Guarantors, especially if they agree with Joint and Severe Liability clause, which makes them all jointly liable for all potential Debts stemming from concluded credit agreement. This is quite common protection instrument in case of Multi-Borrowers credit lines, but in reality these all entities are benefiting from these loans and are captured with core system of the bank.

Accounting_instrument table (PANACR 06)

This table shows performance status and accounting classification of the instruments and corresponding risk values like Impairments, provisions and write-offs. If the data attribute “accumulated impairment amount” is reported, the data attributes  “type of impairment” and “impairment assessment method” further specify which type and method (IFRS stages 1, 2 or 3, or, in the case of GAAP, specific or general allowances; individually or collectively assessed) were used in order to calculate the accumulated impairment amount.

For instance, if the instrument (loan, provided L/C etc.) is not impaired, then Impairment status equals to IFRS Stage 1 (value 1) and performing status will be Performing (10) and Forbearance status will be resulting to No Forbearance (5). Alternatively, in case of any credit deterioration, Impairment status equals to IFRS Stage 2-3 and/or Provisioning (values 2-5) and performing status will be Non-Performing (20) and Forbearance status will be resulting to Forborne instruments with certain relief in repayments or covenants (1-3).

Carrying amount parameter reflects total value of Banks receivables deducted by impairments. So that there will be cross-check on Financial_instrument table (PANACR 03), whereas among others also outstanding balances and accrued interests of each instrument are shown. This table is expected to be updated on quarterly basis, which is usual interval for assessing Loss provisions based on clients classification, as opposed to other Tables that will be presented only on monthly basis. Further, there is certain logic behind the regulator requirement that for instance written-off or sold receivables will appear in this quarterly reporting in order to track their development so that it provides more details to the Regulator what was the reason for their “disappearing” from books.

Protection_received table (PANACR 07)

ECB Guidlines have outlined following major classes of eligible collateral instruments which are usually captured in core systems, while sub-category “Other protection” leaves a quite good space for adding supporting protection factors like Negative pledge etc.:

This table provides detailed overview regarding the received collateral, its valuation and other additional information that may be quite important especially in case of pledged Real estates. In this case the Regulator specifically asks for details like collateral location (Real_Estate_Collateral_Location) and valuation method/approach.

On top of that, (Czech) regulator requires additional parameters a.o. generated Cash-flow from income producing properties (Annual_Rental_Income). Some banks may struggle with providing such detailed information, however they certainly enter into credit approval process, but in case of “basket financing deal”, which are typical for Developers that sell the whole portfolio of logistics/industrial properties, then it is required that each property will be captured in core system as individual collateral. This is important in connection with PANACR 08 table, which shows the linkage between received protection and each individual draw-downs resp. instruments. Other parameters included above like Realizable protection value for capital requirements etc. are derived directly from risk models that calculate all risk ratios. For a simplicity, the example above shows only Financial guarantee as a collateral, so the local parameters that mostly refer to Real estates are displaying the “NTRQ” value.

Pls note that difference between “NTAP” and “NTRQ” is purely logical, whereas in first case the Bank does not dispose with such data, while in latter one such data simply do not make sense to be reported and therefore are not required.

Instrument_protection table (PANACR 08)

Connection between received collateral and individual instrument is displayed herewith, while there is additional parameter for 3^rd party claims, that includes prepayment rights of other creditors in case that collateral is being shared with other Banks resp. when other Bank created its Pledge prior to the reporting Bank. This may require additional data upload as some banks typically capture only “netto” value of the protection into core systems deducted by those claims. However, in the end, the realizeable value of Protection shall be the same.

Counterparty_risk (PANACR 09)

Very simplified table depicting only Counterparty ID (herewith shown as Internal Bank Code, however in final report will be replaced with RIAD IDK No. received from CNB) and its corresponding Probability of Default based on Internal client rating. These are very base risk values for each Borrower, based on which another parameters like RWA are measured.

Counterparty_default (PANACR 10)

Default status measured on Borrower level is herewith reflected, to which corresponding date of changing the status must be stated. That means if Client has no Default status, then no corresponding date is needed to be reported (NTAP). In addition, Default status is also linked with Performing status (PANACR_06 Table), whereas the assessment for retail exposure (incl. SME) should be done based on two primary criteria:

1. Whether any instrument drawn by Client is past-due more than 90 Days and
2. If this past-due instrument makes more than 20% of the gross carrying amount of all on-balance sheet exposures of the debtor.

So, starting with transaction-based assessment, whether each instrument is in default or not in line with Article 178(1) of the CRR., the Bank comes to conclusion if Client as such is Non/Performing given that.

On the contrary, In the non-retail portfolio, the default status is assessed at the level of the whole counterparty, disregarding all individual exposures. As this is quite complex topic, for more information, we recommend to refer to attached Anacredit Manual Part II.

Linked_contract_data table (PANACR 021)

Quite simple sheet depicting only continuation of provided deals on level of Instrument and Exposure ID, whereas previous and new identifications are supposed to be reported for these. The replacement of instruments and contracts is to be justified with following reasons (Refinancing, Extension, Acquisition and Merging of deals) to be able to track the changes that happened to deals month vs. previous month. This means that regulator requires unique identification description for all exposures that will not change during the life-time of deal, which may bring up more complications in case of revolving loans, when one Tranche is replaced with a new one, to which is a new ID number assigned (usually generated automatically by core system).  Then a manual work-around is needed to create some logic for generating a unique numbers that will be linked with each drawings and these numbers will not be duplicated during the same reporting period.

Credit risk table (PANACR 022)

This table gives an overview on how are individual instruments secured and what is resulting risk position of the Bank after certain haircuts in collateral values. In addition, the Banks are obliged to disclose the capital calculation approach (Standard, Advanced IRB), which further depicts the way how RWA, PD, LGD and others are calculated. Therefore it is also crucial that parameter Exposure class is properly stated, which also defines certain capital reliefs like in case of SME clients.

Concerning LGD, there are to be reported standard LGD (shown under LGD_LNG_RN_AVRG) and LGD in economic downturn (LGD_ECNMC_DWNTRN), which means that Banks should have predefined certain rules how will LGD values change for certain collateral classes when there is global economy slump (defined as GDP decline in three consecutive Quarters). Naturally, such situation should imply that in case of Borrowers default, received collaterals should be sold for a lower value than in “normal times” (like pledged Real-estates), so that “downturn” LGD is supposed to be higher. However there was an academic discussion on this topic that actually certain collateral (namely Bonds and securities) could have even higher value leading to lower LGD on the opposite, as it may be broadly expected that Government would try to stabilize the economy in worst case so that there is a bet on bail-out factor taken into account. However this implication is not line with checks/ validation controls, which require that “standard” LGD is less than “down-turn” LGD.

As previously mentioned, there are also parameters like PD on Exposure and Internal Exposure rating, which are being assessed mostly on Borrower level. In these cases, it will be allowed to simply report Not applicable (“NTAP”) results, when the Borrower does not comply with SME business definition (or Individual Persons in later stage of Anacredit project).

Note: the Banks usually apply internal policy for risk costs/capital calculation, which is defined on parent/Group level and this also defines the way how is collateral allocated to individual exposures. Most common logic is that most valuable collateral is linked to cover the highest exposure/ RWA position, which reduces the capital costs. This may lead to situation that some partial exposures will remain uncovered in the final calculation despite the fact that also they should benefit from received protection (through cross-collateral). So that there will be slight discrepancy that this exposures will report received protection (PANACR 08), while it will report increased LGD and RWA when compared with other instruments drawn under the same credit contract and benefitting from same collateral. Nevertheless, this situation will not be conflicting with validation checks, so it should be accepted by regulator, as well.

Group of connected clients (PANACR 023)

The links between the Debtors resp. Borrowers and their parent entities should be captured within this table, which summarizes how many active clients from one Group the reporting Bank provides with lending products. So that each Bank should have created its own description for economically connected Group, that will be joint for each member of the Group. Entity ID is supposed to be in form of RIAD IDK Number, naturally.

Despite the fact that definition of economically connected Group makes reference to Regulation (EU) 575/2013 which requires clear identification of all Group members entities, the Banks are not obliged to report those members to which they simply do not have business relationship.

Why is AnaCredit necessary?

Good policy decisions are based on good data. The need for better and more detailed statistics has increased with the financial crisis, for two reasons.

1. The crisis has shown that different economic sectors, as well as individual corporations and households in the different euro area countries, reacted in very different ways to economic shocks. The ECB – for its policy purposes – has to be aware of, understand and monitor these developments.
2. The ECB and the national central banks and authorities of the euro area have taken on new tasks in terms of macroprudential supervision. New tasks require new instruments and knowledge. Initially, AnaCredit is designed to deliver the necessary additional information for monetary policy and financial stability tasks. At a later stage, additional needs for banking supervision may be considered as well.

AnaCredit will be based on harmonised concepts and definitions and on a complete coverage for (at least) all euro area member states, ensuring more comparability. Therefore it will improve the statistical information basis for the Eurosystem in a significant way.

The key to making good decisions is having a clear view of the situation. This is why central banks need good statistics, like the ones to be provided by AnaCredit. Clear and detailed information would greatly assist monetary policy decision-making and help keep the financial system sound and transparent. This will bring important benefits for everyone: policy makers and supervisors, but also banks and, eventually, citizens.

For the first time we will have data with such a level of detail for all euro area member states, and these data will be fully comparable because they will be based on harmonised concepts and definitions. Therefore AnaCredit will allow analyses and comparisons that cannot be provided based on currently available aggregated data. These analyses are important parts of key central banking policy functions, such as monetary policy preparation and implementation and macroprudential oversight.

For instance, AnaCredit will provide detailed data on the availability of credit to enterprises, including small and medium-sized enterprises (SMEs), for which we now have only partial information based on some surveys. Differences in the supply as well as demand conditions for different economic sectors or categories of firms (e.g. small vs large, manufacture vs services) will become apparent, something currently hidden behind the aggregates. Reliable information on SMEs’ access to bank loans is very important for monetary policy decisions as SMEs are the backbone of the European economy and the main employers, and their financing conditions depend almost uniquely on banks. The granular data collected by AnaCredit will also be used to assess the development of corporate debt and its sustainability for this specific category of firms, which is very important when assessing the risk associated with certain classes of banks’ exposures.

Also in assessing emerging risks to financial stability, experts need detailed information. For example, if the banking system in a member country is not well diversified and is overly exposed to specific regions or industries, AnaCredit would highlight this and enable a more accurate analysis of (sectorial or regional) credit risks and their potential build-up into systemic risks in the financial sector. With harmonised reporting through AnaCredit, it will also be possible to evaluate the total loan exposure of a company towards all euro area banks, including cross-border exposures. This is currently missing, due to incomplete or not fully comparable information. Bank supervisors will be able to detect when a particular company is showing signs of delayed repayments to one or more banks, assess the creditworthiness of that company and evaluate the potential risk for the banks exposed to it.

sources: www.cnb.cz, www.ECB.Europa.eu