EBA Validation Rules: What Changes in the Q3 2026 Update

On 14 September 2026, the European Banking Authority updated its validation-rule files and published a small validation package for its reporting frameworks. The EBA taxonomy is primarily intended for data transmission between competent authorities and the EBA; institutions submit supervisory information to their competent authorities, which determine the technical collection arrangements they apply. The EBA’s validation-rules page states that quarterly small packages can include deactivations, reactivations and severity-status changes; the 14 September entry confirms that a small package was published on that date. Alongside the list, the EBA released a small validation rules package. The 14 September package comprises two components: a micro taxonomy package and Data Point Model (DPM) validation rules update scripts. The announcement identifies only deactivated and reactivated rules, not any change to severity status, and the EBA validation-rules-packages page lists the September 14 entry with those same two components.

For a Luxembourg or any EU reporting team closing the third quarter, the timing is the whole point. The package lands shortly before the 30 September reference date. For the EBA reporting-framework artefacts, the 14 September files are the latest published validation-rule versions and supersede all prior versions, including the July 2026 standalone rules update and the June quarterly package. Institution-level filers should confirm which version and technical implementation their competent authority or reporting vendor applies before treating the EBA package as the operative submission rule set. Get the load wrong in either direction and you pay for it: leave a reactivated blocking rule out and a return that would be rejected slips through your own controls; keep a deactivated rule live and you burn a day chasing an error the supervisor has already switched off.

The mechanics changed with DPM 2.0. From release 4.0 onwards, validation rules sit inside both the taxonomy and the DPM, so a deactivation or reactivation now ships to both artefacts in a single coordinated update. That is why the September announcement pairs a micro taxonomy package with DPM update scripts, and it is why a reporting officer needs to understand what these quarterly packages do before treating them as background noise.

Related reading: our guide to EBA validation rules in supervisory reporting.

What the 14 September package puts on your desk

The quarterly announcement is short, and the precise wording is what matters; read it directly. It does two things. First, it publishes a revised list identifying validation rules that have been deactivated (because of inaccuracies or IT-related issues) or reactivated. Second, it reminds competent authorities across the EU that data submitted under the Implementing Technical Standards and Guidelines should not be formally validated against deactivated rules.

The EBA’s validation-rules page provides the current validation-rule files and the small-package artefacts for the 14 September update. The announcement tells you a change happened and why the EBA maintains the cycle; the operative detail lives in the published Excel validation rules file and in the DPM update scripts. If your question is “which rules changed,” work from the current EBA validation-rule file and the accompanying DPM update artefacts. A practitioner reads the press release for the intent and the deadline pressure, then opens the Excel to build the actual work list.

The contents of a small validation rules package depend on the type of validation-rule change being made. When it carries deactivations or reactivations from release 4.0, it consists of a micro taxonomy package plus DPM validation rules update scripts. Where the package also changes the severity of rules, the EBA adds the Excel file with the validation rules to that set. These components are required from release 4.0 onwards for each update exercise so that the same change is applied consistently to the taxonomy and to the DPM. A quarterly package is maintenance on an existing rule set, so it does not introduce new templates, new data points, or a new framework version.

The quarterly rhythm, and the dates that anchor it

The EBA updates validation rules through three separate channels, and confusing them is a common source of missed changes. Rules change with each new technical package release, on the framework release timeline. They change again around two months before the first reference date of a framework release, to catch corrections needed before go-live. And they change through the small validation rules package, published every quarter.

The quarterly packages have a predictable calendar. They appear roughly 20 days before the reference date at the end of each quarter, which puts them around 10 March, 10 June, 10 September, and 10 December. The 14 September 2026 package is the Q3 entry in that series, sitting just ahead of the 30 September reference date. If you run a reporting calendar, these four dates belong on it as standing checkpoints, distinct from your remittance deadlines.

Two boundaries matter for scoping the work:

• Small packages can only impact framework release 3.0 and subsequent releases. Older releases are out of scope for this cycle.
• The validation rules are split into two files: one applying to framework releases from 4.0 onward, and a separate file for releases up to and including 3.5. You load from the file that matches the release you are reporting under.

The date of the latest update is stamped into the file name, and each change is announced through a news item. That naming convention is your version check: if the file on your engine does not match the date the EBA announced, you are validating against a stale rule set.

Deactivated rules: stop validating against them, keep filing the data

A deactivated rule is a check the EBA has switched off, usually because the rule was written incorrectly or broke on a technical issue. The instruction to competent authorities is explicit: data should not be formally validated against a deactivated rule. If your reporting engine keeps that rule live, it will flag failures that the supervisor will ignore, and your team spends time reconciling numbers that were never wrong.

The trap sits one layer down. A deactivated rule does not remove the underlying reporting obligation. Deactivation does not amend the underlying ITS or Guidelines. The underlying data must still be reported wherever the applicable reporting requirements require it; only the specified validation rule is switched off. Treating a switched-off rule as permission to leave a field blank or to stop reconciling a total is how a genuine error survives into a submission that now passes validation cleanly.

This is also where the taxonomy and the DPM have to agree. When the two artefacts disagree about whether a rule is active, filers get inconsistent behaviour depending on which one their tool reads. The EBA has had to correct exactly this: an earlier micro taxonomy package was republished in April 2026 because two rules were out of step, one active in the taxonomy but deactivated in the database and another deactivated then reactivated across versions. Reconciling the file against your own engine, not assuming they match, is the safeguard.

Reactivations and severity flips are the ones that reject a return

Deactivations are the forgiving half of the cycle. Reactivations are the half that can turn a previously accepted submission into a rejected one. A rule that was switched off last quarter and comes back on this quarter starts firing again against your Q3 data, and if it is a blocking rule, a package that cleared in June can bounce in November on the same logic.

Severity is the second moving part. The EBA uses two validation-rule severity statuses: “Error” and “Warning”. An Error failure causes immediate rejection, while a Warning does not cause immediate rejection but must still be investigated; where a reporter considers that a Warning cannot be met, the reason should be explained to the competent authority.

The practitioner risk is the “Warning” that reads as optional. The EBA has cautioned that warning severity now covers a large number of highly normative rules, not the handful of trivial checks it once carried, so a warning failure needs a real answer rather than a shrug. And the responsibility for the veracity of reported data stays with the reporting entity regardless of which rules the EBA flags. A clean validation report records only the absence of failures the current rule set happens to test; accuracy of data outside that scope is a separate matter. Where a quarterly update changes a rule’s severity from Warning to Error, a failure that previously did not cause immediate rejection can become blocking. Reactivation and severity change are separate types of validation-rule update.

DPM 2.0 changed how a rule reaches your engine

The reason a quarterly package now ships as two coordinated components goes back to the DPM 2.0 transition. The EBA set out its plan for implementing DPM 2.0 in June 2024, rolled it across the framework from release 4.0, and concluded the transition with the final 4.2 technical package published on 25 November 2025 and applicable from December 2025. With DPM 2.0, validation rules are embedded directly in both the taxonomy and the DPM.

Embedding the rules in both places improves traceability, because a change is recorded in the same structure that defines the data, but it also means a change has to be applied in both places at once or the two drift apart. The micro taxonomy package carries the taxonomy side of the change, the DPM validation rules update scripts carry the database side, and together they keep a deactivation, reactivation, or severity change consistent across the artefacts your tooling and the EBA’s read. This is the practical content of the phrase “consistent amendments to the rules in both the taxonomy and the DPM” in the announcement.

If you build your instances from the DPM and your vendor validates against the taxonomy, or the other way round, a package applied to one and not the other is the fault line. The EBA and EIOPA revised the taxonomy architecture to implement DPM Refit improvements and simplify its structure. For validation-rule updates from release 4.0 onwards, the EBA publishes coordinated taxonomy and DPM components so that amendments are reflected consistently in both artefacts. Our note on the EBA DPM known issues list covers where the authority itself parks the mismatches it has already found.

COREP, FINREP, ALMM: which returns pick up the change

Validation rules are an integral part of the EBA technical package that covers the reporting requirements, so they apply across the frameworks a bank actually files. That includes the prudential returns most teams live in: own funds and capital adequacy under COREP, supervisory financial reporting under FINREP, and the additional liquidity monitoring metrics captured in the ALMM templates. A quarterly package can touch the rules governing any of them.

Because the September announcement does not publish a module-by-module breakdown, the honest answer to “does this hit my COREP submission, or my FINREP, or my liquidity return” is that you find out from the Excel file, not from the headline. Each rule in that file is scoped to the template and cells it checks, so a filter on the modules you report gives you your affected list in minutes. The impact can differ by framework release and module, so determine the affected scope from the current validation-rule file rather than assuming that a quarterly package affects all modules equally. The takeaway is procedural: do not assume a quarterly package is irrelevant to your returns because the press release is generic, and do not assume it rewrites all of them.

Where the small package sits against 4.2, 4.3 and 4.4

It helps to place the quarterly cycle against the framework releases, because the two are easy to conflate. Framework 4.2, applicable from December 2025, completed the DPM 2.0 rollout and carried substantive changes including instant payments reporting, resolution planning, operational risk own funds in COREP, and MREL decisions. The EBA published the draft framework 4.3 technical package in April 2026 and the final technical package on 9 July 2026; framework 4.3 is expected to apply on a module-specific basis from Q4 2026. The EBA published the draft 4.4 technical package on 24 July 2026, with the final version scheduled for September 2026, covering IFRS 18 templates in FINREP, Pillar 3 ESG disclosures, FRTB disclosures, and further technical amendments, with first reference dates running from 31 December 2026 into 2027.

Those releases change what you report and how the templates are built. The quarterly small package does something narrower: it corrects and maintains the validation layer that sits on top of whatever release you are already filing. A team preparing for the 4.4 changes and a team loading the September validation package are doing two different jobs, on two different clocks. Reading the quarterly package as if it were a framework upgrade, or ignoring it because the “real” change is 4.4, both miss the point. You can track the release side through our coverage of the EBA 4.4 draft technical package.

Loading the EBA validation rules update before your Q3 submission

The workflow for a quarterly package is short, but the order matters. Pull the latest validation rules Excel from the file that matches your release, the “from 4.0” file for current prudential reporting. Apply the DPM validation rules update scripts and the micro taxonomy package so the database and taxonomy carry the same state. Reconcile the result against your reporting engine or confirm the timing with your vendor, because a package the EBA published on 14 September only protects you once it is live in the tool you actually validate with.

Then re-run your Q3 data against the updated set rather than trusting a validation you ran earlier in the quarter, and read any new failures against the DPM known issues list before concluding the error is yours. At the EBA/EUCLID collection layer, from 1 July 2026 EUCLID rejects packages containing CSV files with a negative filing indicator. That is an EBA collection rule; institutions submitting through a national competent authority’s portal should apply the filing rules implemented by that authority. National competent authorities align their own systems to the EBA rules, so if you file through a domestic portal, confirm your NCA has picked up the same package version; our note on CSSF COFREP validation and the EBA small packages shows how that plays out in Luxembourg.

Frequently Asked Questions

If a validation rule is deactivated, can we leave the related field blank?

No. Deactivation switches off the automated check; the reporting obligation it was testing stays in force. The ITS still requires the data and the figure still has to be correct. The only thing that changes is that the EBA and competent authorities will not validate your submission against that specific rule while it is off.

We use a third-party reporting vendor. Is there anything for us to do?

Yes, at least confirm timing. A package the EBA published on 14 September protects your Q3 filing only once your vendor has built it into the version you validate with. Ask which release of their tooling carries this quarter’s package and when it is available, and do not assume your last validation run reflects the current rule set.

What is the difference between a deactivated rule and a deleted rule?

Deactivation is reversible and is the mechanism used in the quarterly small packages: the rule stays in the list but is switched off, and it can be reactivated in a later package. Deletion removes a rule from the set entirely, and that happens through the technical package releases, outside the quarterly maintenance cycle.

Do these quarterly packages ever affect our older framework 3.x returns?

They can. Small validation rules packages can impact framework release 3.0 and every release after it. The rules are split into two files, one for releases from 4.0 onward and one for releases up to and including 3.5, so if you still report under a 3.x release you load from the up-to-3.5 file.

A failing rule is flagged as “Warning” severity. Can we ignore it?

Not safely. Warning severity now covers many highly normative rules, and the EBA expects them to be met in principle with any exception properly justified. A warning failure needs a documented reason, and the responsibility for the accuracy of the data stays with your institution regardless of how the rule is classified.

How do we identify which rules changed without reading every identifier?

Work from the Excel validation rules file, which scopes each rule to the module, template, and cells it checks, and filter to the modules you report. Confirm the file date against the date in the EBA news item so you know you have the current version, and cross-check the DPM known issues list for anything the EBA has already flagged.

Does our national supervisor reissue these rules, or do we read the EBA file directly?

Both apply. The EBA publishes the authoritative rule set, and national competent authorities align their collection systems to it. If you submit through a domestic portal, the practical version you are validated against is the one your NCA has loaded, so verify the NCA has taken up the same package version rather than assuming it is instantaneous.

Related Articles

• EBA Validation Rules in Supervisory Reporting: How validation rules are structured, scoped, and applied across the EBA reporting frameworks.
• COREP Reporting Explained: The own funds and capital adequacy returns that validation rules police, template by template.
• FINREP Reporting Explained: Supervisory financial reporting scope, templates, and reference dates.
• Liquidity Reporting: LCR, NSFR and ALMM: The liquidity monitoring returns and how they sit alongside prudential reporting.
• The EBA DPM Known Issues List: Where the EBA records taxonomy and DPM mismatches it has already identified.
• EBA Reporting Framework 4.4 Draft Technical Package: The IFRS 18, ESG, and FRTB changes arriving on the release timeline.

Key Takeaways

• The 14 September 2026 EBA validation rules update ships as a small validation package with two components, a micro taxonomy package and DPM validation rules update scripts; load the updated rules from the “from 4.0” file before you validate Q3 data.
• Quarterly small packages land around 10 March, 10 June, 10 September, and 10 December, roughly 20 days before the quarter-end reference date, and can affect framework release 3.0 and later.
• Do not validate against a deactivated rule, but keep reporting the underlying data: deactivation suspends the automated check while the ITS obligation remains.
• Reactivated and severity-raised rules can turn a submission that cleared last quarter into a rejection; re-run your Q3 data against the new set.
• From release 4.0, a rule change ships to the taxonomy and the DPM together; if your engine and the EBA disagree, one artefact was not updated.
• A “Warning” failure still needs a justified explanation, and the reporting entity owns the accuracy of the data whatever the rule severity.
• Watch the platform layer: from 1 July 2026, Euclid rejects packages containing CSV files with a negative filing indicator.
• Check the file date in the file name against the EBA news item; a date mismatch means you are validating against a stale rule set.

Sources and References

• EBA, “The EBA publishes updated list of validation rules as part of its regular quarterly reporting frameworks update” (14 September 2026)
• EBA, Validation rules packages
• EBA, Reporting frameworks (overview and release table)
• EBA, Reporting framework 4.0
• EBA, Reporting framework 4.2
• EBA, “The EBA releases the final technical package for its 4.2 reporting framework” (25 November 2025)
• EBA, Reporting framework 4.3
• EBA, “The EBA releases the final technical package for its 4.3 reporting framework” (9 July 2026)
• EBA, “The EBA seeks feedback on the 4.4 draft technical package” (24 July 2026)
• EBA, DPM data dictionary

Before the next quarterly package around 10 December

The September package is a maintenance release, but a maintenance release you have to act on this quarter. Pull the “from 4.0” validation rules file, apply the micro taxonomy package and the DPM update scripts, reconcile them with your engine, and re-validate your Q3 data before it goes to the supervisor. Then mark 10 December in the reporting calendar, because the next small validation rules package will land about 20 days before the year-end reference date, and the load discipline starts again.

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.