Compliance Fundamentals

PSD2 Audit Trail Requirements: What Regulators Expect in a Submission Record

Isabelle Marchand · · 8 min read
PSD2 Audit Trail Requirements: What Regulators Expect in a Submission Record

When an NCA examination focuses on a payment institution's or e-money issuer's regulatory reporting history, the examination team is not primarily interested in whether the institution's current quarterly submission is accurate. They are interested in whether the institution has maintained a consistent, demonstrably compliant reporting record over time — and whether the evidence of that record is organised in a way that allows the examination team to verify it without extensive back-and-forth with the institution's compliance team.

A defensible audit trail for PSD2 quarterly reporting is not complicated in concept, but it is frequently incomplete in practice. Compliance teams that manage the quarterly cycle well — producing accurate, timely submissions — often underinvest in the archiving and record-keeping step that would allow a third party to reconstruct their compliance history from the records. This article describes what a defensible audit trail looks like and where the common gaps occur.

What Regulators Look for in a Submission Record

An NCA examination of quarterly reporting history will typically attempt to verify three things: that submissions were made on time, that submissions used the correct schema version at the time of submission, and that any corrections or resubmissions were handled through the proper process and clearly documented.

Timeliness evidence. The submission window for a quarterly report opens and closes on specific dates defined by the NCA's reporting calendar. An examination team verifying timeliness wants to see a submission timestamp that falls within the open window, and a portal receipt confirmation from the NCA's system that corresponds to that timestamp. The institution's internal record of when a file was prepared is not sufficient on its own — the portal confirmation is the authoritative record of when a submission was accepted.

If an institution made a submission that was initially rejected and then resubmitted — the correction fell within the submission window, and the original failure was due to a technical error rather than a late attempt — the examination should be able to follow the full sequence: initial submission attempt, rejection, correction, and accepted resubmission. A record that shows only the accepted resubmission, without documenting the correction history, creates an unexplained gap in the record.

Schema version provenance. An examination team reviewing historical submissions may wish to verify that the schema version used for a particular quarterly submission was the current schema version at the time of submission. This requires that the institution has retained not just the submitted XML package but also the XSD schema file that was used for generation and validation.

Storing the submitted XML package alone is insufficient: the XML file contains a namespace declaration that references the schema version, but does not contain the schema itself. If the NCA subsequently updates its schema — which it will — the institution needs to be able to demonstrate that its submission at the time was validated against the then-current schema, even though that schema version is no longer the current one. This means archiving the XSD file as it existed at the time of submission, not relying on the ability to retrieve the current version from the NCA's registry at a later date.

Correction filing documentation. When a submission includes a correction to a prior submission — either because the institution identified an error in its original submission or because the NCA requested a correction — the correction record should be explicitly linked to the original submission in the audit trail. The correction filing should reference the original submission identifier, the nature of the error corrected, the corrected submission XML, and the correction acceptance confirmation from the NCA portal.

The Minimum Defensible Audit Trail

Based on what NCA examination practice requires across the principal European NCAs, a minimum defensible audit trail for each quarterly submission consists of the following records, retained together as a linked submission package:

  • The submitted XML package (the actual file submitted to the NCA portal), with filename as submitted.
  • The XSD schema file used for validation, with version identifier and file hash.
  • The results of local XSD validation run before portal submission (validation pass record with timestamp).
  • The portal submission confirmation (the acknowledgement receipt from the NCA portal, with submission reference number and timestamp).
  • The portal processing confirmation (where the NCA portal issues a secondary processing confirmation after intake, distinct from the upload acknowledgement).
  • The reporting period covered, explicitly stated — not implied by the filename or submission date.
  • The identity of the person who authorised submission (for institutions with role-based access control requirements).

For quarters where a schema change was detected and the submission required an updated package relative to the prior quarter's template, the audit trail should also include the change detection record and the impact analysis that justified the specific update applied.

Retention Periods

PSD2 and its implementing regulation do not specify a single unified retention period for compliance records. The applicable retention requirements derive from a combination of the PSD2 Article 96 framework, the EBA guidelines on reporting, and national regulatory requirements in the institution's home member state jurisdiction.

The FCA's regulatory record-keeping requirements under SYSC and CASS specify minimum retention periods for various record categories, with some categories requiring retention for five to seven years. BaFin's record-keeping requirements under German banking supervisory law and the Zahlungsdiensteaufsichtsgesetz (ZAG) similarly specify multi-year retention for regulatory compliance records. ACPR and CBI requirements are aligned with EU minimum standards, typically providing for retention periods of at least five years for supervisory reporting records.

A conservative and generally defensible retention policy for PSD2 quarterly submission records is five years from the submission date, with permanent retention for records relating to any submission that was the subject of NCA inquiry or examination. For institutions with multi-NCA obligations, the most restrictive applicable retention requirement should be applied across all records.

A Scenario: What an Audit Trail Reconstruction Looks Like Without Adequate Records

Consider a payment institution that is subject to an NCA supervisory review covering its PSD2 reporting for the period 2022 through 2024. The NCA examination team requests documentation of the institution's quarterly submissions over this period, including evidence of timely submission and schema version compliance.

The institution's compliance team can produce the submitted XML packages for most quarters — these were stored in a shared drive organised by year. However, for three quarters in 2023, the submissions were made under a different head of regulatory reporting who has since left the institution, and the portal confirmation records from those quarters were stored in that person's email rather than in a shared compliance record. The XSD files used for 2022 submissions were not archived separately — the compliance team assumed they could retrieve historical schema versions from the NCA's registry if needed, but the NCA's registry only maintains the current and one prior version. Two quarters' schemas are no longer available from the registry.

Reconstructing a complete submission record for this examination requires significant effort: searching archived email systems, attempting to retrieve historical portal submission records through the NCA portal's own history function (which may or may not retain records for that period), and potentially engaging directly with the NCA to confirm receipt records from the institution's own records. The examination process that should take two weeks takes six, and the institution cannot demonstrate complete schema version compliance for the 2022 submissions because the XSD files are not retrievable.

This scenario is plausible and constructed to illustrate the practical consequences of inadequate archiving. The institution is synthetic.

The Schema Version Provenance Problem in Depth

The XSD archiving requirement deserves specific attention because it is the most commonly overlooked element of a PSD2 submission audit trail. Compliance teams typically archive submitted files — the XML packages they generated and uploaded. They rarely archive the schema they validated against, because the schema is not "their" output; it belongs to the NCA.

This reasoning breaks down over time. An NCA's schema registry retains current and recent versions, but historical versions from two or three years ago may not be maintained on the public registry. If an institution needs to demonstrate that its 2022 submissions were valid against the 2022 schema — and the 2022 schema version is no longer available from the NCA registry — the institution cannot reconstruct that validation without a stored copy of the historical schema.

We are not saying that NCAs are likely to question the schema version compliance of historical submissions in routine circumstances. We are saying that in the event of an examination triggered by a substantive compliance concern, the institution's ability to provide a complete, self-contained record of each submission — including the schema it was generated against — is a material factor in the examination outcome.

Automating Audit Trail Completeness

The most reliable way to ensure audit trail completeness is to make it a mandatory step in the submission workflow rather than a voluntary post-submission activity. A workflow that automatically captures the submission metadata — schema version, file hash, submission timestamp, portal reference — at the point of submission does not depend on a compliance officer remembering to archive these elements after the submission window closes. The window between "submission confirmed" and "window closes" is when archiving is most at risk of being deferred indefinitely.

For institutions managing multiple NCAs across multiple quarterly cycles, the archiving discipline required to maintain complete records manually across a multi-year period is significant. The compliance officers who build and maintain this discipline typically leave at some point, and the institutional knowledge of where records are stored and how they are organised is a key-person risk that automated archiving removes.

Stop discovering schema changes after a failed submission