CARF due diligence: self-certification for crypto-asset users.

Why the certification carries the file

Everything downstream of due diligence depends on residence. Residence decides whether a user is reportable at all, and which jurisdiction receives the aggregate. A perfectly engineered aggregation pipeline built on unverified residence data produces a file that is internally consistent and substantively wrong — and the error is invisible to schema validation, because the country code is well-formed.

The Crypto-Asset Reporting Framework therefore front-loads the work: the provider obtains a self-certification, tests it against what it already knows, and only then treats the residence as established.

What must be collected

The reasonableness test

A self-certification is not accepted on its face. The provider must confirm it is reasonable, based on the information it obtained in connection with opening the account — including anything gathered under anti-money laundering and customer due diligence procedures.

In practice that means comparing the declared residence against what the onboarding record already contains: identity documents, addresses, contact details and any jurisdiction indicators captured for other purposes. Where the certification contradicts them, it is not reasonable and cannot be relied on until the contradiction is resolved.

• Automate the comparison rather than leaving it to a reviewer. The contradictions are mechanical and the volumes make manual review impractical.
• Record the outcome, not just the certification. The evidence that a reasonableness test was performed is itself part of the file.
• Validate the identification number structurally for the jurisdiction claimed. A number that does not match its jurisdiction’s format is a signal before it is a rejection.

Entity users and controlling persons

Entity users require a classification before anything else, because it decides whether controlling-person data is needed at all. Where the entity is a passive non-financial entity, each controlling person is assessed and, where reportable, reported alongside the entity. The relationship has to be modelled as a first-class record: one entity can have several controlling persons, each with their own residence set and identification numbers.

Providers coming from a purely retail model consistently underestimate this. The entity path is not a variation on the individual path; it is a second data model.

When a certification is not obtained

The framework sets out consequences where a valid self-certification is not obtained or cannot be confirmed as reasonable, and those consequences have to be operationally real rather than nominal. A provider that continues to transact indefinitely with users whose residence is unestablished has a due diligence failure, not a data gap — and it is visible in the filing as a population that never resolves.

Design the remediation path before launch: reminders, escalation, and the point at which the relationship is restricted. Retrofitting a restriction onto an existing user base is a commercial decision as much as a compliance one.

Changes in circumstances

Residence changes. So do entity classifications and controlling persons. The provider needs a trigger framework that catches a change in circumstances — a new address, a new contact jurisdiction, a change in control — and re-obtains a certification where the existing one is no longer reliable.

Two points matter for reporting. The residence used is the position for the reporting period, not the position at filing. And the date a certification was obtained or refreshed should be retained, because it is what evidences that the residence used was the residence established at the time.

REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.