XBRL vs XML in NCA Reporting: Which NCAs Use Which Format

The split between XBRL and XML in European NCA reporting is not a clean binary. It is a patchwork that reflects each regulator's historical technology decisions, the scope of their reporting infrastructure, and the degree to which they have aligned their requirements to EBA technical standards versus developed their own reporting architecture. For compliance teams at European PSPs and EMIs, understanding which format is required where — and maintaining the tooling to produce both — is an operational necessity, not an academic exercise.

This article maps the current state of XBRL versus XML usage across the major NCAs, explains why the split exists, and addresses what compliance teams need to maintain for each format category.

Why the XBRL/XML Split Exists

ISO 20022 XML and XBRL serve different primary purposes in the regulatory reporting ecosystem. ISO 20022 XML — through messages like PAIN.001 Credit Transfer Initiation and PAIN.002 Payment Status Report — was designed for payment transaction messaging: structured, transaction-by-transaction data about individual payment instructions. XBRL (eXtensible Business Reporting Language) was designed for statistical and financial reporting: period-aggregated data expressed against a taxonomy of defined data points.

PSD2 Article 96 transaction reporting maps reasonably well to ISO 20022 XML, because the underlying data is transaction-level: volumes, values, and instrument types for individual transaction categories over a reporting period. Many NCAs have implemented their PSD2 transaction reporting requirements using ISO 20022-derived schemas, often PAIN.001 and PAIN.002 message formats with NCA-specific extensions.

However, NCAs that operate broader supervisory reporting infrastructure — covering prudential reporting, statistical reporting, and operational reporting alongside PSD2 transaction data — often maintain XBRL-based reporting frameworks for the statistical and prudential categories, because XBRL taxonomies are well-suited to the aggregated, period-summary format that prudential reporting uses. When these NCAs extend their reporting requirements to cover PSD2 data, they sometimes channel it through the existing XBRL infrastructure rather than building a parallel ISO 20022 XML pipeline.

The FCA: XBRL and ISO 20022 in Parallel

The FCA operates two distinct reporting systems: GABRIEL (the Going Electronic Returns system) for statistical and regulatory returns, and separate XML-based systems for payment transaction data. GABRIEL has historically used XBRL taxonomy submissions for the majority of its regulatory returns, and payment institutions with FCA authorisation are likely to have at least some reporting obligations channelled through GABRIEL in XBRL format.

PSD2-equivalent transaction reporting under the Payment Services Regulations 2017 uses a separate technical framework from GABRIEL's XBRL reports. FCA-authorised payment institutions may therefore maintain both XBRL filing capability (for GABRIEL returns) and ISO 20022 XML generation capability (for PSR 2017 transaction reports) simultaneously.

The practical implication is that a compliance team managing FCA reporting obligations should not assume that its ISO 20022 XML tooling covers all FCA reporting requirements. GABRIEL submissions require an XBRL taxonomy mapping, and the FCA's taxonomy for GABRIEL returns is updated on a separate schedule from its XML schema requirements for transaction reporting.

DNB: XBRL as a Primary Reporting Format

De Nederlandsche Bank is the NCA with the most significant XBRL usage for PSD2-adjacent reporting. DNB has developed a substantial XBRL-based reporting infrastructure through its supervisory reporting programme, and payment institutions and e-money issuers authorised in the Netherlands will encounter XBRL taxonomy submissions as a routine part of their DNB reporting obligations.

DNB's use of XBRL encompasses prudential reporting, statistical reporting, and portions of its payment services reporting framework. The specific categories that use XBRL versus ISO 20022 XML depend on the institution type and the reporting category. Compliance teams at DNB-supervised institutions should review DNB's current reporting obligation schedule to identify which returns require XBRL submissions and which use ISO 20022 XML, and should verify this classification when DNB updates its reporting framework.

DNB maintains taxonomy documentation for its XBRL-based returns, and taxonomy updates are published on a schedule aligned with DNB's reporting framework updates. XBRL taxonomy updates can be as consequential as ISO 20022 schema updates for submission validity: a taxonomy version mismatch will produce a validation failure in the same way as an XML schema version mismatch.

BaFin: Primarily ISO 20022 XML via MVP

BaFin's Meldewesen-Plattform (MVP) primarily uses ISO 20022 XML for PSD2 transaction reporting submissions. German payment institutions submitting quarterly PSD2 transaction data through the MVP portal are working with PAIN.001/PAIN.002-family schemas, not XBRL. BaFin does use XBRL for some prudential reporting categories — particularly through the EUCLID reporting framework for certain banking groups — but PSD2 payment transaction reporting within the MVP is XML-based.

This makes BaFin one of the cleaner NCA environments from a format perspective for institutions whose primary reporting obligation is PSD2 transaction data. The focus for BaFin compliance teams is ISO 20022 XML schema version management and MVP portal submission procedures.

ACPR and CBI: ISO 20022 XML

The ACPR's OneGate portal and the CBI's Online Reporting System primarily use ISO 20022 XML formats for PSD2 transaction reporting. Both NCAs have developed their reporting frameworks around ISO 20022 message schemas, and compliance teams submitting to ACPR or CBI will need ISO 20022 XML generation capability rather than XBRL taxonomy support for their core PSD2 transaction reporting obligations.

Both NCAs do operate broader supervisory reporting frameworks that may include XBRL for some categories, but PSD2 transaction reporting specifically is XML-territory for both.

Format-Specific Compliance Considerations

We are not suggesting that XBRL is harder to maintain than ISO 20022 XML, or vice versa. Each format has its own technical characteristics and maintenance requirements. The relevant distinction for compliance teams is that they are different technical competencies requiring different tooling, and that mixed NCA portfolios may require both.

For ISO 20022 XML

• The XSD schema file is the definitive specification for valid submissions. Schema version management is the primary technical maintenance task.
• XML generation can be done through XSLT transformations from source data, direct XML library generation, or template-based approaches. The choice affects how schema updates are absorbed — XSLT-based approaches can be updated by modifying the transformation; hardcoded XML generation requires code changes.
• XML namespace declarations in the report package header must match the schema namespace exactly — a version mismatch at the namespace level will cause validation failure even if the element structure is otherwise correct.

For XBRL

• XBRL taxonomy versioning is analogous to XML schema versioning: the taxonomy file hash must match the version your submission declares. Taxonomy updates require the same monitoring approach as XML schema updates.
• XBRL instance documents reference the taxonomy through linkbases and schema refs. The linkbase structure is more complex than a single XSD reference, which increases the number of files that must be kept current.
• XBRL validation tools (such as Arelle) can validate instance documents against taxonomies locally before portal submission — the equivalent of local XSD validation for XML submissions. Running local validation before portal submission is good practice for both formats.

An NCA Format Reference

The table above reflects the general current state of NCA format requirements based on publicly available documentation. Compliance teams should verify the current format requirement directly with each NCA's technical specifications before each reporting cycle — the format classification for specific reporting categories can change when NCAs update their reporting infrastructure.

Maintaining Both Formats Without Duplication

For institutions that must maintain both ISO 20022 XML and XBRL capabilities, the practical challenge is ensuring that both format stacks are kept current when the underlying regulatory data changes. An NCA requirement update that changes what data must be reported — say, adding a new transaction category — may require updates to both the XML template for one NCA and the XBRL taxonomy mapping for another, drawing from the same source transaction data.

The shared data layer is the most important thing to get right: if the transaction data extracted from internal systems is correct and complete, the format conversion to XML or XBRL is a technical transformation step. Format-specific maintenance costs are lowest when the data extraction logic is format-agnostic and the format conversion is a late-stage step, not when different extraction processes exist for XML reporting versus XBRL reporting.