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 easy part of CARF is easy to reason about: a user buys and sells on your centralised venue. What keeps compliance teams busy is the edges. A DeFi front-end. A withdrawal to a wallet you don't control. A coffee bought with crypto. None of them are as strange as they first look, though each one needs a deliberate answer.
CARF aims at providers who facilitate transactions for users. That reach can extend to interfaces sitting in front of decentralised protocols, well beyond classic exchanges. If you run a service that effects transactions on users' behalf, settlement happening on a protocol doesn't put you outside scope on its own. What matters is what you do for the user. So map each product to that question instead of assuming DeFi is exempt.
Withdraw to a wallet you don't control and the asset drops out of your sight. CARF treats certain transfers as reportable for exactly that reason, so value doesn't vanish from the record right at the edge of the regulated system. Which outbound transfers you report, and capturing the data the moment they happen, is one of the less obvious things you have to build.
Spending crypto on goods and services is a disposal, and CARF pulls retail payments above a set value into scope. Your reporting, then, covers more than trades. It has to recognise a payment as a payment 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: edges have to be classified rather than guessed at, and classification depends on data captured when the event happens. Our CARF and DAC8 reporting platform reads your own activity across exchange, custody and on-chain sources, classifies each transaction as a disposal, a transfer or a retail payment, and applies the thresholds so the hard cases land 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.
It can. CARF targets providers that facilitate transactions for users, and front-ends to decentralised protocols can fall inside that. What decides it is the service you provide to the user. Settlement happening on a protocol doesn't answer the question by itself, so map each product to the service test.
Certain transfers to wallets outside the regulated system are reportable, so value doesn't drop off the record at the edge. Your job is to identify which outbound transfers qualify and capture the data as 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 spot the payment, apply the threshold, and value it in the right currency.

Kryptos 2.0 is a full platform rebuild for the AI-agent era of finance and institutional scale: organizations and workspaces, roles, lock periods, audit history, reconciliation, and a documented API and MCP.

Kryptos 2.0 rebuilds the platform for every investor: faster corrections, room for millions of transactions, live sync, easier reconciliation, and API and MCP access.

FASB's August 2026 proposal on digital assets and cash equivalents, explained. What it changes, the three criteria that matter, and the November 19 comment deadline.
Generate an audit-ready report aligned to your jurisdiction. No credit card required.