CARF reportable transaction classifier
CARF reports in four buckets, not one, and a transaction lands in a different bucket depending on whose agent you are. A merchant payment above the threshold is a Reportable Retail Payment Transaction when you act for the customer — and an ordinary Transfer when you act for the merchant. Classify one transaction and see which bucket it falls into.
CARF Section I · four reporting buckets · USD 50,000 retail threshold · three asset exclusions · nothing stored
Classify one transaction
Runs in your browser · nothing uploadedAnswer for a single transaction effectuated by a Reporting Crypto-Asset Service Provider. The asset question comes first: if the asset is outside the definition of a Relevant Crypto-Asset, nothing downstream applies.
Step 1 — Is the asset a Relevant Crypto-Asset?
Section IV, definitionsThree categories are carved out as presenting limited tax compliance risk. Everything else built on cryptographically secured distributed ledger technology is in scope.
Step 2 — What kind of transaction is it?
Section I, Relevant TransactionWhether an exchange gives rise to a taxable disposition under your own tax rules is irrelevant to this question. The classification turns on the form of the transaction, not its tax effect.
Step 3 — The retail payment tests
Reportable Retail Payment TransactionTwo tests, and both have to be satisfied before the transaction becomes a Reportable Retail Payment Transaction rather than an ordinary Transfer. The second is the one that catches people.
Classification is per transaction; reporting is in aggregate. The digital assets module classifies transactions, aggregates them by user, asset and type with the inward and outward split, and produces the CARF and DAC8 files — with a free tier to start.
Create free account →Four buckets, reported separately
CARF requires aggregate figures for each type of Relevant Crypto-Asset, differentiating inward and outward, and the four transaction types are not pooled. A system that classifies correctly but aggregates into one bucket fails at the file, not at the classification.
Exchanges against fiat
Acquisitions and disposals of Relevant Crypto-Assets against fiat currency — buys and sells. Fiat status turns on an "issued by" test rather than on what is legal tender, so an asset adopted as legal tender somewhere is not automatically fiat for this purpose.
Crypto for crypto
Exchanges between one or more forms of Relevant Crypto-Asset. Separated from bucket 1 because some jurisdictions tax exchanges against fiat but not exchanges between crypto-assets — and reportable regardless of whether a taxable disposition arises.
Transfers
Transfers of Relevant Crypto-Assets, reported by number of units and total value. This is the bucket that reaches transactions with no tax consequence at all, which is what makes CARF different from account-balance reporting.
Reportable retail payments
Transfers in consideration for goods or services above USD 50,000, where the provider processes the payment as agent for the customer. Acting for the merchant instead puts the same economic transaction in bucket 3.
Rules reviewed 21 August 2026 · CARF Section I · OECD CARF FAQs · implemented in the EU through DAC8
What this classifier does
It puts one transaction in a bucket and names the test that put it there. It is not a reporting engine and it does not do due diligence.
It doesClassify the transaction
- Applies the three asset exclusions first, so an out-of-scope asset ends the enquiry.
- Separates the four reporting buckets rather than pooling them.
- Applies both retail payment tests, including the agency capacity that decides between buckets 3 and 4.
- States that an exchange is reportable whether or not it gives rise to a taxable disposition.
- Flags where a transaction is in scope but the bucket cannot be settled on the answers given.
- Reminds you that reporting is aggregate, by asset and type, split inward and outward.
It does notDecide reportability of the user
- Determine whether the user is a Reportable User. That is due diligence and tax residence.
- Determine whether you are an RCASP, or which jurisdiction's rules apply under the nexus and branch rules.
- Address staking, wrapping, or transfers into automatically executing contracts, which the OECD treats specifically.
- Value the transaction, apply fair market value rules, or handle the treatment of fees.
- Apply your own jurisdiction's implementing text, which is what actually binds you.
- Produce anything you can file. It is a classification, not a return.
The same payment, two different buckets
Where a provider processes a transfer from a customer to a merchant above the threshold as an agent of the customer, it reports a Reportable Retail Payment Transaction. Where it acts as an agent of the merchant, the transfer is reported as a Transfer and not as a retail payment. Nothing about the money changes — only whose agent you are. Systems built from summaries of CARF usually miss this, because most summaries reduce bucket 4 to "payments over USD 50,000".
Nothing you enter here leaves your browser
Every answer is evaluated on your own machine. Nothing is sent to REGREP, written to a log, saved to a database, or passed to any analytics tool.
That is deliberate. Your transaction patterns are not something we want to hold.
About reportable transactions
Which transactions does CARF actually reach?
Three types: exchanges between Relevant Crypto-Assets and fiat currencies; exchanges between one or more forms of Relevant Crypto-Asset; and transfers of Relevant Crypto-Assets, which include Reportable Retail Payment Transactions as a distinct reporting category. They are reported in aggregate by type of asset, differentiating outward and inward transactions, with values in fiat currency.
Is a crypto-to-crypto swap reportable if it is not taxable for us?
Yes. Whether an exchange gives rise to a taxable disposition under applicable tax rules does not affect whether it is an Exchange Transaction. The two buckets for exchanges exist precisely because jurisdictions differ on what they tax, and reporting is not limited to what any one of them taxes.
What makes a payment a Reportable Retail Payment Transaction?
Value above USD 50,000, and the capacity in which you process it. Where you process the transfer from a customer to a merchant as an agent of the customer, it is reported as a Reportable Retail Payment Transaction. Where you act as an agent of the merchant, the transfer is reported as a Transfer and not as a retail payment transaction. Below the threshold the category does not arise at all.
Which assets are outside the definition?
Three categories are excluded as presenting limited tax compliance risk: central bank digital currencies; Specified Electronic Money Products, which represent a single fiat currency and are redeemable at any time in that currency, and which the CRS already reaches; and closed-loop crypto-assets that the provider has adequately determined cannot be used for payment or investment purposes.
What about staking and wrapped tokens?
Out of scope for this tool, deliberately. The OECD addresses these specifically — including transfers into automatically executing contracts where the user receives a tokenised version of the same value — and the treatment does not follow from the three buckets alone. Read the CARF FAQs on the point rather than inferring it, and do not assume a wrapping step is neutral.
Does the classification decide what gets reported?
It decides the bucket, not the content. Reporting is aggregate for each type of Relevant Crypto-Asset: fair market values paid and received, numbers of units, and numbers of transactions, separated by bucket and split between inward and outward. A correct classification aggregated into the wrong bucket still produces a wrong file.
Per-transaction classification, aggregate reporting.
Create a free account and take classified transactions through aggregation into CARF and DAC8 files, with the inward and outward split handled for you.
No card required · free tier on core modules · nothing stored from this tool