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 reportable accounts, and, with the entry into force of DAC8, to crypto-asset service providers and operators that fall within the new reporting rules.

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 Kryptowerte-Steuertransparenz-Gesetz (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 is replacing the legacy ELMA upload channel with the BZSt online.portal and its DIP mass-data interface (Digitaler Posteingang), a credentialed, schema-validated programmatic filing route. 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 crypto providers, 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 classification trap that catches newly licensed institutions, considers the DAC8 wave that brings a new cohort of crypto-asset providers 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

Section	Chapter
Section 1	The Three Frameworks FATCA, CRS, and DAC8 — what each requires, who's in scope, and what gets reported.
Section 2	The Classification Trap Why the obligation to classify and run due diligence attaches to your status as a Reporting Financial Institution regardless of what the review finds, and how nil-return rules differ by jurisdiction — Germany does not currently require one.
Section 3	The DIP API Transition How the move from ELMA to the DIP API shifted filing from a compliance browser task to an engineering integration.
Section 4	How Germany Compares With Other EU Jurisdictions Luxembourg, Ireland, the Netherlands — and where the German market sits relative to them.
Section 5	DAC8 and the Wave of Newly Obligated Crypto Providers German crypto-asset service providers and operators facing their first cross-border tax filing obligation under DAC8.
Section 6	The Economics of Building Versus Buying What an in-house DIP API integration actually costs, and why the return on investment is structurally negative.
Section 7	The Datensender Model The German counterpart to the Luxembourg transmitter: legal accountability with the institution, technical execution consolidated.
Section 8	Regfiler How we built a Datensender platform specifically for FATCA, CRS and DAC8 submissions to the BZSt.

---

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 sets tiered fines for reporting violations: up to fifty thousand euros for the categories the statute singles out (Section 28(1) No. 5(b) and Nos. 6 to 20), and up to ten thousand euros in all other cases. For an institution with several thousand reportable accounts spread across multiple jurisdictions, the aggregate exposure on a single deficient filing cycle can still 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 Kryptowerte-Steuertransparenz-Gesetz (KStTG), which entered into force in late 2025. The first reporting period covers the calendar year 2026, with the first filing due by 31 July 2027 under Section 9 KStTG.

The obligated population under Germany’s KStTG is broader than a shorthand reference to MiCAR-licensed CASPs suggests. It covers both Kryptowerte-Dienstleister and Kryptowerte-Betreiber that provide crypto-asset services resulting in exchange transactions for reportable users. Many of these providers have never previously had a cross-border tax reporting obligation. A significant proportion 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 to the BZSt are due by 31 July 2027 for the 2026 reporting period under Section 9 KStTG; other EU jurisdictions operate on their own 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 crypto-provider 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 Classification Trap

Among the most consistently misunderstood points in the entire FATCA and CRS regime is where the obligation comes from. It does not arise from having reportable accounts. It arises from an institution’s status as a Reporting Financial Institution. If you meet that definition, you are required to classify your accounts and carry out the prescribed due diligence — whether or not the review ultimately identifies anyone reportable.

That distinction is what catches newly licensed institutions. Two assumptions do the damage: that an entity is “not really a financial institution” (a classification error), and that “no US clients” means the regime does not apply (which overlooks CRS entirely). Either one lets an institution quietly conclude it has no obligation, when in fact the duty to classify and review attached the moment it met the definition — and, for an institution with an all-European client base, CRS-reportable accounts held by EU tax residents are usually exactly what the review would find.

A word on the nil return, because it is where this obligation is most often misstated. Whether an institution with nothing to report must nonetheless file a nil return is a matter of national choice under the CRS, not a requirement of the standard itself. Some jurisdictions mandate it — Luxembourg has required a nil return for both FATCA and CRS since 2021 — while others do not. Germany currently does not: the BZSt states that no nil or empty report is legally required for either CRS or FATCA where there is no reportable data. That does not lessen the underlying duty. The classification and due-diligence obligations remain, and an institution that never runs the review because it assumed it was out of scope has a genuine exposure — not for failing to file an empty return, but for failing to establish, and document, whether it had anything to report in the first place.

---

3. The DIP Transition

Until recently, FATCA and CRS filings were submitted to the BZSt through ELMA — the Elektronische Massendatenschnittstelle — which operated as a web-based mass-data 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 is transitioning FATCA and CRS reporting to the DIP mass-data interface (Digitaler Posteingang), accessed through the BZSt online.portal. DIP is a programmatic interface that requires machine-to-machine integration. The differences between the legacy and new filing routes are summarised in the table below.

Aspect	ELMA (legacy)	DIP route
Submission method	Manual mass-data upload	REST-based DIP mass-data interface
Authentication	Portal login plus certificate	BZSt online.portal credentials, certificate-based setup, and DIP access-token/client authentication
Schema validation	Post-upload feedback	Structured XSD validation on submission
Error handling	Email notifications	Programmatic response codes
File format	XML upload	XML via programmatic payload
Integration owner	Compliance officer with a browser	Engineering team with an integration

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.

Credential and certificate management add a further layer of operational risk. DIP and BZSt online.portal access depend on credentials, certificates and short-lived access tokens that have to be maintained. A credential problem shortly before a filing deadline can produce 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 are immediate.

Schema validation under DIP is also stricter than was the case under ELMA. The BZSt filing stack depends on procedure-specific XML schemas: FATCA currently references the IRS FATCA XML schema v2.0.1, CRS uses the OECD CRS XML schema v2.0 with the amended CRS/schema transition from 2027, and DAC8 adds the OECD CARF XML schema track. 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.

---

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.

Jurisdiction	Receiving authority	Filing channel	Nil report process	Authorised transmitter model	DAC8 / CARF portal
Germany	BZSt	BZSt online.portal and DIP mass-data interface, with REST endpoints and XSD validation	No mandatory nil return for FATCA or CRS where there is no reportable data; optional empty reporting uses the standard channel	Datensender supported but not widely operationalised; market still maturing	KStTG live; first filing 31 July 2027 for FY 2026
Luxembourg	ACD	Two established channels: Fundsquare e-file and SOFiE; both XML-based	MyGuichet.lu portal: free, government-run, separate simplified flow with LuxTrust signature	Mature transmitter market since 2017; standard practice for funds and most FIs	DAC8 law adopted Mar 2026; first filing 30 Jun 2027
Ireland	Revenue Commissioners	ROS (Revenue Online Service); single portal handles FATCA, CRS and other tax filings	Nil return required via ROS (per Revenue AEOI guidance)	Reporting Entity registration permits filing on behalf of others; widely used	Transposed via amendments to TCA 1997; first reporting follows EU timeline
Netherlands	Belastingdienst	Belastingdienst reporting portals, with ODB publishing DAC8/CARF support materials and validation tooling	Required where the Dutch regime calls for nil reporting; handled through the Dutch reporting process	Service-provider model recognised; credentials issued per reporting setup	DAC8/CARF guidance live; FY 2026 filing due 31 Jan 2027

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 solely to evidence an empty return.

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 financial-institution interactions with the Revenue Commissioners into ROS, the Revenue Online Service. ROS handles FATCA, DAC2-CRS and other tax obligations through one authenticated channel, and Irish AEOI guidance requires nil returns where there are no reportable accounts. The nil return 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: early DAC8 guidance and validation

The Netherlands has positioned itself early on DAC8 readiness, with the Belastingdienst and its ODB support site publishing DAC8/CARF guidance, technical materials and validation tooling in advance of the live filing window. Dutch reporting crypto-asset providers are required to file by 31 January following each reporting year, and the published Dutch material frames DAC8/CARF alongside CRS/DAC2 rather than as an isolated obligation.

This has practical consequences for the build-versus-buy decision. A reporting provider 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, Germany does not provide a separate mandatory nil-return workflow for FATCA or CRS, and the test infrastructure for DAC8 has been more conservatively phased than in the Netherlands.

---

5. DAC8 and the Wave of Newly Obligated Crypto Providers

The implementation of DAC8 represents what is, in practical terms, the largest single expansion of cross-border tax reporting obligations in the past decade. A wave of crypto-asset service providers and operators in Germany will face reporting obligations for the first time. The starting position of many of these entities is materially different from that of an established bank entering a new reporting framework.

Many providers 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, registration analysis, 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. For the 2026 reporting period, the controls need to be in place during 2026 and the first German filing is due by 31 July 2027. Reconstructing the full year retrospectively from transaction logs after year-end is technically feasible, but it 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 many crypto providers is significant. A provider that launched in 2024 with a crypto-native technology stack and a compliance function principally engaged with MiCAR authorisation or operator registration 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.

Cost component	Estimated in-house cost
DIP API integration (one framework)	€40,000–80,000 engineering effort
XML schema implementation (per framework)	€15,000–30,000
Certificate management	€5,000–10,000 per year, ongoing
Schema version updates (annual)	€10,000–20,000 per year
Testing and validation	€10,000–15,000 per year
Total year one (three frameworks)	€150,000–300,000
Total ongoing (annual)	€40,000–70,000

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 crypto providers, 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, a 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 many crypto providers 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, while simultaneously managing MiCAR compliance, operator registration analysis, 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. Regfiler

Regfiler is a filing platform built specifically for FATCA, CRS and DAC8 submissions to the BZSt. It operates as a 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 returns are handled automatically where they are required. Some jurisdictions mandate a nil return when no reportable accounts are found; the platform produces and submits it without manual intervention. Where a jurisdiction such as Germany does not require one, it retains the due-diligence record instead, so the review is evidenced without filing an empty return. 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 crypto providers 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.