CARF / DAC8 Reporting – Overview (Scope, Data & XML Output)
CARF reporting requires Crypto-Asset Service Providers (CASPs) to identify reportable users and transactions and submit standardized CARF data outputs (typically XML-based), aligned to local implementation requirements and validation rules (including DAC8 alignment in the EU).
Competent Authority
OECD (framework owner); implemented locally via national competent authorities (e.g., EU DAC8 implementations)
Submission Method
Electronic submission via the relevant national competent authority reporting channels, based on local CARF/DAC8 implementation and portal/gateway requirements.
Reporting Format / Schema
OECD CARF XML (CARF schema / standardized exchange format)
Deadlines & Timelines
- CARF/DAC8 reporting is typically submitted on a recurring reporting cycle (commonly annual), for the relevant reporting period.
- Submission dates and correction windows depend on local implementation rules.
- Controlled corrections/resubmissions are important due to the volume of transaction-level data and the risk of duplicates.
Common Pitfalls
In-scope / out-of-scope determination for CASP activities
Misidentifying which services and transactions fall under CARF/DAC8 can lead to under-reporting or over-reporting, especially where business models include custody, brokerage, exchange, or transfer services.
Customer identification and tax residence data gaps
Missing or inconsistent customer identity attributes (name, address, date of birth for individuals, entity identifiers) and incomplete tax residence/TIN data frequently break validation and create remediation cycles.
Wallet address and transaction linkage issues
Difficulty linking on-chain addresses, custody accounts, and off-chain identifiers can result in incomplete transaction reporting, mismatched parties, or unclear beneficial ownership contexts.
Asset classification and instrument mapping errors
Misclassifying crypto-assets (or mis-mapping product types) leads to incorrect reportable event tagging, wrong valuation handling, and inconsistent outputs across reporting periods.
Valuation methodology inconsistencies
Inconsistent valuation sources, timestamps, FX conversion rules, or rounding logic can create large reconciliation gaps and trigger rework, particularly for high-volume trading activity.
Duplicate transactions and correction logic
Without a stable transaction identifier strategy and controlled correction workflow, resubmissions can create duplicates and break reconciliation against internal ledgers and customer statements.
High-volume data quality failures
Transaction-level reporting creates scale challenges: missing mandatory fields, invalid codes, inconsistent timestamps, and “schema-pass but business-rule-fail” outputs.
How REGREP supports this
REGREP supports CARF/DAC8 reporting by structuring CASP customer and transaction data into a consistent reporting model, applying validation checks to improve data quality, generating standardized CARF XML outputs aligned to local implementation requirements, and supporting controlled corrections/resubmissions with audit-friendly traceability.
Last Reviewed: 2026-01-31
This page provides high-level regulatory reporting information for operational and technical context only and does not constitute legal, tax, or compliance advice.
