E-money institutions occupy a specific regulatory category under PSD2 and the Electronic Money Directive 2 (EMD2), and there is a persistent misconception among EMIs — particularly those that came to market via the UK FCA's registered small e-money institution (SEMI) route — that their reporting obligations are lighter than those of authorised payment institutions. For quarterly NCA transaction reporting under PSD2 Article 96, this is not accurate. The XML schema compliance burden is the same. The quarterly deadlines are the same. The consequences of a failed submission are the same.
Where EMIs differ from payment institutions in their NCA reporting profile is in the composition of their transaction data — and this distinction, while operationally significant, makes the technical compliance problem no easier. In some respects, it makes it harder.
PSD2 Article 96 and EMI Scope
PSD2 Article 96 requires payment service providers — which includes e-money institutions as defined under Article 2 of PSD2 — to provide statistical data to their national competent authority on a periodic basis. The EBA has developed regulatory technical standards and guidelines specifying the data elements required, with each NCA implementing these requirements through its own technical schema and reporting framework.
EMIs are PSPs under PSD2 Article 1(1)(b) in conjunction with EMD2, which means the Article 96 reporting obligations apply to them in the same manner as to other PSP categories. An EMI authorised by the Central Bank of Ireland, for example, is subject to the same quarterly transaction reporting obligations as a payment institution authorised by the CBI — including the same ISO 20022 XML schema requirements and the same submission window deadlines.
The reporting data required from an EMI includes transaction volumes and values by payment service category, broken down by instrument type, geographic scope of transactions, and other dimensions specified in the applicable EBA guidelines. For an EMI operating a digital wallet or multi-currency payment product, the extraction of this data from internal systems requires careful mapping between the EMI's transaction data model and the categorical structure required by the NCA's reporting schema.
Where EMI Reporting Differs in Practice
The operational differences between EMI and payment institution reporting arise primarily from the transaction data characteristics, not from the regulatory schema requirements themselves.
EMIs are more likely than traditional payment institutions to have high volumes of low-value consumer transactions, multi-currency balances, and cross-border transaction flows — all of which create complexity in the data extraction and categorisation step before XML package generation begins. An EMI that issues e-money in GBP, EUR, and USD simultaneously needs to correctly attribute transaction values by currency and by geographical category in a way that aligns with the NCA's schema field definitions.
Additionally, EMIs that are part of group structures — for example, an EMI subsidiary of a broader fintech group with payment institution licences in multiple jurisdictions — may face consolidated reporting considerations where the same underlying transaction appears in multiple reporting obligations. The PSD2 reporting team must understand which transactions are in scope for each licence and ensure no double-counting or omission occurs across the group's NCA submissions.
Common Failure Modes in EMI Quarterly Reporting
Through the annual reporting cycle, a predictable set of failure modes recurs across EMI reporting operations.
Schema version drift. EMIs with lean compliance teams — a common feature of early-stage e-money operations — often rely on a static report generation template built against the schema version in use when the template was initially constructed. If the NCA updates its schema and the EMI's template is not updated before the next submission window, the submission will fail XSD validation. The time between schema update and the EMI discovering the change is the risk window; wider gaps between quarterly submissions mean that window can extend over three months.
Transaction categorisation errors. The NCA's schema specifies how transactions should be categorised — by payment service type, instrument, geographic scope. EMIs with complex product sets may have internal transaction categories that do not map cleanly to the NCA's categorical taxonomy. Mis-categorisation produces technically valid XML that nevertheless misrepresents the institution's actual transaction profile. NCAs that perform substantive review of submitted data may identify these inconsistencies and request corrections.
Correction filing failures. When an EMI identifies an error in a prior submission — or when an NCA requests a correction — the correction filing must be generated against the same schema version as the original submission, not the current schema version (unless the NCA specifies otherwise in its correction guidance). Generating a correction against the wrong schema version produces a second invalid file and restarts the correction cycle.
Missing e-money specific fields. Some NCAs have introduced schema extensions or additional data requirements specific to e-money reporting categories. An EMI using a generic PSD2 XML template designed for payment institutions may produce submissions that omit these fields, resulting in partial rejections that can be difficult to diagnose without detailed review of the NCA's current schema documentation.
An EMI Reporting Scenario: Quarterly Q3 Submission
Consider a scenario involving an EMI authorised by the ACPR in France, operating a consumer-facing multi-currency e-wallet with approximately 150,000 active accounts and transaction volumes of around 400,000 transactions per quarter. The compliance team consists of a compliance manager and a part-time regulatory reporting analyst.
In Q3 2024, the ACPR published an updated technical annex modifying the PAIN.001 schema version required for PSD2 transaction report submissions. The update was circulated through an ACPR circular, but the circular was not flagged by the EMI's newsletter monitoring (the subscription was to a general regulatory digest that did not capture this specific technical annex release).
The compliance team prepared the Q3 submission using their existing template, which was built against the prior schema version. The OneGate portal returned a validation error on first submission, two days before the submission window closed. The compliance analyst identified the schema version discrepancy, obtained the new XSD from the ACPR's documentation portal, spent one and a half days rebuilding the report package, and filed successfully within the window. The near-miss consumed approximately three working days across the two-person team.
This scenario is plausible and representative of how schema version failures occur at growing e-money operations. The specific institution is synthetic.
The Timeline Pressure of PSD2 Quarterly Deadlines
One underappreciated aspect of quarterly PSD2 reporting for EMIs is that the quarterly deadline is not simply a calendar date — it is a window within which the institutional reporting team must complete data extraction from live systems, validation, package generation, portal submission, and confirmation of successful receipt. For an EMI with high transaction volumes and limited compliance staff, this window can be genuinely tight.
NCA submission windows are typically 30 to 45 days after the reporting period ends, but the usable portion of that window for a small compliance team is shorter: the first week is usually consumed by data extraction and quality checks, the last week is reserved as a buffer for correction submissions. That leaves perhaps 15 to 25 working days in which a schema version discovery and rework must fit.
We are not suggesting that the quarterly timeline is unfair or that NCAs should extend submission windows. We are saying that the intersection of tight timelines, lean compliance teams, and unpredictable schema change schedules creates a systematic risk that is structural rather than the result of any single failure of diligence. Building resilience into the report generation process — rather than relying on the compliance team to manually absorb each schema change — is the appropriate response to this structural reality.
What a Defensible EMI Reporting Process Looks Like
A well-structured EMI quarterly reporting process has four characteristics that distinguish it from a reactive approach.
- Schema currency is actively maintained, not assumed. The current schema version for each covered NCA is tracked against a stored reference and validated before each submission cycle begins — not at the moment of submission.
- Data extraction mappings are documented and version-controlled. The mapping from internal transaction categories to NCA schema field values is documented, tested, and updated whenever the NCA schema or the EMI's product scope changes.
- Correction filing procedures are defined before they are needed. The procedure for generating and submitting a correction filing — including the schema version rule and the NCA's specific correction workflow — is documented and assigned to a responsible team member, not improvised under deadline pressure.
- Submission confirmation is verified, not assumed. The portal's confirmation of successful receipt is retained as part of the compliance record. An upload without a confirmed receipt is not a completed submission.
These four practices are achievable within the resource constraints of most growing EMI compliance operations. They describe a minimum defensible standard, not an aspirational ideal. The gap between current practice and this standard, at many EMIs, is primarily a tooling gap — the processes are understood; the tools to execute them reliably without manual intervention at each step are absent.