EBA Updates Supervisory Reporting Validation Rules: What XBRL and DPM Reporting Teams Must Check

ByOfficer

Last updated: June 2026

An EBA validation rules update your engine misses can do real damage. A deactivated rule that keeps running locally can block a submission the supervisor would have accepted, send your team chasing a data point that was never wrong, and burn hours close to a remittance date that does not move. The mirror failure is quieter: a rule the EBA has reactivated, which your local set never picked up, lets a broken file through to rejection at the supervisor’s end.

On 26 June 2026 the EBA published an updated list of supervisory reporting validation rules. It is a routine technical product, not a change to any template or legal text, which is why teams skim past it. It keeps your XBRL and Data Point Model (DPM) checks aligned with the set the EBA actually applies, and drifting out of sync is a cheap way to fail a clean submission.

Related reading: EBA DPM Known Issues List: What Reporting Teams Should Track

What the EBA validation rules update changed

The updated list groups the changes into three buckets. Some rules were deactivated because of inaccuracies or IT-related issues in the rule itself. Some were reactivated after correction. And some kept their logic but had their severity status changed. The press release reminds competent authorities across the EU that data submitted in accordance with the ITS and Guidelines should not be formally validated against rules that have been deactivated.

The operational point sits in that last line: supervisors are told to stop enforcing the switched-off rules, so a validation layer that has not had the same change applied now runs a stricter test than the regulator does, and the reconciliation gap is entirely on your side of the wire.

The legal basis for CRR supervisory reporting is untouched, but the current ITS is Commission Implementing Regulation (EU) 2024/3117. That regulation replaced Commission Implementing Regulation (EU) 2021/451, which itself had repealed Implementing Regulation (EU) No 680/2014. Validation rules sit outside the Official Journal text; the EBA maintains them as a technical layer on top of the reporting framework, which is why it can revise them on a rolling basis with no change to the legal act, templates, or instructions.

How validation rules sit inside the DPM and the XBRL taxonomy

To act on an update you have to know where the rules live. The EBA translates the data items in the ITS and Guidelines into a DPM, a structured representation that identifies every business concept, its relations, and the validation rules attached to it. The XBRL taxonomy carries those same concepts and rules in the technical format used to transmit data between competent authorities and the EBA. The published Excel validation rules file is the human-readable index to both. The same DPM and taxonomy underpin how COREP reporting works and the FINREP returns alongside it.

Under the taxonomy architecture used across the 4.x releases, deactivation is mechanical. The EBA ships {module}-ignore-val.xml files inside the taxonomy set folders to switch assertions off automatically, so a deactivated rule stops firing for any tool that consumes the official taxonomy. One published rule can also expand into many assertions: a rule such as v2843_m that applies across multiple rows is implemented as v2843_m_001, v2843_m_002 and so on. If you run your own engine rather than the EBA taxonomy directly, those are the identifiers you reconcile against.

Why the deactivated rules are the ones to watch first

Teams generally manage reactivations well, because a reactivated rule that fires produces a visible error they have to clear. Deactivations are the trap: a deactivated rule your engine still enforces produces an error the EBA never raised, and that error looks identical to a real one.

Framework 4.0 gives this concrete shape: the EBA stated that two rules, v6272_m and v23336_m, would not be considered for the error reports it provides, because they should be treated as inactive. Run those locally and you get failures; send the same file to the EBA and you get silence. The file was always valid; the only difference was which rule set each side applied. Across a quarter of deactivations that becomes a backlog of phantom errors that looks like a data problem and is actually configuration drift. Our guide to common COREP reporting errors covers how these false positives surface and how to tell them apart from genuine rejections.

The quarterly cadence, and the cost of waiting for a framework release

The EBA changes validation rules through framework-release updates, possible updated validation-rules packages around two months before a framework release’s first reference date, and small validation-rules packages published quarterly. The 26 June 2026 list is a quarterly validation-rules update: it adjusts the rule set without changing reporting templates, instructions, or the underlying data-point structure.

The mistake is treating rule maintenance as a framework-release task. A team that re-syncs only at each release runs a stale set for up to three months, long enough to span a full remittance cycle on a deactivated rule. The published file is cumulative, carrying the current state for every framework version in scope, including the framework 4.3 release expected in the second quarter of 2026.

Reading the validation rules file without pulling the wrong release

For release 4.0 onward, the EBA publishes a validation-rules Excel file that carries the latest rule state across the relevant 4.x framework releases. The EBA also maintains a separate legacy validation-rules file for releases up to and including 3.5. Pull the wrong release or file and you can re-enable a rule the EBA retired for the version you report under, or miss one that applies only to a newer release.

The discipline is to filter by the framework version that matches your reference date, then diff that subset against the set your engine runs, treating severity as a tracked field rather than an afterthought. A rule whose severity moved from blocking to non-blocking still appears in your results, but a failure against it should no longer stop a submission; if your engine still treats it as blocking, you reject files the EBA would accept. A rule re-graded to blocking means a warning you used to wave through now has to be cleared first. The framework 4.3 DPM changes for COREP and FINREP show how these version-specific differences accumulate, and why a release-aware filter matters.

One adjacent Euclid change to schedule alongside the re-sync

One separate EBA platform change belongs on the same work ticket. For data sent through Euclid, the EBA’s data collection platform, the filing rules govern package structure, not cell content. From 1 July 2026, under EBA filing rules v5.8, Euclid rejects any package containing a CSV file with a negative filing indicator, where before it accepted a header-only CSV when the filing indicator was false. This is separate from the validation rules update but fails a submission just as effectively, and it bites hardest on teams that recently moved to xBRL-CSV, mandatory for reports with a reference date on or after 31 March 2026.

Frequently Asked Questions

Does this validation rules update change any reporting template or deadline?

No. The 26 June 2026 update is a validation rules list, not a framework release. It does not amend templates, instructions, the DPM structure, or any remittance date; CRR supervisory reporting obligations under Commission Implementing Regulation (EU) 2024/3117 are unchanged. What changes is which checks the EBA applies to the data you already report.

What does it mean operationally when a rule is deactivated?

A deactivated rule is one the EBA has switched off, typically because it held an inaccuracy or an IT-related issue. The EBA does not run it in the error reports it produces, and competent authorities are told not to formally validate submissions against it. An engine that still enforces it generates failures the supervisor never raised.

How is a rule technically deactivated in the taxonomy?

Under the 4.x taxonomy architecture, the EBA includes {module}-ignore-val.xml files in the taxonomy set folders that switch the relevant assertions off automatically, so any tool consuming the official EBA taxonomy stops running the rule. Teams on an independent engine apply the equivalent change themselves from the published file.

What is the difference between a small validation rules package and an updated package?

Validation rules are updated with technical-package releases, through possible updated validation-rules packages around two months before a framework release’s first reference date, and through small validation-rules packages published quarterly. A small package adjusts the rule set without a framework change. The 26 June 2026 list is a quarterly validation-rules update.

What does a change in severity status do to my submission?

Validation rules carry a severity that determines whether a failure blocks a submission or only flags a warning. When the EBA changes a rule’s severity status, the rule’s logic stays the same while its consequence changes. A rule moved to non-blocking should no longer stop a file; a rule moved to blocking now has to be cleared before submission. The risk is an engine that keeps the old severity and either over-blocks or under-blocks.

Related Articles

Key Takeaways

  • The EBA published an updated supervisory reporting validation rules list on 26 June 2026, covering deactivated rules, reactivated rules, and rules with a changed severity status.
  • The update is a routine technical product. It does not change any template, deadline, or the legal basis under Commission Implementing Regulation (EU) 2024/3117 for CRR supervisory reporting.
  • Competent authorities are told not to formally validate data against deactivated rules. An engine still enforcing them produces phantom errors the supervisor never raised.
  • Deactivations are the higher-risk bucket, because a false positive looks exactly like a real error; reactivations at least announce themselves by failing.
  • Small validation rules packages arrive every quarter, independently of framework releases. Re-syncing only at framework changes leaves you on a stale rule set for a full quarter.
  • From 1 July 2026, Euclid rejects packages containing CSV files with a negative filing indicator under EBA filing rules v5.8, a separate change worth scheduling alongside the re-sync.

Sources and References

Where this lands in your reporting calendar

A validation rules update earns about an hour of attention and saves a good deal more. Pull the current EBA file, filter to your framework version, and diff it against the set your engine runs, watching deactivations and severity moves. Add the 1 July 2026 Euclid filing-indicator change to the same ticket if you submit through that channel. Do it within the quarter rather than at the next framework release, and the set you validate against stays the one the EBA applies. That is the difference between a file that clears on the first pass and one that fails on a check nobody was still enforcing.

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