How to Categorize Transactions for DAC8 Reporting

Accurate transaction categorization is critical for DAC8 compliance. The directive distinguishes between different types of crypto-asset transactions, and each type may have different reporting requirements and aggregation rules. This guide explains how to map your platform's transaction data to DAC8 categories, handle edge cases, and implement aggregation logic.

> Disclaimer: Transaction categorization rules may vary based on national implementation of DAC8. The categories described here are based on the general framework of Council Directive (EU) 2023/2226. Always verify categorization rules with your national tax authority and the applicable XML schema documentation.

DAC8 Transaction Categories

Under the OECD CARF framework (Section IV.C), there are three categories of Relevant Transactions:

1. Exchange Transactions (Crypto-to-Fiat and Crypto-to-Crypto)

Exchange Transactions include both directions: disposals (selling crypto for fiat or other crypto) and acquisitions (buying crypto with fiat or other crypto). Under CARF Section II.A.3, these are reported in separate sub-categories:

• (b) Acquisitions against Fiat Currency -- aggregate gross amount paid, number of units, and number of transactions
• (c) Disposals against Fiat Currency -- aggregate gross amount received, number of units, and number of transactions
• (d) Acquisitions against other Relevant Crypto-Assets -- aggregate value, number of units, and number of transactions
• (e) Disposals against other Relevant Crypto-Assets -- aggregate value, number of units, and number of transactions

Examples of disposals against fiat:

• User sells 0.5 BTC and receives EUR 15,000
• User sells 100 ETH and receives USD 180,000
• User converts USDC to EUR through the platform

Examples of acquisitions against fiat:

• User buys 1 BTC using EUR 30,000
• User purchases 50 ETH with GBP 90,000

What to capture for all exchange transactions:

• The type and quantity of crypto-asset involved
• The fiat currency or other crypto-asset exchanged and the amount
• The date and time of the transaction
• Fees charged by the platform
• The fair market value of the crypto-asset at the time of the transaction

> Important: Both buying and selling are reportable Exchange Transactions under CARF. Acquisitions and disposals are reported separately in distinct aggregate sub-fields.

2. Crypto-Asset to Crypto-Asset Exchanges

This category covers transactions where one crypto-asset is exchanged for another.

Examples:

• User exchanges 1 BTC for 15 ETH
• User swaps 10,000 USDT for 10,000 USDC
• User trades a DeFi token for ETH through the platform

What to capture:

• The type and quantity of each crypto-asset involved (both the asset disposed of and the asset acquired)
• The fair market value of the transaction in the applicable fiat currency at the time of exchange
• The date and time of the transaction
• Fees charged (and in which asset the fees were denominated)

Valuation challenge: For crypto-to-crypto transactions, you need to determine the fair market value in a fiat currency. Common approaches include:

• Using the mid-market price of the disposed asset in the reporting currency at the time of the trade
• Using the mid-market price of the acquired asset if the disposed asset has limited liquidity
• Using a consistent pricing methodology and documenting it

3. Transfer Transactions

Under CARF Section IV.C.1, Transfers of Relevant Crypto-Assets are explicitly a category of Relevant Transaction. A Transfer is defined (Section IV.C.4) as a transaction that moves a Relevant Crypto-Asset from or to the Crypto-Asset address or account of a Crypto-Asset User, excluding movements between accounts maintained by the same RCASP for the same user.

Both inbound and outbound transfers are reportable:

• Inbound (Section II.A.3(g)): Transfers to the Reportable User not covered by acquisition sub-categories (e.g., deposits from external wallets, airdrops, staking income)
• Outbound (Section II.A.3(h)): Transfers by the Reportable User not covered by disposal sub-categories (e.g., withdrawals to external wallets)
• Transfers to non-VASP wallets (Section II.A.3(i)): Transfers to wallets not associated with a Virtual Asset Service Provider or financial institution

Examples:

• User withdraws BTC from the platform to an external wallet (outbound)
• User deposits ETH from an external wallet to the platform (inbound)
• User receives staking rewards (inbound transfer with specific transfer type)
• User receives an airdrop (inbound transfer with specific transfer type)

Not reportable as Transfers:

• Movements between the user's own accounts on the same RCASP platform (excluded from the Transfer definition)

> Important: The OECD CARF commentary specifies that RCASPs must categorise Transfers by transfer type (e.g., airdrops, income derived from staking, or a loan). This transfer type categorization is required in the reporting.

4. Reportable Retail Payment Transactions

Under CARF Section IV.C.3, a Reportable Retail Payment Transaction is defined as a Transfer of Relevant Crypto-Assets in consideration of goods or services for a value exceeding USD 50,000. This threshold is a core definitional element.

Examples:

• User pays for goods at a merchant using BTC through a crypto payment card, where the transaction value exceeds USD 50,000
• User uses the platform's payment feature to pay a large invoice in crypto

Key points:

• Only retail payments exceeding the USD 50,000 threshold are classified as Reportable Retail Payment Transactions
• Payments below this threshold are reported as regular Transfers
• The threshold is evaluated per individual transaction, not in aggregate

What to capture:

• The crypto-asset type and quantity used for the payment
• The fair market value of the payment in fiat currency (to determine if the threshold is met)
• The date and time of the payment
• Fees charged

Mapping Platform Data to DAC8 Categories

Most crypto platforms already track transactions internally, but the internal categorization may not map directly to DAC8 categories. Here is how to create that mapping:

Step 1: Inventory Your Internal Transaction Types

List all transaction types in your platform's database. Common internal types include:

• Buy, Sell, Trade, Swap, Deposit, Withdrawal, Transfer, Payment, Fee, Reward, Staking, Unstaking, Airdrop, Fork, Referral, Adjustment

Step 2: Create a Mapping Table

Map each internal transaction type to a DAC8 category:

Internal Type	DAC8/CARF Category	Reportable?	Notes
Buy	Exchange Transaction (Acquisition against Fiat)	Yes	Reported under Section II.A.3(b)
Sell	Exchange Transaction (Disposal against Fiat)	Yes	Reported under Section II.A.3(c)
Trade/Swap	Exchange Transaction (Crypto-to-Crypto)	Yes	Reported as both acquisition II.A.3(d) and disposal II.A.3(e)
Deposit	Transfer (Inbound)	Yes	Reported under Section II.A.3(g)
Withdrawal	Transfer (Outbound)	Yes	Reported under Section II.A.3(h)
Internal Transfer	Not a Transfer under CARF	No	Excluded: same RCASP, same user
Payment > $50k	Reportable Retail Payment Transaction	Yes	Threshold: USD 50,000 per transaction
Payment ≤ $50k	Transfer	Yes	Reported as regular Transfer
Fee	Not a standalone category	No	Typically included as part of the related transaction
Staking Reward	Transfer (Inbound, type: staking income)	Yes	Categorised by transfer type per CARF commentary
Airdrop	Transfer (Inbound, type: airdrop)	Yes	Categorised by transfer type per CARF commentary
Fork Proceeds	Transfer (Inbound)	Yes	Treatment follows same Transfer rules
Referral Bonus	Transfer (Inbound)	Yes	Treatment follows same Transfer rules

Step 3: Handle Edge Cases

Several transaction types require careful analysis:

Stablecoins: Transactions involving stablecoins (e.g., USDT, USDC) are generally treated the same as other crypto-to-crypto or crypto-to-fiat exchanges, depending on the nature of the transaction. A stablecoin is typically classified as a crypto-asset under DAC8.

Wrapped Tokens: Wrapping or unwrapping tokens (e.g., converting ETH to WETH) may or may not constitute an exchange depending on the technical implementation and national guidance. Document your treatment and rationale.

DeFi Interactions via Platform: If your platform integrates with DeFi protocols and users can swap tokens through your interface, these may be reportable crypto-to-crypto exchanges.

NFTs: DAC8 may apply to certain NFTs depending on national implementation and how NFTs are classified under the crypto-asset definition in your jurisdiction. Check your national guidance.

Staking and Lending: Rewards from staking or lending activities may be reportable depending on how they are characterized under national law. The DAC8 framework primarily targets exchanges, but some jurisdictions may extend reporting to cover income from staking or lending.

Aggregation Rules

DAC8 reporting typically requires aggregated data rather than individual transaction records. Understanding the aggregation rules is essential for producing a correct report.

General Aggregation Approach

For each Reportable User, you should generally aggregate transactions by:

1. Crypto-asset type: Report totals per crypto-asset (e.g., separate totals for BTC, ETH, etc.)
2. Transaction category: Report separate totals for each DAC8 transaction type (crypto-to-fiat, fiat-to-crypto, crypto-to-crypto)
3. Reporting period: Aggregate all transactions within the calendar year reporting period

What to Aggregate

For each combination of user, crypto-asset type, and transaction category, you may need to report:

• Gross amount: The total value of transactions in fiat currency terms
• Number of transactions: The count of individual transactions
• Net amount or consideration: The net amount after fees (depending on schema requirements)
• Fees: Total fees paid, if reported separately

Aggregation Example

Consider a user who made the following BTC-to-EUR transactions during the reporting period:

Date	BTC Sold	EUR Received	Fee (EUR)
2026-03-15	0.5	15,000	50
2026-07-22	0.3	10,500	35
2026-11-08	0.2	7,200	25

Aggregated report data for this user's BTC-to-EUR activity:

• Crypto-asset: BTC
• Transaction type: Crypto-to-Fiat Exchange
• Number of transactions: 3
• Total BTC sold: 1.0
• Total gross proceeds (EUR): 32,700
• Total fees (EUR): 110

Fair Market Value Calculation

For transactions that do not involve fiat currency directly (particularly crypto-to-crypto), you need a reliable method to determine fair market value.

Recommended Approaches

1. Platform's own price: If the transaction occurred on your exchange, use the execution price on your platform
2. Volume-weighted average price (VWAP): Calculate a VWAP across multiple reputable exchanges for a defined time window around the transaction
3. Reference price from a major exchange: Use the price from a widely recognized exchange at the time of the transaction
4. Index price: Use a recognized crypto-asset index provider's price

Documentation Requirements

Whichever methodology you choose:

• Document the methodology in writing
• Apply it consistently across all transactions and reporting periods
• Be prepared to explain and defend your methodology to the tax authority
• Record the source of pricing data and the timestamp used for each valuation

Implementation Checklist

• [ ] All internal transaction types inventoried
• [ ] Mapping table created from internal types to DAC8 categories
• [ ] Edge cases identified and treatment documented
• [ ] Fair market value calculation methodology documented
• [ ] Pricing data sources identified and validated
• [ ] Aggregation logic implemented (by user, crypto-asset type, transaction category)
• [ ] Aggregation tested against manual calculations for sample users
• [ ] Transfer transactions distinguished from exchange transactions
• [ ] Staking, lending, and reward transactions reviewed for reportability
• [ ] NFT and DeFi transaction handling clarified with legal/compliance
• [ ] Reconciliation process established between raw transaction data and aggregated totals

Summary

Transaction categorization for DAC8 requires a systematic approach: inventory your internal transaction types, map them to DAC8 categories, handle edge cases with documented rationale, implement reliable fair market value calculations, and aggregate the data correctly. The mapping table is your central reference document. Keep it updated as your platform adds new features or transaction types, and as national guidance evolves.

This article is for informational purposes only and does not constitute legal or tax advice. Transaction categorization rules may differ based on your jurisdiction's transposition of DAC8. Consult your national tax authority or a qualified tax advisor for specific guidance.