NCA schema registries are not a standardised infrastructure. Each national competent authority maintains its technical documentation and schema files in a format that reflects its own reporting systems, publication practices, and update workflows. For an organisation building a monitoring system that tracks schema changes across multiple NCAs simultaneously, this lack of standardisation is the core technical problem.
This article explains the technical approach to schema registry monitoring across the principal European NCAs — what the monitoring targets are, how change detection works in the absence of standardised publication mechanisms, and why version string comparison alone is insufficient as a monitoring strategy.
What a Schema Registry Actually Is
The term "schema registry" implies a structured, queryable data store — a service that exposes schema versions through an API, maintains a change history, and publishes version diffs. Most NCA schema registries are nothing like this. In practice, a schema registry is a section of an NCA's documentation website that contains one or more XSD files available for download, typically alongside accompanying documentation such as technical implementation guides, changelog documents (when they exist), and validation rules.
The publication mechanisms vary significantly:
- BaFin MVP documentation publishes technical specifications as PDFs with accompanying XSD files. Updates are announced through BaFin's general publication channels (BaFin journal, circular system) with varying specificity about the technical content of schema changes.
- FCA technical documentation for payment reporting schemas is maintained through FCA's GABRIEL documentation and separate PSR-related schema publications, with updates referenced through FCA's policy and guidance publication system.
- ACPR/OneGate documentation publishes technical annexes and XSD files through Banque de France's reporting documentation system, with ACPR circulars providing some advance notice of schema updates.
- DNB reporting portal documentation maintains both ISO 20022 XML schemas and XBRL taxonomy files with update notices published through DNB's supervisory communication channels.
- CBI ONR documentation publishes technical reporting specifications on the CBI website with periodic updates that may or may not be accompanied by a structured change notice.
The common thread: schema updates are published at the NCA's discretion, without standardised advance notice periods, through documentation channels that are not designed for automated change detection.
Why Version String Monitoring Is Insufficient
The most obvious approach to schema monitoring is tracking the version string in the NCA's current XSD file — polling the schema source periodically and comparing the version identifier against the last known version. This approach catches most schema changes but misses a critical category: silent updates.
A silent update occurs when an NCA modifies the content of an XSD file without changing the version identifier. This can happen when the NCA considers the change to be a correction to the current version rather than a new version — fixing a typo in an element description, adjusting a constraint that was incorrectly specified, or adding a comment. These corrections may be functionally trivial, or they may be substantive: a constraint that was too permissive being tightened, for example, can cause submission failures for packages that were valid under the prior version of the file.
Detecting silent updates requires comparing the XSD file content itself, not just the version identifier. The practical approach is to store a cryptographic hash (SHA-256 or similar) of each monitored XSD file and compare subsequent downloads against the stored hash. A hash mismatch indicates that the file content has changed, regardless of whether the version string changed.
The Monitoring Pipeline Architecture
A robust NCA schema monitoring pipeline operates in distinct stages.
Stage 1: Schema Source Discovery
The first stage establishes the source locations for each NCA's schema files. For a multi-NCA monitoring system, this means maintaining a configuration that maps each NCA to its schema file source URLs, the document format (XSD, XBRL taxonomy, or documentation-embedded schema), and the publication channel used by the NCA to announce updates.
This configuration must be maintained manually — there is no automated way to discover NCA schema source URLs from a central registry, because no central registry exists. When an NCA restructures its documentation website or migrates its reporting portal, the schema source URL may change, and the monitoring system must be updated.
Stage 2: Change Detection
The second stage polls each schema source on a defined schedule and compares the retrieved file against the stored reference. For file-based schemas (XSD downloads), this means:
- Fetch the current XSD file from the source URL.
- Compute the file hash.
- Compare against the stored hash for this NCA/schema combination.
- If hashes differ: flag as a change event and trigger impact analysis. If hashes match: no change, update the last-checked timestamp.
For XBRL taxonomy monitoring, the process is more complex because XBRL taxonomies are typically distributed as a set of linked files rather than a single XSD. The monitoring must cover the entry point schema, the linkbase files, and any imported schema components. A change to any file in the taxonomy set constitutes a taxonomy update.
Stage 3: Version Differential Analysis
When a change is detected, the monitoring system must produce a useful representation of what changed — not just that a change occurred. For XSD files, a structural diff produces a list of element additions, deletions, and modifications. For XBRL taxonomies, the diff covers element additions and removals in the taxonomy's concept set, changes to linkbase relationships, and changes to labels.
The raw XSD diff must be interpreted in the context of the institution's reporting requirements. A field addition to a section of the schema that is not used in the institution's transaction types is less urgent than a change to a required field used in the institution's primary transaction category. Impact analysis maps the schema diff against the institution's data model to identify which changes are relevant.
Stage 4: Impact Classification
Based on the differential analysis, changes are classified by urgency:
- Breaking changes: additions to required fields without defaults, removal of elements previously in use, enumeration value changes for values the institution uses, data type constraint tightening. These require immediate action before the next submission.
- Non-breaking changes: additions of optional fields, additions to enumeration lists, documentation or description changes, additions of new elements not in the institution's current use. These require awareness but no immediate action unless the institution wants to take advantage of new optional fields.
- Indeterminate changes: changes to schema structure that may or may not be relevant depending on the institution's specific data. These require human review to classify.
Polling Frequency and Its Trade-offs
The appropriate polling frequency for schema monitoring depends on the balance between detection speed and resource consumption. For most NCA schema registries — which update on irregular schedules measured in months, not days — daily polling is a reasonable baseline. For NCAs that announce upcoming changes through publication channels with advance notice, the polling frequency can remain at baseline until an announcement is received and then increase to hourly or more frequent during the notice period.
We are not suggesting that hourly polling of NCA documentation sites is generally appropriate — high-frequency polling of regulatory documentation sites is not the correct approach for monitoring infrastructure that updates infrequently. The right architecture monitors the announcement channels at high frequency (NCA publication channels, regulatory newsletter subscriptions) and increases the polling frequency on specific schema sources when an announcement suggests a change is imminent.
The CBI ONR Challenge
To illustrate the practical difficulty of multi-NCA schema monitoring with a specific case: the CBI's Online Reporting System does not publish a structured API for schema version queries. The current schema specifications for CBI reporting are embedded in technical documentation PDFs as well as being available as downloadable XSD files. Detecting a CBI schema update requires monitoring both the XSD file (for the hash-comparison change detection described above) and the documentation section of the CBI website (for announcement-level signals that a change is coming).
When CBI updated its technical specification documentation in mid-2024 to reflect changes to its PAIN.001 schema requirements for PSD2 transaction reporting, the update was reflected in a revised PDF technical annex published on the CBI website before the updated XSD file was posted. Monitoring systems that only checked the XSD source would not have detected the change until the XSD was updated — which was several days after the technical annex was revised. Systems monitoring both the documentation and the XSD had more lead time.
The specific update referenced is illustrative; the pattern of documentation preceding XSD publication is common across NCAs and is a valid monitoring strategy consideration.
Building on Unstable Ground
The absence of standardised NCA schema publication mechanisms is not a temporary gap that will be filled by PSD3 harmonisation next year. Even under a more harmonised technical standard framework, individual NCAs will continue to implement and update their reporting infrastructure on their own schedules. The technical monitoring challenge — the need to track multiple heterogeneous sources, detect changes reliably, and interpret their impact — remains regardless of the degree of cross-NCA harmonisation at the policy level.
What effective schema registry monitoring provides is the ability to operate proactively rather than reactively in the face of this structural instability: knowing about schema changes when they happen, not when a submission fails. The operational value of that advance knowledge — measured in days of lead time available for impact analysis and package regeneration before the submission window opens — is what makes schema monitoring the foundation of a resilient PSD2 reporting process.