Primary tabs

German Savings Banks Association (DSGV)

All stakeholders in the area of statistics, prudential and resolution.
National data (without an opt-out) and European, statistical and prudential, incl. resolution data
In general, many key aspects have been addressed, although considerations for the procedural handling of a more granular reporting system, including data validation/corrections and reporting follow-up processes (in this context, the considerations on feedback loops) could be further elaborated in terms of their substance.
Equally, the options for taking proportionality into account in a granular reporting system should be addressed in greater detail.
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   
Yes, generally okay.
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   
All our answers are given from the perspective of German savings banks. We do not have detailed answers, but like to contribute as follows:

The approach is generally appropriate from an academic/scientific perspective in terms of structured preparation of the topic, but from an institutions’ point of view (implementation view), it is difficult to understand and too abstract.
We therefore view the discussion paper as the prelude to a discussion at European level about the more detailed design of the individual components, with priority given to the data dictionary and granularity and the associated procedural implications for the handling of data reporting. Against this background, it is difficult or even impossible to answer many of the questions in the discussion paper (e.g. questions 12 -15 or questions 39 and 40).
For example, our answer to question 15 (cost reduction for ad hoc queries through a standardized data dictionary) is based on the premise that the data to be queried are largely already defined and stored in the operational systems of the institutions.

Examining different levels of integration makes sense in principle. However, it should not lead to a situation where institutions must additionally provide the normal summary sheet reporting – as is the case today – on top of an integrated and more granular reporting system. At the level of the institutions, this would lead to a duplication of both organisational, content-related and technical processes. In this respect, aggregation at client level or at the level of a “group of connected clients” would be appropriate.
Necessary validation prior to implementation (negative example: procedure in the case of definitions for AnaCredit purposes)
In the case of a transition to more granular reports, a long phase in parallel to the current system/process can be expected
EBA data point model (DPM) and internally developed data dictionary on the basis of regulatory and statistical requirements
The characteristics are generally complete, important especially redundancy-free and unambiguously defined
For integration, it is very desirable for the national reporting requirements to also be included in the standardised data dictionary, or for the standardised data dictionary developed at European level to be extended on a country-specific basis to include national requirements.
- Promotes an understanding of and reconciliation between different reporting requirements
- Defines the data (input interface) for the reporting system
Understanding reporting regulationX  
Extracting data from internal systemX  
Processing data (including data reconciliation before reporting) X 
Exchanging data and monitoring regulators’ feedback X 
Exploring regulatory dataX  
Preparing regulatory disclosure compliance.  X
Other processes of institutions X 
Understanding reporting regulation: If semantically distinct

Exploring regulatory data: Exploring (including with regard to any ad hoc) requests is made easier for the supervisor

Other processes: Risk management in the institution or network
In our opinion, a unique and standard data dictionary (or several redundancy-free ones) is a fundamental condition for integration. Alternatively, several redundancy-free dictionaries could be used.
Highly costly
high in terms of the expected IT and resource impacts, see also IReF)
Moderate cost reductions
moderate in proportion to the data required for the national or European reporting system, but also takes into account the distinction between the presumed significantly higher advantage from the point of view of large cross-border banks; the cost advantages are also questionable if proportionality falls by the wayside
Moderate cost reductions
in general are understandable
Irrespective of the granularity (depth/scope) of data to be reported, BCBS 239 is complied with. Our response is therefore neutral.
  • statistical
  • resolution
  • prudential
Statistical comment: In principle, yes (in individual areas); however, granular data should only be reported where necessary, as the more granular the data is, the more cost-intensive the reporting becomes.

Resolution comment: In principle, yes (in individual areas)

Prudential comment: In principle, yes (in individual areas); problematic with regard to process-related requirements (requirements highlighted in the discussion paper for data quality assurance via feedback loops and anchor values); preservation of proportionality

Option 1: feasible

Option 2 feasible and preferable under certain conditions, design (e.g. scope and depth of granularity/associated costs) still too vague, only if current template-based reporting system is eliminated.

Option 3: More likely not (e.g. in terms of the granularity of the FINREP report)
Is feasible, but not preferable.
Option 2 preferable under certain conditions, design (e.g. scope and depth of granularity/associated costs) still too vague, only if current template-based reporting system is eliminated.
Avoidance of multiple reporting processes, i.e. elimination of template-based reporting with summary sheet reports with aggregate values (as is the case today) and additionally an integrated more granular report that ultimately serves only to verify the summary sheet report. This results in an x-fold burden on the institutions and multiple effort.

Process/design of the feedback loops and required (partial) replication of the transformation rules (if implemented centrally), resulting in a risk of permanently high resource costs compared with the status quo, or possibly even higher);

Preservation of proportional design
Granular data can be raw data (e.g. name, first name) or derived data (e.g. client classification (KUSY)), as well as partially offset/computed values (e.g. offset collateral, total exposure). In our view, aggregation at client level or at the level of a “group of connected clients” is also still feasible. Any aggregation beyond this, e.g. at institution or segment level, is no longer expedient in our view
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 transformations X  
IT resourcesX   
Human resourcesX   
Complexity of the regulatory reporting requirementsX   
Data duplication X  
Other: please specifyX   
Answer to question 21 in general refers to Option 2 (however, this does not mean that we are finally saying anything about our preferences because of the lack of any more detailed design and process-related effects, or even increased resource costs),

- Risk of losing proportional design. This must still be ensured.

- Process/design of the feedback lops and mandatory (partial) replication of the transformation rules (if performed centrally), resulting in the risk of permanently high and possibly even increased resource expenditure compared to the status quo,
Highly (1)Medium (2)Low (3)No benefits (4)
Reducing the number of resubmissions  X 
Less additional national reporting requests X  
Further cross-country harmonisation and standardisation   X
Level playing field in the application of the requirements  X 
Simplification of the internal reporting process  X 
Reduce data duplications X  
Complexity of the reporting requirements   X
Other: please specifyX   
Under the aforementioned assumptions (see main challenges, question 19, especially elimination of template-based reports), processes could be greatly simplified both in the institutions and in the technical implementation because most of the coordination effort can be avoided.
- Process/design of the feedback loops and required (partial) replication of the transformation rules (if implemented centrally), resulting in a risk of permanently high resource costs compared with the status quo, or possibly even higher),

Regarding Complexity:
If complexity is meant to refer to the number of data points to be reported: no benefits; benefits will arise from the data dictionary (which is presumed to be a given fact)
Proposed response geared towards Option 2
- Multiple reporting processes if additionally integrated and more granular reporting were to be required as well as the summary sheet reports (as is the case today), i.e. (extensive) elimination of template-based reporting is necessary.
- Process-related costs in connection with feedback loops and anchor values, coupled with additional implementation of transformations by the institutions (also to maintain
information symmetry with the supervisor)
- Elimination of proportionate design
- Possible strategic considerations in connection with increased transparency / data sovereignty
- Increased reporting frequencies in connection with procedural handling (defined time frames for reporting submissions, release process of quality-assured data by the institutions and limited deadlines for queries must be maintained regardless of the technical way of data collection (push/pull))
Authorities and reporting institutions jointly
Harmonised and standardised, ready to be implemented by digital processes (fixed)
In general: Provided that nGAAP is not affected and feedback loops and anchor values are unavoidable, in case more granular data are reported and transformation is conducted centralised by supervisory authorities.

Authorities / costs: Risk of additional financial burdens for institutions due to cost allocations, involvement of the industry in an advisory capacity

Authorities / benefits: Binding nature, standardised, understanding of supervisory considerations, information symmetry

Authorities / Challenges: Speed of development and continuous adjustments

Authorities / design (options/solutions): Adequate implementation periods

Additional remark (as hint cannot be given regarding answer to question 23):
- For definition in question 23: a) authorities
- For execution in question 23: a) or b) depending on who performs the transformation (so to speak authorities and institutions jointly)
Open as regards nGAAP
More mathematical, unambiguous definitions, fewer legal definitions
Generally, feedback loops are problematic, as presumably there will be very high process-related effort. Anchor values – which are critical for the supervisory assessment – must be adequate, in conjunction with the introduction of tolerance thresholds.
Proportionality approaches in a granular integrated reporting system:
feasible approaches would be a streamlined set of anchor values, streamlined feedback loops, introduction of tolerance thresholds, elimination of entire reports or individual reports within a reporting area depending on the size of the institution and/or the business model , reporting frequencies, data topicality requirements
Not applicable
Multiple dictionaries
Use DPM and internally developed data dictionary
Different formats
The formats specified by the national and European supervisory authorities are used (XML, XBRL, paper, possibly email in the case of notifications under the German Banking Act)
Somehow important
Language barrier in the case of fully centralised contact; well established understanding of German savings banks, and their business as with the Regional Offices of the Deutsche Bundesbank should not endangered. Moreover, from the perspective of the German savings banks (no burden from different national formats due to a lack of foreign subsidiaries) a centralised, one-time collection of data based on a single format appears less important than improving data sharing and data coordination between the various supervisory authorities, among other things to avoid ad hoc/parallel inquiries.
- Simplification of information exchange (data sharing/data coordination) between authorities in the sense of “report once”
- In the case of a CDCP, mandatory preservation of communication via national supervisory authority (language barrier in the case of centralised contact, high level of understanding of German savings banks, their business and network structure at national level)
- Incorporation of national reporting requirements into a central data register
- Information security, high availability, access to all data submitted by the institution concerned
Improve governance so as to intensify data sharing/data coordination by adapting the legal conditions for intensifying data sharing between the relevant supervisory authorities; establishing up a central data register is therefore adequate from the perspective of the savings banks (rather than a centralised data collection)

It will be necessary to examine whether it is appropriate to interpose the NCAs between the CDCP and the institutions so that it will also be possible to cover the national reporting system in a single architecture and a single process.
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   X
Data dictionary – Cost contribution  X 
Granularity – Involvement  X 
Granularity – Cost contribution X  
Architectures – Involvement X  
Architectures – Cost contributionX   
Governance – Involvement X  
Governance – Cost contributionX   
Other – Involvement    
Other – Cost contribution    
The technical way to supply data as such (push and/or pull) is not decisive from an institution's point of view, it depends on the respective process-related framework conditions, which are, however, too unspecific in the discussion paper, hence also question 41 without an answer.

For the processual handling are in particular compelling:
- receipt of defined time windows for message submissions,
- receipt of release of quality-assured data by the institutions, and
- definition of limited deadlines for queries/validations.
In general, the mechanism appears to be feasible, the proposed opt-out for national reporting requirements could be problematic; there would have to be clear, narrowly defined rules under which it would be possible; if not, integration would be frustrated
Not fully developed or useful for my needs
Data collection
Improvement in data quality in input data pool
Data processing centre clients do not want to invest in reporting at this time
via a service provider
Data quality, see above
Christina Wehmeier