Response to consultation to amend the ITS on procedures, forms and templates for resolution planning
Go back
A final/definitive database for the completion of the templates is thus not available until late. Further analyses must be conducted on this database, which is extended in part by quantitative and qualitative information, as the required data cannot be derived entirely from the data in the annual financial statements. For this purpose, a separate data system must be set up in parts. Between the individual templates there are interdependencies that must be observed when filling them in. In ESBG’s view, a concurrent overall report of all templates would make sense. The reporting/reference date should therefore not be brought forward.
Some concrete suggestions:
Since the audited group results are annually published at the end of March, we suggest changing the remittance date for template R 01.00to 30 April, which would be, practically, much more appropriate.
Regarding the templates in the block on information on on- and off-balance sheet items (R 02.00, R 03.00, R 04.00, R 05.01, R 05.02 and R 06.00), we suggest changing the remittance date to 30 April, since this date corresponds with the already tight remittance date set by the SRB for templates R 02.00, R 03.00 and R 04.00 of this Draft ITS. Furthermore, the remittance date of 30 April would also reflect the fact that information necessary for templates R 05.01, R 05.02 and R 06.00 are usually contained in audited group results that are annually published and available as of the end of March.
For all templates relating to the block as regards “Critical functions and core business lines”, we prefer 31 May as a proper remittance date. This is due to fact that, for instance, the criticality assessment is based on company data as of 31 December and market share data which is simply not available before April for many markets and economic functions. In particular, with regard to developing banking markets in CEE, market shares can change significantly year-by-year with a direct impact on the criticality assessment. Without the availability of the most accurate market data as of 31 December, the criticality assessment would lose accuracy and quality. Therefore, and in order to simplify this regular reporting requirement for the banking sector, ESBG suggests harmonising the remittance dates for all the templates R 07.01 to R 10.02 by changing the proposed remittance date to 31 May.
Additionally, for entities on solo level, detailed information for the contribution to the group figures are not available as group adjustments are done by the consolidating (parent) entity. Therefore, a reconciliation process with solo entities is not possible at this stage. ESBG proposes to re-think this data request for template R 01.00.
With regard to the new template for deposit insurance, the name of the institutional protection scheme has to be given in reporting field 050. According to the explanations for this reporting field, this involves institutional protection schemes pursuant to Art. 113(7) CRR. Reference to deposit protection, however, is made only via institutional protection schemes pursuant to Art. 1(2) c) Directive 2014/49/EU (DGS Directive). Presumably, this, therefore, means such institutional protection schemes. Institutional protection schemes recognised pursuant to Art. 113(7) CRR can exist on a voluntary basis too and detached from the obligations of the DGS Directive.
R 02.00 (Liability Structure):
As regards template R 02.00 (Liability structure), it should be noted that columns 090 and 100 are not cumulative since both can include intragroup liabilities and issuances under non-EU Member State jurisdictions/law. When submitting data for individual entities, in some jurisdictions the data will be subject to national accounting standards, which creates issues with some of the definitions in the template. This relates, for example, to the position r330, balance sheet liabilities arising from derivatives (and further the position total liabilities and own funds). In our understanding, the expectation is rather to obtain market values as they would be reported under IFRS within this position. Nevertheless, market values are not necessarily reported on-B/S under national accounting standards.
Ad R 03.00 (Own funds):
The instructions state that where the entity the report refers to is not subject to individual own funds requirements, the contribution of the entity to the consolidated prudential own funds shall be reported as reported in the COREP template C 06.02 regarding the contribution of entities to solvency of the group. Given that the own funds template does not require entities to enter information on actually available own funds but rather requires an input of capital requirements in percentage terms, this approach is not possible. The contribution of entities to the solvency of the group only includes information on own funds of the entities in question that are counted as own funds at group level – there is no possibility to infer a capital requirement for these entities that could be entered in the own funds template.
Apart from that, the term “critical function” in resolution planning should not differ from the terminology in recovery planning, in ESBG’s opinion. This should be in the interests of the authorities involved too. However, on the basis of the data requested in the template for “critical function”, this is unfortunately not the case, according to ESBG’s understanding.
The data for FMIs and information systems are not readily available, but must be collected in an extensive manual process covering multiple divisions within banks. A transition period of 3 years would certainly be helpful for banks to set up processes and methods to ease the collection of the relevant data. However, a transitional period can make sense only if definitions and requirements of the EBA and resolution authorities are transparent and understandable. If definitions (e.g. for “information systems” – see also question 7) are not understandable, a transitional period is fairly pointless. The definitions and requirements should, moreover, not be constantly adjusted, but should be fixed for the duration of the transitional period. So far, the definitions and requirements have been “moving targets”.
With the current layout and the instructions given, the templates can sometimes not be properly filled. The intention of the templates is not always very clear. It would be appreciated if the EBA could provide a list of typical services that they expect. Ideally, the EBA should provide examples of what kind of services/relationships they want to see here.
Presumably, the templates R 10.01/ R 10.02, now called “Critical Information Systems” of the current consultation process, represent an update of the former Annex IX. We would like to understand whether “Critical Information Systems” are synonymous with “Key Management Information Systems” and whether the reference to Section B of the Annex to Directive 2014/59/EU is still valid. Does the focus of the templates still lie on risk management, accounting and financial reporting? The resolution authorities have to understand that neither “Critical Information Systems” nor “Key Management Information Systems” nor solely “Information Systems” are terms that are commonly used in bank practice. There is no industry-wide standard nor a commonly-accepted definition so far. The definition of “Critical Information System” in the Instructions is far too vague, in ESBG’s opinion. We would even argue that it is unclear what the core intention of the EBA behind the two templates is. The lack of a clear-cut definition and a missing industry standard will inevitably lead to a very heterogeneous data provision across European banks. This cannot be in the interest of resolution authorities.
The IT infrastructure of large banks consist of thousands of IT products and IT systems. These IT products often come in IT supply chains. While information for resolution purposes might be centralised in data warehouses, this information is supplied to the data warehouses by a multitude of other IT products. Without these data supplies, the data warehouse would be useless, only an empty shell. Do “Critical Information Systems” only include the data warehouse or the whole IT supply chain? Furthermore, there are IT products that cannot be mapped to specific critical functions but are indispensable for bank operations and the IT infrastructure of the bank as a whole. How should these IT products be dealt with? If these IT products shall be included in the templates, the list would be quite long.
Considering current market trends (e.g. big data, in memory technologies), the borders between “Management information systems” and IT products supporting the operational business become even more blurred. Thus, a differentiation in this way does not appear sustainable to ESBG.
As the term “Information Systems” is not used in bank-practice, these systems are not readily available. Rather, the identification of these systems is a manual task for thousands of IT products. The resolution authorities need to understand that this is a huge challenge for banks that will need massive resources. Therefore, banks need concrete assistance in the following points: at first, in order to perform a mapping of information systems to critical functions, the critical functions need to be stable (= no moving target). Second, banks need to better understand what the basic intention of the resolution authorities behind the templates is. What does the resolution authority want to know, what is the focus? Third, there must be a clear-cut definition and industry-wide standard of the term “Information Systems” which has to be prescribed by the EBA and resolution authorities. Fourth, the EBA should clearly define the scope of “Information Systems” with regard to IT-supply chains and IT products that support the IT infrastructure and bank operations as a whole and cannot be separately linked to single critical functions.
Moreover, we recommend that the exercise of identifying parts of the IT products and systems for resolution purposes is harmonised with similar tasks which are frequently conducted. To name just two examples, the institutions business continuity management as well as the information security management contain well-known and standard-based procedures to identify the crown jewels of the IT landscape.
Question 1. Would the envisaged remittance date (31 May to be progressively advanced to 31 March) appropriate for all templates? If not, please justify your answer and indicate, template by template, the alternative remittance date you would suggest.
According to Regulation (EU) 2015/534 of the European Central Bank dated 17 March 2015 on reporting of supervisory financial information (ECB/2015/13), the national competent authorities (NCAs) are, for significant supervised entities that are part of a significant supervised group, obliged to report final FINREP data by the close of business of the 55th day after the reporting/reference date. For this, the NCAs set the date as of which the supervised entities have to report the supervisory financial information so that the NCAs can meet these deadlines. This generally means that a first report by an institution of its preceding year’s figures is made by mid-February and the final report accordingly subsequent to, if needs be, after a concluding discussion with the regulator. In addition, reporting dates for annual financial statements must be observed (as a rule March/April).A final/definitive database for the completion of the templates is thus not available until late. Further analyses must be conducted on this database, which is extended in part by quantitative and qualitative information, as the required data cannot be derived entirely from the data in the annual financial statements. For this purpose, a separate data system must be set up in parts. Between the individual templates there are interdependencies that must be observed when filling them in. In ESBG’s view, a concurrent overall report of all templates would make sense. The reporting/reference date should therefore not be brought forward.
Some concrete suggestions:
Since the audited group results are annually published at the end of March, we suggest changing the remittance date for template R 01.00to 30 April, which would be, practically, much more appropriate.
Regarding the templates in the block on information on on- and off-balance sheet items (R 02.00, R 03.00, R 04.00, R 05.01, R 05.02 and R 06.00), we suggest changing the remittance date to 30 April, since this date corresponds with the already tight remittance date set by the SRB for templates R 02.00, R 03.00 and R 04.00 of this Draft ITS. Furthermore, the remittance date of 30 April would also reflect the fact that information necessary for templates R 05.01, R 05.02 and R 06.00 are usually contained in audited group results that are annually published and available as of the end of March.
For all templates relating to the block as regards “Critical functions and core business lines”, we prefer 31 May as a proper remittance date. This is due to fact that, for instance, the criticality assessment is based on company data as of 31 December and market share data which is simply not available before April for many markets and economic functions. In particular, with regard to developing banking markets in CEE, market shares can change significantly year-by-year with a direct impact on the criticality assessment. Without the availability of the most accurate market data as of 31 December, the criticality assessment would lose accuracy and quality. Therefore, and in order to simplify this regular reporting requirement for the banking sector, ESBG suggests harmonising the remittance dates for all the templates R 07.01 to R 10.02 by changing the proposed remittance date to 31 May.
Question 2. Are there any technical obstacles or inconsistencies in the template ‘R 01.00 - Organisational structure (R-ORG)’ which would prevent you from, or make it disproportionate for you, to report the information required thereby?
Regarding columns 080 (Total assets) and 100 (LRE) of template R 01.00 (Organisational structure), ESBG would like to ask the EBA to clarify whether entities on solo level using nGAAP as their accounting standard should fill in data on an IFRS basis or on an nGAAP basis. Based on the instructions in Annex II, we assume that entities on solo level using nGAAP will have to provide data according to their nGAAP for the columns 080 and 100, while for columns 110 (“Contribution to total consolidated assets”), 120 (“Contribution to total consolidated REA”) and 130 (“Contribution to consolidated Leverage Ratio Exposure”) data based on IFRS have to be provided for. If that is the case, we would question the expected benefit of columns 080 and 100 since the template R 01.00 will most likely list a variety of entities using nGAAP or IFRS as their respective accounting standards. Besides, institutions might not have the IFRS figures available on solo level.Additionally, for entities on solo level, detailed information for the contribution to the group figures are not available as group adjustments are done by the consolidating (parent) entity. Therefore, a reconciliation process with solo entities is not possible at this stage. ESBG proposes to re-think this data request for template R 01.00.
Question 3. Are there any technical obstacles or inconsistencies in the second block of templates (R 02.00 - Liability Structure (R-LIAB), R 03.00 - Own funds (R-OWN), R 04.00 - Intragroup financial interconnections (R-IFC), major counterparties, R 06.00 - Deposit insurance (R-DIS)) which would prevent you or make it disproportionate for you to report the information required thereby?
In this context, ESBG has similar recommendations to the ones presented above: in short, there must be sufficient time to derive the data. In addition, it should be ensured in particular that the “parent waiver” from the COREP return is valid for the MREL report too. From a superordinate perspective, we can say that a number of components of the second block (particularly the template “Liability Structure”) as part of the annual Liability Data Template (LDT) are to a greater extent concretised by the Single Resolution Board (SRB). Accordingly, here, particular attention should be paid so that this does not result in duplicative reporting and/or returns with differing content (e.g., as a result of other cluster formations, etc) for the institutions (concrete example: the accounting standard used as the basis for MREL data at single-institution level should be identical with that of the report to the SRB).With regard to the new template for deposit insurance, the name of the institutional protection scheme has to be given in reporting field 050. According to the explanations for this reporting field, this involves institutional protection schemes pursuant to Art. 113(7) CRR. Reference to deposit protection, however, is made only via institutional protection schemes pursuant to Art. 1(2) c) Directive 2014/49/EU (DGS Directive). Presumably, this, therefore, means such institutional protection schemes. Institutional protection schemes recognised pursuant to Art. 113(7) CRR can exist on a voluntary basis too and detached from the obligations of the DGS Directive.
R 02.00 (Liability Structure):
As regards template R 02.00 (Liability structure), it should be noted that columns 090 and 100 are not cumulative since both can include intragroup liabilities and issuances under non-EU Member State jurisdictions/law. When submitting data for individual entities, in some jurisdictions the data will be subject to national accounting standards, which creates issues with some of the definitions in the template. This relates, for example, to the position r330, balance sheet liabilities arising from derivatives (and further the position total liabilities and own funds). In our understanding, the expectation is rather to obtain market values as they would be reported under IFRS within this position. Nevertheless, market values are not necessarily reported on-B/S under national accounting standards.
Ad R 03.00 (Own funds):
The instructions state that where the entity the report refers to is not subject to individual own funds requirements, the contribution of the entity to the consolidated prudential own funds shall be reported as reported in the COREP template C 06.02 regarding the contribution of entities to solvency of the group. Given that the own funds template does not require entities to enter information on actually available own funds but rather requires an input of capital requirements in percentage terms, this approach is not possible. The contribution of entities to the solvency of the group only includes information on own funds of the entities in question that are counted as own funds at group level – there is no possibility to infer a capital requirement for these entities that could be entered in the own funds template.
Question 4. Are there any technical obstacles or inconsistencies in the third block of templates (critical functions and core business lines, R 08.00 - Critical services (R-SERV), FMI services, critical information systems) which would prevent you or make it disproportionate for you to report the information required thereby?
No. However, it should be noted that for numerous economic functions (e.g. Payment, Cash, Settlement, Clearing, Custody as well as Capital Markets and Wholesale Funding) market data is not available. And for economic functions where market data is generally available, the data as of 31 December is not published by national banks or national statistics bodies before April.Apart from that, the term “critical function” in resolution planning should not differ from the terminology in recovery planning, in ESBG’s opinion. This should be in the interests of the authorities involved too. However, on the basis of the data requested in the template for “critical function”, this is unfortunately not the case, according to ESBG’s understanding.
Question 5. The reporting of FMIs and information systems is already required since 2016. In practice are you operationally able to provide such view and do you think it is necessary to set a transition period, for example to progressively build up over the course of three years a full view of the systems within groups?
Because of the complexity of the necessary data collection and the general, regular systems adjustments, it is, in ESBG’s view, necessary to allow for a transitional phase of at least 3, ideally 5 years.The data for FMIs and information systems are not readily available, but must be collected in an extensive manual process covering multiple divisions within banks. A transition period of 3 years would certainly be helpful for banks to set up processes and methods to ease the collection of the relevant data. However, a transitional period can make sense only if definitions and requirements of the EBA and resolution authorities are transparent and understandable. If definitions (e.g. for “information systems” – see also question 7) are not understandable, a transitional period is fairly pointless. The definitions and requirements should, moreover, not be constantly adjusted, but should be fixed for the duration of the transitional period. So far, the definitions and requirements have been “moving targets”.
Question 6. The reporting of FMI services and enabling services, in templates R 09.02 and R 09.03 could be facilitated if a list of typical services was included. Can you suggest such list?
Such a list would, in our opinion, have to be drawn up by the competent authorities on the basis of their collective experiences/empirical values. In ESBG’s view, there should be no reports from the institutions.With the current layout and the instructions given, the templates can sometimes not be properly filled. The intention of the templates is not always very clear. It would be appreciated if the EBA could provide a list of typical services that they expect. Ideally, the EBA should provide examples of what kind of services/relationships they want to see here.
Question 7. Does the nomenclature of information systems in template R 10-01 - Critical Information systems (General information) (R-CIS 1) cover the various types of existing systems, and would it in your view enable the authority to properly identify systems that are key in the performance of critical functions?
In the original ITS on information for resolution plans from 2014-2015, the EBA introduced Annex IX called “Information Systems”. The instructions of template IX made reference to Section B of the Annex to Directive 2014/59/EU and requested “[…] a detailed inventory and description of the key management information systems, including those for risk management, accounting and financial reporting […].”Presumably, the templates R 10.01/ R 10.02, now called “Critical Information Systems” of the current consultation process, represent an update of the former Annex IX. We would like to understand whether “Critical Information Systems” are synonymous with “Key Management Information Systems” and whether the reference to Section B of the Annex to Directive 2014/59/EU is still valid. Does the focus of the templates still lie on risk management, accounting and financial reporting? The resolution authorities have to understand that neither “Critical Information Systems” nor “Key Management Information Systems” nor solely “Information Systems” are terms that are commonly used in bank practice. There is no industry-wide standard nor a commonly-accepted definition so far. The definition of “Critical Information System” in the Instructions is far too vague, in ESBG’s opinion. We would even argue that it is unclear what the core intention of the EBA behind the two templates is. The lack of a clear-cut definition and a missing industry standard will inevitably lead to a very heterogeneous data provision across European banks. This cannot be in the interest of resolution authorities.
The IT infrastructure of large banks consist of thousands of IT products and IT systems. These IT products often come in IT supply chains. While information for resolution purposes might be centralised in data warehouses, this information is supplied to the data warehouses by a multitude of other IT products. Without these data supplies, the data warehouse would be useless, only an empty shell. Do “Critical Information Systems” only include the data warehouse or the whole IT supply chain? Furthermore, there are IT products that cannot be mapped to specific critical functions but are indispensable for bank operations and the IT infrastructure of the bank as a whole. How should these IT products be dealt with? If these IT products shall be included in the templates, the list would be quite long.
Considering current market trends (e.g. big data, in memory technologies), the borders between “Management information systems” and IT products supporting the operational business become even more blurred. Thus, a differentiation in this way does not appear sustainable to ESBG.
As the term “Information Systems” is not used in bank-practice, these systems are not readily available. Rather, the identification of these systems is a manual task for thousands of IT products. The resolution authorities need to understand that this is a huge challenge for banks that will need massive resources. Therefore, banks need concrete assistance in the following points: at first, in order to perform a mapping of information systems to critical functions, the critical functions need to be stable (= no moving target). Second, banks need to better understand what the basic intention of the resolution authorities behind the templates is. What does the resolution authority want to know, what is the focus? Third, there must be a clear-cut definition and industry-wide standard of the term “Information Systems” which has to be prescribed by the EBA and resolution authorities. Fourth, the EBA should clearly define the scope of “Information Systems” with regard to IT-supply chains and IT products that support the IT infrastructure and bank operations as a whole and cannot be separately linked to single critical functions.
Moreover, we recommend that the exercise of identifying parts of the IT products and systems for resolution purposes is harmonised with similar tasks which are frequently conducted. To name just two examples, the institutions business continuity management as well as the information security management contain well-known and standard-based procedures to identify the crown jewels of the IT landscape.