The situation, in four facts
| 01.01.2026 | Collection duty running: crypto-asset service providers have been recording user and transaction data since the start of the year (KStTG). |
| 31.07.2027 | First report to the BZSt, covering reporting period 2026. |
| CARF XML v1.5 | The prescribed format (BMF letter of 14.01.2026). No form-based route has been published. |
| 100 | Crypto-asset service providers authorised in Germany under MiCAR, by far the largest pool in the EEA. We list them individually in the CASP register. Crypto-asset operators without a MiCAR authorisation that are resident or doing business in the EU must report as well. |
Legal basis this page works from: the Kryptowerte-Steuertransparenzgesetz (KStTG), the BMF letter of 14.01.2026 on the CARF reporting format, the BZSt record-format specification (dated 17.11.2025) and the communication manual (version 1.0, dated June 2026). The sourced individual answers are in the facts; a file can be checked beforehand in the validator.
What you get, step by step
| Step | Stablewerk | Stays with you |
|---|---|---|
| Self-certification | A form per user and per entity with up to ten controlling persons, mandatory fields checked, gaps chased with a due date. | Collecting it and having it signed. |
| TIN and residency | Check digits for DE, BE, NL, ES, SE, FI, PL, HR, CZ from the authorities' own texts; structure for the rest of the EU, GB and CH; every finding with its source. | Queries back to the user. |
| Partner states | Per third state, the status of CARF agreements with source and date; your decision is recorded with its reasoning. | The decision. |
| Aggregation and XML | Acquisitions, disposals, transfers per user and crypto-asset under the schema's enumerations; CARF XML 1.5, checked against the OECD schema. | The transaction data as CSV. |
| DIP envelope and signature | The unsigned delivery in the BZSt envelope, checked against dip.xsd, with its SHA-256; a synthetic test delivery first. | Signing with your own certificate, uploading in DIP, marking it sent. |
| Corrections | Correction and cancellation reports with an unambiguous reference to the delivery the BZSt actually holds; a correction ledger per record. | The changed data. |
What the workflow covers
The XML is the last link of a chain that starts much earlier. The workflow we are building follows the chain in the order it actually occurs in operation:
1. Due diligence & self-certifications. Reporting starts long before the XML: collecting self-certifications, sanity-checking residencies and TINs (tax identification numbers), chasing gaps. That is the real workload, and it runs all year.
2. Consolidating transaction data. Acquisitions, disposals, transfers per user and crypto-asset, aggregated the way the law prescribes, from the systems where they actually live.
3. Validation before filing. An XML the BZSt rejects is not a report. Structural and plausibility checks against the CARF schema before anything leaves the house.
4. CARF XML & the corrections cycle. Producing the file for the DIP (Digitaler Posteingang, the BZSt's mass-data interface), inside the BZSt envelope with its transfer ticket, and the part nobody talks about: corrections and cancellations when data changes after the fact, referencing the delivery the BZSt actually received.
5. Partner states outside the EU. EU residents are reported by the law itself. For third states it requires a qualifying agreement (KStTG section 1(13) and (21)), and no official list exists yet. Stablewerk shows per state what is on record, and you record your decision with its source.
For tax firms
Many smaller reporting entities will hand the task to their tax firm. Stablewerk is built for the reporting company, and the tax firm works inside it: one adviser, many clients, one report per client to run, check and file. If your tax firm serves crypto clients and DAC8 is rolling toward you, talk to us.
What a crypto mandate costs the firm: the calculator
What the DAC7 precedent says about enforcement
DAC7, the directly comparable reporting duty for platform operators, has applied since 2023. Answering a parliamentary question, the federal government published its enforcement figures (Bundestag Drucksache 20/14937, 10.02.2025): Germany transmitted 44,376 datasets and received 448. Fourteen platform operators had been audited at that point, and no breaches of the reporting duty had yet been referred to the BZSt unit responsible for fines.
Two things belong with these figures. First, it was a snapshot: operator reports had only existed since spring 2024, so the figure covers roughly ten months. Second, CARF differs in one way that matters for enforcement: registration for crypto-asset operators has been open at the BZSt since 13.05.2026. Anyone who registers is known by name, whereas under DAC7 the administration first had to find the obligated entities.
So our argument is not the penalty. It is that the duty repeats every year, that data about your customers goes to the tax administration, and that the work in front of the filing has to happen either way: collecting self-certifications, resolving residencies, carrying corrections through.
Two honest notes
First: this product is under construction. We are developing it with a small first group of providers, on the same deterministic engine that powers our stablecoin bookkeeping: versioned rules, documented sources, a hash-chained audit trail. Second: the procedure is published. Registration for crypto-asset operators, a communication manual (version 1.0, dated June 2026), access through a BOP or ELSTER certificate plus a one-off application for the DIP mass-data interface; the record-format specification (dated 17.11.2025): CARF XML under the OECD schema v1.5 in the DIP envelope, corrections via the previous report's CorrMessageRefId. What no portal takes off your hands is the due diligence, the self-certifications and the corrections cycle before the filing: that is where the workload sits, and that is where we start.
A few lines are enough: who you are, roughly how many reportable users, how you handle it today. We reply personally.
Information as of 22.10.2026; legal basis: Germany's crypto tax transparency act (KStTG) and the BMF letter of 14.01.2026 on the CARF reporting format. Procedure, registration and deadlines per the BZSt's own description of the Crypto-Asset Reporting Framework (retrieved 15.09.2026). The DAC7 enforcement figures come from the federal government's answer, Bundestag Drucksache 20/14937 of 10.02.2025. This page describes a product, not legal or tax advice; whether and how your firm must report is a question for your advisors.