When I spent the better part of a decade in regulatory reporting roles at European payment institutions, the question of automation versus manual processes was rarely framed as a strategic choice. It was just the way things were done. You had a spreadsheet that fed an XML template that someone had built years ago and that you hoped would still work next quarter. If it didn't — if the NCA had updated its schema and your template was no longer valid — you spent the days before the submission deadline fixing it manually, which meant finding the right XSD, mapping the changes, rebuilding the file, and running validation. The process worked, most of the time, until it didn't.
Building Fynrex meant talking extensively with heads of regulatory reporting and compliance officers at European PSPs and EMIs about how they actually manage this process today. What I heard was not so different from what I experienced myself: highly capable compliance professionals spending significant portions of their quarterly cycles on work that is structurally automatable, at an operational cost that most compliance teams have not fully quantified because it has always been treated as a fixed cost of doing business.
What Manual Report Generation Actually Costs
The direct time cost of manual PSD2 report generation varies considerably by institution size, transaction complexity, and the number of NCAs covered. From conversations with compliance teams at growing European PSPs and EMIs — institutions with transaction volumes in the range of 50,000 to 500,000 transactions per quarter and NCA coverage of one to four regulators — a typical range for manual quarterly report generation is 8 to 25 person-days per NCA per quarter.
This estimate spans data extraction (2–5 days), data validation and categorisation checking (2–4 days), XML package generation and local validation (1–3 days), portal submission and confirmation (0.5–1 day), and audit trail documentation (1–2 days). Multiplied across multiple NCAs, a four-NCA institution might spend 25 to 60 person-days per quarter on PSD2 reporting — roughly six to fifteen working weeks of a single full-time compliance professional's time.
The hidden cost is the schema change discovery and remediation cycle. In quarters where no NCA updates its schema, the process runs as described above. In quarters where one or more NCAs push a schema update, the remediation cycle adds an unpredictable number of days: from half a day for a minor well-documented change to five or more days for a significant schema version increment with limited NCA documentation. Across a year, schema change remediation adds an average of perhaps 20 to 40 hours per NCA — but the distribution is highly skewed: most quarters have no schema change, and the occasional quarter with a schema change absorbs a concentrated burst of effort at exactly the worst time.
What Automated Report Generation Costs
Automated report generation does not eliminate compliance officer involvement — it restructures it. The work that compliance teams spend the most time on (data extraction, XML template management, local validation) is automated. The work that genuinely requires human judgment (reviewing extracted data for logical accuracy, interpreting NCA schema change impact, making correction decisions when NCA review identifies issues) remains with the compliance professional.
In practice, compliance teams at institutions using automated report generation describe the quarterly cycle as shifting from a 2–3 week intensive period of manual work to a 2–3 day review-and-sign-off process for each NCA, with monitoring alerts arriving well before the submission window in the event of a schema change. The total compliance officer time per quarterly cycle per NCA drops to roughly 1.5 to 4 days in the absence of anomalies, with schema change events adding 1–2 days for review and approval rather than 3–5 days for manual reconstruction.
The infrastructure cost of automation is a valid consideration. Building bespoke report generation automation in-house requires engineering time that is not trivial — estimate 40 to 80 engineering days to build an initial system for a single NCA, with ongoing maintenance at roughly 15–25 engineering days per year per NCA, plus additional cost for each schema update. For a four-NCA institution, that is a meaningful engineering investment that most PSPs and EMIs cannot justify within a compliance budget.
The Schema Change Variable
The cost comparison between manual and automated approaches shifts most dramatically in the schema change scenario. In a manual process, a schema change that arrives three weeks before a submission deadline initiates a crisis-response mode: schema acquisition, impact analysis, template modification, validation, and re-submission preparation, all under time pressure. The compliance team's ability to maintain quality in other work during this period is compromised.
In an automated process with schema registry monitoring, the schema change is detected when it is published — not when the submission fails. The detection leads to an automated impact analysis and an alert to the compliance team, which has days or weeks (rather than hours) to review the impact and approve the updated package generation. The urgency is different in kind, not just in degree.
We are not saying that automated systems eliminate all risk associated with schema changes. A schema change that introduces a new required data element — one that requires a change to the data extraction process, not just the XML generation template — still requires compliance team involvement and potentially engineering support. Automation cannot manufacture data that does not exist in the source systems. What it does is compress the time between schema change publication and compliance team awareness, and it removes the manual XML reconstruction work for changes that are within the scope of the automated generation system.
Error Rate: The Underquantified Factor
Compliance teams are generally reluctant to discuss their submission error rates in specific terms. The broader pattern from conversations across the industry is that first-submission failure rates for manual report generation — submissions that require correction or resubmission — are materially higher than most compliance teams' internal quality metrics would suggest, because many failures are caught in local validation before the first portal submission attempt and are not counted as failures.
The failure modes that carry the most regulatory risk are not the ones caught in local validation — those are found and fixed before submission. The higher-risk failures are logical errors in transaction categorisation that pass XSD validation but represent the institution's transaction profile incorrectly, and schema version mismatches that occur in portals with partial validation at intake. Both types of error are more common in manual processes than in automated ones, primarily because manual processes have more human handoff points where inconsistencies can be introduced.
A Comparison at the Margin
For an institution considering the investment in automation, the decision calculus comes down to a comparison between the annual cost of manual compliance labour, the occasional cost of schema change remediation (including the value of compliance team time spent under crisis conditions), and the risk-adjusted cost of a failed submission.
NCA penalty exposure for failed quarterly submissions varies by jurisdiction and severity. Most NCAs distinguish between late submissions, incorrect submissions, and failure to submit — with different consequences for each. Even setting aside formal penalty exposure, a failed submission that requires correction and resubmission carries an implicit cost: compliance team time, potential NCA scrutiny, and the operational disruption of working under deadline pressure with a broken reporting process.
The break-even calculation for automation depends heavily on the institution's NCA coverage, transaction complexity, and the current burdened cost of compliance labour. For institutions covering two or more NCAs, the calculus generally favours automation. For single-NCA institutions with very simple transaction profiles, the calculus is less clear, though the asymmetric cost of schema change remediation should be weighted appropriately — it is a low-probability, high-impact event rather than a predictable cost.
What the Comparison Misses
The manual versus automated framing, while useful, can obscure what is actually at stake. The compliance officer's value is in regulatory judgment: interpreting what an NCA examiner would consider adequate, making decisions about how to categorise ambiguous transactions, and understanding when a submission error requires a correction versus an explanation. None of that is automated. All of that is made better when the compliance officer is not spending three weeks manually rebuilding an XML file and has instead spent two hours reviewing an automatically generated package that is already schema-validated and ready for submission.
The case for automation in PSD2 report generation is not that it removes the need for expert compliance professionals. It is that it removes the commodity work that absorbs expert compliance professionals' time, so they can focus on the judgment-dependent work that actually requires their expertise.