EBA Reporting for Fintechs

Most fintechs discover their EBA reporting duties one regime at a time. DORA requires reporting on ICT third-party providers. MiCA requires reporting from token issuers and, in part, from the crypto-asset service providers that support them. Traditional prudential reporting can apply too, usually only if the business holds a credit institution license or is a large investment firm.

Firms usually work out which obligation applies without much trouble. Getting the underlying data into the exact structure a supervisory portal will accept is the actual difficulty. That structure is fixed down to individual fields, and a value that only approximately matches what a template expects still fails. Get it right once, validate it before submission, and every later filing becomes a routine data refresh.

How exacting that structure is becomes clear from a single figure. In their joint summary report on the 2024 dry run of DORA’s Register of Information, the three European Supervisory Authorities found that only 6.5% of the nearly 1,000 participating financial entities passed all 116 data quality checks on first submission. Half of the remaining entities failed fewer than five of those checks. The recorded causes of failure were procedural. Wrong file formats, free text entered where a controlled code was required, and duplicated identifiers accounted for most of them.

One reporting system, many regimes

The EBA runs several reporting regimes, each grounded in its own regulation but sharing a common technical architecture, and fintechs rarely deal with only one for long. A team that has built one submission correctly has already done most of the work needed to build the next.

Traditional prudential reporting means COREP for capital adequacy and FINREP for financial statements. Both sit under the Capital Requirements Regulation and its supervisory reporting technical standards, currently Commission Implementing Regulation (EU) 2021/451. It applies to credit institutions and, above a size threshold set by the Investment Firms Regulation, to the largest investment firms. A payment institution, an e-money institution, and a crypto-asset service provider hold none of those licenses, so COREP and FINREP do not apply.

The Instant Payments Regulation reaches a wider slice of that client profile. Regulation (EU) 2024/886 inserted a new reporting duty into Article 15(3) of the SEPA Regulation (Regulation (EU) No 260/2012). It requires payment service providers offering instant credit transfers in euro to report annually on transfer charges, and specifically on the share of payments they reject because of sanctions and other restrictive measures screening. Commission Implementing Regulation (EU) 2025/1979 lays down the standard templates for that reporting. The duty applies regardless of whether the provider is a bank, a payment institution, or an e-money institution.

DORA and MiCA are the two regimes fintechs encounter most often, because both apply broadly across the sector regardless of license type. Neither sits inside the COREP and FINREP technical package. DORA’s Register of Information is reported under its own dedicated Implementing Technical Standard, Commission Implementing Regulation (EU) 2024/2956. MiCA’s asset-referenced-token and e-money-token reporting runs under Commission Implementing Regulation (EU) 2024/2902 instead.

These regimes share the same Data Point Model logic, the same XBRL-CSV submission format, and the same multi-stage validation sequence, applied separately to each one. That shared infrastructure matters more than any single regulation on its own.

Who actually has to report

DORA casts the widest net of any of these regimes. Article 2 covers credit institutions, payment institutions, e-money institutions, investment firms, crypto-asset service providers, and insurers, among others. Most licensed fintechs fall somewhere inside it.

Size does not shrink that scope as much as firms expect. Article 16 gives a simplified ICT risk management framework to a specific, narrow list of firms, among them small and non-interconnected investment firms and certain exempted payment institutions, credit institutions, e-money institutions, and occupational pension providers. Being a microenterprise does not put a firm on that list by itself. DORA treats ”microenterprise” and this narrow list as separate categories throughout, so a microenterprise credit institution or crypto-asset service provider gets no relief unless it independently qualifies under one of the listed categories.

Firms that qualify for that relief, and read it as also covering the Register of Information, are wrong. The EBA’s own Single Rulebook Q&A confirms that Article 28(3) imposes the register duty with no exception, so a firm exempted from the general risk management rules still has to build and maintain the register. Proportionality only changes how complex that register needs to be for a firm with few ICT suppliers.

MiCA applies to issuers of asset-referenced and e-money tokens and to the crypto-asset service providers that support them. Once an asset-referenced token’s issued value exceeds 100 million euros, Article 22 requires the issuer to report quarterly on the token’s value, its reserve, and its transaction volumes. The competent authority can also extend that duty to smaller tokens at its own discretion.

A separate and much higher bar applies under Article 43, where the EBA assesses whether a token has become significant based on factors including the number of holders, the size of the reserve, and daily transaction volumes. A token that crosses into significant territory moves from national supervision to direct EBA oversight.

A crypto-asset service provider handling a reportable token carries real exposure here even though the filing duty formally sits with the issuer. That same article requires the CASP to supply the issuer with the transaction data needed to compile the report, on the issuer’s reporting timeline. A CASP that waits to be asked for this data risks discovering, close to the filing deadline, that its own records and turnaround time determine whether the issuer’s report is accurate and on time.

The Instant Payments Regulation reaches payment service providers, banks included, that offer instant credit transfers in euro. Between DORA, MiCA, and the Instant Payments Regulation, most fintech business models are covered without COREP or FINREP ever entering the picture, unless the firm also holds a banking license.

A fintech that touches payments, e-money, or crypto-assets in any meaningful way should assume some EBA reporting duty applies. Which regime, and at what level of detail, depends on license type, transaction volumes, and how a token or service is structured.

Why the data gets collected

National competent authorities, such as Finland’s FIN-FSA, supervise to protect the stability of the financial system and the interests of consumers and investors. Their supervision works by comparing an entity’s risk profile against its peers and against its own history over time. Comparisons like that only work if the data arrives in the same structure from every firm, on the same fields, at the same intervals.

At EU level, the EBA uses aggregated data for specific, identifiable purposes. DORA requires every in-scope entity to maintain a register of its ICT contracts and providers. National regulators feed that combined dataset upward, and in November 2025 the ESAs used it to name the first nineteen ICT providers designated as critical under DORA. That designation means a regulator concluded the provider’s failure would pose enough concentration risk to the financial system to justify direct EU-level oversight.

MiCA applies the same logic to tokens. Circulating value, market capitalization, and transaction volume figures feed directly into the significance assessment, which decides whether a token remains under national supervision or moves to the EBA. The quarterly filings that smaller tokens already submit build the baseline that assessment gets compared against.

COREP and FINREP exist for a more familiar reason. They let supervisors see capital ratios, exposure concentrations, and balance sheet positions before solvency risk becomes a live problem. Instant Payments data serves a narrower, consumer-facing purpose. It lets the EBA and the European Commission verify that payment providers are honoring the price parity the regulation requires between standard and instant transfers, and lets supervisors see how much sanctions screening is actually blocking.

How a submission actually gets built

Submission is required in XBRL-CSV, a structured, machine-readable format profiled separately for each framework. XBRL-CSV is a rendering of the EBA’s Data Point Model, EBA’s own data dictionary, which defines every reportable data point as a table, a metric, and a set of dimensions, independently of any file format. EBA moved from XBRL-XML to XBRL-CSV in 2021, and that packaging has stayed stable since. What does get refreshed regularly is the dictionary itself, most recently at the end of 2025 under reporting framework 4.2 (DPM 2.0). A register or reporting engine built on top of that dictionary, rather than hard-coded to a specific taxonomy release, absorbs those updates with far less rework.

A submission package is a ZIP archive with a fixed internal structure, including metadata, a filing-indicators file naming which templates are included, and one CSV file per reported table. Every field must match the published taxonomy exactly, down to field names, data types, permitted codes, and the relationships that must hold between tables.

For DORA, and for COREP and FINREP, a firm submits to its national competent authority, such as FIN-FSA’s own reporting portal. The authority forwards the data to the EBA’s central EUCLID infrastructure afterward. MiCA reporting and Pillar 3 disclosures for larger institutions run through EUCLID’s ERRP platform directly. Either way, the receiving system validates the package automatically before any supervisor reviews the content.

DORA’s Register of Information spans fifteen interlinked tables, more than two hundred fields, and 117 EBA validation rules, up slightly from the 116 checks used in the 2024 dry run as the ruleset was refined before live reporting began. A contract reference, a provider identifier, or a function identifier has to match exactly across every table it appears in, and a single mismatched character cascades into every downstream record that depended on it.

DORA separately requires reporting at least yearly to the competent authority on the number of new ICT arrangements, provider categories, contract types, and services involved, wording that reads like a second, standalone report on top of the register itself. The EBA has confirmed that the yearly submission of the register generally satisfies that requirement too.

Validation itself runs in stages. A technical check of the package structure comes first, followed by Data Point Model and business rule checks, followed by external checks such as verifying a Legal Entity Identifier against the GLEIF database. Teams that treat these stages as interchangeable often fix a problem at the wrong stage, since the actual defect occurred earlier in the sequence than the error message suggests.

The 2024 dry run flagged the same handful of causes behind most failures. Submissions arrived in the wrong format, free text got used where a controlled code was required, mandatory fields were left blank, and, specific to DORA, sub-outsourcing tables were left largely empty because gathering supply chain data from providers takes longer than most firms expect.

The same architecture, with different tables and codes, governs Instant Payments reporting and MiCA’s filings, and a validation failure in any of them usually comes down to a code that does not exist in the allowed list, a mandatory field left blank, or an identifier that does not match across linked tables. When a package fails, the correction happens at the package level, and the whole thing gets resubmitted as a unit.

Reporting continues after submission

DORA’s register needs continuous upkeep throughout the year, including timely notice to the competent authority of any planned new arrangement supporting a critical or important function, or of a function becoming critical or important, on top of the yearly submission discussed above. MiCA’s quarterly reporting continues on the same cycle for as long as a token stays above the threshold, and the Instant Payments Regulation’s charge and rejection reporting repeats every 12 months.

That same cross-table consistency has to survive every update the register goes through during the year. A provider’s identifier that changes partway through the year has to be corrected in every table that references it, or the next submission fails a check that has nothing to do with the substance of the change. The EBA’s own Q&A guidance treats a blank key field the same way, as a data quality failure. Where a field genuinely has no applicable value, the literal text ’Not Applicable’ has to go in its place, because an empty key breaks the cross-table matching the whole register depends on.

Contract terms, provider identifiers, and criticality assessments usually live with procurement, vendor management, and risk separately, and none of those teams is naturally responsible for keeping identifiers consistent across fifteen linked tables and two hundred fields. A firm that keeps a single source for each provider’s identifier, with every table referencing that source, only has to update the source each reporting cycle. A firm that retypes the same identifier into every table by hand each cycle risks a mismatched entry somewhere in thousands of fields.

If you are still working out which of these obligations applies to your business, need help building the package itself, or want a second opinion on one before you send it, our team at Nordic Law is happy to help. In our own practice, we work with a reporting engine built directly on the EBA’s Data Point Model to handle that mapping, keeping a client’s submissions consistent as the taxonomy changes.

Our Junior Trainee Vilhelmi Korhonen took part in writing this article.