Fintech Compliance: Building Regulatory Reporting Infrastructure

Three regulations, one data problem

The regulatory landscape for fintechs operating in the European fintech sector has compressed. MiCA (Markets in Crypto-Assets) is fully applicable since December 2024 for asset-referenced tokens and e-money tokens. DAC8 (the eighth Directive on Administrative Cooperation) requires crypto operators to report transactions to national tax authorities starting January 2026. PSD2 has been in force for years but supervision has intensified, and PSD3 is in the pipeline.

What these three regulations share is a common technical requirement: the ability to aggregate, reconcile, and report transactional data with accuracy, traceability, and within defined deadlines. This is not a compliance problem. It is a data engineering problem.

And most fintechs are solving it with duct tape: manual queries, CSV exports, spreadsheet reconciliations. This works when you process 500 transactions per month. It stops working at 5,000.

What each regulation demands

MiCA requires periodic reports to the national regulator (in Spain, the CNMV or Banco de Espana depending on license type) including: transaction volume, asset reserves, investor protection mechanisms, and operational incident reports. Format and frequency depend on license type, but the trend is toward quarterly reporting with monthly data.

DAC8 requires crypto platforms to report to the tax authority (AEAT in Spain) the transactions of resident users: user identity, transaction type, assets involved, and euro values. It is essentially a Form 720 for crypto. The data volume and required accuracy (reconciliation with KYC data) make automation the only viable option.

PSD2 requires fraud reporting to national authorities, data access through open APIs (open banking), and SCA (Strong Customer Authentication) compliance. The reporting aspect is the obligation to notify security incidents to the regulator within strict deadlines (4 hours for the initial report in major incidents).

Reporting architecture that scales

A regulatory reporting pipeline has four components.

Data aggregation. All transactional data sources (transaction database, KYC system, custody provider, payment gateway) consolidate into a data warehouse or data lake. Aggregation must be continuous, not daily batch, because DAC8 and MiCA require data that can be reconciled at any time. Apache Kafka or an equivalent streaming service feeds a warehouse (BigQuery, Snowflake, Redshift) with minutes of latency.

Reconciliation. Data from different sources must match. Custody balances must agree with recorded transactions. KYC data must be linked to every reportable transaction. Discrepancies must be detected automatically and resolved before the report is generated. A reconciliation job that runs hourly, compares sources, and generates alerts when discrepancies exceed a configurable threshold is the minimum. The alternative is discovering the discrepancy when the regulator asks for explanations.

Report generation. Reports are generated automatically in the format required by each regulator. This means transforming aggregated data to the XML/JSON/CSV schema the authority demands, applying filtering rules (for example, only transactions above a certain threshold for DAC8), and validating the report against specifications before submission. An Apache Airflow or Prefect pipeline with transformation, validation, and generation tasks covers this case.

Audit trail. Every data point that enters a report must be traceable to its source. The regulator can request justification for any figure. The audit trail records: where each data point came from, when it was processed, what transformations were applied, and who (or what process) generated the final report. This is not optional. It is an explicit MiCA requirement and an implicit requirement of any serious regulatory framework.

The cost of not automating

A 3-person compliance team spending 60% of their time preparing manual reports costs roughly EUR 120,000 per year in salaries. Automating the reporting pipeline has an implementation cost of EUR 40,000-80,000 (depending on complexity) and an operational cost of EUR 2,000-5,000 per month in infrastructure and maintenance.

The ROI is not only economic. It is risk reduction. An error in a manual report that goes unnoticed can result in penalties ranging from EUR 500,000 to 5% of annual revenue under MiCA. The cost of automation is insurance with a positive return.

For a concrete example of automated reconciliation in this sector, see our article on real-time payment reconciliation. Fintechs that build their data infrastructure with regulatory reporting as a design requirement (not as an afterthought) have a real competitive advantage: they can scale transaction volume without linearly scaling their compliance team. Those that treat reporting as a manual problem discover, usually painfully, that regulation scales faster than their capacity to comply with it.