CARF due diligence starts at signup. Here's how self-certification, reasonableness checks, and TIN validation fit into a CASP onboarding flow.
Most of CARF's due diligence isn't a year-end task. It's an onboarding task. The framework expects a reporting crypto-asset service provider to know who its users are tax-resident where, and to have collected that at the point they signed up, not scrambled it together the week a filing is due.
Most of it happens at onboarding. A reporting crypto-asset service provider collects a self-certification of tax residence and TIN when a user signs up, checks it for reasonableness, and validates the TIN format, rather than gathering it all at year end.
It is the user's declaration of their tax residence and taxpayer identification number, plus the controlling persons for entity accounts. The provider must confirm it is reasonable against other information on file before relying on it.
Each jurisdiction's TIN has a defined format, and an invalid TIN is a common reason a CARF filing is rejected. Checking the structure at capture fixes errors early, while the user is still in the flow, instead of at filing time.
Austrian providers must withhold 27.5% KESt on crypto gains. Here's what triggers it, how the moving-average basis works, and how to automate the filing.
Withhold KESt at source and your users' crypto tax is final, no return needed. Use a foreign provider and they self-declare. Here's why the difference matters.
Austria requires the gleitender Durchschnittspreis for crypto, not FIFO. Here's how the moving-average basis works and why it complicates withholding.
Generate an audit-ready report aligned to your jurisdiction. No credit card required.
At onboarding, each user provides a self-certification of their tax residence and taxpayer identification number. For an entity account, you also need to identify the controlling persons and their residences. This is the spine of the whole regime: everything downstream depends on knowing which jurisdictions a user is reportable to.
You can't just store the self-certification, you have to confirm it's reasonable against the rest of what you hold. If a user certifies residence in one country but every signal you have, address, phone country code, IP, points somewhere else, that's a conflict CARF expects you to resolve before you rely on the certification.
A taxpayer identification number has a defined structure in each jurisdiction: length, allowed characters, sometimes a checksum. Validating the format at capture catches a large share of errors before they ever reach a filing, where an invalid TIN is one of the most common reasons a report gets rejected. We go deeper on that in our piece on the CARF XML errors that get filings rejected.
If a user never provides a valid self-certification, you can't just carry on indefinitely. CARF sets a cure period with reminders, and if it lapses, you have to restrict the account. The mechanics of that are worth their own read: see the CARF 60-day rule.
The reason to treat this as one workflow, rather than three bolted-on checks, is that they share data and they feed the filing directly. Our CARF and DAC8 reporting platform captures self-certifications, runs the reasonableness and TIN checks at onboarding, and carries the validated result straight through to the report, so the same facts you collected at signup are the ones you file. If you're scoping this for an exchange, the exchanges and custodians overview shows where it sits in the stack. The OECD's exchange-of-information hub has the source rules.