The FATCA, CRS and DAC8 Filing Gap

Executive Summary

Automatic exchange of financial account information has stopped being a topic that concerns only large international banks. It is now an annual filing obligation that applies to every BaFin-supervised institution holding or managing accounts for non-residents, and, with the entry into force of DAC8, to every Crypto-Asset Service Provider operating under MiCAR in the European Union.

Three overlapping frameworks govern cross-border tax reporting for German institutions today. FATCA, the United States Foreign Account Tax Compliance Act, requires reporting on US persons. CRS, the OECD Common Reporting Standard implemented in Germany under the Finanzkonten-Informationsaustauschgesetz (FKAustG), extends equivalent obligations to more than one hundred participating jurisdictions. DAC8, transposed in Germany under the Kryptowertetransparenzgesetz (KStTG), applies the same model to crypto-asset transactions. Each framework reports to the Bundeszentralamt für Steuern, each uses a distinct XML schema with its own validation rules, and each carries financial penalties for late, missing or inaccurate filings.

The infrastructure required to meet these obligations has changed materially in recent years, and the practical implication is not yet fully understood within compliance functions. The BZSt has retired the legacy ELMA upload portal in favour of the DIP API, a certificate-authenticated, schema-validated programmatic interface. Compliance officers who were previously able to upload an XML file through a browser now depend on engineering capacity to build and maintain the integration. Institutions newly entering the market, particularly licensed FinTechs and CASPs, often have no reporting infrastructure of any kind and limited internal awareness of the obligation.

This paper sets out the three frameworks in turn, examines the technical infrastructure now required to file, places the German position alongside that of comparable EU jurisdictions, addresses the nil reporting trap that catches newly licensed institutions, considers the DAC8 wave that will bring approximately five hundred newly obligated CASPs into scope from the 2026 reporting year, and concludes with the build-versus-buy economics that have shifted the question of how to file in a particular direction.

What's inside

1. The Three Frameworks

1.1 FATCA: reporting on US persons

The Foreign Account Tax Compliance Act was enacted by the United States in 2010 and took practical effect from 2014. It requires Foreign Financial Institutions to identify, document and report financial accounts held by US persons to the US Internal Revenue Service. Germany implements the obligation through a Model 1 Intergovernmental Agreement, under which German institutions report to the BZSt and the BZSt transmits the consolidated data to the IRS.

The set of obligated institutions is broader than is commonly assumed. It includes banks, custodians, certain insurance undertakings, investment funds, and FinTechs offering deposit or custodial accounts. A number of entities that do not consider themselves financial institutions in the colloquial sense are nevertheless captured by the FATCA definition, and the consequences of overlooking that classification surface only when a regulator or correspondent bank asks the question.

The reporting content for each US person account holder includes name, address, US Taxpayer Identification Number, account number, year-end account balance or value, and the gross amounts of interest, dividends and other income credited to the account during the reporting period. US person status is established through a defined set of indicia, including US place of birth, US residential or mailing address, US telephone number, and US citizenship or tax residency. The annual filing to the BZSt is generally due by 31 July for the preceding calendar year, with onward transmission to the IRS by 30 September.

The penalty regime under FATCA is structured rather differently from a typical administrative fine. An institution that fails to file, or that files materially inaccurate data, can be classified as a non-participating FFI. The practical consequence is a thirty per cent withholding tax on US-source payments routed through the institution, which in commercial terms removes its ability to operate in US dollar clearing. The administrative penalty is therefore secondary to the operational consequence.

1.2 CRS: the global automatic exchange

The Common Reporting Standard, developed by the OECD and endorsed by the G20 in 2014, is the multilateral counterpart to FATCA and is implemented in Germany through the FKAustG. More than one hundred jurisdictions participate, and the German obligation extends to identifying and reporting accounts held by tax residents of any participating jurisdiction. The category of obligated institutions tracks FATCA closely, but the jurisdictional scope is considerably wider.

Reporting under CRS requires similar data points to FATCA, with two differences worth noting. The TIN reported is that of the account holder’s jurisdiction of tax residence rather than the United States, and the data must be partitioned by jurisdiction. An institution with reportable accounts across, for example, fifteen participating jurisdictions produces fifteen separate data sets within its annual filing. The annual filing to the BZSt is due by 31 July for the preceding calendar year, with onward transmission to participating jurisdictions through the EU Common Communication Network or the relevant bilateral channels.

Section 28 FKAustG provides for fines of up to fifty thousand euros for each reporting violation. For an institution with several thousand reportable accounts spread across multiple jurisdictions, the aggregate exposure on a single deficient filing cycle can be substantial, and is most often realised when validation errors in the submitted data set are identified after the deadline has passed.

1.3 DAC8 and the KStTG: crypto-asset reporting

Directive (EU) 2023/2226 on Administrative Cooperation, commonly referred to as DAC8, extends the automatic exchange of information regime to crypto-asset transactions. Germany has transposed the directive through the Kryptowertetransparenzgesetz, which entered into force in late 2025. The first reporting period covers the calendar year 2026, with filings falling due in 2027.

The obligated population under DAC8 is the set of Crypto-Asset Service Providers as defined under MiCAR, which includes crypto exchanges, custodial wallet providers and brokers of crypto-asset transactions. Approximately five hundred entities in Germany fall into this category, the great majority of which have never previously had any cross-border tax reporting obligation. A significant proportion of them were not classified as financial institutions under the pre-DAC8 definitions and have therefore never engaged with the BZSt at all.

The reportable data set for each crypto user resident in a participating jurisdiction includes name, address, TIN, date of birth, the type of each crypto-asset transacted, the aggregate transaction value, the aggregate number of transactions, and the fair market value of transfers and exchanges. The data is reported to the BZSt under the OECD Crypto-Asset Reporting Framework XML schema. The first filings are due by 31 January 2028 for the 2026 reporting period, although certain jurisdictions are expected to operate on accelerated timelines.

A further structural point is worth flagging. Unlike FATCA and CRS, which were designed to capture non-resident account holders, DAC8 explicitly extends to domestic transactions. A German exchange must report on its German users as well as its EU and third-country users, which is a meaningful expansion of scope relative to the assumptions on which most CASP compliance programmes were originally built.

The penalty framework in the KStTG mirrors the structure of the FKAustG, with fines per violation. The Federal Ministry of Finance has indicated, both in its consultation responses and in published guidance, that enforcement is expected to be active from the first filing cycle, reflecting the political weight that crypto-asset taxation transparency has acquired at EU level.

2. The Nil Reporting Trap

Among the most consistently misunderstood obligations in the entire FATCA and CRS regime is the requirement to file a nil report. An institution that has carried out the prescribed due-diligence procedures and identified no reportable accounts is not relieved of the filing obligation. It is required to submit a filing that affirmatively states that no reportable accounts were identified.

The reasoning is straightforward once it is understood. The obligation to file does not arise from the existence of reportable accounts. It arises from the institution’s status as a Reporting Financial Institution. The nil report is the evidentiary record that the due-diligence procedures were performed: that the customer base was reviewed, the identification rules were applied, and the determination that no accounts crossed the reporting threshold is a documented outcome rather than an untested assumption. The absence of a filing leaves no such record, and is treated by the regulator as evidence that the review did not take place.

This is a particular issue for newly licensed FinTechs, payment institutions and CASPs in their first year of operation, where the assumption that an absence of US person customers or non-resident account holders implies an absence of any filing obligation is widespread. The BZSt has issued reminders to newly registered institutions on this point, and consultancies serving the German FinTech sector consistently report the same omission pattern across cohorts.

3. The DIP API Transition

Until recently, FATCA and CRS filings were submitted to the BZSt through the ELMA portal, which stood for Elektronische Massendaten-Annahme and operated as a web-based upload interface. Compliance officers logged in, submitted an XML file, and received subsequent feedback by email. Registration and a certificate were required, and a basic understanding of the schema was necessary, but the process was, in operational terms, a human-driven workflow.

The BZSt has now transitioned to the Daten-Import-Portal API, generally referred to as DIP. DIP is a programmatic interface that requires machine-to-machine integration. The differences between the two interfaces are summarised in the table below.

The transition is more consequential than the technical changes might suggest, because it shifts the locus of the filing process from the compliance function to the technology function. A compliance officer who previously uploaded a file once a year now depends on an engineering team to build, test and maintain an API integration on which the institution’s filing position depends. For an institution carrying both FATCA and CRS obligations, the engineering effort is disproportionate to the business value of the deliverable, and yet the obligation itself is non-negotiable.

Certificate management adds a further layer of operational risk. The DIP API requires client certificates that must be renewed on a defined cycle. A certificate that is allowed to expire before a filing deadline produces a rejected submission and, depending on the timing, a missed deadline. The administrative simplicity of the legacy portal is not preserved under DIP, and the consequences of routine operational lapses, particularly around certificate renewal, are immediate.

Schema validation under DIP is also stricter than was the case under ELMA. The BZSt publishes XSD schemas based on the IRS FATCA XML Schema v2.0 and the OECD CRS XML Schema v2.0, and submissions that would have passed ELMA’s informal validation routinely fail DIP’s real-time checks. The most common rejection reasons fall into a small number of categories: TIN formatting that does not conform to the jurisdiction-specific validation rules, jurisdiction codes that have been updated since the previous filing cycle, and account balance fields submitted with data types or precisions that the schema does not accept. DAC8 introduces a third schema, based on the OECD Crypto-Asset Reporting Framework, which adds a further integration track for institutions operating across all three frameworks.

4. How Germany Compares With Other EU Jurisdictions

It is worth setting the German position alongside that of comparable EU member states, because the question of how to file is one on which member states have made meaningfully different choices. The frameworks themselves, FATCA, CRS and DAC8, are uniform across the European Union by design, but the channels through which institutions submit, the existence and form of nil reporting flows, the maturity of the authorised-transmitter ecosystem, and the readiness of DAC8 portals all vary. The summary below is based on currently published guidance from the relevant national authorities.

Several patterns emerge from the comparison that are worth drawing out, because they illuminate where the German market currently sits and where it is likely to move.

4.1 The Luxembourg model: a mature transmitter ecosystem

Luxembourg is the clearest example in the European Union of a jurisdiction in which the authorised-transmitter model has been treated as the default rather than the exception. The Administration des contributions directes accepts FATCA and CRS reporting through two recognised channels, Fundsquare e-file and SOFiE, both of which have operated as production transmitters since 2017. The arrangement reflects the structure of the Luxembourg fund industry, in which a small compliance function within a fund or ManCo would not be expected to operate a direct integration with the tax authority, and where the service-provider model is well established for almost every operational function.

A further design choice that distinguishes Luxembourg is the explicit separation of the nil-reporting flow. Reporting Financial Institutions that have no reportable accounts can submit their nil returns through MyGuichet.lu, the government-operated business portal, free of charge and signed using a LuxTrust certificate. The full XML reporting flow remains with the transmitters, but the most common case for smaller institutions, namely the nil return, is handled through a simpler government channel. The result is that institutions that have no reportable accounts in a given year are not forced to procure transmitter services they do not need, and the rate of nil-report omission is correspondingly lower than in jurisdictions where the only channel is the full XML pipeline.

The penalty framework reinforces the point. A failure to submit any return, including a nil return, attracts a fixed fine of ten thousand euros, and breaches identified through audit can produce fines of up to two hundred and fifty thousand euros. The combination of an accessible nil-reporting channel and an explicit, published penalty schedule has produced a market in which compliance teams treat the filing as routine rather than exceptional.

4.2 The Irish model: one portal, multiple obligations

Ireland has taken a different approach, consolidating all financial-institution interactions with the Revenue Commissioners into a single platform. The Revenue Online Service (ROS) handles FATCA, DAC2-CRS and other tax obligations through one authenticated channel, with a Reporting Entity Registration that is portable across reporting types. The auto-generated nil return, with a published filer-category dropdown, is built into the same workflow rather than separated into a different portal.

The advantage of this design, from the perspective of an obligated institution, is operational simplicity. A single registration and a single login support multiple reporting obligations, and a compliance officer encountering FATCA for the first time is not navigating a separate ecosystem of transmitters and credentials. The disadvantage is that the platform is government-built and therefore evolves on a government timetable; the technical specifications and the user interface are designed to be acceptable rather than optimal, and institutions with high reporting volumes have generally chosen to use authorised filers regardless.

4.3 The Dutch model: an ODB portal designed around DAC8

The Netherlands has positioned itself early on DAC8 readiness, with the Belastingdienst publishing a dedicated ODB Digital Messaging portal for DAC8 and CARF that includes a Validation Test Service made available in advance of the live filing window. Dutch RCASPs are required to file by 31 January following each reporting year, and the integrated CRS/DAC2/DAC8/CARF framing on the ODB portal reflects an explicit policy choice to present the four reporting regimes as a single operational pipeline rather than as separate tracks.

This has practical consequences for the build-versus-buy decision. A CASP filing in the Netherlands has access to a pre-go-live validation environment, published technical specifications and a defined support channel through which integration questions can be raised before the first live submission. The starting position of an institution preparing for its first DAC8 filing in Amsterdam is materially better resourced than that of an equivalent institution in Frankfurt, where the equivalent test infrastructure is less developed at the time of writing.

4.4 What the comparison says about Germany

The German market sits between these models. The technical infrastructure is in place, the legislation is enacted, and the BZSt operates a functional API. What is less developed than in Luxembourg or the Netherlands is the surrounding ecosystem: the authorised-transmitter market is recognised in principle but has not yet matured into a default channel, the nil-reporting flow runs through the same DIP API as the full reporting flow rather than through a simplified government portal, and the test infrastructure for DAC8 has been more conservatively phased than in the Netherlands.

5. DAC8 and the Wave of Newly Obligated CASPs

The implementation of DAC8 represents what is, in practical terms, the largest single expansion of cross-border tax reporting obligations in the past decade. Approximately five hundred CASPs in Germany, licensed or registered under MiCAR, will face reporting obligations for the first time. The starting position of most of these entities is materially different from that of an established bank entering a new reporting framework.

Most CASPs in scope have never filed with the BZSt for any purpose. They have no existing FATCA or CRS infrastructure, in many cases because they were not classified as financial institutions under pre-DAC8 definitions and were not therefore obligated. Their engineering capacity is concentrated on blockchain infrastructure, custody design and trading systems rather than tax reporting integrations. Their compliance teams are typically composed of two to five people whose recent attention has been absorbed by MiCAR authorisation and AML programme buildout, and who do not, as a rule, have FATCA or CRS reporting experience.

The work required for the first reporting period is substantial. Customer tax-residency self-certification has to be collected and stored. TINs have to be validated against jurisdiction-specific formats. Crypto-asset transactions have to be aggregated by user and by jurisdiction in a manner consistent with the CARF schema. XML output has to be generated in conformance with that schema. The DIP API integration has to be built, tested and certified. All of this needs to be operational by 1 January 2027 if the full 2026 reporting period is to be captured contemporaneously, rather than reconstructed retroactively from transaction logs after the year-end. Retroactive reconstruction is technically feasible but is both more difficult to execute correctly and weaker as an audit trail.

The gap between the regulatory expectation and the operational starting point of most CASPs is significant. A provider that launched in 2024 with a crypto-native technology stack and a compliance function principally engaged with MiCAR authorisation may not have given any considered thought to annual cross-border tax reporting infrastructure. The DAC8 filing deadline will arrive irrespective of whether the infrastructure has been built.

6. The Economics of Building Versus Buying

For an institution considering whether to build FATCA, CRS and DAC8 reporting infrastructure in-house, the underlying economics are worth setting out explicitly. The estimates below reflect the experience of mid-tier German institutions and FinTechs that have either completed an in-house build or have started one and reconsidered.

These figures assume an engineering team that is competent in XML schema integration, certificate-based authentication and the specifics of BZSt requirements. In most FinTechs and CASPs, the realised cost is meaningfully higher than the estimate, because the learning curve is steep, the BZSt documentation is in German, and the schema edge cases consume a disproportionate share of debugging time relative to the surface area of the deliverable.

The output of the investment is two or three XML filings per year. The infrastructure sits idle for fifty weeks of every year and requires maintenance whenever the BZSt updates the API, the schema, or the certificate requirements. The return on investment, evaluated against any conventional financial measure, is negative. The reason institutions undertake the work nevertheless is that the alternative, namely non-compliance, carries financial penalties, reputational damage and, in extreme cases, exposure to loss of licence.

7. The Datensender Model

German tax infrastructure has long supported the concept of a Datensender, an authorised third party that submits filings on behalf of obligated entities. The model is well established for domestic tax filings, and the BZSt DIP API supports it explicitly for FATCA, CRS and DAC8 submissions. It is also the German counterpart to the Luxembourg transmitter model and the Irish reporting-entity arrangement, although it has not yet matured to the same level of market default in either jurisdiction.

Under the Datensender model, the obligated institution retains legal responsibility for the accuracy and completeness of the underlying data. The Datensender handles the technical submission chain, which comprises the DIP API integration, certificate management, XML schema generation and pre-submission validation. The BZSt receives the filing from the Datensender but attributes it to the obligated institution, and the institution receives the filing confirmation through the Datensender. The legal accountability and the technical execution are separated, and the latter is consolidated.

The economic logic of the model follows directly. A single Datensender serves a portfolio of institutions and amortises the engineering and maintenance cost of the integration across the client base. The institution’s compliance team retains the work that requires institutional knowledge, namely ensuring that customer tax residency information is accurate, that TINs are valid, and that account balances are calculated correctly. The work that does not require institutional knowledge, namely the technical delivery of correctly formatted XML through a certificate-authenticated API, is handled centrally.

For the five hundred or so CASPs facing their first DAC8 filing, the model is not principally a matter of convenience. It is, in practical terms, the only viable path to compliance within the available timeline. Building a DIP API integration from a standing start in twelve months, while simultaneously managing MiCAR compliance, AML programme buildout and ordinary business operations, is not a realistic plan for a compliance team of two to five people, irrespective of the engineering quality of the underlying institution.

8. WBP Reporting

WBP Reporting is a filing platform built specifically for FATCA, CRS and DAC8 submissions to the BZSt. It operates as an authorised Datensender and handles the full technical filing chain. Customer and account data are ingested through structured import or API integration. Tax residency is classified and TINs are validated against the relevant jurisdiction-specific formats. Reportable accounts are identified against the schema rules. XML output is generated in conformance with the IRS FATCA, OECD CRS and OECD CARF schemas. Submission is made through the DIP API with certificate management handled centrally, and the institution receives a filing confirmation together with a complete audit trail.

Nil reporting is generated automatically. Where no reportable accounts have been identified for a given framework or jurisdiction, the platform produces and submits the nil report without manual intervention, eliminating the most common compliance breach we encounter in newly licensed institutions. Schema version updates, DIP API changes and certificate renewals are managed centrally, which removes the per-institution maintenance burden that drives the ongoing cost of an in-house build.

For CASPs preparing for their first DAC8 filing, the platform provides a guided onboarding process that maps existing crypto-asset transaction data to the CARF schema requirements, identifies gaps in customer tax residency documentation, and produces a filing-readiness assessment in advance of the deadline rather than at it.

Mohan Paranthaman and Karthik Iyengar are co-authors at WBP RegTech, which builds the methodology layer and WBP Reporting for BaFin-supervised institutions.