The CARF XML schema, section by section

The message header

Every CARF file opens with a header that says what this message is: who is sending it, which tax period it covers, and whether it's a new submission, a correction, or a nil return. This is also where the message carries its unique reference. Get the header wrong, and validators reject the file before they even look at the data, which is why we treat it as its own checkpoint in the piece on the errors that get filings rejected.

The reporting provider block

Next comes the block that identifies the reporting crypto-asset service provider: your legal identity and tax details as the entity on the hook. It's small, but it anchors the whole file, because everything downstream is reported as coming from you.

The user records

The bulk of the file is one record per reportable user. Each carries the identity and tax-residence data you collected at onboarding, the taxpayer identification number, and, for entities, the controlling persons. This is exactly the payload the self-certification and TIN validation workflow exists to produce, and it's why due diligence is an onboarding task, not a year-end scramble.

The transaction data

Attached to each user is their reportable activity for the period: disposals, and in some cases transfers and retail payments above the threshold, aggregated the way the schema expects rather than listed raw. The values have to be computed on the right cost basis and expressed in the right currency before they ever reach the file.

Why the shape matters for your build

Reading the schema top to bottom is really a map of where your data has to come from: identity from onboarding, tax residence from self-certification, amounts from a reconciled transaction ledger. Our CARF and DAC8 reporting platform assembles all of it into a valid file and validates before submission, and for the jurisdiction-by-jurisdiction differences in that file, see CARF vs DAC8 XML. The OECD exchange-of-information hub publishes the schema and its user guide.