CARF readiness is an evidence problem before it is a filing problem

Crypto-Asset Reporting Framework (CARF) preparation is often described as a future reporting project. That description is too late. The difficult work begins before a reporting portal, XML schema or annual return: a firm must be able to show which group entities and services fall within scope, where the reporting nexus lies, whose tax residence has been established, which transactions are reportable, and how the final annual figures can be traced to reliable source records. A late filing process cannot repair a weak customer, transaction or ownership record.

For Hong Kong practices, the immediate message is readiness rather than premature compliance claims. The Inland Revenue Department (IRD) says Hong Kong has committed to conduct its first CARF automatic exchanges in 2028, conditional on domestic legislation being in place by 2026. The CARF/CRS Bill was gazetted in May 2026 and, subject to passage, CARF amendments are proposed to operate from 1 January 2027.[1] Those qualifications matter. The Bill-dependent registration, retention and penalty provisions described by the IRD must not be represented as enacted obligations today.

Nevertheless, CPA firms and TCSPs have a material role now. Some will advise potential reporting crypto-asset service providers (RCASPs). Some will provide accounting, tax, corporate, trust, beneficial-ownership or compliance services to groups with crypto-asset activities. Others may be asked to assess data or controls. Each should distinguish carefully between a client that is actually an RCASP and an adviser whose role is to help build a defensible readiness process. The best way to do so is to build one controlled chain from activity to nexus, user, transaction, report and retained evidence.

Start with a status map: Hong Kong’s pathway versus Singapore’s operating example

Hong Kong’s framework provides a local direction of travel. An RCASP with a Hong Kong nexus would, subject to the Bill’s passage, face CARF registration, due diligence and reporting from 1 January 2027. The IRD lists nexus through tax residence, incorporation or organisation, management, or a regular place of business including a branch. It also says an RCASP can have multiple nexuses, with a hierarchy intended to avoid duplicate reporting.[1] A group with a Hong Kong branch, management function or platform-support activity should therefore not assume that incorporation alone resolves the analysis.

Singapore supplies a useful—but legally separate—operating benchmark. Its CARF regulations were enacted in August 2026, and the Inland Revenue Authority of Singapore (IRAS) published an e-Tax Guide explaining due diligence, electronic self-certification, reporting and record controls.[2] Singapore’s first exchange intention, reporting dates and five-year retention periods are not Hong Kong requirements. They are useful because they illustrate the sort of operational evidence that a tax administration may expect when a CARF regime moves from policy to production.

A firm should keep a concise status map in its project file. It should place every control into one of three columns: Hong Kong official direction or current source material; Hong Kong Bill-dependent detail awaiting passage or further IRD specification; and comparative design evidence from Singapore or another jurisdiction. EY’s May Hong Kong alert provides a useful independent summary of the Bill’s gazettal, first-reading timetable and the intended 2027 and 2028 introduction of CARF and amended CRS.[3] This separation protects clients from two opposite errors: postponing readiness until every local detail is available, or importing foreign dates and requirements as if they were Hong Kong law.

The EQC CARF evidence chain

EQC recommends viewing CARF readiness through a six-link evidence chain: activity, nexus, user, transaction, return and retention. A gap at one link contaminates the next. For example, a complete annual transaction extract is not useful if the entity performing the activity was not classified correctly; a valid self-certification is not sufficient if a change of circumstances was ignored; and a correct return is difficult to defend if the data transformation from wallet or platform record to aggregated report cannot be reconstructed.

The chain is deliberately broader than an annual tax return. It incorporates group structure, business process, client onboarding, beneficial ownership, AML/KYC information, ledger and wallet data, vendor interfaces, approval decisions and archival evidence. It is therefore a useful common language for tax partners, crypto specialists, client-service teams, technology staff, risk personnel and external service providers. It also makes the readiness project auditable: every link has an owner, inputs, control objective, evidence output, exception route and periodic test.

1. Activity and nexus: classify the service before classifying the data

The first question is functional, not branding-based: does an individual or entity, as a business, provide a service that effectuates exchange transactions in relevant crypto-assets for or on behalf of customers? The IRD explains that an RCASP can act as counterparty or intermediary, or make a trading platform available. Its examples include dealers, crypto ATMs, exchanges acting as market makers, brokers and certain distribution activity.[1] The analysis should document what each entity actually does, who contracts with the customer, who controls the platform or wallet, who executes or intermediates transactions, and where those functions are carried out.

Then map nexus. Do not treat a branch, Hong Kong management team or regular place of business as a footnote. Document tax residence, incorporation or organisation, management location, regular places of business and transaction routing by branch. Where more than one jurisdiction could have nexus, retain the analysis that applies the relevant hierarchy. A CPA firm should not issue an RCASP conclusion from a single group chart. It should ask for service agreements, workflow maps, system-access roles, operational manuals, customer terms and transaction-flow evidence.

For TCSPs, the immediate task is often different. A TCSP may not be an RCASP, but may form or administer entities, provide registered office services, maintain beneficial-ownership files, or assist groups that operate platforms. Its file should record whether the client’s activity creates a CARF assessment trigger and which party owns the classification analysis. Escalation triggers include a new wallet or exchange business, a change in management location, a new branch, a move from technology support to customer-facing execution, or an acquisition of a crypto-related entity.

2. User and controlling-person evidence: make self-certification an operating control

The IRD states that RCASPs must obtain and confirm the reasonableness of self-certifications from crypto-asset users and relevant controlling persons when onboarding new customers. For pre-existing users, it describes a 12-month period after CARF operates to obtain and validate the certification. A change of circumstances that makes an original self-certification incorrect or unreliable requires a fresh valid self-certification, or a reasonable explanation and supporting documentation.[1] This is an operating process, not a form-collection exercise.

The control design should connect tax-residence data to existing onboarding and AML/KYC records without assuming the two systems answer the same question. A user attestation should collect required residences and taxpayer identifiers where relevant. The reviewer should compare it with available identity documents, address, incorporation data, beneficial-ownership information, contact details and other relationship information. Where the records conflict, the case should enter an exception queue. The outcome must show whether a new certification, explanation, supporting document, restriction or escalation was obtained.

Singapore’s e-Tax Guide demonstrates why electronic design matters. It says an electronic self-certification system should preserve the information sent, document user-access events connected with submission, renewal or modification, verify that the accessor is the named person, and be capable of producing a hard copy on request.[2] This is a Singapore-specific control description, not a Hong Kong requirement. It is nevertheless a sound benchmark for asking a practical question: if a reviewer picked one user record a year later, could the business prove who made the attestation, what they saw, when they affirmed it and how any later change was handled?

3. Transaction lineage: reconcile the economic event, not only the exported file

CARF-relevant transactions include exchanges between relevant crypto-assets and fiat currencies, exchanges between relevant crypto-assets, and transfers of relevant crypto-assets, including reportable retail payments and transfers to or from external wallet addresses.[1] The reporting data must be aggregated by relevant crypto-asset and transaction type. That means a successful control design cannot begin with a spreadsheet at year-end. It needs a documented population of source systems, wallet addresses, platforms, custody arrangements, counterparties, transaction statuses, rates or fair-value data where applicable, reversals and adjustments.

Build a lineage record for each data field that could reach a return: field name, business definition, source system, owner, extraction method, transformation, validation, exception treatment, reporting aggregation and retention location. Reconcile the population to independent anchors, such as platform activity, wallet records, settlement data, customer accounts, revenue records or management reporting. The suitable anchor depends on the business model. The control objective is consistent: the firm should know that the population is complete before it tests the accuracy of individual rows.

A sample test should follow a transaction in both directions. From a reportable output, trace back to the platform or wallet event, user record, transaction attributes and supporting evidence. From a source population, trace forward to the correct reportable category, aggregation, exclusion or exception. This two-way testing exposes missing external-wallet transfers, duplicated internal transfers, incorrect customer linkage, inconsistent asset identifiers and manual spreadsheet adjustments. It also produces a more credible workpaper than an unexplained system report.

4. Return, nil return and retention: assign accountability before the portal exists

The IRD says it will develop a CARF Portal and publish a data schema. The Bill proposes that every RCASP meeting the nexus rules register even when it has no information to report, and register by 31 January following the calendar year in which it first meets a nexus criterion.[1] The IRD also describes proposed six-year record keeping after the relevant return due date, covering due-diligence evidence, steps taken and information used to establish reporting accuracy. These provisions remain Bill-dependent, but they are sufficiently concrete to justify an accountable owner, project plan and evidence architecture now.

The control question is not simply “who presses submit?” Assign ownership for classification, customer data, controlling-person information, transaction completeness, aggregation, technical schema preparation, review, declaration, submission evidence, error correction and post-submission monitoring. Document the service-provider boundary. The IRD says RCASPs may engage service providers to carry out obligations, but an outsourcing arrangement should not make the principal entity unable to evidence the work performed. Contracts should specify data access, service levels, exception handling, retention, audit rights, change notification and responsibility for correcting identified errors.

Singapore’s guide is a helpful comparator because it envisages annual returns and nil returns, and requires evidence of due diligence and transactions to be retained under its own rules.[2] Use it to test the completeness of a process design, not to set Hong Kong deadlines or retention periods. The Hong Kong project file should include a requirements-status register that is reviewed when the Bill, Portal, jurisdiction lists and data schema are updated.