Q-End Regulatory Submission Checklist for PSD2 Compliance Officers

The quarterly PSD2 submission cycle is predictable in its timing but unpredictable in its execution. Every head of regulatory reporting at a European payment institution or e-money issuer knows the approximate deadline dates a quarter in advance. What remains unpredictable is whether the NCAs have updated their schema requirements since the last submission, whether the portal authentication credentials are still valid, whether the data extraction process has captured the correct period correctly, and whether the generated package will pass validation on first submission.

This checklist is structured around the four phases of the quarterly submission cycle: pre-period (work that should happen before the reporting period ends), preparation phase (data extraction and package generation), submission phase (portal upload and confirmation), and post-submission (archiving and audit record completion). Each phase has specific failure modes; addressing them in sequence reduces the probability of a submission window crisis.

Phase 1: Pre-Period Checks (4–6 Weeks Before Submission Window Opens)

Schema Version Verification

The single most important pre-period check is confirming the current schema version for each NCA you are reporting to. This means checking the actual XSD file on the NCA's schema registry — not just the version string in your template, and not just the version number listed in a document that was last reviewed three months ago.

• Access each NCA's schema registry directly (FCA, BaFin MVP documentation, ACPR/OneGate technical specifications, DNB reporting portal, CBI technical documentation).
• Compare the current XSD file against your stored reference version using a file hash comparison, not just a version string check. NCAs can update XSD file content without changing the version identifier.
• If a version change is detected, obtain the change summary or diff from the NCA's documentation (if published) or perform a manual diff between the current and prior XSD files.
• Assess the impact of any detected changes on your data extraction process and XML generation template before beginning the preparation phase.

Submission Window Confirmation

Submission window dates are typically published by NCAs in their annual reporting calendars, but should be re-confirmed before each cycle. NCAs occasionally adjust submission windows for public holidays, regulatory system maintenance windows, or exceptional circumstances.

• Confirm the exact submission window open and close dates for each covered NCA.
• Identify any NCA-specific early warning submissions or pre-submission notification requirements.
• Note whether the NCA accepts submissions before the window formally opens (some do; most do not count pre-window submissions as valid).

Portal Access Verification

NCA submission portals — BaFin MVP, ACPR OneGate, CBI ONR, FCA GABRIEL — use authentication credentials that can expire or require periodic re-validation. Credential failures discovered on the day of a submission attempt are an avoidable source of submission delay.

• Log in to each NCA portal with current credentials at least three weeks before the submission deadline.
• Verify that all user accounts with submission permissions are active.
• Confirm that any institutional certificates or qualified electronic signatures required for portal authentication are current and valid.
• Check for any portal system maintenance notices that might affect availability during your planned submission window.

Phase 2: Preparation Phase (2–3 Weeks Before Submission Deadline)

Data Extraction

Data extraction for PSD2 Article 96 reporting covers the full reporting period — typically the calendar quarter. The extraction must capture all in-scope transactions with the attributes required by the NCA's current schema, including any fields that may have been added or modified in a schema update detected in Phase 1.

• Confirm the reporting period start and end dates match the NCA's reporting period definition (some NCAs use business days for period boundaries; others use calendar days).
• Verify that all transaction categories in scope for the NCA's schema are being extracted correctly, including any categories that were modified or added in recent schema updates.
• Check for any transactions that span the period boundary — transactions initiated before period end but settled after — and confirm they are correctly included or excluded per the NCA's guidance.
• For multi-currency EMIs: verify that currency conversion rates used for period-end value calculations use the rate specified in the NCA's reporting guidance (typically mid-market rate at period end).

Data Quality Validation

Before generating the XML package, validate the extracted data against the NCA's schema requirements at the logical level — not just the XML structure. Logical validation errors (transactions categorised under instrument types not applicable to your product, implausible transaction values, geographic category mismatches) will not necessarily be caught by XSD validation but may surface during NCA review.

• Check that transaction value totals are consistent with internal management accounts for the period.
• Verify that transaction counts by category are consistent with operational system records.
• Check for any anomalies — particularly large value movements or unusual volume spikes — that should be understood and documented before submission.

XML Package Generation

• Generate the report package against the current NCA schema version confirmed in Phase 1.
• Validate the generated XML against the current XSD using an XML validation tool before portal submission (do not rely on the portal validator as the first validation step).
• Verify file naming conventions against the NCA's current technical specification. BaFin MVP in particular has specific file naming requirements that cause portal-level rejection if not met.
• Confirm that all required metadata fields (reporting period, institution identifier, submission type) are correctly populated in the package header.

Phase 3: Submission Phase

Portal Submission

• Submit the validated package through the NCA's portal using the correct submission method (file upload, API, or SFTP as applicable per the NCA's current technical specification).
• Record the portal's submission reference number or acknowledgement immediately upon upload.
• Wait for portal validation confirmation — do not assume submission is complete at the point of upload. Portal validation (checking file format, naming conventions, and basic schema structure) is a separate step from substantive NCA review.
• If the portal returns a validation error, treat it as a submission failure requiring correction before the window closes. Do not assume the error is a portal glitch until you have confirmed that the submitted file passes local XSD validation.

Submission Confirmation

This step is missed more often than it should be. Portal acceptance of a file upload does not always equate to successful submission processing. Some portals issue an initial upload acknowledgement followed by a secondary processing confirmation after a brief delay.

• Check the NCA portal for a processing confirmation, not just an upload acknowledgement, within 24–48 hours of submission.
• Retain the processing confirmation reference as part of your submission record.
• If a processing confirmation is not received within the NCA's published processing window, contact the NCA's reporting team directly — do not wait for the submission window to close.

Phase 4: Post-Submission Archive and Audit Record

Audit Trail Completion

The audit trail for a quarterly submission should be complete before the submission record is considered closed. An NCA examination of your reporting history will look for evidence that submissions were made on time, that the schema version used was current at the time of submission, and that any corrections were made through the proper correction filing process.

• Archive the submitted XML package, the XSD it was validated against, the portal submission confirmation, and the processing confirmation in a single submission record.
• Record the schema version string and the hash of the XSD used for generation as part of the submission metadata.
• Record the submission timestamp (not just the date) — NCA portals that are timezone-sensitive may record submission times in UTC; ensure your records are consistent with the portal's records.
• If the submission involved any corrections from a prior submission, archive the correction record separately and cross-reference it with the original submission record.

Schema Reference Update

After each submission cycle, update your stored schema reference to reflect the version actually used for the submission. If a schema version change was detected and applied during this cycle, note it as an update event in your schema version log.

• Store the current XSD file and its hash for each NCA as the baseline for next cycle's pre-period check.
• Record the date on which each NCA's current schema version was last verified.

This checklist represents a minimum defensible process for quarterly PSD2 submissions. We are not suggesting that every institution needs the same level of process formality — a small EMI with a single NCA obligation has different resource constraints than a multi-NCA payment institution group. What every institution needs is a reliable record that shows, for each submission, what schema was used, when the submission was made, and that the submission was confirmed received. Without that record, an NCA examination becomes a documentation reconstruction exercise rather than a straightforward compliance review.