Articles

ESMA Revision 6: Is Your Annex IV XML Actually Compliant?

Compliance and data teams reviewing Annex IV XML validation

There is a version of Annex IV compliance that is entirely invisible to the compliance team responsible for it.

The file goes in before the deadline. The NCA portal confirms receipt. No immediate rejection is issued. The compliance team marks it done and moves on.

Weeks later, a DQEF warning is generated that nobody inside the firm sees until the NCA follows up. By that point, the submission window has closed, the data cannot be corrected without a formal resubmission, and the regulator has already formed a view about the quality of the firm’s reporting processes based on the deficiency in the file.

This sequence is not hypothetical. It is a recurring operational reality for a meaningful number of AIFMs submitting under the current regime, and it has a specific structural cause: the governance model for Annex IV production is designed around the submission deadline, not around the validation standard the submission will actually be assessed against.

ESMA’s Revision 6 technical guidance, applicable since November 2023, tightened that standard materially.

The number of firms whose compliance model kept pace with it is smaller than it should be.

What Revision 6 changed and why it matters now

ESMA’s periodic revisions to the AIFMD Reporting IT Technical Guidance are not cosmetic updates.

Each revision reflects ESMA’s assessment of where the data quality failings are most persistent and where the technical infrastructure needs to be tightened to address them.

Revision 6, which introduced XSD Version 1.2 as the mandatory schema requirement for submissions from November 2023 onwards, made a series of changes that collectively raised the precision required of every submission.

The most operationally significant changes centre on identifier fields.

ESMA’s data quality monitoring had consistently identified high rates of missing or invalid LEIs and ISINs in AIF002 submissions. This is the AIF level report that carries the bulk of the portfolio, exposure and instrument data.

Revision 6 strengthened the mandatory field requirements around these identifiers and updated the cross referencing logic in the DQEF to flag submissions where reported instruments lack valid ISINs, where counterparty LEIs are absent or do not resolve in GLEIF, and where derivative trading funds lack the entity level LEI required for EMIR reporting alignment.

The schema version change carries its own complication.

Submissions using pre Revision 6 schema versions, such as XSD 1.1 or earlier, are handled inconsistently across NCAs. Some portals reject them outright. Others accept them structurally but generate DQEF flags that are passed to the NCA without the filer being immediately notified.

The practical consequence is that a firm whose reporting provider updated to XSD 1.2 promptly has been submitting compliant files for over a year.

A firm whose provider did not, or whose internal systems were not updated, may have been generating avoidable validation failures across every subsequent filing cycle, with no visible signal that anything is wrong.

For firms that outsource Annex IV production, the schema version question is precisely the kind of technical detail that falls into the oversight gap between the AIFM and the service provider.

The AIFM knows whether the filing went in on time. It frequently does not know which schema version the file was built against, because no one in the compliance function has been looking at the XML.

A submission built on the wrong schema version passes the deadline test. It fails the regulatory standard. In most outsourced reporting arrangements, nobody on the AIFM side knows the difference until the NCA makes contact.

The architecture of ESMA’s validation system

Understanding why Annex IV quality failures are so frequently invisible requires understanding how ESMA’s validation infrastructure is actually structured.

It operates in layers that many compliance teams have not mapped.

The first layer is the NCA’s own portal validation. This is the check that happens at the point of submission.

It is a structural test. Is the XML well formed? Does it conform to the required schema version? Are the mandatory fields present in the expected format?

A file that passes portal validation receives a confirmation receipt. This is the signal that many compliance teams treat as confirmation of compliance.

It is not.

It is confirmation that the file was correctly constructed. It says nothing about whether the data inside it is accurate.

The second layer is ESMA’s central DQEF, which operates downstream of the NCA portals.

NCAs transmit received submissions to ESMA’s reporting system, where the DQEF runs its suite of automated tests. These tests cross reference reported values against external data sources, including GLEIF for LEI validity and expiry status, EMIR trade repositories for derivative instrument coverage, and MiFID FIRDS for financial instrument reference data.

They also apply internal plausibility logic.

Does the reported leverage methodology produce figures consistent with the fund’s AuM and gross exposure data? Does the investor level liquidity profile align with the asset classes reported? Is a fund claiming no leverage exposure while reporting derivative positions?

When the DQEF generates warnings, they are passed back to the NCA for assessment and potential follow up with the AIFM. The AIFM is not notified directly by ESMA. The NCA decides whether and how to raise the findings.

The result is that DQEF warnings can sit in an NCA’s supervisory queue for weeks before the AIFM is aware of them. When contact is made, the submission is historical rather than current, making remediation more complex and the supervisory signal more pointed.

The practical implication is that the validation feedback loop for Annex IV has a significant time lag, and that time lag creates false confidence.

A firm that has not received NCA follow up on recent submissions is not necessarily filing clean data. It may be filing data that generates DQEF warnings that have not yet been escalated, or that are being monitored for patterns before the NCA decides whether to engage.

The absence of negative feedback is not positive confirmation of quality.

The oversight model for outsourced production is not fit for purpose

The governance problem that Revision 6 exposes most sharply is not a technology problem. It is an oversight problem.

For firms where Annex IV production is managed by a third party service provider, which is the majority of AIFMs, the compliance team’s visibility into the quality of what is being submitted on their behalf is typically limited to a summary report.

The XML itself is rarely reviewed. The validation logic applied by the provider is rarely independently tested. The schema version and DQEF alignment of the provider’s output is rarely verified.

This is not an unreasonable position for a compliance team to have arrived at. Annex IV production was outsourced precisely because the technical complexity exceeds what most in house teams can maintain.

But the outsourcing of production is not the same as the outsourcing of accountability.

The AIFM remains the reporting entity in the eyes of the NCA. When a DQEF warning is generated and the NCA follows up, it contacts the AIFM, not the service provider.

The SMF16 carrying compliance oversight responsibility cannot point to the service agreement as a defence against a finding that the firm’s submissions have consistently failed ESMA’s quality standards.

What adequate oversight of outsourced Annex IV production requires is more specific than many firms currently deliver.

It requires understanding which schema version the provider is using and confirming it is aligned with the current ESMA guidance.

It requires independent testing of the provider’s validation logic against ESMA’s DQEF test specifications, rather than simply taking the provider’s word for it. A sample of submissions should be run through a parallel validation process that checks the same cross references the DQEF applies.

It also requires reviewing the provider’s own quality metrics.

What is the resubmission rate across their client base? What proportion of submissions generate NCA follow up? What DQEF warning categories are most frequently occurring?

These are questions that a well governed oversight relationship asks routinely.

Most do not.

It also requires someone on the AIFM side to look at the XML.

Not the entire file on every submission, but a periodic, structured review of the actual output against the ESMA guidance, sufficient to confirm that the file being submitted on the firm’s behalf reflects current standards and not a provider workflow that has not been updated since 2022.

Why this becomes more consequential under AIFMD II

Revision 6 compliance is worth addressing urgently because of the trajectory of the regulatory standard it sits within.

It should not be treated as a technical housekeeping matter.

ESMA is developing the DQEF’s test coverage in parallel with AIFMD II’s expanded data requirements. The new Annex IV framework will introduce delegation data, total exposure reporting, FTE disclosures and liquidity management tool information.

Each of these new data categories will generate new DQEF test logic.

The test suite that currently runs forty plus checks against a relatively bounded data set will run against a significantly larger and more complex data surface under the AIFMD II template.

Firms that arrive at the first AIFMD II filing cycle with validation processes that are not aligned to current ESMA guidance will face a compounding problem.

That includes firms still operating on outdated schema assumptions, firms that have not resolved their identifier deficiencies and firms that are not independently testing their provider’s output.

The data surface is larger. The test coverage is broader. The supervisory tolerance for persistent quality failures is lower.

ESMA has been signalling the direction of travel through its annual statistical reports for a decade. Under AIFMD II, it will have the data infrastructure to act on what it finds with considerably more specificity.

Key takeaways

ESMA Revision 6 has been applicable since November 2023. Firms not aligned with XSD Version 1.2 may have been generating avoidable validation failures across every subsequent filing cycle.

NCA portal validation and ESMA’s DQEF are distinct systems testing different things. Portal confirmation is a structural test. DQEF is a substance and consistency test. Satisfying the first does not mean satisfying the second.

DQEF warnings are passed to NCAs without direct notification to the filer. The absence of regulatory contact is not confirmation of clean submissions.

For firms with outsourced Annex IV production, the compliance team’s oversight model needs to include schema version verification, independent validation testing and periodic XML review, not just sign off on a summary report.

ESMA is expanding DQEF test coverage in parallel with AIFMD II’s data scope. Firms with unresolved Revision 6 deficiencies are not starting from a neutral position. They are carrying forward a quality gap into a more demanding validation environment.

The question for SMF16 holders and COOs

The question that cuts through the technical detail is straightforward.

For any SMF16 or COO at a firm where Annex IV is produced by an external provider: when did someone on your side last look at the raw XML output of a submission?

Not the summary. Not the dashboard. The actual file.

When did someone confirm that the file reflects current ESMA technical guidance?

If the answer requires thought, or involves escalating to the service provider to ask, the oversight model has a gap that a regulator asking the same question will notice before you do.

Revision 6 has been live for over a year.

The firms that treated it as a provider issue rather than a governance issue have had multiple filing cycles to accumulate a quality record they may not be aware of.

AIFMD II will not be a reset. It will be a continuation of that record, on a larger data surface, with a more developed supervisory response capability sitting behind it.

How Datox helps

Datox helps fund managers, fund administrators and compliance teams bring Annex IV production into a controlled regulatory reporting environment.

By connecting source data, applying structured validation logic and creating a clearer evidence trail from data ingestion to final XML output, Datox helps firms reduce reliance on manual review, improve reporting oversight and prepare for the higher validation standard under AIFMD II.

To see how Datox can support Annex IV reporting, book a demo with our team.

Related Articles

Schedule a Demo

Experience the future of automated financial regulatory reporting with a personalized demo.