Regulatory licences and tax reporting status do not fully coincide
UK HMRC guidance brings certain operators that transact for customers or provide a means of transacting within the scope of reporting crypto asset service providers, and the specific UK nexus and asset classes must still be assessed. A platform's self-description as a payment instrument or technical interface, or its lack of an exchange licence, is not sufficient to exclude tax reporting obligations; conversely, pure software cannot be swept in merely because it involves a wallet. Each item should be checked against actual functions, transaction methods and local definitions.
Use clear dates to distinguish collection, reporting and exchange
As of 29 October 2026, the UK rules require relevant data collection from 1 January 2026, and the first report covering 2026 must be submitted to HMRC by 31 May 2027. New Zealand's official guidance sets the first reporting period as 1 April 2026 to 31 March 2027, with the first reporting deadline on 30 June 2027. These two examples show that even where CARF is adopted, business systems cannot be configured with a single globally uniform reporting cycle. Exchange arrangements between tax authorities must also be verified separately.
Hypothetical scenario: KYC completed does not mean tax information is sufficient
Assume the platform has collected a customer's passport and registered address, but has no tax residence, tax identification number or appropriate self-certification. Completion of identity due diligence does not equal satisfaction of tax reporting. Corporate customers may also require identification of relevant controlling persons under local rules. The reasonableness of information and changes to it should be checked, and nationality, mobile phone country codes or company registration place must not be treated directly as the entirety of tax residence.
Do not promise customers that "the tax authorities will not know"
Whether information is exchanged with a particular region depends on the implementing rules, effective exchange relationships, customer identity and the scope of reporting. It cannot be broadly claimed that all on-chain transactions will be automatically transmitted to mainland China in real time, nor can it be guaranteed that they will not become known. Platforms should explain the statutory purpose of reporting and retain correction and objection-handling mechanisms. The reporting obligation and whether a customer actually owes tax are two separate matters, and a platform's submission of data does not itself replace the customer's tax analysis.
Finance, compliance and engineering teams should reconcile the same sample set of transactions, covering executions, cancellations, refunds, internal transfers and cross-wallet transfers. How items are specifically classified should follow local reporting specifications, but the system must first be able to retain original records and the correction chain, avoiding treating every wallet movement as a new customer transaction or deleting cancelled transactions entirely. Reconciling reporting results with financial accounts and customer details makes it easier to identify problems than hastily extracting data from the chain at the reporting deadline.
Recommended actions
- Establish a table of collection start dates, reporting periods, filing deadlines and exchange arrangements by operating entity and country.
- Check existing account-opening materials and tax residence self-certifications against local data fields.
- Test transaction classification, fiat valuation, duplicate records and correction procedures, and determine the responsible reporting person.
This content is for general information only and does not constitute legal advice. Please consult a qualified lawyer about specific matters.
References
- Check if you need to report cryptoasset data to HMRC — UK HMRC
- Crypto-Asset Reporting Framework overview — New Zealand Inland Revenue Department (IRD)
- HMRC International Exchange of Information Manual: IEIM8000050 – Commencement — UK HMRC
