Most CARF questions aren't about the easy 90%. Here's how the framework treats DeFi interfaces, withdrawals to self-custody, and payments for goods.
The straightforward part of CARF, a user buys and sells on your centralised venue, is easy to reason about. The questions that keep compliance teams up are the edges: the DeFi front-end, the withdrawal to a wallet you don't control, the coffee bought with crypto. None of them are as exotic as they first look, but each needs a deliberate answer.
It can. CARF targets providers that facilitate transactions for users, which can include front-ends to decentralised protocols. The test is what service you provide to the user, not whether settlement happens on a protocol, so each product should be mapped to that question.
Certain transfers to wallets outside the regulated system are reportable, so that value doesn't disappear from the record at the edge. You need to identify which outbound transfers qualify and capture the data when they happen.
Yes, a payment for goods or services is a disposal, and CARF brings retail payments above a set value into scope. Reporting has to recognise the payment, apply the threshold, and value it in the right currency.
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.
CARF is aimed at providers who facilitate transactions for users, and that can reach interfaces that sit in front of decentralised protocols, not just classic exchanges. If you provide a service that effects transactions on users' behalf, the fact that settlement happens on a protocol doesn't automatically put you outside scope. The test is what you do for the user, so map each product to that question rather than assuming DeFi is exempt.
When a user withdraws to a wallet you don't control, you lose sight of the asset, and CARF treats certain transfers as reportable precisely so that value doesn't vanish from the record at the edge of the regulated system. Knowing which outbound transfers you have to report, and capturing the data at the moment they happen, is one of the less obvious build requirements.
Spending crypto on goods and services is a disposal, and CARF brings retail payments above a set value into scope. That means your reporting isn't only about trades; it has to recognise a payment for what it is and apply the threshold correctly, in the right currency, which the CARF XML schema expects as structured data rather than a raw log.
The through-line is that edges need classification, not assumptions, and classification needs data captured when the event happens. Our CARF and DAC8 reporting platform ingests activity across exchange, custody and on-chain sources, classifies disposals, transfers, and retail payments per transaction, and applies the thresholds so the hard cases end up in the file correctly. For the residence side of scope, see nexus under CARF, and the OECD exchange-of-information hub for the source rules.