Crypto Exchange Tax Reporting 2026: CARF, DAC8 and 1099-DA
Table of Contents
- Why 2026 Is the Year Exchange Tax Reporting Became Real
- CARF: The Global Framework
- DAC8: How the EU Implements CARF
- Form 1099-DA: The US Broker Regime
- UK and Other Jurisdictions
- Which Regime Applies to Your Exchange
- The Data Architecture Behind Compliant Reporting
- Penalties and the Cost of Getting It Wrong
- Implementation Checklist and Timeline
- Frequently Asked Questions
- Bottom Line and Next Steps
Why 2026 Is the Year Exchange Tax Reporting Became Real
For most of the industry’s history, crypto exchange tax reporting was a user problem. Traders downloaded CSVs, operators shrugged, and tax authorities relied on voluntary disclosure. That arrangement ended on 1 January 2026.
Three regimes converged on the same date. The OECD’s Crypto-Asset Reporting Framework (CARF) began its first collection year in the early-adopter group of jurisdictions. The EU’s DAC8 directive, which transposes CARF into European law, started applying. And in the United States, brokers issued the first Form 1099-DA statements for 2025 transactions, with cost-basis reporting phased in for 2026 activity.
The practical effect is that an exchange is now a reporting intermediary, in the same way a bank or stock broker is. The obligations do not depend on your size or on whether your users ask for tax documents. They depend on where your entity sits, where your users live, and what transactions you facilitate.
This guide covers what each regime requires from the operator, how to work out which ones apply to you, and the data architecture that turns an annual panic into a scheduled export. It is orientation, not legal or tax advice. Every timeline below varies by country, and you should confirm the current position with a qualified advisor before relying on it.
CARF: The Global Framework
CARF is the OECD’s extension of the Common Reporting Standard to crypto-assets. More than 65 jurisdictions have committed to it, with the first wave collecting data through 2026 and exchanging it with partner countries in 2027. A second wave follows a year later. The exact adoption calendar is published per jurisdiction, so treat these dates as the general pattern rather than a fixed rule.
Who is a Reporting Crypto-Asset Service Provider
The core test is functional, not legal-form based. An entity or individual that, as a business, provides a service effectuating exchange transactions in relevant crypto-assets for or on behalf of customers is a Reporting Crypto-Asset Service Provider (RCASP). That covers centralized exchanges, brokers, OTC desks, and most P2P platforms that hold or control funds at any point in the trade.
The nexus rules then decide which jurisdiction you report to. You report in a participating jurisdiction if you are tax resident there, incorporated or organized there, managed from there, or have a regular place of business or branch there. The first matching test wins, which prevents double reporting but also means you cannot avoid the regime by choosing a non-participating country for incorporation while running operations from a participating one.
Due diligence and self-certification
Under CARF reporting crypto asset service provider rules, every individual and entity customer must provide a self-certification covering name, address, jurisdiction(s) of tax residence, taxpayer identification number (TIN), and date of birth. For entity customers you also identify controlling persons. You must collect this before the customer transacts, and you must apply reasonableness tests against the KYC data you already hold.
In practice this merges with onboarding. If your KYC and AML system already captures nationality, residency, and ID documents, the CARF self-certification is a small extension of the same flow rather than a separate process.
What gets reported
CARF reports are annual and aggregated per user and per asset type. The reportable categories are:
| Category | What it covers | Reported as |
|---|---|---|
| Crypto-to-fiat | Sales for fiat currency, purchases with fiat | Gross amount paid or received, number of units, transaction count |
| Crypto-to-crypto | Swaps between relevant crypto-assets | Fair market value in fiat at the time of exchange, units, count |
| Transfers | Movements to and from external wallets | Units and value, with wallet address where known |
| Retail payment transactions | Merchant payments above a threshold | Value and count |
The framework intentionally excludes some assets, such as closed-loop tokens and most CBDCs, and it treats stablecoins and NFTs as relevant crypto-assets in most cases. The definitional edges matter for listing decisions, so keep a documented classification for every asset you support.
DAC8: How the EU Implements CARF
DAC8 is the eighth amendment to the EU’s Directive on Administrative Cooperation. It brings CARF into EU law and adds reporting on e-money and CBDCs. Member states had to transpose it by the end of 2025, and the rules apply to transactions from 1 January 2026, with first reports due in 2027.
The three points that catch non-EU operators off guard:
- Scope follows the customer, not the platform. Any crypto-asset service provider serving EU-resident users falls within DAC8 obligations for a crypto exchange, whether or not the entity is based in the EU. A non-EU platform must register in one member state of its choice and report through it, unless it is already reporting under an equivalent and recognized CARF arrangement.
- MiCA-authorized providers do not re-register. If you hold a MiCA CASP authorization, you report through your home member state automatically. The two regimes are designed to be worked together, which is one more reason to treat MiCA authorization as the foundation of any EU strategy.
- Non-cooperative users must be cut off. If a user fails to provide a valid self-certification after two reminders, DAC8 requires you to block further transactions for that account. This has product and support consequences, so design the collection flow early.
Reporting goes through a national XML schema aligned with the OECD CARF schema. Most member states accept bulk uploads via a tax authority portal, and several have published validation tools you can test against before the first live submission.
Form 1099-DA: The US Broker Regime
The United States did not adopt CARF but built a parallel domestic regime through the broker reporting rules under Internal Revenue Code section 6045. The new instrument is Form 1099-DA, Digital Asset Proceeds From Broker Transactions.
The phase-in as currently understood:
| Transaction year | What brokers report | Statements issued |
|---|---|---|
| 2025 | Gross proceeds from sales and exchanges of digital assets | Early 2026 |
| 2026 onward | Gross proceeds plus cost basis for covered assets acquired on the platform | Early 2027 |
Covered here means custodial brokers: centralized exchanges, hosted wallet providers, and payment processors that take custody of customer assets. A separate rule that would have pulled non-custodial DeFi front ends into the definition was rescinded in 2025 under the Congressional Review Act, so form 1099-DA broker reporting currently sits with custodial platforms only.
For an exchange serving US customers, the operating requirements are collecting a valid TIN (usually via Form W-9 for US persons and W-8 series for non-US persons), applying backup withholding where a TIN is missing or invalid, tracking lot-level cost basis for assets bought on your platform, and filing both to the IRS and to the customer by the statutory deadlines. Transfers in from external wallets arrive without basis, which is why the regulations defer basis reporting for transferred-in assets and why your database needs a per-lot provenance flag.
UK and Other Jurisdictions
The United Kingdom is implementing CARF as a first-wave jurisdiction, with data collection from 1 January 2026 and first reports to HMRC due by the end of May 2027. HMRC has published a UK-specific reporting schema and has signaled that it will apply the framework to UK users of non-UK platforms through its exchange agreements.
A quick survey of other markets operators commonly ask about:
- Dubai (UAE): The UAE has committed to CARF with a later start date. VARA-licensed platforms should expect to collect self-certifications ahead of go-live and should read the framework alongside their existing licensing obligations.
- Singapore: Committed to CARF with exchanges of information beginning in 2028. MAS-licensed providers will report through IRAS.
- Hong Kong: Has committed to CARF, with legislation expected to follow the broader 2026 to 2028 window.
- Switzerland, Canada, Australia, Japan, South Korea: All in the first or second CARF wave. Several already run domestic transaction reporting that CARF will supplement rather than replace.
The pattern is clear. By 2028, almost every jurisdiction with a credible licensing regime will also have automatic tax reporting. Building for it now avoids a second migration later.
Which Regime Applies to Your Exchange
The crypto exchange tax reporting question founders actually need answered is not “what is CARF” but “what do I have to file, where, and about whom”. The decision table below is a starting point. Treat it as orientation and confirm it with an advisor in each relevant jurisdiction.
| Your situation | CARF | DAC8 | 1099-DA |
|---|---|---|---|
| Entity in a CARF jurisdiction, no EU or US users | Yes, report to home authority | No | No |
| Entity in a CARF jurisdiction, some EU users | Yes | Covered via CARF if recognized as equivalent; otherwise register in one member state | No |
| Entity in the EU (MiCA CASP) | Yes, via DAC8 | Yes, via home member state | No, unless serving US customers |
| Entity outside EU and outside CARF, EU users | No | Yes, register in one member state | No |
| Any entity with US customers taking custody | Per home jurisdiction | Per EU users | Yes |
| Non-custodial, pure matching, no fund control | Generally no, but check | Generally no, but check | No |
Two observations from the table. First, serving customers in a jurisdiction creates obligations even when your entity is elsewhere. Second, the US regime is additive: it never replaces CARF or DAC8, it stacks on top of them.
The Data Architecture Behind Compliant Reporting
Every crypto exchange tax reporting regime above is downstream of the same question: can your platform produce, per user and per year, a complete and reconciled record of what they did? Operators who build for this from day one find annual reporting is a scheduled job. Operators who retrofit it discover that their trade history, wallet ledger, and KYC profile were never designed to join.
Fields your database must hold
Per user:
- Verified legal name, address, and date of birth
- Tax residency jurisdiction(s) and TIN(s), with the self-certification document and timestamp
- Entity type and controlling persons for business accounts
- A reportable-user flag per regime, recomputed when residency changes
- Self-certification status (pending, valid, reminded, blocked)
Per transaction:
- Type (fiat buy, fiat sell, crypto swap, deposit, withdrawal, internal transfer, payment)
- Timestamp in UTC, asset, quantity, counter-asset, fee, and fiat value at execution
- For US-covered assets: acquisition lot, cost basis, and provenance (acquired on platform or transferred in)
Per external transfer:
- Direction, chain, transaction hash, external address, and whether the address is attributed to a known VASP
If your current schema cannot produce these joins, the fix is a reporting ledger that captures each event once at the moment it happens, not a reconstruction from exchange logs eighteen months later.
Generating the reports
CARF and DAC8 submissions use an OECD XML schema with per-country extensions. Form 1099-DA is filed through the IRS FIRE or IRIS systems in a different format. A sensible pipeline is one normalized reporting dataset, with three thin export adapters on top. Generate the files quarterly in a dry run, validate them against the tax authority’s schema tools, and reconcile totals against your general ledger. Finding a mismatch in October is a bug ticket; finding it in May is a compliance incident.
The exchange admin panel should surface this as an operator workflow: a per-regime dashboard showing users with missing self-certifications, blocked accounts, reconciliation status, and a one-click export for the reporting period. Codono’s admin and ledger model store residency, TIN, and per-event records in a form that exports cleanly, which is the part that matters when a tax authority asks for a corrected file.
User-facing statements
Users will ask for the same data in a form they can give their accountant. A per-year transaction export, a realized gains summary where you have basis, and the regime-specific statement (such as the customer copy of a 1099-DA) reduce support load and signal that the platform is run properly. Pair this with a clear notice on how data is shared under CARF, which several jurisdictions require anyway.
Annual reporting calendar
| Period | Task |
|---|---|
| January | Freeze prior-year dataset, open new year lots |
| February to March | US 1099-DA statements to customers and IRS (deadlines vary by filing method) |
| April to May | CARF and DAC8 validation runs, corrected self-certifications |
| By mid-year | First CARF and DAC8 submissions (country deadlines range from end of January to end of June) |
| Quarterly | Dry-run exports and ledger reconciliation |
Penalties and the Cost of Getting It Wrong
Penalty regimes are set nationally and differ widely. Illustrative ranges, not quotes: EU member states have adopted per-failure penalties that commonly run into the tens of thousands of euros, with some scaling by number of unreported users. The US imposes per-form penalties for late, incorrect, or missing 1099-DA filings, escalating with delay and with intentional disregard, plus potential liability for backup withholding you should have collected. The UK applies per-failure penalties with daily uplifts for continued non-compliance.
The direct fines are rarely the real cost. The real cost is that tax authorities now share this data with licensing regulators. A platform that cannot produce clean reports is a platform that will struggle through a regulatory audit and will find banking partners, who increasingly ask for CARF readiness during onboarding for fiat rails, harder to keep.
Implementation Checklist and Timeline
Use this as the crypto exchange tax compliance obligations workstream in your launch or remediation plan. A platform with a modern ledger can complete it in 8 to 12 weeks; a legacy stack with fragmented data can take two to three times that.
- Map your entity nexus and user base against CARF, DAC8, and 1099-DA with a qualified advisor
- Classify every listed asset as relevant crypto-asset, excluded, or uncertain
- Add tax residency, TIN, and self-certification capture to onboarding, with reasonableness checks against KYC
- Backfill self-certifications for existing users with a two-reminder, then block, workflow
- Build or verify the normalized reporting ledger: per-user, per-transaction, per-transfer
- Add lot-level cost basis and provenance tracking if you serve US customers
- Implement XML and IRS export adapters and validate against official schema tools
- Reconcile quarterly dry runs to the general ledger
- Publish user tax statements and a data-sharing notice
- Register with the relevant tax authority portal(s) and calendar the deadlines
- Add the regime to your compliance program documentation and board reporting
Operators launching a new platform should slot these items into their launch checklist rather than treating them as a post-launch project. The data model decisions are far cheaper to make before the first trade.
Frequently Asked Questions
Does CARF apply to a small exchange with a few thousand users?
In most adopting jurisdictions, yes. CARF has no user-count or volume threshold. If your platform effectuates exchange transactions in crypto-assets for customers and you are tax resident, incorporated, managed, or have a branch in a participating jurisdiction, you are a Reporting Crypto-Asset Service Provider. Confirm the specific trigger tests with a local advisor, because a few countries phase in smaller operators later.
My exchange is incorporated outside the EU. Do DAC8 obligations still apply?
They can. DAC8 reaches non-EU platforms that serve EU-resident users unless the platform is already reporting under an equivalent CARF arrangement that the EU recognizes. A non-EU operator with EU customers typically has to register in one member state and report through it. Ignoring EU users does not remove the obligation; it just removes your awareness of it.
What is the difference between Form 1099-DA and CARF reporting?
Form 1099-DA is a US domestic requirement: brokers, including custodial exchanges serving US customers, report digital-asset sale proceeds (and, for 2026 transactions onward, cost basis for covered assets) to the IRS and the customer. CARF is an international automatic-exchange framework where exchanges report to their home tax authority, which forwards the data to the user’s country of residence. A US-facing platform operating from a CARF jurisdiction may face both.
What is the minimum data my exchange must keep to be ready for CARF and DAC8?
Per user: verified identity, tax residency country or countries, taxpayer identification number, date of birth, and a signed self-certification. Per transaction: type, timestamp, asset, quantity, fiat or crypto value, fees, and the counter-asset. Per transfer: direction, amount, and the external wallet address where known. Retain for at least five years, or longer if your jurisdiction says so. If your platform cannot export these fields today, that is the first gap to close.
Bottom Line and Next Steps
Crypto exchange tax reporting is no longer optional, and it is no longer only about your users. From 2026, CARF, DAC8, and Form 1099-DA make the exchange itself the reporting party, and the data you collect this year is the data you will file in 2027.
The operators who handle this well share one trait: their platform records residency, identity, and every balance-changing event in a single ledger that exports on demand. Everything else, from the XML schema to the user statements, is a thin layer on top of that. Treat the reporting ledger as core infrastructure, pair it with a thorough KYC program, and the annual cycle becomes routine.
If you are building new, choose infrastructure that already holds these fields. Codono’s exchange software ships with the KYC, ledger, and admin export model described above, and the same foundation underpins the white-label deployment for operators who want to launch quickly without compromising on reporting readiness.
Want to see how the reporting and compliance workflow looks in practice? Request a demo or explore Codono crypto exchange software.
The Codono Team has been building crypto exchange infrastructure since 2017. This guide reflects production experience across 250+ exchanges and the reporting frameworks taking effect in 2026. It is not legal or tax advice; confirm current requirements with a qualified advisor in each jurisdiction where you operate.
Codono Team
Codono builds enterprise-grade crypto exchange software deployed by 250+ operators across 30+ countries. Our team writes from production experience running spot, derivatives, custody, and compliance at scale.
View all posts by Codono Team →