The moment a quarterly PSD2 submission fails NCA validation, the forensics always lead to the same place: a schema version mismatch. Not a data error, not a misconfigured report field — a version string in the XML declaration that no longer matches what the regulator's validator expects. The institution's compliance team built the report package against pain.001.001.09. The NCA had quietly published pain.001.001.11 six weeks earlier. Nobody noticed.
This is not an edge case. It is the dominant failure mode in PSD2 transaction reporting, and it is structural: the mechanisms by which NCAs communicate schema changes are not designed to prevent it.
How NCA Schema Registries Actually Work
Each National Competent Authority maintains its own schema registry — a collection of XSD files and accompanying technical documentation that defines what a valid submission looks like. These are not hosted on a unified European infrastructure. The FCA maintains its own, BaFin maintains the Meldewesen schemas within its own reporting environment, ACPR operates through the Banque de France's reporting infrastructure, and DNB uses its own portal with XBRL taxonomy overlays for certain categories alongside ISO 20022 XML.
Schema updates are published asynchronously. An NCA may push a version change to its registry in response to a change in the ISO 20022 message standard, a national regulatory clarification, or a correction to a discovered inconsistency in the prior version. The timing is driven by the NCA's internal publication schedule, not by a European-wide coordination calendar. EBA Technical Standards provide the overarching framework, but the specifics of when and how each NCA updates its local schema implementation are left to each authority.
The result is that compliance teams must monitor five to seven distinct publication channels — each with its own document format, change notification mechanism, and update cadence — to maintain currency with the schemas their submissions will be validated against.
The Discovery Gap: How Teams Find Out About Changes
Consider a payment institution operating under FCA authorisation and filing quarterly transaction reports under the Payment Services Regulations 2017. The institution's head of regulatory reporting maintains a manually maintained spreadsheet of current schema versions, updated during the quarterly preparation cycle — typically the two to three weeks before a submission window closes.
If the FCA updated its PAIN.001 schema in the middle of a quarter — say, in the fifth week after the previous submission — the compliance team may not discover this until they begin preparing the next submission. If they begin preparation with three weeks remaining, validate against what they believe is the current schema, and submit, they face two outcomes: either the NCA's validator accepts the outdated version (some NCAs accept minor version increments within a generation), or it rejects the file with an XSD validation error.
In practice, a growing number of NCAs are tightening their validation to require exact version matches. The rejection message may contain the schema version string that was expected, which gives the team a starting point — but the work of identifying precisely what changed, rebuilding the report package against the new schema, and re-validating before the window closes can span several days of specialist time.
Why the Manual Process Has a Structural Ceiling
There is a common assumption in compliance operations that more diligent monitoring solves this problem. If the compliance team checks NCA documentation pages more frequently — weekly rather than quarterly — they will catch changes in time. This is true in principle. In practice, it fails for three reasons.
First, NCA documentation pages are not designed for change notification. They are maintained as current-state reference sites. A schema update may be reflected by a new file appearing in a directory listing or by an updated version number in a reference table, with no change log, no RSS feed, and no structured announcement. Detecting that a change occurred requires either a manual comparison against a prior state or an automated diff against a stored snapshot.
Second, the XSD file itself must be parsed to understand what changed. A version increment from pain.001.001.09 to pain.001.001.11 does not tell you whether a required field was added, an enumeration value was changed, or a data type constraint was tightened. An institution needs to understand the impact of the change against its own transaction data model before it can produce a compliant package. This analysis requires someone with both XML schema competence and regulatory context.
Third, these activities cannot practically be delegated to non-specialist staff. The person doing the monitoring and impact analysis must understand both the technical schema format and the regulatory context well enough to judge whether a changed field is relevant to their institution's submission.
We are not saying that manually managed processes are inherently incapable of producing compliant submissions. Many institutions with well-resourced compliance teams file accurately every quarter. We are saying that the reliability ceiling of a manual process — the maximum degree of assurance it can provide without automation — is significantly below what most institutions need, and that as NCAs tighten schema validation requirements, that ceiling is getting lower.
A Representative Failure Mode
A mid-size e-money institution authorised by the Central Bank of Ireland, operating a multi-currency wallet product with transaction volumes in the range of 80,000 to 120,000 transactions per quarter, maintains its PSD2 reporting process internally. Two members of the compliance team share responsibility for quarterly preparation.
In mid-2024, CBI updated its PAIN.001 schema requirements in response to ISO 20022 migration guidance. The update included a change to how the CdtTrfTxInf/Amt element handled multi-currency transactions — a modification relevant to this institution's core use case. The institution prepared its Q2 2024 submission against the prior schema version. Validation failed on first submission.
The compliance team identified the schema version mismatch within four hours and obtained the updated XSD. Understanding the specific change — isolating which data transformation in their extraction process needed updating — took approximately two and a half days. Rebuilding and re-validating the package took one further day. The institution filed within the submission window, but the process consumed nearly four full working days from two compliance staff members, plus a short engagement with an external XML consultant.
This scenario is plausible and representative. The specific institution is synthetic; the pattern is not.
Version Strings as Risk Indicators
The ISO 20022 message standard uses a version identification scheme of the form <message-type>.<organisation>.<version> — for example, pain.001.001.11 identifies Credit Transfer Initiation version 11. NCA-specific extensions layer onto this base, sometimes with NCA-specific namespace prefixes or additional required elements not present in the ISO base schema.
When a version increment is minor — a decimal position change — it is tempting to treat it as low risk. This is unreliable. Even a patch-level version increment may involve a change to a mandatory element's enumeration list or a constraint tightened in response to a regulatory interpretation. Treating any version increment as potentially breaking, until a diff analysis confirms otherwise, is the conservative and correct posture.
A number of NCAs have been observed to make significant schema changes without major version increments — releasing changes as corrections to the current version. This makes version comparison alone an insufficient monitoring strategy; the XSD file content itself must be hashed and compared against stored states to detect silent updates.
What Structural Resilience Actually Requires
A compliance team that is structurally resilient to NCA schema changes has three capabilities in place: continuous registry monitoring that detects changes at the XSD level, not just at the version string level; rapid impact analysis that maps a detected change against the institution's transaction data model; and automated report package regeneration that produces a validated submission-ready package against the new schema without requiring manual XML reconstruction.
The first of these — continuous monitoring — is a precondition for the second and third. Without reliable change detection, impact analysis is reactive and often arrives too late. Without impact analysis, regeneration may produce a package that validates against the new schema but does not correctly represent the institution's transactions under the new field requirements. All three capabilities are necessary; none is sufficient alone.
The quarterly submission cycle for PSD2 reporting is not going to become less demanding. PSD3 draft provisions, currently under European Commission review, propose changes to both the scope and the timing of reporting obligations. NCAs are expected to update their schema infrastructure in response. Institutions that have closed the schema detection gap now will be better positioned to absorb those changes when they arrive.