A revision of the reporting system can only be beneficial if all reports are taken into account. This relates to statistical reporting, regulatory reporting and reporting to resolution authorities and deposit guarantee institutions (the latter two are not relevant for many EAPB members). In the end only in this way simplifications and reductions in cost can be achieved. Therefore, all relevant stakeholders must be taken into account in a feasibility study, i.e. both the reporting authorities and the reporting institutions.
Training / additional staff (skills)
Changes in processes
Changes needed in the context of other counterparties / third-party providers
Time required to find new solutions
Other (please specify)
Data Dictionary - Semantic level
Data Dictionary - Syntactic level
Data Dictionary - Infrastructure level
Data collection - Semantic level
Data collection - Syntactic level
Data collection - Infrastructure level
Data transformation - Semantic level
Data transformation - Syntactic level
Data transformation - Infrastructure level
Data exploration - Semantic level
Data exploration - Syntactic level
Data exploration - Infrastructure level
A robust and well-defined data model for all reporting areas is the key to a future-oriented new reporting format. Approaches that are already well advanced in development, such as BIRD, should definitely be included in the development. The data dictionary should be structured in such a way that a transaction with all its components only needs to be reported once in order to fulfill all reporting requirements.
Understanding reporting regulation
Extracting data from internal system
Processing data (including data reconciliation before reporting)
Exchanging data and monitoring regulators’ feedback
Exploring regulatory data
Preparing regulatory disclosure compliance.
Other processes of institutions
High cost reductions
High cost reductions
Regarding the granularity of the data to be reported, reporting at the individual transaction level must be intended. If aggregations and evaluations are carried out at the reporting recipients on the reported data, the rules used for this must be transparent and traceable for the reporting institution. Furthermore, it should be possible for the reporting party to get access to these results. In the end, only the reporting institution can be responsible for e.g. calculated capital ratios. Due to this initial situation, only option 2 (page 78 of the Discussion Paper) can be the preferred way of implementation, with the reduction of the volume of data to be reported being a key objective.
No costs (4)
Collection/compilation of the granular data
Additional aggregate calculations due to feedback loops and anchor values
Costs of setting up a common set of transformations*
Costs of executing the common set of transformations**
Costs of maintaining a common set of transformations
Complexity of the regulatory reporting requirements
Other: please specify
No benefits (4)
Reducing the number of resubmissions
Less additional national reporting requests
Further cross-country harmonisation and standardisation
Level playing field in the application of the requirements
Simplification of the internal reporting process
Reduce data duplications
Complexity of the reporting requirements
Other: please specify
Authorities and reporting institutions jointly
Definition of appropriate rules.
Data collection on prudential, statistical and resolution legislation should be aligned; supervisory scope should change.
Valuation methods, for example, fair value, amortized costs etc. should be harmonized; unique valuation method.
Rules across the entire EU should be harmonized.
Alignment across the entire EU, like legislation on confidentiality and data privacy, etc.
Legal aspects should be treated at national level and taken into account at European level definitions.
The majority of the institutions report to different authorities in their countries.
Problems that arise from reporting to different authorities:
- Differences in: (data) delivery models, accounting rules, definitions, consolidation aspects, technical formats, reporting timelines and frequencies;
- Overlapping data requests;
- Local differences in terms of regulation;
- Mix of aggregated and granular data;
Because of differences in primary reporting definition as well as in the technical input layer across EU countries, institutions are consequently using a different semantic and syntactic data definition and a different semantic and syntactic definition for the data collection.
In other cases, dictionaries differ country by country or by reporting framework. Some are using an internal data dictionary, while some other banks are using one conceptual data dictionary with more technical implementations. That’s why, each system has its own implementation.
- One dictionary for all data collections, without any regard to the final purpose, who the requesting authority is, and what the national vs EU nature of the request is.
- Only one collection layer, no existence of multiple reporting layers.
- Proper governance should be established, in order to reuse and share already existing data.
- Standardized transformation rules deriving regulatory data/templates.
- In order to protect sensible data from EU and other countries, encryption facilities should be available.
- For all types of reports and in all jurisdictions, the interfaces for data collection should be consistent.
- Uniform protocols and formats should be used for data exchange between the institutions and the authorities.
- Common roles and access control rules.
- Data quality should be assured through quality controls and control framework.
- Clearly defined Data Dictionary covering the data definitions; principles and rules of data quality management;
- Complex data transformation should be avoided.
Following aspects should be taken into account to reduce the costs:
- A commonly used single granular data model in the European banking industry is essential to reduce the costs of reporting.
- To the reporting institutions both the proposed "centralized system" (5.2.10) and "distributed system" (5.2.11) are beneficial in a same manner, but we consider that the centralized system would produce a lower TCO. Furthermore, if the "distributed system" allows for national divergence of data requirements, this alternative will be significantly worse than the centralized system for the reporting institutions.
Yes, to a limited extent
not valuable at all
valuable to a degree
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
The estimation of costs is bank-specific and requires a detailed analysis. Moreover, it depends on the scenario (full integration to optimizing current DPM), the granularity of reporting frameworks and transformation aspects. Because of theses unknowns we are not able to provide a figure.
A push approach
With regard to the organization of future reports, an institute should only have to deliver a report to one central office and only clarify any data quality problems that arise with this office (single point of contact). Since the responsibility for the correctness of the data lies with the supplying institute, the push model seems to be the only possible solution in terms of architecture.
We agree with the EBA-description of the ‘Agile Coordination Mechanism’, because it represents a simple and efficient way to manage a better governance of new data requests and to make use of the capabilities of the CDCP and the common data dictionary. For example, since the objective of the data request can differ, it could start with defining the data definitions per competent authority. Once this is done, it could detect and eliminate overlaps. A unified code for each data definition will support this (and will ease machine readability). In case an authority wants to add a new definition, it should clearly state why this definition from its point of view is missing in the central dictionary. Then a board of supervisors for prudential and statistical reporting should judge the new requests and, if approved, should ensure that the data element is added to the central framework.
We consider that this matter should be discussed in the further course.
Other (please explain)
The use of RegTech by the institutions differs. Some of them do not use it at all. Others use it partially, for example, to support data collection and transformation. There are also institutions using it widely, in each step of the reporting process.
The advantages of using RegTechs can only be assessed on an institution-specific basis. The larger and more complex or specialized an institution's business, the lower the marginal benefit of using a RegTech.