DAC8 and CARF for crypto exchanges: what a platform collects, reports and when

DAC8 and CARF make a crypto exchange a tax reporter. It collects each customer's tax residence and tax identification number (TIN) at onboarding, values every trade and transfer during the year, and reports yearly totals per customer and per crypto-asset to its tax authority. In the EU this applies from 1 January 2026, so the first report covers 2026 and is filed in 2027.

Two texts, one model

CARF, the Crypto-Asset Reporting Framework, is a set of model rules the OECD published in June 2023 for any country to put into its own law. It covers who reports, what is collected, which transactions count and what goes in the report (CARF rules, Sections I to V).

DAC8 is the EU's version. Council Directive (EU) 2023/2226 of 17 October 2023 amends the directive on administrative cooperation in taxation, 2011/16/EU, and adds a new Annex VI that follows CARF's structure almost line for line. Member States had to adopt their laws by 31 December 2025 and apply them from 1 January 2026 (Article 2).

Who reports is wide: any crypto-asset service provider (CASP) under MiCA, and any other crypto-asset operator, that carries out exchange transactions for or on behalf of a reportable user, with staking and lending counted as services. A provider authorised under MiCA reports in its Member State, and one without MiCA authorisation can be caught too, for example through tax residence or a regular place of business in a Member State (Annex VI, Section I).

What a platform collects at onboarding

Everything starts with a self-certification: the customer's own statement of where they are resident for tax purposes. The provider obtains it when the relationship is established, and from customers already on board on 31 December 2025 by 1 January 2027 (Annex VI, Section III).

For an individual, the self-certification is valid only if it is signed or otherwise positively affirmed, dated at the latest on the date of receipt, and contains:

• first and last name;

• residence address;

• the Member State or States of residence for tax purposes;

• the TIN for each of those Member States;

• date of birth.

An entity gives its legal name, address, residence and TIN, and, unless it is an active entity or excluded, the same details for each controlling person. Most of this already sits in the KYC record; what is new is the tax residence, the TIN and the customer's confirmation.

The provider then confirms the reasonableness of the self-certification against what it already knows, including documents collected for anti-money-laundering checks: a declared residence in Germany next to a verified address elsewhere is a mismatch to resolve. If circumstances change, a new self-certification, or a reasonable explanation, is needed. The guide to KYC, AML and the Travel Rule covers the identity checks this builds on.

The rule has teeth. Where a customer does not provide the information after two reminders following the initial request, and not before 60 days have passed, the provider has to prevent that customer from performing reportable transactions (Annex VI, Section V, A(2)). DAC8 also asks Member States to endeavour to let reporting entities confirm a TIN's validity electronically (Article 1, point 11); meanwhile, checking each TIN against its country's format catches most typing errors.

Which transactions are reportable

DAC8 and CARF count two kinds of reportable transaction:

1. Exchange transactions: crypto-assets for fiat currency, and crypto-assets for other crypto-assets.

2. Transfers: any movement of a crypto-asset to or from a customer's address or account, other than one the provider keeps for that same customer, which the provider cannot identify as an exchange transaction. Deposits from and withdrawals to outside wallet addresses are the usual case.

A transfer that pays for goods or services worth more than USD 50,000 is a reportable retail payment transaction, with its own line in the report. Central bank digital currencies, electronic money as the directive defines it, and crypto-assets the provider has adequately determined cannot be used for payment or investment are outside the scope.

The report does not list trades one by one. For each customer, and for each type of crypto-asset, it gives totals in these buckets (Annex VI, Section II, B(3)):

Alongside the totals go the customer's name, address, residence, TIN and date of birth (place of birth only where domestic law requires it), and the provider's own name, address and TIN.

A value on every movement

Values are fixed when each movement happens, not at year end. Trades against fiat are reported in the currency paid or received; where several were used, they are converted into one at the time of each transaction, in a way the provider applies consistently. Crypto-for-crypto trades and transfers are reported at fair market value in a single currency, valued the same way.

So every trade, swap, deposit and withdrawal needs a timestamped price, from live market prices, stored with it in the ledger. The method has to be written down and kept the same, because the law asks for consistency rather than one prescribed price source.

Take one illustrative customer, resident in Germany, in 2026:

• 10 March: buys 0.2 BTC for 12,000 EUR.

• 12 May: buys 0.2 BTC for 14,000 EUR.

• 2 July: swaps 0.1 BTC for 2.5 ETH. With bitcoin at 65,000 EUR, the swap is worth 6,500 EUR.

• 15 September: sells 0.2 BTC for 15,000 EUR.

• 20 November: withdraws 1 ETH to an outside wallet, worth 3,000 EUR at the time.

The five movements become five lines. Bitcoin: bought for fiat, 26,000 EUR, 0.4 BTC, two transactions; sold for fiat, 15,000 EUR, 0.2 BTC, one; sold for other crypto-assets, 6,500 EUR, 0.1 BTC, one. Ether: bought with other crypto-assets, 6,500 EUR, 2.5 ETH, one; transferred by the customer, 3,000 EUR, 1 ETH, one, also counted under line (i) if the address is not known to belong to a provider.

When the report is due

DAC8 sets the rhythm: the information is reported annually, in the calendar year after the year it relates to, starting with 2026 (Annex VI, Section II, D). The exact filing date comes from each Member State's own law, in the electronic format its tax authority accepts; CARF likewise leaves the date blank for each country to fill in (CARF, Section II, G).

Tax authorities then exchange the information within nine months of the end of the calendar year, so data on 2026 moves between EU authorities by 30 September 2027 (Article 8ad(6) of Directive 2011/16/EU, inserted by Article 1).

Around the filing, the provider keeps records of the steps it took and the information it relied on for at least five and at most ten years after the reporting deadline (Annex VI, Section V, B). Each individual has to be told that their information will be collected and transferred, and given what data protection law entitles them to, before it is reported (Article 25(4) of Directive 2011/16/EU, as amended). A third party can do the due diligence, but the obligations stay the provider's.

What the exchange software has to do

Put together, the work falls to the platform as much as to the compliance team:

1. Capture the self-certification inside onboarding, prefilled from KYC, with tax residence, a TIN per country, a format check and the customer's confirmation.

2. Chase what is missing: send the reminders, count the days and block reportable transactions when the rule says so.

3. Value every movement at the moment it happens, in one reporting currency, and store the price used.

4. Classify each movement into the report's lines, telling a transfer from an exchange.

5. Aggregate per customer and per crypto-asset for the year, and build the report file in the format the authority specifies.

6. Approve before filing: one person prepares, a second approves, and both are logged.

7. Keep the evidence for the retention period.

Marengo, our exchange, has this built in as part of the white-label crypto exchange: the tax self-certification sits inside KYC with TIN checks, every movement is valued, including the euro markets, and CARF and DAC8 XML reports need two people to approve them. More of the reporting side is in the compliance reporting module and the MiCA checklist.

The customer's yearly statement

DAC8 is a report to the tax authority, not to the customer. But a customer whose data is about to be reported will want the same numbers, and a yearly statement answers most questions before they reach support.

A useful statement repeats the movements and works out gains on a stated cost basis. With first in, first out (FIFO), the coins bought first count as sold first.

In the example, the July swap uses 0.1 BTC from the March lot (cost 6,000 EUR, value 6,500, a gain of 500). The September sale uses the other 0.1 BTC from March and 0.1 from May (cost 13,000, proceeds 15,000, a gain of 2,000). The year's gains come to 2,500 EUR, and 0.1 BTC from May is still held.

Whether a swap is taxed, and which cost method applies, is for the customer's own country's rules; the statement supplies the numbers.

You can see this in Marengo: each customer gets a yearly statement with a FIFO cost basis and a year-end notice, downloadable as CSV and available in six languages.

Frequently asked questions

Does DAC8 apply to a provider that is not authorised under MiCA? It can. The directive covers crypto-asset operators as well as authorised CASPs, and a provider without MiCA authorisation reports in a Member State where, for example, it is tax resident, incorporated, managed or has a regular place of business (Annex VI, Section I).

Is a move between two of a customer's own accounts at the same exchange a transfer? No. A transfer is defined as a movement to or from a customer's address or account other than one the provider maintains for that same customer, so moving between them inside one platform is not reported as a transfer.

What happens if a customer never gives a TIN? After the initial request and two reminders, and not before 60 days, the provider has to stop that customer's reportable transactions. Under CARF, a TIN is not needed where the country of residence does not issue one or does not require it to be collected.

See it working

Tax reporting is easiest to judge on a working platform. Open Marengo at marengo.paynoramic.com to see the exchange the reports are built into, in Lite and Pro.