EBA reporting for fintechs, and why the first filing usually fails

Of the roughly 1,000 financial entities that took part in the 2024 dry run of DORA’s Register of Information, 6.5% passed all 116 data quality checks on first submission. The three European Supervisory Authorities published that figure in their joint summary report. Half of the entities that failed missed fewer than five checks.

Almost none of those failures were substantive. Mandatory fields left blank accounted for the overwhelming majority. Invalid legal entity identifiers came next. And 92 submissions never reached the content checks at all, because the file itself arrived in the wrong format or under the wrong name. Most of the failed filings we see die at that same first stage, before a supervisor has read a single number.

Working out which EBA obligation applies to a fintech is rarely the hard part. The difficulty is getting the underlying data into the exact structure a supervisory portal will accept, a structure fixed down to individual fields, where a value that only approximately matches what a template expects still fails. Build it correctly once and every later filing becomes a data refresh.

In this article, we set out which EBA reporting regimes reach a fintech, how a submission is built and validated, and where filings fail in practice.

One reporting system, many regimes

The EBA runs several reporting regimes, each with its own regulation behind it, and fintechs rarely deal with only one for long. What they share is the machinery. The same data dictionary defines the fields, the same structured CSV format carries them, and the same staged validation decides whether a package is accepted. A firm that learns it once carries that knowledge into every regime it later falls under.

Traditional prudential reporting means COREP for capital adequacy and FINREP for financial statements, both under the Capital Requirements Regulation and Commission Implementing Regulation (EU) 2021/451. They reach credit institutions and the largest investment firms. A payment institution, an e-money institution, and a crypto-asset service provider hold none of those licenses, so neither applies to them.

The Instant Payments Regulation reaches further. Regulation (EU) 2024/886 inserted a reporting duty into Article 15(3) of the SEPA Regulation, and payment service providers offering instant credit transfers in euro now report every 12 months on the charges they levy and on the share of payments they reject because of sanctions screening. The duty applies 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.

Who actually has to report

DORA casts the widest net of any of these regimes. Article 2 covers credit institutions, payment institutions, account information service providers, e-money institutions, investment firms, crypto-asset service providers and insurers, among others. It expressly includes payment institutions and e-money institutions holding a waiver under PSD2 or the E-Money Directive.

That list is narrow. It reaches small and non-interconnected investment firms and certain exempted payment institutions, credit institutions and e-money institutions. Being a microenterprise does not put a firm on it. The relief also stops at the risk management rules. Proportionality shapes how complex that register is, and a firm with few ICT suppliers keeps a simpler one.

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 number of holders, its issued value and reserve of assets, and its daily transaction counts and values. 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 on criteria covering holders, reserve size and daily transactions. A token that crosses it moves from national supervision to direct EBA oversight. The quarterly filings a smaller token already submits build the baseline that assessment is measured against.

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.

Between DORA, MiCA, and the Instant Payments Regulation, most fintech business models are covered without COREP or FINREP entering the picture. A fintech that touches payments, e-money, or crypto-assets should assume some EBA reporting duty applies. Which one, and at what level of detail, turns on the license, the transaction volumes, and how a token or service is structured

Supervision works by comparison, so the data has to arrive in the same structure from every firm. National regulators feed the combined DORA registers upward, and in November 2025 the ESAs used them to designate the first nineteen critical ICT providers. The list includes Amazon Web Services, Microsoft, Google Cloud, IBM, Oracle and SAP. Your own register is one of the inputs to that decision.

How a submission actually gets built

A firm files in a structured, machine-readable CSV format. Most regimes use XBRL-CSV. DORA’s Register of Information uses a plain CSV rendering of the same table structure, so its files open like an ordinary spreadsheet. It spans fifteen interlinked tables and around 120 fields, and nothing about the checks that run against it is clever. They compare strings.

Underneath both sits the EBA’s Data Point Model, the data dictionary that defines every value a firm can be asked to report, independently of any file format. The dictionary is an actual database. Every template, every row and column, and every permitted code in every framework comes out of it, and the EBA now publishes one consolidated version of it covering all current releases.

A firm declares, template by template, what it is reporting and what it is deliberately not reporting. Those declarations decide which validation rules run against the package at all. Every field must then match the published taxonomy exactly, down to the permitted codes and the relationships that must hold between tables.

Some of the rules are counterintuitive. Certain yes-or-no fields may only ever be reported as true, so an explicit false is a format error and the way to say no is to say nothing. A key field with no applicable value is the opposite. Leaving it blank fails, and the literal text ‘Not Applicable’ goes in its place, because a blank key breaks the register’s cross-table matching.

DORA reports go to the national competent authority, such as FIN-FSA’s own reporting portal, which forwards them to the EBA’s central EUCLID infrastructure. MiCA reporting runs through EUCLID directly. Whichever route a package takes, the receiving system validates it automatically before any supervisor reads a line of the content.

A contract reference, a provider identifier, or a function identifier has to match exactly across every table it appears in. One mismatched character cascades into every downstream record that depended on it. The register looks like a spreadsheet and behaves like a relational database, and firms that treat it as the former discover the difference late. When a package fails, the correction happens at the package level, so the whole archive is rebuilt and goes back as a unit.

Validation runs in stages, and the first one is structural. The file name is parsed against the contents, so a hand-renamed archive fails before anything inside it is read. Data Point Model and business rule checks follow. Many templates repeat once per significant currency, and the sum checks hold inside each copy, so a firm that consolidates currencies first fails rules that are individually correct.

The EBA publishes the full consolidated list of validation rules as a downloadable file, and the taxonomy is standard XBRL. A firm can therefore reproduce the receiving system’s structural and format checks on its own machine before it sends anything. The open-source Arelle processor with the EBA’s plugin is what most practitioners use for it.

The work does not stop at 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 cross-table consistency has to survive every update the register goes through during the year. A provider identifier that changes in March 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. Nobody notices until the filing is rejected.

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 more than a 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.

Lastly

The dictionary keeps moving. It is refreshed roughly once a year, and the next release is in draft now. That release model decides how much work each new taxonomy costs a firm. A reporting engine that reads the dictionary absorbs most of a new release as a data refresh. An engine hard-coded to one release has to be re-engineered every time the EBA publishes another one.

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.