A crypto reporting programme needs a defensible answer to four operational questions: which entity reports, whose information it collects, which transactions enter the return and who approves submission. When customer tax data is spread across onboarding, compliance and transaction systems, product requirements and reporting controls must reflect those decisions.
The implementation scope connects the legal assessment with an entity map, customer-data requirements, remediation rules and a first-report review. It is designed for tax, compliance and product teams coordinating across countries, group companies and reporting vendors.
Platforms and reporting jurisdictions
Start with the legal entity that provides each service. CARF generally covers businesses effectuating exchanges for customers, including intermediaries and trading platforms within its functional definition. A platform's brand, group structure or choice of software does not identify the reporting entity. DAC8 also requires assessment of its MiCA-authorised provider and cryptoasset-operator categories. (OECD CARF, IV.B.1; Directive 2011/16/EU, Annex VI, IV.B.1–3.)
The country analysis then tests tax residence, incorporation, management, business locations and branches, together with applicable authorisation and registration rules. CARF is an international standard implemented through domestic law. Its adoption announcements and exchange commitments do not establish every country's collection dates or filing obligations.
For a UK entity serving customers through an Irish group operation, each entity needs its own assessment. Both countries collect information for 2026, but their reporting rules and relief conditions must be applied separately. UK law also covers UK-resident users and relevant controlling persons; an equal-nexus election abroad does not remove that domestic reporting limb. (SI 2025/744, regs. 3–6; Finance Act 2026, s. 275; Taxes Consolidation Act 1997, ss. 891HA and 891M.)
Any reliance on reporting elsewhere needs evidence that the applicable conditions are met. Tax registration also supplies no permission to provide cryptoasset services. UK regulatory requirements and EU MiCA authorisation must be checked separately before the service proceeds. (Regulation (EU) 2023/1114, arts. 59–61.) The underlying allocation questions are explored in CARF and DAC8 reporting across an international platform.
Customers, assets and transactions in scope
Customer classification must distinguish individuals, entities, excluded persons and controlling persons. An entity can itself be reportable even where its active status removes controlling-person look-through. An entity outside a reportable jurisdiction can still have reportable controlling persons. Trusts require the relevant control roles to be captured, beyond a corporate shareholding field. (OECD CARF, III.B and IV.D–E; Directive 2011/16/EU, Annex VI, III.B and IV.D–E.)
Asset decisions require analysis of the token's features and use. Stablecoins and NFTs are not excluded simply by their labels. The exclusions for central bank digital currencies, specified electronic-money products and assets that cannot be used for payment or investment have defined conditions. (OECD CARF, IV.A; Directive 2011/16/EU, Annex VI, IV.A.)
The transaction map covers exchanges against fiat, crypto-to-crypto exchanges, reportable retail payments and relevant transfers. Both sides of a crypto-to-crypto exchange need the required reporting treatment. Transfers to an external wallet can be reportable even without a sale. The USD 50,000 threshold concerns the defined retail-payment category; it is not a general exemption for smaller transactions. (OECD CARF, II.A.3 and IV.C; Directive 2011/16/EU, Annex VI, II.B.3 and IV.C.)
Each classification should connect to source records, valuation rules and the prescribed aggregates. The reporting obligation does not itself determine whether a transaction creates a taxable gain.
Tax residence, TINs and incomplete accounts
New onboarding needs a valid tax self-certification at the start of the relationship. The data model should capture all tax residences, relevant tax identification numbers, identity details, entity status and controlling-person information, with the customer's affirmation and date. Compliance must check whether the certification is reasonable against the information already held. A valid-looking TIN format does not establish the customer's tax residence. (OECD CARF, III.A–C; Directive 2011/16/EU, Annex VI, III.A–C.)
Historical accounts need a dated remediation queue. In the UK and Ireland, the initial review of pre-existing users must be completed by 31 December 2026. A missing TIN needs a documented explanation and the applicable country's exception, where available; an unanswered request does not establish an exemption. Existing CRS certifications can be reused only where they meet the relevant CARF or DAC8 requirements. (HMRC, IEIM8000470; Irish Revenue, Tax and Duty Manual 38-03-38, §§6–7; OECD CARF, III.C–D.)
The workflow should assign requests, evidence review, escalation and transaction restrictions to named owners. In Ireland, failure to provide the required information after two written reminders triggers prevention of the relevant transactions once 60 days have elapsed from the second reminder. The product rule must reflect that national timetable. (Taxes Consolidation Act 1997, ss. 891HA(10) and 891M(12).)
Changes of circumstances require a fresh assessment when the existing certification becomes unreliable. For the UK CARF rules, unresolved changes after the permitted remediation period require treatment under both the original and newly indicated residences. The 90-day provision is not a general onboarding grace period. (SI 2025/744, reg. 2; OECD CARF Commentary, III, para. 17.)
Tax requirements should connect with AML and KYC programme work, with separate decisions where the regimes differ. Retain the evidence, historical values and reasons for each classification so a later change does not erase the basis of an earlier return.
From source data to an accepted return
The reporting calendar must distinguish collection, registration, customer notification, filing and exchange between authorities. For the 2026 calendar year, UK and Irish provider returns are due by 31 May 2027. The UK also requires the initial reporting notification by 31 January 2027. Ireland requires the prescribed information to be given to the user by the return deadline. DAC8's 30 September 2027 deadline concerns the first exchange between tax authorities. (SI 2025/744, regs. 6 and 8; Taxes Consolidation Act 1997, ss. 891HA(5) and 891M(6); Directive 2011/16/EU, art. 8ad(6).)
Tax and legal teams should approve the entity, country and classification decisions. Compliance owns the evidence and remediation decisions. Product and engineering implement the required fields, transaction attribution, restrictions and data extraction. The reporting operator prepares and submits the return under the provider's authority. External tax review, engineering delivery and operational filing need express allocations in the engagement and vendor schedules.
Outsourcing due diligence does not transfer the provider's responsibility. Vendor terms should secure access to evidence, change notifications, correction support, audit records and data export on exit. CRS and AML information can support the work, but neither replaces the crypto reporting assessment. (OECD CARF, III.D; Directive 2011/16/EU, Annex VI, III.D.)
Before filing, reconcile source totals to the report, test the national format and validation rules, resolve exceptions and retain the submission receipt and correction history. Retention also needs a country rule: UK records generally run for five years from the end of the relevant collection, generation or reliance year; Ireland generally requires six years after the reporting period, with an extension for an unfinished enquiry. (SI 2025/744, reg. 4(3)–(4); Taxes Consolidation Act 1997, ss. 891HA(11) and 891M(13).)
Implementation deliverables and required inputs
The proposed scope produces five connected deliverables:
- An entity-and-obligation map identifying each provider, legal nexus, reporting country, registration route, claimed relief and evidence needed before relying on it.
- A customer-data dictionary linking identity, tax residence, TIN, entity status, controlling persons and transaction fields to their source systems and validation rules.
- Onboarding and remediation requirements covering certification, reasonableness, missing information, changed circumstances, restrictions and an auditable decision record.
- A responsibility schedule allocating legal decisions, compliance review, engineering changes, vendor tasks, tax approval, submission and corrections.
- A country calendar and first-report review plan covering national deadlines, required formats, retention, reconciliation and acceptance evidence.
Scoping requires the group chart, service and customer contracts, entity and branch locations, customer-country mix, product and token list, onboarding forms, transaction samples, existing CRS and AML procedures, and vendor agreements. Data samples should be limited to what the assessment needs.
The work proceeds from entity and activity classification to data and process requirements, then readiness review. Unresolved nexus, missing evidence or a failed reporting reconciliation needs a named owner and resolution before the affected decision is approved. Engineering implementation, external tax sign-off and operational submission must be assigned expressly when the scope is agreed.
Scope the reporting implementation
Bring the entity structure, current onboarding fields and proposed reporting-country list. Licentium can scope the legal assessment, document changes and review responsibilities needed to turn them into an implementation plan. Scope a reporting implementation.