EBA Known DPM Issues List: Workarounds and Timelines

ByOfficer

Last updated: April 2026

On 9 April 2026, the EBA started publishing a list of known data point model (DPM) issues, with workarounds and indicative resolution timelines. For reporting teams this is useful, but it also shifts the control burden. Once the regulator has publicly acknowledged a defect and named a workaround, “we followed the taxonomy” is no longer a complete answer on its own. You are expected to know the list, assess the impact on your filings, apply the workaround correctly, and document what you did.

The first batch covers Pillar 3 disclosures and resolution planning reporting. COREP, FINREP and the other modules are scheduled to follow in later releases. That does not mean COREP teams can ignore this. The process you set up now for Pillar 3 is the same process you will run for every other module once the EBA extends the list.

This guide walks through how I would handle an entry on the EBA known DPM issues list in practice: triage, workaround, control trail, vendor coordination, and submission timing.

Related reading: our Pillar 3 disclosure requirements guide for Luxembourg banks

What the EBA DPM known issues list actually is

The EBA announcement on 9 April 2026 confirmed that the Authority will begin publishing, on a regular basis, a list of known issues in the DPM framework. The list is published as a spreadsheet on the EBA website alongside the taxonomy and validation rules. It is not a replacement for the Single Rulebook Q&A or the validation rules releases. It sits next to them, covering a specific gap: defects in the DPM artefacts themselves that institutions and competent authorities have already hit during filing.

For each entry, the file provides a short description, the affected artefacts (template, taxonomy module, validation rule), an assessed severity, current status, any available workaround, and the expected release in which the item is planned to be resolved. In other words it tells you three things a reporting officer needs before month-end: is this really broken, what do I do in the meantime, and when will the fix arrive.

The first phase is deliberately narrow. The EBA opened with Pillar 3 disclosures and resolution planning reporting because those frameworks have generated a particularly high volume of queries from institutions and national competent authorities. Other modules will be added over time. Validation rule errata, taxonomy fixes and Q&A answers continue to flow through their existing channels.

What it is not

A few things the list does not do, because I have already heard people misread it.

It does not grant waivers. If an entry says “workaround: leave rows 0050 to 0070 blank”, that is a technical instruction, not a carve-out from the CRR disclosure obligations. Your legal obligation to disclose is unchanged.

It does not freeze the validation rules. Rules flagged as defective on the known issues list still block submissions until the NCA or the EBA processes a corresponding errata. The list is usually ahead of the validation rules release, not in sync with it.

It does not cover interpretation. If your question is “does this exposure belong in column A or column B”, that is still a Q&A question. The list covers DPM defects, not definitions.

Reading an entry without getting it wrong

Every row on the list has a few fields that look simple and are not. Before I let a junior analyst act on an entry, I walk through the fields with them.

Affected artefact

The artefact column names the template, the taxonomy module, and sometimes the specific cell or data point. This is the most frequently misread field. An entry that names “C 33.00” does not necessarily apply to every version of C 33.00 across every taxonomy release. Check which taxonomy version is in scope. A defect in the 3.4 taxonomy is often fixed in 3.5 and simply disappears from the list.

Severity

The EBA rates severity on its own scale. Treat it as directional, not as your materiality assessment. A defect rated “low” by the EBA can still be a material control failure for your institution if it affects a high-value disclosure or a front-page KPI. I always override severity with my own impact check before deciding how to handle a row.

Status

Common statuses include “open”, “workaround available”, “fix scheduled”, and “fixed in release X”. An item marked “fixed in release X” still requires you to do something if you are filing under the earlier release. The fix does not backfill your prior submissions.

Workaround

Workarounds fall into three shapes. A pure technical workaround (report the value under a different XBRL datapoint or leave a specific cell empty). A narrative workaround (use a free text field or a public disclosure to explain the defect). And a deferral (the EBA accepts that an item cannot be reported until the fix lands, and NCAs will not chase it). Read carefully which kind you have. Teams that confuse a deferral with a technical workaround end up with submissions that pass validation but misstate the position.

Expected release

The timeline on the list is indicative, not contractual. I have seen EBA fixes slip by one release cycle more than once. Plan on the indicative date and build a buffer for the cycle after it. Do not commit internal stakeholders to a fix date that is entirely in someone else’s gift.

Step 1: Triage each entry against your filings

When a new version of the list drops, the first job is triage. I do not let the list drive the roadmap. I run each entry through a short filter and only the ones that survive reach the production schedule.

The filter I use has four questions.

Does this artefact appear in any report I actually file? A bank that does not hold resolution reporting obligations, or does not file a given Pillar 3 template, can retire most of the current list immediately. Check your reporting perimeter, not your aspirations.

Does it affect the taxonomy version my vendor is running this quarter? Vendors upgrade at different cadences. If you are on taxonomy 3.4 and the defect only appears in 3.5, flag it and park it. If you are on 3.5 and the defect is fixed in 3.6, that is your problem now.

Does the affected cell carry a non-zero value in your data? An open defect on a cell you always report as zero is a low priority. An open defect on a cell driving a leverage ratio denominator is not.

Is the workaround within my operational control? Some workarounds require the vendor tool to allow a manual override. Others require a validation rule to be muted at NCA level. You want to know which it is before committing to a timeline.

Rows that survive the filter go on a simple tracker: entry ID, affected report, reporting period, taxonomy version, workaround type, decision owner, and a go or no-go for the next submission. That tracker sits next to the reporting calendar, not inside the ticketing system where it gets lost.

Step 2: Assess materiality with your own criteria

Materiality on a DPM defect has two dimensions, and people regularly collapse them into one.

The first is quantitative. How much of a reported value is affected, and does that value drive a capital ratio, a liquidity metric, a large exposures threshold, or a Pillar 3 headline number. I would treat any defect that moves a CET1 ratio, a leverage ratio, an LCR or an NSFR by a measurable amount as high materiality by default, even if the EBA calls it low severity.

The second is qualitative. Does the defect touch a disclosure that is public, such as Pillar 3 tables published on the bank website, or does it stay inside confidential supervisory reporting. A defect in a public disclosure has reputational exposure that an internal COREP cell does not. A defect in a resolution planning template sits in a narrower audience but goes straight to the resolution authority, which has a long memory.

I document the materiality call in one paragraph, not a spreadsheet. Who decided, what they knew, and why they decided the way they did. That paragraph is what you read to the internal auditor eighteen months from now when they ask why you left a cell blank in Q2 2026.

Step 3: Apply the workaround the way the control framework expects

A workaround that is not documented inside the control framework is a finding waiting to happen. The same controls you run for a normal submission have to cover the workaround as well.

I keep it simple. For every workaround applied on the list I want four artefacts on file.

A reference to the EBA list entry, including the version of the spreadsheet I consulted and the date. The list is updated regularly. “I followed the EBA known issues list” without a version is not a reference. “Entry 2026-Q2-P3-014 as published in the 9 April 2026 version of the list” is.

A plain language description of what we actually did in the tool. Which cell is blanked, which override is applied, which manual journal is posted. Reviewers should be able to reconstruct the behaviour without opening the vendor product.

A sign-off from the reporting owner and, for material items, from the head of finance or the head of risk depending on where the metric lives. On a Pillar 3 defect that changes a published ratio, I escalate to disclosure committee level. That is not overkill. It is how you protect the people signing the disclosures.

A reconciliation back to source. The workaround tells you what to report. The reconciliation tells you what the correct number would have been without the defect. If the fix arrives and you need to refile, you want that figure already sitting in the file.

Teams I have seen get this wrong usually skip the reconciliation. They apply the workaround, the submission validates, everyone moves on, and when the fix lands six months later nobody can remember what the true number should have been. That is how a small technical workaround turns into a material restatement.

Step 4: Coordinate the vendor and internal fixes

Most reporting teams do not build their own XBRL engine. You run a vendor product, and the vendor ships taxonomy updates on their own schedule. The EBA known issues list adds a second cadence to coordinate.

I treat the relationship as three parallel tracks.

The EBA track

Subscribe to the EBA reporting frameworks page notifications. When a new list version drops, pull it into the tracker the same day. Do not rely on a vendor newsletter to tell you the EBA has published something. I have seen week-long gaps between an EBA publication and a vendor heads-up.

The vendor track

Send the vendor a short ticket for every entry that affects your taxonomy version, even if the workaround is purely manual. You want them to confirm that their validation engine will not block your workaround, and you want their release notes to reference the entry ID when the fix lands. Vendors that already track the list will return a structured response. Vendors that do not should be having an awkward conversation with their relationship manager.

The internal track

Internal fixes cover the bits the vendor cannot reach. Source system mappings, manual journals, the disclosure template in the annual report, the audit trail in the reporting database. Raise these as normal change requests with the usual testing and approval. The presence of an EBA entry does not waive your change management process. If anything, it raises the bar, because you are documenting a deliberate departure from a standard calculation.

One practical move that helps: tag every EBA list entry with a short internal code that is used across all three tracks. When the vendor release notes reference the internal code, when the change request references it, and when the control file references it, reconstructing the audit trail in a year takes minutes instead of days.

Step 5: Manage the submission timeline

Pillar 3 disclosures run on the same remittance cycle as the associated prudential returns. Resolution planning templates run on their own annual and ad hoc cadences. Neither of these cycles slows down because the DPM has defects.

I plan the submission timeline around three fixed points.

The EBA remittance date. This is the deadline for the NCA to receive your file, as set by the implementing technical standards. It does not move. Even if the list tells you a fix is coming “in the next release”, you still have to submit on the original date using whatever workaround is available.

The NCA’s internal pre-validation window. Most Luxembourg filings go through CSSF eDesk with pre-validation steps before the formal submission. Build a two or three business day buffer so that if the workaround fails pre-validation you have time to swap to an alternative (for instance, a manual narrative disclosure in place of a failed XBRL cell).

The point at which your controls freeze. I freeze the data and the workaround decisions three business days before the remittance date. Anything discovered after the freeze goes on a post-submission issues list and, if material, becomes a resubmission candidate once the fix lands.

If the list flags a defect late in the cycle, say three working days before remittance, do not panic and do not improvise. Run the triage filter against the entry, and if it is high impact raise it to the NCA directly rather than trying to find a workaround under time pressure. The CSSF, like most NCAs, would rather hear from you before the deadline than receive a broken file on the deadline.

Common mistakes I see with known issues handling

The first one is treating the list as the only source of truth about DPM defects. It is the EBA’s own curated list. It is not exhaustive. Your vendor will have a longer private list of defects that never reached the EBA. Your NCA will have its own view. The EBA list is a floor, not a ceiling.

The second is applying a workaround without rereading it each cycle. Workarounds get revised as the EBA learns more. A workaround that said “leave blank” in Q1 can become “report zero” in Q2 and “populate with the new data point XYZ” in Q3. Teams that paste the old workaround into every quarter end up out of step with the current guidance.

The third is forgetting the public disclosure angle. Pillar 3 tables are published on the bank website. If the workaround involves a reduced disclosure, the public version needs a short explanation that references the EBA guidance. A silent omission with no footnote looks like a control failure to the market. I would rather have an ugly footnote than a quiet hole.

The fourth is assuming the list covers COREP today. It does not. The initial scope is Pillar 3 and resolution planning. COREP teams who are waiting for “their” list to start the process are losing preparation time. The same workflow will apply when COREP is added. Build it on the Pillar 3 entries now and you will not be scrambling later.

The fifth is not capturing the resolution. When a fix is released and the workaround ends, teams rarely update the tracker to close the entry. Six months later somebody applies a workaround that is no longer required and creates a real defect in an otherwise clean submission. Close entries formally, with a date and an owner.

Luxembourg specifics

Two things matter for institutions filing in Luxembourg.

The CSSF receives prudential returns through eDesk in the XBRL packages generated from the EBA DPM. When the EBA ships a taxonomy update or a fix, the CSSF typically accepts it on the same reporting reference date the EBA mandates. That alignment means you do not get a local grace period on top of the EBA timeline. Plan around the EBA date.

For Pillar 3 disclosures, Luxembourg credit institutions publish their tables on the bank website in line with the EBA implementing standards. A workaround that affects a public table has to be reflected both in the regulatory XBRL filing and in the website publication. These two outputs tend to be managed by different teams, and a workaround coordinated only with the XBRL team does not automatically update the PDF disclosures. I have seen a few near misses on this exact split. Close the loop explicitly.

A sample tracker layout

If you want something to start with on Monday, here is the layout of the tracker I would build on day one. It is seven columns wide and fits in a single spreadsheet tab.

Entry ID from the EBA list. Version and date of the list pulled. Affected report and template. Taxonomy version. Workaround type (technical, narrative, deferral). Decision owner and date. Status (open, applied, closed, superseded). Nothing else on the first tab. Detail notes, reconciliations, and evidence links go on a per-entry tab.

Review the tracker at the weekly reporting stand up, not monthly. The list updates between your monthly cycles and you want to know about new entries in days, not weeks.

Frequently Asked Questions

Does the EBA known DPM issues list cover COREP today

No. The first published version covers Pillar 3 disclosures and resolution planning reporting. The EBA has said it will extend the list gradually to other modules supported by the DPM framework and XBRL taxonomy, which includes COREP, FINREP and the rest. Build your handling process now so you are ready when COREP entries appear.

Does the list replace the Single Rulebook Q&A

No. The Q&A still handles interpretation questions: what a definition means, which exposure class applies, how a metric should be computed. The known issues list covers DPM artefact defects: a broken cell, a wrong datatype, a validation rule that fires when it should not. They are complementary, and you will often need both for a given problem.

If a workaround says “leave blank”, does that satisfy my disclosure obligation

It satisfies the technical submission. It does not on its own satisfy the substantive disclosure obligation under the CRR and the Pillar 3 implementing standards. Check whether the workaround should be paired with a narrative explanation in the public Pillar 3 document or in the notes to the submission. Document the decision either way.

What happens if we submit with a workaround and the fix lands later

It depends on the entry. Some fixes are forward looking only, meaning earlier submissions stay as filed. Others require a resubmission on the corrected taxonomy. The list will usually say. If it does not, ask the NCA. In Luxembourg that means a short note to the CSSF through the normal reporting contact channel, not a waiver request.

Should we wait for the vendor to apply the workaround in the tool

Only if the vendor commits to delivering before the remittance date. If they cannot, you need a manual workaround ready in parallel. The remittance date does not move because the vendor’s release train slipped. Plan for both paths and close the one you do not use.

Do we need to disclose that we applied a workaround

For confidential supervisory reporting, no general disclosure is required. For Pillar 3 public tables, a short explanation in the notes is strongly advisable when the workaround changes what a reader sees. Silence on a changed disclosure invites questions you would rather not answer.

Who signs off on a workaround

The reporting owner always. For material items, the head of finance or the head of risk, depending on which side of the house the metric sits. For items that affect the published Pillar 3 document, escalate to disclosure committee or equivalent. Document the sign-off with the workaround, not in a separate email chain.

How often is the list updated

The EBA has committed to updating it on a regular basis alongside taxonomy and validation rule releases. There is no fixed cadence yet. Monitor the EBA reporting frameworks page and pull the new version into your tracker the day it drops.

Related Articles

Key Takeaways

  • The EBA DPM known issues list is the regulator’s own list of DPM defects, workarounds and indicative fix timelines, and it started on 9 April 2026 with Pillar 3 and resolution planning reporting.
  • The list does not grant waivers, freeze validation rules, or replace the Q&A. Treat it as a technical defect register, not as legal cover.
  • Triage every new version against your reporting perimeter, your taxonomy version, your actual data and your operational control before acting.
  • Run your own materiality assessment. A defect rated “low” by the EBA can still be high impact for your ratios or public disclosures.
  • Document every workaround with the list entry reference, the tool behaviour, the sign-off, and the reconciliation back to the correct figure.
  • Coordinate the EBA, vendor and internal change tracks with a shared internal code so the audit trail reconstructs itself.
  • Plan the submission timeline around the EBA remittance date, the NCA pre-validation window, and a hard internal freeze three business days before filing.
  • Build the workflow now on the Pillar 3 entries. COREP will be added to the list later and the same process will apply.

Sources and References

Disclaimer

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