Primary tabs

European Association of Co-operative Banks (EACB)

NA
Please refer to our answer under Q4.
Please refer to our answer under Q4.
Not relevantSomewhat relevantRelevantHighly relevant
Training / additional staff (skills)  X 
IT changes  X 
Changes in processes  X 
Changes needed in the context of other counterparties / third-party providers  X 
Time required to find new solutions  X 
Other (please specify)  X 
The EACB welcomes the opportunity to comment on the EBA DP on a Feasibility Study of an Integrated Reporting System under Article 430c CRR.
At a general level we would highlight the following:
 While one of the desirable objectives of an integrated reporting system would be to reduce the number and frequency of ad hoc requests, it should be considered that many such exercises arise from idiosyncratic reasons that are difficult to define upfront. There is therefore a risk that banks will have to face both a more granular system and persisting ad hoc requests, thus resulting in no relief from an administrative perspective. We see a need for a clear commitment from authorities to issue fewer ad hoc requests and invest more time in digging into the granular data that they would receive.
 As generally understood, proportionality in reporting is currently embedded via the templates. Such an approach would be hard to implement in a framework with increased granularity and fundamentally data driven. While discussions would still be needed on the most suitable way forward, we encourage EBA to continue give proportionality a prominent place in discussions.
 For smaller and medium sized banks more granular reporting means building infrastructure for data never collected before. This could mean considerable initial investments but also higher ongoing costs. Especially in a pull system more verification would be needed.
 A pull system presents the question of data accountability. A key issue would be the need for proper governance and process to take note of who accesses the data and when. A pull model also needs to address questions of real- or near-time availability in the bank of oversight on data, which would make allocation of responsibility more complex. Data room-like solutions might be needed, or the use of possible cutoff dates for institutions to generate the data. We understand that a data room might appear like a form of push model, but practical systems should be favoured. Solutions could also envisage “data days” when supervisors will/may pull the data. It should also be noted that supervisors might perform all kinds of aggregations and deep dives with the data pulled, institutions would need to be able to know what kind of queries were pulled e.g. to replicate what supervisors did.
 A pull system also entails technical challenges in terms of technologies to be used. It is in fact to be clarified whether reporting institutions' data repositories must be built upon a very specific technology, or a set of accepted technologies, or interfaces with all commercial solutions would be available. Furthermore, it would have to be specified how downtime would be managed (or whether institutions would be expected to have an ongoing guaranteed uptime of systems, which would be extremely costly). Finally, data transfer should also not be overlooked, sending large amounts of granular data through an API/Web Service could be more challenging than with a managed file transfer which is typically used for a push.
 We understand that the EBA has so far not reflected on a direct link or mechanism between the shift in the data generation and reporting and data quality aspects, including effects on scoring, under SREP. We believe that this aspect should be thoroughly discussed with institutions before being reflected in the SREP GLs.
 The timeline for implementation is a key cost driver, as also acknowledged by the EBA. We would reiterate that when the new dictionary is eventually set up, it must be flexible enough to be implemented by all banks and authorities, easy to update and adjust.
 It should also be noted in fact that cost estimations at this stage would require a difficult analysis with too many missing variables. Costs can be regular, one-off or recurring, much will depend on decisions on granularity and transformations.
 In this regard good governance arrangements will be key to the system, and it should not be overlooked that small institutions will have shoulder the bulk of costs at first. We believe that banks should be involved in the governance of the reporting system, even if not with “voting rights” at least with an advisory role.
 Finally, we would like to stress that a data driven environment (particularly at supervisory level) should be considered also at the level of originating legislative proposals and designing of the relevant regulatory requirements. While this dimension is missing in the consultation, it is essential to take this into account at an early stage to avoid having to introduce incremental fixes that only weigh on the overall complexity of reporting and related costs.
NA
Highly agreeAgreeSomewhat agreeDon’t agree
Data Dictionary - Semantic levelX   
Data Dictionary - Syntactic levelX   
Data Dictionary - Infrastructure levelX   
Data collection - Semantic levelX   
Data collection - Syntactic levelX   
Data collection - Infrastructure levelX   
Data transformation - Semantic levelX   
Data transformation - Syntactic levelX   
Data transformation - Infrastructure levelX   
Data exploration - Semantic levelX   
Data exploration - Syntactic levelX   
Data exploration - Infrastructure levelX   
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
SignificantlyModeratelyLow
Understanding reporting regulationX  
Extracting data from internal systemX  
Processing data (including data reconciliation before reporting)X  
Exchanging data and monitoring regulators’ feedbackX  
Exploring regulatory dataX  
Preparing regulatory disclosure compliance.X  
Other processes of institutionsX  
NA
NA
NA
NA
NA
NA
SREP and BCBS 239
As indicated in the General comments (see Q4), the implications for the SREP of the move to the new reporting framework remain unclear. At the same time, Question 17 asks about the implications of granular data reporting on the institutions’ compliance with BCBS 239. We would note that the assessment of compliance with BCBS 239 is an aspect of the SREP process, which has so far revealed quite a degree of heterogeneity across JSTs in the SSM (for directly supervised banks). At this stage, it would therefore be firstly an issue of consistent criteria across JST teams.
At the same time, there are other elements that should be considered when addressing BCBS 239 compliance. These include the lack of a common regulatory data dictionary (which the project aims to develop), the duplication of data requests, gold plating and so on. If the reporting process is thoroughly and sustainably designed and takes into account the practical implementation process of institutions, compliance with BCBS 239 would certainly be facilitated. The common dictionary, reduction of overlaps and redundancies, avoidance of gold plating, would be steps in the right direction.
Granularity
The level of granularity is possibly going to be the “elephant in the room” in the discussions as the projects develops further, in particular how much the data-driven reporting can drill down into a more granular level still reaping benefits compared to the current template-based reporting, and without making the shift unfeasible or unsustainable in the long term (investment costs and maintenance costs).
In this regard, it is essential that the transition towards a data driven approach follows a staged approach, also including clear milestones that institutions can prepare for and anticipate. It is necessary to avoid incurring in costs for changes in systems that would need to be further adjusted in an iterative process of trial and error just for a drive for increased granularity.
For instance, a path to decommission existing template step by step is necessary, otherwise banks will be challenged to comply with multiple reporting sets based on different approaches without reaping the benefit of a define once-report once principle.
NA
NA
NA
NA
NA
NA
Highly (1)Medium (2)Low (3)No costs (4)
Collection/compilation of the granular dataX   
Additional aggregate calculations due to feedback loops and anchor valuesX   
Costs of setting up a common set of transformations*X   
Costs of executing the common set of transformations**X   
Costs of maintaining a common set of transformationsX   
IT resourcesX   
Human resourcesX   
Complexity of the regulatory reporting requirementsX   
Data duplicationX   
Other: please specifyX   
NA
Highly (1)Medium (2)Low (3)No benefits (4)
Reducing the number of resubmissionsX   
Less additional national reporting requestsX   
Further cross-country harmonisation and standardisationX   
Level playing field in the application of the requirementsX   
Simplification of the internal reporting processX   
Reduce data duplicationsX   
Complexity of the reporting requirementsX   
Other: please specifyX   
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
not valuable at allvaluable to a degreevaluablehighly valuable
Data definition – Involvement    
Data definition – Cost contribution    
Date collection – Involvement    
Date collection – Cost contribution    
Data transformation – Involvement    
Data transformation – Cost contribution    
Data exploration – Involvement    
Data exploration – Cost contribution    
Data dictionary – Involvement    
Data dictionary – Cost contribution    
Granularity – Involvement    
Granularity – Cost contribution    
Architectures – Involvement    
Architectures – Cost contribution    
Governance – Involvement    
Governance – Cost contribution    
Other – Involvement    
Other – Cost contribution    
NA
NA
NA
 A pull system presents the question of data accountability. A key issue would be the need for proper governance and process to take note of who accesses the data and when. A pull model also needs to address questions of real- or near-time availability in the bank of oversight on data, which would make allocation of responsibility more complex. Data room-like solutions might be needed, or the use of possible cutoff dates for institutions to generate the data. We understand that a data room might appear like a form of push model, but practical systems should be favoured. Solutions could also envisage “data days” when supervisors will/may pull the data. It should also be noted that supervisors might perform all kinds of aggregations and deep dives with the data pulled, institutions would need to be able to know what kind of queries were pulled e.g. to replicate what supervisors did.
 A pull system also entails technical challenges in terms of technologies to be used. It is in fact to be clarified whether reporting institutions' data repositories must be built upon a very specific technology, or a set of accepted technologies, or interfaces with all commercial solutions would be available. Furthermore, it would have to be specified how downtime would be managed (or whether institutions would be expected to have an ongoing guaranteed uptime of systems, which would be extremely costly). Finally, data transfer should also not be overlooked, sending large amounts of granular data through an API/Web Service could be more challenging than with a managed file transfer which is typically used for a push.
NA
NA
NA
Framework aspects
Among the objectives of an integrated reporting system, alleviating the reporting burden for institutions is a focal point. In this vein, the industry is a fundamental stakeholder and some form of participation of the industry in the proposed Joint Committee should be envisaged.
The involvement of the industry at the level of the Joint Committee would allow banks to contribute input from the beginning and assess from the grounds the challenges and impact that the new reporting requirements/framework would entail.
This is even more evident if we consider that there are numerous technical aspects in play that will have to be covered in the implementation phase, from the common dictionary to the overall architectures and possible technologies available, from the expected timelines to the decommissioning of the existing reporting frameworks (gradual phase out, temporary overlaps etc.).
It should also be clear that the end goal should not be to establish new reporting requirements as a result of the integrated reporting initiative, but rather achieve harmonisation of definitions, smoother submission processes, and overall reduced complexity compared to the current framework.
Finally, we should also consider that implementing the integrated reporting system will also have to take into account/possibly integrate the requests coming from NCAs, and national frameworks can still reveal rather different.
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
Marco Mancino
E