CARF Customer Transaction Information Reporting: What Data Processing Is Required to Move from On-Chain Records to Tax Reporting?

Key Takeaways

• On-chain transaction records must be linked to customer information, platform-executed trades and account records before they can be used for reporting.
• Transaction classification and valuation must follow the applicable rules. Transaction labels used in business systems cannot be treated as substitutes for reportable transaction categories.
• Customer transaction information reporting serves a different purpose from calculating a business’s own tax liability. The required data fields and calculation methods should be determined separately.
• Reported results should be traceable to source records, with supporting evidence retained for discrepancy resolution, review and correction.

CARF Customer Transaction Information Reporting: What Data Is Needed Beyond On-Chain Records?

The crypto-asset reporting provisions under the EU’s DAC8 have applied since 1 January 2026, making 2026 the first reporting year. Crypto-asset platforms must continuously collect customer information and transaction data, and convert records distributed across wallets, accounts and business systems into reportable information. A platform’s crypto-asset tax reporting process must establish, for each record, who it relates to, what transaction took place, which value should be used, and how the information feeds into the final report.

Consider a customer who deposits ETH into a trading platform, exchanges it for BTC on the platform, and then withdraws the BTC to an external address. On-chain records can be used to reconcile the deposit and withdrawal, while the exchange executed on the platform must be supported by trade details and account records. The team must also establish which customer the records relate to, what type of business activity each asset movement represents, and which price at what point in time should be used to calculate the reportable amount. Simply combining several sets of transaction records does not answer these questions.

This article examines platform reporting of customer transaction information under the Crypto-Asset Reporting Framework (CARF), covering six stages: data ingestion, linking addresses to customers and legal entities, transaction classification, valuation, reconciliation and report generation. The outputs of these stages form the supporting documentation for reporting, allowing the users, transaction categories and amounts in the report to be traced back to source records.

CARF Reporting Data Ingestion: Linking On-Chain Records with Internal Platform Records

Before ingesting data, a business should identify the legal entities, business activities and reporting period covered by the filing, and then determine which records need to be extracted. For the transaction described above, wallet records are used to reconcile deposits and withdrawals, the matching engine records the exchange, the account system records changes in customer balances, and fee details reflect related deductions. On-chain records and internal business records provide different information about the same transaction. During ingestion, the records must be linked, and duplicate records describing the same activity across different systems must be identified.

The data team should use this information to prepare a data-source inventory recording the systems associated with each business activity, the periods available for extraction and any data gaps. After ingestion, time formats, asset identifiers, quantity precision and record IDs should be standardised while the original fields are retained. On-chain transaction hashes, trade IDs and account ledger references should be linked so that the team can determine whether multiple records describe the same business transaction or separate asset movements. Gaps caused by system migrations or interface limitations should be listed separately, together with their scope, retrieval approach and processing status.

Time formats and asset identifiers should be standardised during ingestion. For example, if two systems use local time and Coordinated Universal Time (UTC), the same year-end transaction may appear under different dates. The time zone should therefore be retained when data is extracted, and timestamps should be converted consistently. Asset codes should also be mapped to information such as the relevant network and contract address. The standardised records can then be used for customer and entity identification, transaction classification and amount reconciliation.

CARF Customer Identification: Linking Wallet Addresses, Accounts and Tax Identity

Once data ingestion is complete, each record must be linked to the relevant customer, account and legal entity. In the example scenario, the ETH deposit should correspond to the customer’s account credit, the BTC exchange should be linked to a trade in that account, and the withdrawal should be reconciled against the customer’s instruction and the on-chain outgoing transaction. If the platform uses a shared custodial address, the balance at address level cannot be allocated directly to an individual customer; the internal ledger must also be consulted. For an external receiving address whose ownership cannot yet be confirmed, the information already available and the verification status should be retained. The address should not be designated as a customer-owned wallet without confirmation.

Customer and entity identification also includes tax identity verification. Under the due diligence guidance issued by HM Revenue & Customs (HMRC) in the United Kingdom, a Reporting Crypto-Asset Service Provider (RCASP) must obtain user self-certifications and identify Reportable Users. For certain Entities, the provider must also identify their Controlling Persons and determine whether they are Reportable Persons. Existing Know Your Customer (KYC) records are used to assess whether a self-certification is reasonable, and the tax residence information in the certification must be checked against the onboarding records. Businesses should link each certification, its verification result and the date of any change to the customer master record.

The relationship between an account and its customer or legal entity must also be mapped for the relevant period. For example, a customer may receive a new account ID following a system migration, while historical transactions continue to carry the old ID. The records must be reconciled by mapping the old and new IDs. Where customer information differs across records, the reason should be checked against the self-certification and supporting documents. HMRC guidance requires a new self-certification to be obtained where an existing one no longer meets the reasonableness requirements, or evidence supporting the original certification to be obtained. Account mapping and tax information verification should each have their own processing records.

CARF Transaction Classification: Mapping Asset Movements to Reporting Categories

Once the relationships between addresses and accounts have been established, the team must reconstruct the business activity represented by each asset movement. The example includes a deposit, a crypto-to-crypto exchange and a withdrawal; related fees must also be identified separately. “Incoming” and “outgoing” describe the direction of an asset movement, but the nature of the activity must be determined by reference to orders, contracts, customer instructions and product rules. Transfers of customer assets, movements of the business’s own funds, exchanges and other activities should be mapped to their respective reporting categories. Pledging, lending and rewards should also have documented classification criteria.

The UK HMRC guidance on crypto-to-crypto transactions provides an example. For a reportable ETH-for-BTC exchange, the fair market value of both the asset disposed of and the asset acquired must be reflected separately, with transaction fees deducted in accordance with the guidance, and each side allocated to the relevant reporting category. If a service provider processes only one side of the transaction and does not know which asset the customer received, the guidance requires the transaction to be treated as a Transfer. Classification therefore also depends on the services actually performed by the provider and the information available to it. Businesses can maintain separate mappings for business labels, accounting codes and reporting categories, and record the relationships between them and the versions of the rules applied. Records that cannot yet be classified can be placed in a pending-review queue and assigned to finance and compliance for confirmation before being included in a category.

The basis for each classification decision should be retained. For the deposit, exchange and withdrawal in the example, the relevant account credit, trade details and withdrawal instruction should each be linked to the record, with the reason for the selected category documented. Contracts and funding arrangements associated with transactions carrying the same business label should also be checked to identify transactions that differ in substance. Once classification is complete, each record awaiting valuation should have a clearly identified asset, direction and business category. The corresponding valuation methodology can then be applied.

CARF Transaction Valuation: Determining the Valuation Time, Price Source and Conversion Method

After transactions have been classified, the business must determine the valuation time, price source, conversion currency and fee treatment to be used for each reportable amount. A crypto-to-crypto exchange involves two assets, and quantities alone are not sufficient to generate the reportable amount. The team should retain the quotations and conversion calculations used at the time of the transaction, and reconcile the quantities and fee records for both sides. Transaction-time values and end-of-period balance valuations serve different purposes; an end-of-period price should not be applied retrospectively to all transactions throughout the year.

The UK CARF valuation guidance for Transfers requires reporting at fair market value at the time of the transaction, in a single Fiat Currency, using a reasonable and consistently applied method based on evidence available at that time. The guidance prioritises applicable internal transaction data. Where no suitable reference value is available, the alternatives are, in order, internal book value, third-party price aggregation data, the most recent internal valuation, and, as a last resort, a reasonable estimate. Where one of these alternative methods is used, the method must be indicated in the XML report. The supporting workpapers should retain the price source, quotation time and basis for selecting the method.

Valuation workpapers should also retain the asset quantity, unit price used, conversion exchange rate, reporting currency and fee adjustments so that reviewers can recalculate the amount. Records with missing quotations should be included in a valuation discrepancy log. The process of obtaining a replacement price or applying an alternative method should be documented, after which the reportable amount for the relevant transaction can be updated.

CARF Data Reconciliation: Checking Account Balances, Transaction Classifications and Reportable Amounts

Once transaction-level data has been classified and valued, both the detailed records and the preliminary summaries derived from them must be reconciled. The process can begin with the opening and closing balances of each asset in the customer’s account. Deposits, trades, fees and withdrawals during the reporting period should then be matched item by item, with checks for duplicate records, unlinked accounts and missing prices. When reconciling balances, the team should establish whether fees have already been included in the outflow amount to avoid deducting them twice. Where the platform aggregates or custodies assets, movements in customer accounts should also be distinguished from transfers between wallets, and the balances being compared should first be confirmed to cover the same scope.

For the example transaction, a reviewer should be able to trace the ETH deposit, exchange execution and BTC withdrawal from the customer account, and then verify how those records flow into the report summary. The reviewer may also start with an aggregated amount and sample the underlying records to identify omissions or duplicate aggregation. When a discrepancy is found, its cause, scope, correction method and review result should be recorded. The finance team explains the amounts and their calculation basis; the compliance team checks the reporting scope and classifications; and the data team provides extraction and transformation records. Any unresolved discrepancy should be assigned to a person responsible for handling it and a reviewer.

The results of balance reconciliation and review of the reporting treatment should be documented separately. For example, both sides of an exchange may have been recorded in the account, so the balances still reconcile, even though the disposed-asset category was mapped incorrectly and the classification summary needs to be adjusted. The team should return to the classification or valuation stage, correct the record and regenerate the affected summary. The reconciliation workpapers should also identify the customer, asset and reporting fields involved, ensuring that the report file is generated from the same reviewed version of the data.

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

Validated transaction-level data and summary results must be converted into the reporting fields required by the relevant jurisdiction. Under UK HMRC requirements, information is aggregated by user, Relevant Crypto-Asset and transaction type. The supporting workpapers should preserve the relationship between the underlying records and each reported amount. When generating the file, customer identity, transaction category, asset quantity, amount and reporting currency should be mapped to the corresponding fields. Required fields, code values, data types and logical relationships between fields should also be checked.

Under the UK reporting guidance, the first report covering 2026 must be submitted by 31 May 2027. The report file must be in XML format and comply with both the OECD Schema and HMRC file requirements. After format validation, the team must also review the scope of Reportable Users, transaction classifications and aggregated amounts, complete internal approval and submit the report. The submitted version, acknowledgement receipt and corresponding workpapers should be retained together. HMRC makes clear that where a third party is engaged to submit the report, the reporting entity remains responsible for the accuracy and completeness of the information.

Each file version should be linked to the corresponding data snapshot, classification rules and pricing records. If an error in customer identity or transaction amount is identified after submission, the team should use these records to establish which data was used in the original report, recheck the affected records and arrange for the report to be corrected. Updates to internal data and corrections to reports already submitted should be recorded separately, so that current system data can be reconciled with historical filings.

CARF and DAC8 Reporting Treatment: Distinguishing Customer Transaction Information Reports from Corporate Income Tax Calculations

Platform customer transaction information reports under CARF and DAC8 provide user identity and related transaction information. When calculating its own income tax, a business must also trace asset acquisitions, subsequent disposals and tax adjustments to determine income, cost and gains or losses. The amounts included in transaction information reports serve a different purpose from acquisition cost records, so the two sets of supporting workpapers should be maintained separately.

Reporting formats, filing deadlines and correction procedures are determined by each implementing jurisdiction. The OECD CARF XML guidance is primarily intended to support the exchange of information between tax authorities, and may also be used for domestic reporting where local law permits. Platforms operating across jurisdictions should configure the required fields, aggregation rules and file specifications separately for each jurisdiction while working from the same underlying dataset.

CARF Reporting Workpapers: End-to-End Reconciliation from Source Records to Reportable Fields

Moving from on-chain records to tax reporting requires businesses to link source records, classify business activities, calculate amounts and validate reports. The supporting workpapers should explain the source and processing steps for each reported data item, and retain records of discrepancy corrections and reviews. Finance, compliance and data teams can select a sample of actual transactions and perform an end-to-end reconciliation from source records to reportable fields, assigning each identified data gap to a specific owner and completion date.

For a review of the checks required for the first reporting cycle, please refer to FinTax’s earlier analysis of DAC8 reporting preparation.

To review your business’s transaction data preparation and reporting readiness processes, please contact the FinTax team.

Frequently Asked Questions (FAQ)

Can CARF customer transaction information reports be prepared using on-chain records alone?

Transactions involving platform-executed trades, customer account allocation or off-chain fees also require internal records. Only by linking on-chain records with trade, account and fee details can the transaction flow and the corresponding reportable amount be fully explained.

Can records labelled as “internal transfers” be excluded from CARF transaction classification automatically?

The “internal transfer” label alone is not sufficient to determine the reporting treatment. The entities, service providers and business relationships associated with the sending and receiving accounts must be confirmed. Movements between the business’s own wallets should be distinguished from transfers of customer assets, after which the records can be classified under the applicable reporting rules.

How should valuation gaps for CARF reporting and acquisition-cost gaps for income tax purposes be handled separately?

Valuation gaps and acquisition-cost gaps should be recorded separately. For reporting valuations, missing prices should be obtained or an alternative method applied in accordance with the relevant rules. For income tax calculations of gains and losses, the asset’s acquisition cost must be traced. The calculation basis and review records should be retained for both processes.

Does successful validation of a CARF XML report mean that the filing is complete?

After format validation, the reporting scope, transaction classifications and amounts must still be reviewed, followed by approval, submission and acknowledgement checks. Passing structural validation and ensuring the accuracy and completeness of the report content are two separate checks.