Category: XML Templates Last Updated: 2026-02-12 Applies To: EU DAC8 / OECD CARF XML Schema

---

Overview

Crypto-to-crypto exchanges -- where a user swaps one crypto-asset for another without fiat currency involvement -- are a reportable transaction type under DAC8/CARF. Unlike crypto-to-fiat transactions where the fiat amount provides a clear value, crypto-to-crypto swaps require the RCASP to determine the fair market value at the time of the trade and express it in the reporting currency.

This article covers how to value, encode, and report crypto-to-crypto transactions.

What Qualifies as Crypto-to-Crypto

A crypto-to-crypto transaction occurs when a user disposes of one crypto-asset and receives a different crypto-asset in return. Examples:

  • Trading BTC for ETH on an order book
  • Swapping USDT for BTC
  • Converting any token to another via an on-platform exchange
  • Automated portfolio rebalancing that swaps assets

Edge case -- same asset: A swap of BTC for BTC (e.g., moving between different representations on the same platform) is generally not a reportable exchange. The transaction must involve two distinct crypto-assets.

Fair Market Value Determination

Since there is no fiat amount in a crypto-to-crypto trade, you must determine the fair market value (FMV) of the transaction. The OECD CARF framework expects RCASPs to determine FMV at the time of the transaction.

Which Side to Value?

You can value either the crypto-asset disposed of or the crypto-asset acquired. In a fair exchange, both sides should have approximately equal value. The practical approach is to use whichever side has the more reliable pricing data.

Recommended approach:

  1. If either side of the trade has a direct fiat trading pair with reliable volume on your platform, use that price
  2. If both sides have reliable fiat pairs, you may use either (but be consistent)
  3. If neither side has a reliable direct fiat pair, use a reputable external price feed

Valuation Example

User swaps 2.0 ETH for 0.08 BTC on 2025-07-15 at 14:30 UTC

ETH/EUR price at 14:30 UTC on your platform: 1,800.00 EUR
BTC/EUR price at 14:30 UTC on your platform: 45,000.00 EUR

Valuing the disposed asset (ETH):
  FMV = 2.0 * 1,800.00 = 3,600.00 EUR

Valuing the acquired asset (BTC):
  FMV = 0.08 * 45,000.00 = 3,600.00 EUR

Both approaches yield 3,600.00 EUR (as expected in a fair exchange)

In practice, there may be small discrepancies due to spread. Pick one side and apply that approach consistently.

Reference Currency

The FMV must be expressed in the reporting currency (typically EUR for EU jurisdictions). If your platform's primary price feeds are in USD, convert to EUR using the exchange rate at the time of the transaction.

ETH/USD price: 1,980.00 USD
EUR/USD rate: 1.10

FMV in EUR = 2.0 * (1,980.00 / 1.10) = 3,600.00 EUR

XML Encoding

Standard Crypto-to-Crypto Summary

<TransactionSummary>
  <TransactionType>EXCHANGE_CRYPTO</TransactionType>
  <NumberOfTransactions>12</NumberOfTransactions>
  <AggregateGrossProceeds currCode="EUR">18400.00</AggregateGrossProceeds>
  <CryptoAssetDetails>
    <AssetCode>ETH</AssetCode>
    <TotalUnits>10.50000000</TotalUnits>
  </CryptoAssetDetails>
</TransactionSummary>

Reporting Both Sides: Disposal and Acquisition

A crypto-to-crypto swap involves two crypto-assets. Under the CARF framework, each crypto-to-crypto exchange must be split into two reportable elements (CARF Section II, paragraph 20 of the Introduction):

  1. A disposal of Crypto-Asset A -- the reportable gross proceeds based on the market value at the time of disposal (reported under Section II.A.3(e): disposals against other Relevant Crypto-Assets)
  2. An acquisition of Crypto-Asset B -- the reportable acquisition value based on the market value at the time of acquisition (reported under Section II.A.3(d): acquisitions against other Relevant Crypto-Assets)

Both must be reported separately. For example, if a user swaps 5 ETH for 0.2 BTC:

<!-- Disposal side: ETH disposed of -->
<TransactionSummary>
  <TransactionType>EXCHANGE_CRYPTO</TransactionType>
  <SubType>DISPOSAL</SubType>
  <NumberOfTransactions>5</NumberOfTransactions>
  <AggregateGrossProceeds currCode="EUR">9000.00</AggregateGrossProceeds>
  <CryptoAssetDetails>
    <AssetCode>ETH</AssetCode>
    <TotalUnits>5.00000000</TotalUnits>
  </CryptoAssetDetails>
</TransactionSummary>

<!-- Acquisition side: BTC acquired -->
<TransactionSummary>
  <TransactionType>EXCHANGE_CRYPTO</TransactionType>
  <SubType>ACQUISITION</SubType>
  <NumberOfTransactions>5</NumberOfTransactions>
  <AggregateAcquisitionValue currCode="EUR">9000.00</AggregateAcquisitionValue>
  <CryptoAssetDetails>
    <AssetCode>BTC</AssetCode>
    <TotalUnits>0.20000000</TotalUnits>
  </CryptoAssetDetails>
</TransactionSummary>

> Note: The exact XML element names (e.g., SubType, AggregateAcquisitionValue) are illustrative. Always refer to the official XSD schema for the correct element names. The key point is that both the disposal and acquisition legs must be reported as separate entries.

> Caution: There is a risk of double-reporting if both platforms involved in a swap report the same transaction. Since DAC8 reporting is per-RCASP, you report only the transactions that occur on your platform.

Handling Stablecoin Pairs

Swaps involving stablecoins (e.g., USDT to BTC) are still crypto-to-crypto transactions even though the stablecoin approximates fiat value. Treat them the same as any other crypto-to-crypto swap:

<TransactionSummary>
  <TransactionType>EXCHANGE_CRYPTO</TransactionType>
  <NumberOfTransactions>30</NumberOfTransactions>
  <AggregateGrossProceeds currCode="EUR">42000.00</AggregateGrossProceeds>
  <CryptoAssetDetails>
    <AssetCode>USDT</AssetCode>
    <TotalUnits>45360.00000000</TotalUnits>
  </CryptoAssetDetails>
</TransactionSummary>

The valuation of the stablecoin disposal is straightforward since USDT closely tracks 1 USD, but you must still convert to the reporting currency (EUR) and use the actual market price, not a fixed 1:1 assumption.

Price Feed Requirements

For reliable FMV determination, your platform should:

  1. Record the price at execution time. Store the price used for each trade at the moment it executes. Do not rely on end-of-day prices for intra-day trades.
  1. Use your own platform prices when available. If the trade occurred on your order book, the execution price is the most accurate FMV.
  1. Fall back to external price feeds. For assets that do not trade on your platform against fiat, use reputable market data providers (e.g., CoinGecko, CoinMarketCap, or institutional data feeds).
  1. Document your methodology. Tax authorities may ask how you determined FMV. Maintain records of your price sources and any fallback logic.

Aggregation for Crypto-to-Crypto

Follow the same aggregation rules as other transaction types:

  • Aggregate per user, per transaction type, per crypto-asset
  • Sum FMV values (in reporting currency) for AggregateGrossProceeds
  • Sum crypto-asset units for TotalUnits
  • Count transactions for NumberOfTransactions

SQL Example

SELECT
    s.user_id,
    s.disposed_asset AS asset_code,
    COUNT(*) AS num_transactions,
    ROUND(SUM(s.disposed_amount * p.price_eur), 2) AS aggregate_fmv_eur,
    SUM(s.disposed_amount) AS total_units
FROM swaps s
JOIN price_snapshots p
    ON p.asset = s.disposed_asset
    AND p.snapshot_time = s.executed_at
WHERE s.status = 'COMPLETED'
  AND s.executed_at >= '2026-01-01T00:00:00Z'
  AND s.executed_at < '2027-01-01T00:00:00Z'
GROUP BY s.user_id, s.disposed_asset;

Common Challenges

  1. Illiquid assets. For tokens with very low trading volume, FMV can be unreliable. Use the best available data and note any material uncertainty.
  1. DEX aggregation. If your platform routes orders through decentralised exchanges, ensure you capture the actual execution price, not the quoted price.
  1. Multi-hop swaps. If a user swaps A to B to C in a single transaction (via an automated routing engine), determine whether this should be reported as one transaction (A to C) or two (A to B, B to C). Follow the OECD CARF guidance on the definition of an exchange transaction.
  1. Wrapped tokens. Wrapping (e.g., ETH to WETH) may or may not constitute an exchange depending on the jurisdiction's interpretation. Treat cautiously and follow available guidance.
  1. Price discrepancies. If the FMV of the disposed asset and the FMV of the acquired asset differ significantly (beyond normal spread), investigate whether the price data is accurate.

Need help with DAC8 reporting?

Our team handles XML generation, TIN validation, and submission for CASPs across all 27 EU Member States.

Get Expert Help