Crypto Tax Reporting: What Crypto Businesses Need to Know

A crypto platform can hold a fully verified identity file on a customer — passport checked, address confirmed, sanctions screening clean, every AML obligation met — and still be unable to produce a tax report for that customer. The identity is there. The tax residence is not.

That gap is the whole subject of this page. Tax reporting adds a second layer on top of what onboarding already collects:

• tax residence;
• taxpayer identification number;
• entity classification;
• controlling persons;
• asset classification;
• transaction categorisation;
• reporting-period aggregates;
• jurisdiction-specific outputs.

Crypto tax reporting is not simply an extension of KYC. It requires a reporting-grade data layer that connects customer tax information with transaction activity and jurisdiction-specific reporting rules.

Crypto tax-reporting obligations are expanding rapidly, but effective rules, scope, and start dates differ by jurisdiction. This page is about the data and the process that hold up across all of them.

Quick Facts

• CARF is the main OECD international standard for crypto tax reporting.
• DAC8 is the EU-specific legal regime, in force since 1 January 2026.
• The US uses Form 1099-DA rather than CARF as its main current broker-reporting framework.
• AML/KYC data can support tax reporting but does not replace tax-residence due diligence.
• Multi-jurisdiction businesses need a common data layer plus jurisdiction-specific reporting logic.

What Crypto Tax Reporting Means for a Business

Two different things share the same name, and conflating them is the fastest way to build the wrong system.

Individual tax compliance is the user's own obligation: working out gains, losses and liability, and filing a personal return. Business information reporting is the platform's obligation: collecting prescribed information about users and their activity, and submitting it to a tax authority on a set cycle.

This page is about the second process only. Crypto tax reporting for businesses is an information-reporting process and is separate from calculating an individual user's final tax liability. It does not cover how capital gains are taxed, and nothing here is tax advice for investors.

The practical consequence is a change of posture. A crypto business can have information-reporting obligations even though it does not calculate or determine the customer's final tax liability. The job is accuracy and completeness of prescribed data, not getting a tax answer right.

Whether a crypto business has tax-reporting obligations depends on the applicable reporting regime, the services it performs, its reporting nexus, and the users or transactions covered by that regime. There is no single global test, and the regime decides the answer — which is why the first step is always working out which regimes apply, covered in our comparison of crypto tax reporting requirements across key jurisdictions.

The Main Crypto Tax Reporting Regimes

This section is deliberately short. Its job is to say which framework is which, not to restate any of them.

CARF and DAC8 are two of the most important reference frameworks for international crypto tax reporting, while countries such as the United States operate separate domestic reporting models.

OECD CARF

CARF is the OECD's international standard for collecting and automatically exchanging tax-relevant information on crypto-asset users and transactions. It defines who reports, which users are reportable, how tax residence is established, which assets and transactions are in scope, and what data moves between tax authorities.

Being an international standard, CARF is not directly enforceable on its own. Obligations arise through the domestic law of jurisdictions that implement it, and the effective dates and reporting years differ between them. The scope rules, nexus tests and due-diligence requirements are set out in full in our guide to OECD CARF reporting requirements.

EU DAC8

DAC8 is the EU's own legal regime for crypto tax reporting, applying since 1 January 2026, with 2026 as the first crypto reporting period. It is closely aligned with CARF but has its own scope, registration, due-diligence and enforcement rules.

One timing point matters even at this level: 2026 is the first reporting year, Member States must exchange that period's information by 30 September 2027, and the domestic deadline by which a provider files with its own tax authority is set nationally and is often earlier. Treating the exchange date as your filing date is a planning error, not a detail. The mechanics are covered in EU DAC8 crypto reporting requirements.

National Reporting Regimes

Not every market reports through a CARF-aligned regime, and the United States is the reason you cannot architect only around CARF. US broker reporting runs on Form 1099-DA under domestic tax rules: gross proceeds reporting for transactions from 2025, with basis reporting for certain covered transactions from 2026.

In practical terms, that regime asks for something the CARF family largely does not — what an asset cost — which pulls acquisition history, transfer records and per-account tracking into the data model. A system built purely to CARF shape will not produce it.

The regimes also weigh custody differently, which is why this page gives no single answer on non-custodial models. Under the current US broker rules, taking possession of customer assets is close to determinative. Under CARF and DAC8, a non-custodial structure is not an automatic exclusion, because the test runs on the service performed and the operator's role. The same business can therefore land on different sides of two regimes. For the full picture by market, compare crypto tax reporting rules by jurisdiction.

Why AML/KYC Data Is Not Enough for Tax Reporting

AML/KYC data can provide part of the identity layer for crypto tax reporting, but it does not normally contain all tax-residence, TIN, classification, and reporting information required by tax regimes.

The overlap is real but partial. For each field AML onboarding already holds, tax reporting needs a counterpart it usually does not:

• Legal Name is collected for AML; tax reporting additionally needs tax residence.
• Date of Birth is collected for AML; tax reporting additionally needs a TIN or equivalent.
• Address is collected for AML; tax reporting additionally needs the reportable jurisdiction, which is not the same thing as a mailing address.
• Entity and UBO Data is collected for AML; tax reporting additionally needs tax classification and controlling-person reportability, where the definition of "controlling" can differ from the AML one.
• Customer Account Records exist for AML; tax reporting additionally needs reporting-period classification.
• Transaction Records exist for AML monitoring; tax reporting additionally needs tax-reporting transaction categories and aggregates.

The pattern is consistent: the AML system is a legitimate source for part of the identity layer, and it is not a source for tax residence, tax self-certification, TINs, tax-specific entity classifications, or reporting categories. Those have to be collected and evidenced on their own terms.

The distinction is worth understanding properly before building, and we cover how crypto KYC requirements differ from tax-reporting due diligence separately. On the entity side, existing beneficial ownership and KYB verification work feeds the corporate file without completing it.

Build a Shared Tax-Reporting Data Layer

The architecture that survives more than one regime separates what is universal from what is local. A scalable crypto tax-reporting architecture should separate common underlying data from jurisdiction-specific reporting rules.

In practice that means four layers of data, each with a clear owner.

Customer layer — account and customer ID, identity, tax residence, TIN, entity details, controlling persons, and change-of-circumstances status. This is where self-certification lives, with its own validity state rather than as a free-text field.

Asset layer — an internal asset ID, the blockchain or network, the token representation, fiat valuation data, and the asset's classification under each relevant reporting rule. The internal ID matters more than it looks: without one, the same asset on three networks becomes three assets.

Transaction layer — the transaction or account event, the reporting period it falls in, the transaction category, amount, units, the relevant valuation, and the source system it came from. Recording the source system is what makes later reconciliation possible.

Jurisdiction layer — the reporting entity, the applicable regime, the reporting jurisdiction, each user's reportable status, and the mapping from internal data to each required output.

The organising principle is simple to state and easy to violate: collect common data once, but apply reporting rules separately for each regime. The moment a regime-specific rule gets written into the customer or transaction layer, the next regime forces a rebuild.

How to Handle High-Volume and Multi-Chain Crypto Data

At volume, the difficulty is not storage. It is making sure one piece of economic activity does not vanish, duplicate, or get classified differently in two systems without a reason anyone can explain.

The recurring sources of that problem:

• one customer holding multiple wallets and accounts;
• the internal ledger and the blockchain recording different things;
• transfers between the business's own wallets;
• chain bridges;
• wrapped and tokenized representations of the same underlying asset;
• forks and network migrations;
• stablecoins issued across several networks;
• the same transaction represented twice by different systems;
• inconsistent timestamps and time zones;
• fiat valuation at the right moment and rate;
• corrections, reversals and failed transactions.

Multi-chain activity can create duplicate or inconsistent reporting when bridges, wrapped assets, internal wallet transfers, and token representations are not normalized consistently. High-volume crypto tax reporting depends on consistent transaction normalisation and reconciliation rather than on exporting raw blockchain data directly into a reporting template.

In practical terms, the test to apply is a reconciliation one: take a customer, a period, and an asset, and check that the ledger, the chain data and the reporting output describe the same activity. If they do not, the normalisation rules are the thing to fix, not the report.

Multi-Jurisdiction Reporting Without Fragmented Systems

Two models fail predictably. The first is one global report that is assumed to satisfy everyone. The second is a separate, independent reporting stack per country, which multiplies cost and guarantees the numbers diverge.

The model that works is a common database with separate rule and output layers on top.

The common layer holds identity, tax residence, transactions, asset IDs, valuations, and the audit trail. It is built once and reused.

The jurisdiction-specific layer holds provider scope, reporting nexus, reportable-user determination, transaction classification, aggregation rules, deadlines, output format, and the filing process. It is built per regime and expected to change.

A common data layer can support multiple tax-reporting regimes, but jurisdiction-specific legal and reporting logic still needs to be applied separately. The practical payoff is that a legal change in one market touches one rule set rather than the whole platform — which is also why the regime inventory has to be accurate before anything is built. Our comparison sets out the reporting rules and deadlines across key jurisdictions.

CARF vs DAC8: What Can Be Shared and What Must Stay Separate

Because DAC8 is aligned with CARF, teams reasonably ask how much of the work is shared. The honest answer splits cleanly in two.

What can often be shared across both:

• customer identity;
• tax residence;
• TIN;
• entity and controlling-person data;
• asset master data;
• core transaction records;
• audit history.

What must be mapped separately for each:

• provider scope;
• reporting nexus;
• registration rules;
• reportable-jurisdiction logic;
• transaction classification details;
• filing deadline;
• submission format and process.

A common customer and transaction data layer can support CARF, DAC8, and national regimes without making those legal frameworks identical. CARF alignment allows data reuse, not automatic legal equivalence.

The dividing line is worth memorizing: the left-hand list is data, the right-hand list is law. Data travels between regimes; legal determinations do not. The specific rules on each side are set out in the CARF guide and the DAC8 guide linked earlier, and neither can be derived from the other.

Build Reporting-Grade Data Controls

Collecting the data is the smaller half of the work. Without controls, a reporting dataset is a collection of plausible values nobody can defend.

Validation

Validation runs before aggregation, and checks for missing tax residence, missing or invalid TINs where required, inconsistent identity data across records, duplicate customers, unmapped assets, incomplete transactions, and inconsistent classifications.

Reconciliation

Reconciliation compares the trading engine, the custody ledger, blockchain data, the accounting records, and the reporting output, and explains any difference between them.

One assumption to avoid: the on-chain record is not automatically authoritative. For a custodial business, the internal ledger is often the better record of a user's economic activity, because user-level trades may never touch the chain at all. Internal platform ledgers and blockchain data may represent different parts of the same economic activity and must be reconciled before regulatory reporting. High-volume crypto tax reporting requires transaction normalisation, reconciliation, and consistent asset identification rather than a direct export of raw blockchain transactions.

Audit Trail

The trail preserves the source data, every change to it, the classifications applied, the calculation logic, corrections made, the versions of each report, and the submission history.

Reporting-grade crypto data must be reproducible: a business should be able to explain where each reported value came from, how it was classified, and how corrections were handled. A number that cannot be traced back is a number that cannot be defended in a review.

Exception Handling

Not every record classifies automatically, and pretending otherwise just moves the failure to filing day. A review queue is needed for incomplete tax data, conflicting residence information, unsupported assets, valuation failures, classification uncertainty, and reconciliation differences — with ownership and a turnaround expectation, not as a dumping ground.

How to Prepare for the Next Reporting Cycle

1. Map the legal entities and the markets each one operates in.
2. Determine which reporting regimes apply to each entity.
3. Inventory the tax and user data you already hold.
4. Identify missing self-certification and TIN fields.
5. Map every transaction source system.
6. Build the common data model.
7. Apply the regime-specific rules on top of it.
8. Validate against sample reporting outputs rather than against the schema alone.
9. Run reconciliation before filing, not after.
10. Track legal and technical changes separately from the core data model, so a rule change never requires a data migration.

The most reusable part of a crypto tax-reporting system is the underlying validated data model, not the final filing format. Formats and portals change; the data model should outlive several of them.

Conclusion

The hard part of crypto tax reporting is not generating a file once a year. It is maintaining reliable customer, tax, asset, and transaction data throughout the year so that multiple reporting regimes can be supported without rebuilding the process each time. CARF alignment can reduce data duplication across jurisdictions, but each implementing regime still needs its own scope, deadline, classification, and filing logic. The sequence that holds up is the same in every market: shared data – regime-specific rules – validated output.

FAQ

What Is Crypto Tax Reporting for a Crypto Business?

It is platform-level information reporting: the business collects prescribed information about its users and their crypto activity and submits it to a tax authority, which may then exchange it with other jurisdictions. It is not the calculation of any individual user's tax liability, which remains the user's own obligation.

Is Crypto Tax Reporting the Same as AML or KYC?

No. AML and KYC processes can supply part of the identity layer, such as name, date of birth and address. Tax reporting additionally requires tax-residence information, a taxpayer identification number where applicable, tax-specific entity classification, and transaction information organised into reporting categories that AML monitoring does not produce.

What Data Do Crypto Businesses Need for Tax Reporting?

Broadly: customer identity, tax residence, TIN, entity and controlling-person data, asset identification, transaction records, fiat valuation, and the reporting period each transaction falls in. The exact fields, classifications and aggregation rules differ by regime, so the field list has to be confirmed against each applicable framework.

What Is CARF in Crypto Tax Reporting?

CARF is the OECD's international reporting standard for crypto-assets. It sets common rules for which providers report, which users are reportable, how tax residence is established, and what information tax authorities exchange automatically. As an international standard, it takes effect through the domestic law of each implementing jurisdiction.

What Is DAC8 in Crypto Tax Reporting?

DAC8 is the EU's legal regime for crypto tax transparency, applying from 1 January 2026, with 2026 as the first crypto reporting period. It brings crypto-assets into the EU's existing framework for automatic exchange of tax information and sets its own scope, due-diligence and enforcement rules.

What Is the Difference Between CARF and DAC8?

CARF is the OECD international standard; DAC8 is an EU legal regime closely aligned with it but with EU-specific scope, registration, due-diligence, exchange and enforcement rules. A business can share one underlying data foundation across both, while the legal mapping and reporting workflow are determined separately for each.

How Can a Crypto Company Manage Tax Reporting Across Multiple Jurisdictions?

By building one common reporting data layer — identity, tax residence, transactions, assets, valuations, audit trail — and applying separate jurisdiction-specific rule and output layers on top of it. That keeps a legal change in one market from touching the shared data, and avoids running an independent reporting stack per country.

Why Is Crypto Tax Reporting Difficult at High Transaction Volumes?

Because the same economic activity has to be reconciled consistently across customer accounts, internal ledgers, multiple chains, different representations of the same asset, fiat valuation at the right moment, and reporting categories. At scale, small inconsistencies in any of those produce duplicated or missing activity that is expensive to find later.

Can Raw Blockchain Data Be Used Directly for Tax Reporting?

Usually not by itself. Blockchain data does not carry customer identity, tax residence, account context, or reporting classifications, it does not distinguish internal transfers between a platform's own wallets, and it does not supply the cost-basis context some regimes require. It is one input to a reporting dataset, not the dataset.

Does One CARF-Compatible Reporting System Satisfy Every Country's Rules?

No. A shared CARF-aligned data foundation reduces duplication, but each jurisdiction may apply different scope rules, classifications, aggregation methods, deadlines, submission formats and domestic requirements. The same validated dataset usually has to produce several different outputs on several different dates.