ECB Supervisory Data Quality: What Banks Learn When the ECB Grades Their Submissions

ByOfficer

Last updated: May 2026

A COREP submission that passes every EBA validation rule can still generate a supervisory follow-up request two weeks later. The ECB runs its own layer of data quality checks on top of the EBA framework, and when those checks flag anomalies, the response lands on your desk as a question you did not anticipate. Most reporting teams discover this the hard way: the file was technically clean, but the supervisory assessment found something the validation rules never tested.

ECB data quality feedback is not a pass/fail stamp. It is a structured, multi-layered assessment that compares your institution’s submissions against peer benchmarks, time-series consistency, cross-template logic, and supervisory expectations that go well beyond the published validation taxonomy. Understanding how this feedback works, what it signals, and how it connects to SREP outcomes is the difference between reactive firefighting and a reporting function that stays ahead of supervisory pressure.

Related reading: Common COREP Reporting Errors and How to Avoid Them

How ECB Data Quality Assessment Actually Works

The ECB’s supervisory data quality framework operates on three tiers, and reporting teams often only see the first one. Tier one is the EBA validation rule layer, the automated checks that run when your XBRL or CSV hits the regulator’s collection system. These are the rules published by the EBA alongside each Data Point Model release, covering arithmetic consistency, cross-template reconciliation, and basic plausibility. If your submission fails a blocking validation rule, it bounces back immediately. Most teams treat passing this layer as the finish line. It is not.

Tier two is the ECB’s own plausibility and consistency framework. After your submission passes EBA validations and reaches the ECB’s centralised data infrastructure, Joint Supervisory Teams and the ECB’s data quality function run additional checks. These include time-series analysis comparing your current submission to previous quarters, peer-group benchmarking that flags outliers within your asset-size bucket, and cross-framework reconciliation between COREP, FINREP, and other supervisory data collections. I have seen cases where a capital ratio moved by 15 basis points quarter-on-quarter and triggered a follow-up, not because the number was wrong, but because the ECB wanted the institution to explain the driver before accepting the data into its risk dashboards.

Tier three is the supervisory judgement layer. This is where data quality intersects with the SREP. If an institution repeatedly generates quality queries, produces late resubmissions, or shows patterns that suggest weak internal controls over reporting data, that pattern feeds into the SREP assessment of internal governance and risk management. The ECB’s reformed SREP framework, as described in its 2025 paper on streamlining supervision, explicitly links the quality and timeliness of supervisory data to the broader assessment of an institution’s risk management capability.

What the ECB’s Feedback Actually Contains

When the ECB identifies a data quality issue, the feedback typically arrives through one of three channels. For directly supervised institutions, the Joint Supervisory Team sends the query through IMAS, the ECB’s supervisory information management system. For less significant institutions supervised by national competent authorities like the CSSF, the query routes through the NCA. In Luxembourg, the CSSF itself runs supplementary plausibility checks beyond the EBA validation rules, as set out in Circular CSSF 22/823, and forwards issues that require ECB-level attention.

The common mistake is treating these queries as isolated data requests. They are not. Each query is logged in the ECB’s supervisory tracking system, and patterns of repeated issues contribute to the institution’s overall supervisory profile. A single quarter with three data quality queries is a nuisance. Three consecutive quarters with the same type of query is a governance finding.

Feedback categories I encounter regularly in practice include the following. First, cross-template inconsistencies: a value reported in COREP own funds that does not reconcile with the corresponding FINREP balance sheet line. Second, time-series breaks: a sudden shift in a reported metric without an accompanying explanatory note or restatement. Third, peer outlier flags: your institution reports a ratio or exposure that sits more than two standard deviations from the peer group, triggering a plausibility check. Fourth, late or incomplete resubmissions: the original file passed validation but contained errors that the institution corrected after the deadline, and the resubmission itself introduced new inconsistencies.

The Validation Rule Layer: What It Catches and What It Misses

EBA validation rules are the foundation, but they have structural limitations that reporting teams must understand. The EBA publishes validation rules alongside each DPM release, and these rules fall into several categories: arithmetic checks (row and column sums), cross-template checks (matching values between related templates), and plausibility checks (flagging values that fall outside expected ranges). As of framework 4.2, the EBA taxonomy contains thousands of individual validation rules across COREP, FINREP, and supplementary modules.

What the EBA rules do not catch is where the real supervisory risk lies. They do not test whether your reported values are economically plausible in the context of your business model. They do not compare your submission to your own historical patterns. They do not cross-reference your prudential data against other supervisory data collections such as AnaCredit, securities holdings statistics, or the ECB’s own ad hoc data requests. The ECB does all of this.

A concrete example: the EBA validation rules check that your large exposure template totals reconcile with your COREP credit risk templates. They do not check whether a sudden disappearance of a previously reported large exposure counterparty makes economic sense. If you wound down a major credit line, the data is technically correct. But if the ECB’s time-series analysis flags the change and you cannot produce documentation explaining the rationale within the requested timeline, you have a supervisory dialogue on your hands.

Teams commonly get this wrong: they build their quality assurance processes around passing EBA validation rules and assume that a clean validation report means a clean submission. In my experience filing in Luxembourg, about half of the data quality queries I have dealt with concerned issues that no EBA validation rule would have caught.

How Data Quality Feeds Into SREP Outcomes

The connection between reporting data quality and SREP outcomes is direct but not always visible to reporting teams. The ECB’s SREP methodology assesses institutions across four pillars: business model viability, internal governance and risk management, risks to capital, and risks to liquidity. Data quality sits under the internal governance and risk management pillar, specifically in the assessment of the institution’s data aggregation and reporting capabilities.

The ECB has been increasingly explicit about this link. The 2025 SREP reform paper describes a remediation strategy where findings are categorised by severity, with escalation pathways that range from recommendations to binding supervisory measures. Lower-severity findings are handled through a streamlined, tiered follow-up process introduced in July 2025, which allows supervisors to concentrate detailed verification on the most severe findings. Higher-severity findings, including persistent data quality deficiencies, enter the formal remediation tracking process with intermediate deadlines and escalation triggers.

What reporting teams commonly miss is the cumulative effect. A single data quality issue in one quarter is a finding. The same class of issue recurring across quarters becomes evidence of a control weakness. And a control weakness in data aggregation and reporting can affect the SREP score for internal governance, which in turn affects the overall SREP outcome and potentially Pillar 2 requirements.

The ECB reduced new qualitative SREP measures from about 700 in 2021 to fewer than 400 in 2025, reflecting what it describes as more targeted use of supervisory tools and more timely action outside the annual SREP cycle. For reporting teams, this means that data quality issues are increasingly addressed through ongoing supervisory dialogue rather than waiting for the annual SREP letter. The pressure is more continuous and less predictable.

The Luxembourg Angle: CSSF Plausibility Checks

In Luxembourg, the data quality framework has a national layer on top of the ECB and EBA frameworks. The CSSF requires credit institutions to verify arithmetic and qualitative accuracy, completeness, compliance with EBA validation rules, and compliance with the CSSF’s own plausibility rules before transmitting data. This requirement is set out in CSSF Circular 22/823, which governs the transmission of prudential information.

The CSSF’s reminder procedure is mechanical and unforgiving. Any table that fails to reach the CSSF, or that includes errors on the closing date for transmission, triggers a first reminder letter the following day. A second failure on the next day triggers a second reminder. The procedure is designed to create immediate pressure for correction, and persistent failures are escalated to the supervisory team responsible for the institution.

What teams working in Luxembourg sometimes underestimate is the CSSF’s supplementary plausibility checks. These go beyond the EBA validation rules and apply additional logic specific to the Luxembourg reporting population. The CSSF publishes these plausibility rules separately, and institutions are expected to run them internally before submission. In practice, I find that smaller institutions sometimes miss the CSSF plausibility layer entirely, treating EBA validation clearance as sufficient. When the CSSF rejects a file on plausibility grounds, the resubmission cycle eats into already tight reporting deadlines.

For institutions under direct ECB supervision, the CSSF acts as a conduit for data quality feedback from the Joint Supervisory Team. For less significant institutions, the CSSF is the primary supervisor and runs its own quality assessment. In both cases, the data quality queries arrive through established CSSF reporting channels, and the expectation is a response within the timeline specified in the query letter.

What Teams Commonly Get Wrong About Data Quality Remediation

The first and most damaging mistake is treating data quality queries as one-off questions. Each query is an opportunity to demonstrate that your institution has strong internal controls. Each query is also a data point in the ECB’s assessment of your governance. Responding with a corrected number but no explanation of the root cause is the fastest way to ensure the same query returns next quarter.

The second mistake is siloing data quality within the reporting function. When a cross-template inconsistency arises between COREP and FINREP, the root cause often sits in how the general ledger feeds into the regulatory reporting engine, not in the reporting team’s template mapping. Fixing the reported number without addressing the upstream data flow means the inconsistency will recur.

The third mistake is underinvesting in pre-submission analytics. The ECB runs time-series analysis and peer benchmarking on your data. There is nothing stopping your team from running the same analysis before submission. Institutions that build their own internal dashboards comparing current-quarter submissions to prior quarters, and flagging outliers against known business events, catch most supervisory queries before they are asked.

A fourth mistake, specific to institutions undergoing business model changes or mergers, is failing to communicate proactively with the JST about expected data breaks. If your institution acquired a portfolio that will shift your credit risk profile, telling the JST in advance prevents a plausibility query and demonstrates control maturity. Waiting for the query to arrive and then explaining after the fact signals reactive governance.

Building a Data Quality Framework That Anticipates Supervisory Expectations

An effective data quality framework for supervisory reporting has five layers, and most institutions only build the first two.

Layer one: EBA validation rule compliance. This is table stakes. Your reporting solution should run the full EBA validation rule set against every submission before it leaves your institution. Blocking rules must produce zero errors. Warning rules should be reviewed and documented.

Layer two: CSSF (or NCA) plausibility checks. In Luxembourg, this means running the CSSF’s supplementary plausibility rules alongside the EBA rules. Other jurisdictions have equivalent national layers. This is where many institutions stop.

Layer three: internal time-series analysis. Build automated comparisons between the current submission and the prior four to eight quarters. Flag any metric that moves by more than a defined threshold. For each flagged item, require a documented explanation linked to a business event. This is the layer that prevents the most common ECB follow-up queries.

Layer four: cross-framework reconciliation. If your institution reports COREP, FINREP, large exposures, liquidity metrics, and AnaCredit, build reconciliation checks between these frameworks. The ECB does this. You should do it first.

Layer five: peer benchmarking simulation. This is the hardest to build internally because you do not have access to peer data. However, you can approximate it using published aggregate statistics from the EBA’s Risk Dashboard, the ECB’s Supervisory Banking Statistics, and the EBA’s transparency exercises. If your reported ratios diverge significantly from published peer averages, prepare the explanation before submission.

The EBA Reporting Simplification and What It Means for Data Quality

The EBA’s ongoing reporting simplification programme is directly relevant to data quality management. The simplification effort aims to reduce the volume of reported data by removing unused templates, lowering reporting frequencies for certain modules, and applying proportionality more aggressively. For data quality teams, simplification cuts both ways.

On the positive side, fewer templates mean fewer cross-template reconciliation points to manage. Removing rarely used data points reduces the surface area for errors. Lower frequencies for certain submissions give teams more time for quality assurance on the remaining higher-frequency modules.

On the negative side, simplification often comes paired with new or restructured templates under framework releases like the forthcoming EBA framework 4.4, which is slated to carry the amendments to existing modules (the CRR3/CRD6 step-two changes, FINREP changes for IFRS 18, and liquidity restructuring). Each new DPM release introduces new validation rules, new cross-template checks, and often breaks existing automated reconciliation logic. The transition period after a framework release is typically when data quality issues spike, because reporting systems have been reconfigured but internal quality checks have not been fully updated.

Teams that run their data quality checks only against the current production taxonomy, without also testing against the upcoming release taxonomy, will always be behind the curve during framework transitions.

The BCBS 239 Connection: Risk Data Aggregation Standards

No discussion of supervisory data quality is complete without addressing BCBS 239, the Basel Committee’s Principles for Effective Risk Data Aggregation and Risk Reporting. While BCBS 239 is formally addressed to global systemically important banks, the ECB has consistently applied its expectations across the directly supervised population, and increasingly expects less significant institutions to demonstrate proportionate compliance.

BCBS 239 sets out fourteen principles covering governance, data architecture, accuracy and integrity, completeness, timeliness, adaptability, and reporting practices. The ECB’s data quality assessment implicitly tests many of these principles. When the ECB queries a time-series break in your COREP submission, it is testing Principle 3 (accuracy and integrity). When it flags a late resubmission, it is testing Principle 5 (timeliness). When it finds that your institution cannot explain a data anomaly quickly, it is testing Principle 6 (adaptability).

The practical implication for reporting teams is that BCBS 239 compliance is not a separate project from data quality management. The two are the same work, viewed from different angles. Institutions that have invested in BCBS 239 compliance, particularly in data lineage and data governance infrastructure, consistently perform better in ECB data quality assessments. Those that treated BCBS 239 as a documentation exercise without changing underlying data architecture continue to generate supervisory queries.

How the ECB’s Reporting Streamlining Affects Quality Expectations

The ECB has been working on reducing the burden of supervisory reporting, partly through its own initiatives and partly through its contribution to the EBA simplification process. The ECB has identified least-used templates and is reviewing existing reporting requirements with the aim of addressing overlaps and lowering frequencies where possible. The ECB also contributed its data-user perspective to the Joint Bank Reporting Committee, which coordinates reporting standards across the ECB, EBA, European Commission, and SRB.

For data quality teams, the streamlining effort signals a shift in supervisory expectations. The ECB is moving toward a model where it collects less data but expects higher quality from what it does collect. The emphasis on reducing resubmissions is telling: the ECB has explicitly identified resubmissions as a cost driver for both institutions and supervisors. An institution that submits clean data the first time, every time, is demonstrably less expensive to supervise. That message filters into SREP assessments.

The ECB is also exploring how technology, including generative AI, can improve supervisory efficiency. The ECB’s IT strategy for 2024-2028 includes investment in supervisory technology applications to improve data access and risk analysis. For reporting teams, this means the ECB’s ability to detect anomalies, run peer comparisons, and identify patterns in submission data will only improve. Manual spot checks will increasingly be supplemented by automated analytics. The bar for data quality will rise accordingly.

Practical Steps Before Your Next Submission

Before your next COREP or FINREP submission, consider these operational checks that go beyond standard validation.

Run a quarter-on-quarter comparison for every material template. Flag any cell that moved by more than 5% or by more than a defined absolute threshold. Document the driver for each flagged item. If you cannot explain a movement, investigate before submitting.

Reconcile your Pillar 3 disclosure data against your COREP submission. The ECB cross-references these, and discrepancies generate follow-up queries. Under the current Pillar 3 ITS (Commission Implementing Regulation (EU) 2024/3172), the disclosure templates map closely to COREP templates. If the numbers diverge, one of them is wrong.

Check your FINREP balance sheet against your published financial statements. This is a basic reconciliation point, but I consistently see institutions where the FINREP equity figure does not tie to the audited balance sheet because of timing differences, scope differences, or mapping errors. The ECB checks this. You should check it first.

For Luxembourg institutions, run both the EBA validation rules and the CSSF plausibility rules. If your reporting software does not natively support CSSF plausibility rules, build them as a separate check layer. The CSSF publishes these rules, and there is no excuse for submitting data that fails plausibility checks the CSSF has already told you to apply.

Finally, review the EBA DPM known issues list before each submission. Known issues in validation rules can create false failures or, worse, allow genuine errors to pass undetected. Knowing which rules are under review helps you prioritise your quality assurance effort.

Frequently Asked Questions

Does the ECB publish a formal data quality score or grade for each institution?

The ECB does not publish a single numerical data quality score to institutions. Instead, it communicates through targeted queries, formal supervisory letters, and SREP findings. The internal assessment feeds into the SREP’s internal governance component, but the specific data quality assessment is not disclosed as a standalone metric. What you receive as an institution is the cumulative effect: the frequency and severity of queries, the tone of supervisory dialogue, and ultimately any formal findings in the SREP decision letter.

What is the difference between an EBA validation rule failure and an ECB data quality query?

An EBA validation rule failure is an automated check that blocks or warns at the point of submission. It tests arithmetic consistency, cross-template reconciliation, and basic plausibility within the published taxonomy. An ECB data quality query comes after your submission has passed all validation rules and been accepted into the supervisory data infrastructure. It tests economic plausibility, time-series consistency, peer comparability, and cross-framework reconciliation that no automated rule covers.

How quickly must an institution respond to an ECB data quality query?

Response timelines vary depending on the channel and severity. Routine queries routed through the JST or NCA typically carry a response deadline of two to four weeks. Queries raised during SREP assessment or in the context of on-site inspections may require faster turnaround. The CSSF’s reminder procedure for submissions with errors operates on a next-day basis for the first reminder. In all cases, responding within the stated deadline is a minimum expectation, not a target.

Can persistent data quality issues affect Pillar 2 capital requirements?

Not directly through an automatic add-on, but indirectly through the SREP. If the ECB determines that data quality weaknesses reflect inadequate internal governance or risk management, this can worsen the institution’s SREP score for the governance component, which contributes to the overall SREP assessment and can influence the Pillar 2 Requirement or Pillar 2 Guidance.

What role does the CSSF play in data quality for ECB directly supervised institutions in Luxembourg?

The CSSF acts as the data collection point for Luxembourg institutions, including those directly supervised by the ECB. It runs its own plausibility checks under Circular CSSF 22/823 and forwards data to the ECB. For directly supervised institutions, the JST may route data quality queries through the CSSF or communicate directly. For less significant institutions, the CSSF is the primary quality gatekeeper and supervisory interlocutor.

Should institutions build their own peer benchmarking for data quality?

Yes, to the extent possible. While institutions do not have access to individual peer data, they can use the EBA Risk Dashboard, ECB Supervisory Banking Statistics, and EBA transparency exercise data to construct approximate peer benchmarks. Flagging significant deviations from published peer averages before submission helps pre-empt ECB plausibility queries and demonstrates proactive data governance.

How do upcoming EBA framework releases affect data quality management?

Each framework release introduces new or amended validation rules, new templates, and potentially restructured cross-template checks. Framework 4.3, published in draft on 16 April 2026 with a first reference date of 31 March 2027, is scoped to new modules for third-country branch reporting under CRD VI and AMLA-related reporting; it does not amend existing COREP or FINREP templates. The amendments to existing modules, including the CRR3/CRD6 step-two changes, FINREP changes for IFRS 18, and liquidity restructuring, are slated for framework 4.4. Reporting teams should update their internal quality check libraries to match each new taxonomy before the first reporting date under that framework. Running quality checks against the old taxonomy after a framework transition is a common source of missed errors.

What happens when the ECB finds a systemic data quality issue across multiple institutions?

The ECB may issue horizontal guidance, contribute observations to the EBA’s validation rule review process, or raise the issue through the Joint Bank Reporting Committee. The ECB has explicitly stated that it feeds its data-quality and data-user experience back into the EBA’s validation rule framework. Systemic issues can lead to new or amended validation rules in subsequent DPM releases.

Related Articles

Key Takeaways

  • Passing EBA validation rules is necessary but not sufficient. The ECB runs additional plausibility, time-series, and peer benchmarking checks that go well beyond the published taxonomy.
  • Data quality queries are tracked cumulatively. Repeated issues of the same type become governance findings that feed into the SREP assessment of internal controls.
  • The ECB’s SREP reform links data quality directly to the internal governance and risk management pillar, meaning persistent quality issues can influence Pillar 2 outcomes.
  • In Luxembourg, the CSSF adds a national plausibility layer under Circular CSSF 22/823 that institutions must run before submission, on top of EBA validation rules.
  • Cross-framework reconciliation between COREP, FINREP, large exposures, liquidity, and Pillar 3 disclosures is an area where the ECB actively checks and institutions frequently have gaps.
  • Proactive communication with the JST about expected data breaks from business model changes prevents plausibility queries and signals governance maturity.
  • Framework transitions, such as the forthcoming EBA framework 4.4, are high-risk periods for data quality because internal check libraries may not yet match the new taxonomy.
  • Building internal time-series analysis and approximate peer benchmarking before submission is the single most effective way to reduce supervisory data quality queries.

Sources and References

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts