On-chain transaction data is insufficient to support tax declarations; platforms need to integrate multi-source data to meet DAC8 compliance requirements.

Written by: FinTax

Key Information:

• On-chain transaction data needs to be associated with customer information, transaction records within the platform, and account records to form reportable data.
• Transaction classification and valuation should be processed according to applicable rules; transaction labels in the business system cannot directly replace report categories.
• Client transaction information reporting is different from the company's own tax calculation purposes; required fields and calculation methods should be confirmed separately.
• The declaration results should be traceable to original records and retain information on discrepancies, reviews, and corrections.

CARF Client Transaction Information Report: What Other Data Is Needed Besides On-Chain Transaction Data?

The EU DAC8 regulations regarding the reporting of crypto assets will apply starting January 1, 2026, with 2026 being the first reporting year. Trading platforms need to continuously collect customer information and transaction data and transform records scattered across wallets, accounts, and business systems into reportable information. The process of crypto asset tax declaration for the platform requires identifying who each record corresponds to, what transactions occurred, what values were used, and how to form the final report.

Imagine a client depositing ETH into a trading platform, exchanging it for BTC within the platform, and then withdrawing the BTC to an external address. On-chain records can be used to verify deposits and withdrawals, while the internal exchange requires detailed transaction and account records for support. The team must also confirm which client these records correspond to, what business the asset changes belong to, and what price should be used to calculate the report amounts. Simply merging a few transaction records is still unable to answer these questions.

This article focuses on the platform's client transaction information report under CARF (Crypto Asset Reporting Framework) and systematically sorts through six aspects: data access, address and entity association, transaction classification, valuation, verification, and report generation. The outcomes of each process collectively form the basis for declarations, ensuring that users, transaction categories, and amounts in the report can be traced back to original records.

CARF Declaration Data Access: Associating On-Chain Transactions with Internal Records

Before data access, the company should clarify the legal entities, business scope, and reporting periods involved in this declaration, and then determine which records need to be extracted. For the transactions mentioned above, wallet records are used to verify deposits and withdrawals, the matching system retains exchange transactions, and the account system records changes in customer balances, with fee details reflecting related deductions. On-chain records and internal business records provide different information for the transaction; correspondence must be established during access, and systems must identify duplicate records for the same transaction.

The data team establishes a data source list based on this to record the systems corresponding to each business, the extractable periods, and any missing data. After access, standardize the time format, asset identification, quantity precision, and record numbers while preserving the original fields. The on-chain transaction hash, transaction number, and account transaction number should be related, allowing the team to determine whether several records describe the same transaction or different asset changes. Gaps caused by system migration or interface limitations should be separately documented, identifying impact ranges, retrieval methods, and processing statuses.

Time and asset identifiers need to be standardized during access. For example, if two systems use local time and Coordinated Universal Time (UTC) respectively, the same year-end transaction may appear as different dates, and data extraction must retain the timezone and uniformly convert it. Asset codes should correspond to the network, contract address, and other information. The standardized records are then used for subsequent entity association, transaction classification, and amount verification.

CARF Client Identification: Associating Wallet Addresses, Accounts, and Tax Identities

After completing data access, it is necessary to confirm the corresponding client, account, and related legal entities for each record. In the hypothetical scenario, the ETH deposit should correspond to the client's incoming record, BTC exchange should be traceable to the account's transaction, and withdrawals should be verified against customer instructions and on-chain outgoing records. If the platform uses a shared custodial address, balances at the address level cannot be directly allocated to an individual client and must still be verified against internal accounts. For external receiving addresses whose ownership is temporarily unconfirmed, the information and verification status obtained should be preserved, and they should not be directly marked as customer-owned wallets.

Entity association also includes tax identity verification. According to the UK's HMRC due diligence guidelines, reporting crypto asset service providers need to obtain self-declarations from users and identify reportable users. Some entities also need to identify controllers to determine if they are reportable individuals. Existing client identification (KYC) information is used to verify the reasonableness of the declaration, and the tax residency information in the declaration must be cross-verified with account opening documents. The company should associate the declarations, verification results, and change dates with the client main file.

The relationship between accounts and entities should also correspond to specific periods. For example, if a client obtains a new account number after a system migration, historical transactions retain the old number; during verification, mapping must be done using both new and old numbers to confirm record ownership. When discrepancies exist in client information, the reasons should be verified with the declaration and proof materials. The UK HMRC guidelines require obtaining a new declaration for those that no longer meet reasonableness criteria or obtaining evidence to support the original declaration. Account mapping and tax data verification should retain separate processing records.

CARF Transaction Classification: Mapping Asset Changes to Reporting Categories

After clarifying address and account relationships, the team needs to restore asset changes to specific businesses. The aforementioned scenario includes deposits, currency exchanges, and withdrawals, and relevant fees must also be identified separately. "Incoming" and "outgoing" indicate the direction of asset changes, while the nature of the business must be confirmed considering orders, contracts, customer instructions, and product rules. Client asset transfers, internal fund allocations, exchanges, and other businesses should each be mapped to report categories, and scenarios such as staking, lending, and rewards should also have corresponding classification bases.

Taking the UK's HMRC currency exchange guidelines as an example, for reportable ETH to BTC exchange transactions, it is necessary to separately reflect the fair market value of disposed and acquired assets and deduct transaction fees as per guidelines, each classified under the respective report category. If the service provider only processes one end and does not know what asset the client acquired, the guidelines state to process it as a transfer. Therefore, classification also depends on the actual business performed by the service provider and the information available. The company may maintain separate business tags, accounting subjects, and report categories while documenting their correspondence and applicable versions. Records that cannot be classified may temporarily be listed as pending review items, to be classified into the appropriate categories after confirmation by finance and compliance.

Classification results must retain the basis for judgment. For deposits, exchanges, and withdrawals in the example, they should be linked to incoming records, transaction details, and withdrawal instructions to explain the reasons for adopting the corresponding categories. Contracts and funding arrangements under the same business tag also need to be verified to identify substantively different transactions. Upon completing classification, each record pending valuation should clearly indicate the asset, direction, and business category, with amount calculations made according to the appropriate scope.

CARF Transaction Valuation: Determining Valuation Point, Price Source, and Conversion Basis

After completing transaction classification, it is essential to determine the valuation point, price source, conversion currency, and fee handling methods for each reported amount. The same currency exchange transaction involves two assets, and having only quantities is insufficient to generate report amounts. The team should retain the quotation used and the conversion process at the time of the transaction, verifying the asset quantities and fee records at both ends. Transaction point value and end-period balance valuation serve different purposes and should not retrospectively fill in year-end prices for all transactions.

The UK CARF valuation guidelines for transfers require reporting at the fair market value at the transaction point, using a single fiat currency, and employing methods based on evidence available at the time, which are reasonable and consistently applied. The guidelines prioritize using applicable internal transaction data; in the absence of suitable reference values, internal book value, aggregated third-party price data, the most recent internal valuation, and finally reasonable estimates should be used in turn. When using the above alternative methods, the method must be specified in the XML report, and the price source, quotation time, and basis for choice are retained in the working documents.

The valuation working document retains asset quantities, unit prices, conversion rates, reporting currencies, and fee adjustments, facilitating re-calculation of amounts by reviewers. Records lacking quotations are included in the valuation discrepancy list, documenting the process of retrieving prices or using alternative methods, and subsequently updating the report amounts for the respective transactions.

CARF Data Verification: Verifying Account Balances, Transaction Classifications, and Report Amounts

After transaction details complete classification and valuation, it is necessary to verify the details and the preliminary summary results derived from them. Verification can begin with the beginning and ending balances of customer accounts and various assets, correlating deposits, transactions, fees, and withdrawals during the period to check for duplicate records, unassociated accounts, and missing prices. When checking balances, it should be clear whether fees have been included in the outflow amount to avoid double deductions. For those involving platform aggregation or custody, distinctions should be made between customer account changes and transfers between wallets, confirming that the balances used for comparison fall within the same range.

For the transactions mentioned above, reviewers should be able to trace the ETH deposit, exchange transactions, and BTC withdrawals from the customer account and then check how these records entered the report summary; alternatively, they could sample down from a particular summary amount to confirm whether there are omissions or duplicate collections. When discrepancies are found, reasons, scope of impact, correction methods, and verification results should be recorded. The finance team explains amounts and calculation bases, the compliance team verifies report scope and classifications, and the data team provides extraction and conversion records, with unresolved discrepancies assigned to responsible parties and reviewers.

Balance verification and report scope reviews must each document results separately. For instance, if both ends of a currency exchange have been credited, but the disposal category was misclassified, balances may still match, while classification summaries may need adjustments. The team should return to the classification or valuation steps to correct records and regenerate the affected summaries. The verification working document should also specify the involved clients, assets, and report fields to ensure that document generation uses the same version of data after reviews.

CARF Report Generation and Submission: Field Mapping, XML Validation, and Correction Records

Verified details and summary results need to be converted to report fields required by the tax jurisdiction. The UK HMRC requires summarization by user, related crypto assets, and transaction types, and the working document should retain the correspondence between details and report amounts. During document generation, customer identity, transaction category, asset quantity, amounts, and reporting currencies need to be mapped to corresponding fields, checking required items, code values, data types, and logical relationships between fields.

According to UK reporting guidelines, the first report covering 2026 must be submitted by May 31, 2027. Report files must be in XML format while adhering to both OECD Schema and HMRC document requirements. After completing format validation, the team also needs to verify user scope, transaction classifications, and summary amounts, complete internal approvals, and submit. The version submitted, receipts, and corresponding working documents should be retained. The UK HMRC specifies that when a third party is commissioned to submit, the reporting entity remains responsible for the accuracy and completeness of the information.

Document versions should be linked to corresponding data snapshots, classification rules, and price records. If errors in client identity or transaction amounts are discovered after submission, the team should confirm the original data used in the report, re-verify affected records, and process document corrections. Internal data updates and reports corrections that have been submitted must be documented separately, allowing the current system data to correspond with historical submissions.

CARF and DAC8 Report Standards: Distinguishing Client Transaction Reporting from Corporate Income Tax Calculations

The client transaction information report on the platform under CARF and DAC8 provides user identities and related transaction data. When a company calculates its own income tax, it must also trace asset acquisition, subsequent disposals, and tax adjustments to determine income, costs, and gains and losses. The report amounts for transaction information serve different purposes than acquisition cost, and the two types of working documents should be maintained separately.

Report formats, declaration deadlines, and correction procedures are specifically defined by each implementing jurisdiction. The OECD CARF XML guidelines are primarily used for information exchange between tax authorities but may also be used for domestic reporting where local laws permit. Cross-jurisdiction platforms should configure the required fields, summary standards, and document rules based on a single set of fundamental data.

CARF Declaration Working Document: Full Process Verification from Original Records to Report Fields

From on-chain transaction data to tax declaration, companies need to complete the associations of original records, business classifications, amount calculations, and report verifications. The declaration working document should explain the origins and processing of each report data point and retain records of discrepancies, corrections, and reviews. Finance, compliance, and data teams can select a set of actual business samples to complete a full verification process from original records to report fields, ensuring that the identified data gaps are assigned to specific handlers and completed on time.

For information verification related to the first reporting period, please refer to FinTax's previous analysis of DAC8 reporting preparations.

Frequently Asked Questions FAQ

Can CARF Client Transaction Information Reports be completed solely based on on-chain transaction data?

Businesses involving internal transactions, client account allocations, or off-chain fees require obtaining internal records simultaneously. Only after associating on-chain transaction data with transaction, account, and fee details can the complete transaction process and its report amount be adequately explained.

Can CARF transaction classifications directly exclude records marked as "internal transfers"?

The "internal transfer" label is insufficient to determine report handling. It should confirm the entities of the outgoing and incoming accounts, service providers, and business relationships, distinguishing between internal wallet allocations and client asset transfers before classifying according to reporting rules.

How should the gaps in CARF report valuation be handled separately from acquisition cost gaps for income tax?

Register valuation gaps and acquisition cost gaps separately. Report valuations should retrieve prices according to corresponding rules or use alternative methods; income tax profit and loss calculations need to trace acquisition costs. Both types of processing should retain calculation bases and review records.

Does passing XML file validation for CARF reports mean that the declaration is complete?

After completing format validation, the report scope, transaction classifications, and amounts still need to be reviewed, approvals completed, submitted, and receipts checked. Passing structural validation and ensuring the accuracy and completeness of the report content are two different verification matters.