Response to discussion on a Feasibility Study of an Integrated Reporting System under Article 430c CRR
Go back
2) For SRB are just mentioned EBA harmonized reporting and not valuation dataset which is another relevant granular data collection;
3) Standard OSI templates (e.g. credit risk loan tape) are missing as well
The scenario infrastructure-only is not realistic since it would be an unfeasible aggregation of different data.
Very often they are strictly related to several application/layers involved in the reporting framework and in some cases they are provided by external vendors.
Extracting data: the functional analysis to define extraction rules could start from the data dictionary with savings, for example, in terms of capacity for their production.
Processing data: the dictionary would facilitate the reconciliation and DQ checks along data aggregation and processing phases.
Exchanging and monitoring: Regulators’ feedback would be more specific and DQ could be enhanced.
Finally, this activity should be seen in a medium long term scenario where relevant costs (investments) should overcome actual (equally high) costs and reporting burden.
The definition of a granular dictionary and related transformation will enhance aggregation capabilities of the reporting institutions.
Nevertheless, a gradual, carefully defined approach towards Option 2 make sense and is preferable in the longer term, e.g. to remove gradually data duplications and complexity where benefit/cost ratio is highest.
There are many challenges to be faced with granular data reporting:
- items that cannot be depicted with an instrument approach (loan by loan): e.g. other assets, consolidation adjustments
- DQ issues (DQ indicators to be defined)
- legal constraints (e.g. GDPR, banking secrecy, third countries legislation).
Finally, ESCB IReF project, which has a wide coverage of banking products/events, could be a good benchmark for future solutions.
There are several challenges mainly related to legal issues:
(i) new regulations with new governance
(ii) MoU with third countries authorities
(iii) data protection management
Manual adjustments should be reduced as much as possible. In this perspective, the usage of End User Computing applications (IDP) should be discouraged.
2) It would foster the dialogue between Regulators and banks
3) Ad hoc requests are expected to be less frequent since data sharing between authorities will be enhanced
Among others, following items are worth to be mentioned:
- Clear governance for data usage and sharing
- Same protocols and formats for data exchange between banks and Authorities
- Agreed DQ framework
- data encryption
Data collection and data transformation: only partially, higher degree for some countries (e.g. Italy)
Partial/No used explained by a variety of factors, dependent on country/regulatory process: Not available at all (for some countries), not fully developed (for some countries), available but not useful for my needs (e.g. due to integration complexity)
a) data definition (e.g. thanks to common metadata, shared among operators and regulators, and made available "real time" to the market through common tools)
b) data collection (e.g. through common repositories/granular data models, to be used for mapping from internal systems)
c) data transformation (e.g. to commoditize all "deterministic calculations" common across all banks, and subject to periodic updates from regulatory authorities)
d) data exploration (less important for RegTech, since more frequently needed in conjunction with internal data, but potentially useful e.g. to boost data quality checks on granular data)
If data integration is referring to the "last mile" protocol vs regulatory authorities, we believe this should be a feature of available market tools.
1) Please explain which institutions you think should be considered by the Feasibility Study.
Banks (credit institutions) subject to CRR and national requirements. Priority should be given to larger banks (e.g. cross border institutions) that could take benefit from a more harmonized reporting framework2) Please explain which data collections you think should be considered by the Feasibility Study.
All regulatory reporting other than those submitted exclusively to NCAs where harmonization is hard to achieve and there is not enough data volumes where economies of scale can be obtained.3) Do you consider that the issues identified, the options proposed and the assessment approach taken throughout the discussion paper are relevant and complete? If not, please explain.
Items covered are complete; it could be added to the Data dictionary topic that the more standardization would facilitate comparability of data at a deeper level and managerial data exploration with the reuse of regulatory data.Please specify "other" from question 4
The main obstacles to be overcome are: 1) the adoption of a single and shared taxonomy (to be provided by the Authorities), including to the maximum extent the same degree of granularity; 2) the analysis of local peculiarities in terms of business and regulators requirements (including legal entities outside EU); 3) Change Management topics (i.e. resistance to change); 4) Legal barriers (e.g. different data/banking secrecy frameworks that could affect in particular the collection of granular data) 6) ICT investments and related costs due to possible decommissioning of actual solutions.5) Do you confirm the findings presented in the stocktake? If you have additional information, please provide more specific details about the amount of data collected.
1) Different solutions in the data model and data transmission (DPM vs ERM) where DPM is less usable for data analysis; DPM is very rigid and maintenance costs are relevant and more frequent. Moreover DPM is prone to redundancy (e.g. Large Exposures: depiction of exposures towards Central administration that are reported as many times as are the connected group of clients).2) For SRB are just mentioned EBA harmonized reporting and not valuation dataset which is another relevant granular data collection;
3) Standard OSI templates (e.g. credit risk loan tape) are missing as well
Please insert hereafter any comments you might have in relation to question 6
We deem appropriate keeping to the maximum extent the alignment between semantic and syntactic layer.The scenario infrastructure-only is not realistic since it would be an unfeasible aggregation of different data.
What solutions should the EBA investigate in the areas listed in question 6 that could help to reduce reporting costs?
The reduction of reporting costs should be realized reducing the requests of some aggregated information leveraging on (statistical) granular data. Obviously avoiding micromanagement in terms of full reconciliation but foreseeing some thresholds below which the data can be considered sound.8) Do you use one or more data dictionaries in your compliance and reporting processes?
This is a stepwise approach: to cover the entire end-to-end chain of the data life cycle, the framework embraces a continuous improvement approach, enabling the growth and improvement of data dictionaries. We tend to use as much as possible homogeneous data dictionary/taxonomies . At the same time, in order to deal with the heterogeneous requests coming from the different regulators, our Data Lineage practice allows to manage several data dictionaries managing them in a consistent way.Very often they are strictly related to several application/layers involved in the reporting framework and in some cases they are provided by external vendors.
9) What are the characteristics you think a data dictionary should have? Do you agree with the one referred to in this document? Do you think any characteristic is missing or should not be included?
The (syntactic) data dictionary should be a central catalog containing high-level business concepts, as well as their characteristics, which can be easily identified / understood / integrated / updated. A catalog accessible and appropriately updated by any licensed / authorized business expert would avoid data duplication and help building a robust / comprehensive dictionary. Once a certain level of maturity is achieved, a higher level of granularity could be contemplated and it might be useful to also include common transformation rules that can be involved in defining a high-level business concept. It should include, from a high-level perspective, all framework-specific semantic definitions it supports.10) What is the role you think the data dictionary can have in regulatory compliance and reporting?
The data dictionary has a central role. It is the starting point in order then to guarantee a sound usability of data for different strategic options. It should be the basis for all communication from and to the banks and could be meant as a reference for the feasibility of new data requirements, at least in the short term.Please explain how would a standard data dictionary help institutions to improve the listed processes.
Understanding reporting regulation: a single and shared data dictionary will strengthen clarity at all levels of the data reporting process with fewer interpretation differencesExtracting data: the functional analysis to define extraction rules could start from the data dictionary with savings, for example, in terms of capacity for their production.
Processing data: the dictionary would facilitate the reconciliation and DQ checks along data aggregation and processing phases.
Exchanging and monitoring: Regulators’ feedback would be more specific and DQ could be enhanced.
12) How important is it for institutions to have a unique and standard data dictionary for all regulatory data with the aim of ensuring consistent use across the supervisory, resolution and statistical reporting?
Highly important13) How much would it cost to move to a unique regulatory data dictionary?
Highly costlyPlease include any other comment to question 13
Despite the possible increase in costs in the initial phase, related to the implementation of the unique data dictionary metamodel and the updating of all existing systems, once the unique data dictionary is consolidated and adopted, we believe that a significant cost reduction is expected. The initial phase of data analysis, mostly one of the most expensive phases of a project, would be greatly facilitated by a centralized data repository.Finally, this activity should be seen in a medium long term scenario where relevant costs (investments) should overcome actual (equally high) costs and reporting burden.
14) How much cost reduction is expected by integrating the national regulatory reporting together with the harmonised reporting regulation into a unique data dictionary?
High cost reductionsPlease include any other comment to question 14
This choice would reduce current heterogeneity among jurisdictions in the EU and thus enhance the common level playing field in particular for cross boarders banks.15) How much cost reduction is expected by integrating ad hoc regulatory reporting with harmonised regulation into a unique data dictionary?
High cost reductionsPlease include any other comment to question 15
The integration of ad hoc regulatory reporting with harmonised regulation into a unique data dictionary would solve discrepancies among transformations and business concepts' meaning. Hence, it would allow: on one hand a common comprehension, as well as usage, of the transformation rules for reporting frameworks; on the other hand to use the already existing assets as building blocks for new future transformations at different granular levels.16) Do you agree with the costs and benefits highlighted in the chapter? Do you see other costs and benefits when implementing a standard data dictionary?
The dictionary would facilitate the detection of “single source of truth” data flows and boost governance within banks of the same group.17) What would be the implication of granular data reporting on the institutions’ compliance with BCBS 239 (also in the context of the options presented)?
Granular data can be required in a context in which there is a great homogenization both in terms of semantic and syntactic otherwise it may generate additional efforts.The definition of a granular dictionary and related transformation will enhance aggregation capabilities of the reporting institutions.
18) For which reporting areas (prudential, statistical and resolution or modules/parts of these areas) may the use of granular data present a solution? (multiple choices)
prudentialPlease include any other comment to question 18
It may help across the different reporting areas. In terms of priority we propose (i) statistics (ii) resolution (iii) prudential as capital ratios would be included in the set of aggregated data to be calculated both by the regulator and the institutions.Feasable and preferable
option 2Main challenges and possible solutions - option 2
Granularity can allow for more flexible use of data and easily prevent duplication; that said, a higher level of granularity could be less feasible initially and Option 1 would be the most feasible at an early stage, where the maturity level may not be as high and the costs are more significant.Nevertheless, a gradual, carefully defined approach towards Option 2 make sense and is preferable in the longer term, e.g. to remove gradually data duplications and complexity where benefit/cost ratio is highest.
There are many challenges to be faced with granular data reporting:
- items that cannot be depicted with an instrument approach (loan by loan): e.g. other assets, consolidation adjustments
- DQ issues (DQ indicators to be defined)
- legal constraints (e.g. GDPR, banking secrecy, third countries legislation).
20) In case of Option 2, please specify how should the granular collection layer be designed to your best advantage (and benefit of reporting more granularly)?
We believe the backbone of Option 2 should be to have granular data underlying Finrep since crucial for consistency/completeness purposes, less "transformation intensive", audit-relevant and as common denominator for many other reporting streams. Other reporting streams could be handled as gradual add-ons on this backbone, aiming to add only additional data specific for the reporting purpose and avoid/remove existing data redundancies. Instutions should be given ample room for shaping the roadmap for onboarding.Finally, ESCB IReF project, which has a wide coverage of banking products/events, could be a good benchmark for future solutions.
Please specify "other" from question 21 - COSTS
- DQ issues and management of several accounting principlesPlease specify "other" from question 21 - BENEFITS
More stability in regulatory requests and fewer ad hoc requests22) What possible aspects related to the design of the option (Question 19) would make the costs for this option higher than the benefits and therefore not worth implementing?
A key aspect, that could be a significant cost/complexity driver, is to avoid an excessive period of co-existence between old/new reporting paradigm, and the lack of modularity in the transition approach - which should allow the single banks different options for adopting the new framework.23) If transformations are to be defined (as depicted in Option 2 or Option 3), who should be responsible for their definition (e.g. who takes responsibility for their correctness) and their execution?
Authorities and reporting institutions jointly25) How should the transformations be in terms of formalisation and readiness for digital processes?
Harmonised and standardised, ready to be implemented by digital processes (fixed)Please include any comment to question 24
The definition should be made jointly but the responsibility of output data remains in the banks.There are several challenges mainly related to legal issues:
(i) new regulations with new governance
(ii) MoU with third countries authorities
(iii) data protection management
Manual adjustments
Higher threshold of acceptance are considered useful.Manual adjustments should be reduced as much as possible. In this perspective, the usage of End User Computing applications (IDP) should be discouraged.
Consolidated/individual figures
Some consolidated data (portion of tempates or entities) could be left to direct contribution of banks (output data) without tracking the transformations from individual data.Different valuations
Harmonization of metrics requiredPrinciple-based rules
Harmonization of regulationsLegal aspects
extensive harmonization in the EU29) Is your institution reporting to different authorities in your home country?
Yes30) Is your institution reporting to other authorities in host countries?
YesPlease comment: What problems arise from reporting to different authorities?
Different taxonomies, different rules (semantic, syntactic and technical protocols).31) Are you using one or more data dictionaries for reporting? How?
Multiple dictionariesPlease comment: how are you making use of them?
We are feeding a data dictionary with unique business terms (semantic layer) in the Group and more syntactic and technical implementations disseminated within legal entities applications.32) Are you using the same or different formats for prudential/resolution reporting and for statistical reporting?
Different formatsPlease include any other comment to question 32
There are significant variations both between different reporting types and different countries. Nevertheless we are working in order to guarantee data lineage between different layers.33) How important would it be, for your institution, to have access to a CDCP for all prudential, resolution and statistical reports? Why?
Very importantPlease include any other comment to question 33
1) It would overcome current primary reporting collection layers and enhance scalability and reusability of the Data and IT regulatory projects for all the EU legal entities.2) It would foster the dialogue between Regulators and banks
3) Ad hoc requests are expected to be less frequent since data sharing between authorities will be enhanced
34) What should be, in your view, the main characteristics of a CDCP?
Competent authorities should find the right governance rules, also to remove over time possible discrepancies&redundancies in - and to help define a clear and common/consistent evolutionary path for managing changes over time, aspects which are clearly made difficult by multiple data collection points. Some flexibility should be maintained In order to handle transition smoothly (in terms of changed cut of time/frequencies) for various reporting types/countries should be kept.Among others, following items are worth to be mentioned:
- Clear governance for data usage and sharing
- Same protocols and formats for data exchange between banks and Authorities
- Agreed DQ framework
- data encryption
Please answer here to question 35
The main costs should be at competent authorities. A significant change in terms of homogenous semantic, syntactic and clear governance rules for the management of the CDCP and for the definition of new request. At institutions level we see only benefits after initial one off costs for adapting to the new set-up.37) Would the industry be prepared to bear the costs of integrated reporting?
Yes, to a large extentPlease include any other comment to question 37
A clear and long term roadmap should be defined, and statement is of course dependent on complexity of final scenario. In our Grouo we are already moving towards the integration of assets and processes.39) On a best effort basis, please include any monetary cost estimate you may be able to provide (% of operational costs) related to the implementation of an integrated reporting system for your institution.
Based on internal projects we are running for integrating architectures, we can estimate at least 150 million euros40) Would you prefer the future integrated reporting system to be based on:
A push approachPlease include any other comment to question 40
Absolute preference remains on a PUSH approach, also considering high heterogeneousness both between different group entities and reporting processes.pull
We would not change respect to a push approach. We see only drawbacks (process, data quality, governance) for a pull approachFeasibility of the central data collection point
Delivery of granular data for retail customers in light of local regulations (e.g. Austrian one) making it impossible to receive centrally granular data for retail perimeterIf no, please explain:
Other (please explain)please explain "other" from the above question
Data definition: only partially, for higher degree for some countries (e.g. Italy) or processes (e.g. Anacredit)Data collection and data transformation: only partially, higher degree for some countries (e.g. Italy)
Partial/No used explained by a variety of factors, dependent on country/regulatory process: Not available at all (for some countries), not fully developed (for some countries), available but not useful for my needs (e.g. due to integration complexity)
Please include any other comment to question 49
We believe that RegTech development could be useful both to increasingly industrialize all 4 process steps, according to following remarks:a) data definition (e.g. thanks to common metadata, shared among operators and regulators, and made available "real time" to the market through common tools)
b) data collection (e.g. through common repositories/granular data models, to be used for mapping from internal systems)
c) data transformation (e.g. to commoditize all "deterministic calculations" common across all banks, and subject to periodic updates from regulatory authorities)
d) data exploration (less important for RegTech, since more frequently needed in conjunction with internal data, but potentially useful e.g. to boost data quality checks on granular data)
51) Would you be keen to invest in RegTech for integration of different types of data? How would you develop such a technology?
in-housePlease include any other comment to question 51
Yes, we see this definitely as an interesting option, although currently with a preference for solutions allowing OnPremise installations. Our Group already today has a preference for RegTech/standard solutions wherever possible to address regulatory requirements, and especially so if the requirements are of European/cross-border relevance (due to the wide geographical scope of the group, both within ECB perimeter and beyond).52) How do you think RegTech can help in data integration?
see question 51.If data integration is referring to the "last mile" protocol vs regulatory authorities, we believe this should be a feature of available market tools.