Spindipper Guides
CARF vs CRS vs FATCA
How Crypto Founders Actually Get Captured by Global Reporting Regimes
Most founders who deliberately avoid banks do so with a very specific belief in mind. If everything happens in self custody wallets, on chain, and in stablecoins, then CRS style reporting never enters the picture. In practice, this belief often survives for years because nothing forces it to be tested. Then an accountant or counsel explains the uncomfortable truth. CARF was created precisely because CRS did not capture crypto reliably, and CARF reporting can attach from January 1, 2026 even if the project never touches a bank account. The mistake is treating FATCA, CRS, and CARF as alternative systems that can be escaped by choosing the right technology. In reality they are layered regimes that can apply simultaneously, and your only real lever is what activities your entities perform and where those activities are located.
Crypto Reporting Regimes Are Layered, Not OptionalFATCA, CRS, and CARF are not competing frameworks. FATCA is built to follow U.S. persons and U.S. control, wherever the entity sits. CRS is built to force financial institutions to identify account holders and report across borders. CARF extends this logic into crypto by focusing on entities that facilitate exchange, transfer, custody, or settlement of crypto assets, because those functions were not consistently captured under CRS. Each layer expands coverage. None of them disable the others. This is why founders who think offshore incorporation or on chain operations automatically remove reporting exposure end up surprised. The legal regime does not ask whether you used a bank. It asks whether an entity played a reportable role in the movement or safekeeping of value, and whether the entity sits inside a jurisdiction committed to information exchange.
Jurisdiction still matters, but mostly as a question of timing and administrative intensity rather than exemption. The EU tends to implement quickly and coordinate reporting with broader crypto supervision, which means founders operating EU based service surfaces will feel CARF earlier. The UAE often aims to remain commercially attractive while still aligning with OECD exchange commitments, which can produce slightly different rollout timing or reporting expectations. Cayman remains widely used for foundations and treasuries, but it participates in global transparency regimes and will not function as a secrecy layer once exchange is live. The practical point is that a slow adopting jurisdiction may delay exposure, but it does not remove it, especially when transaction histories remain visible and cross border inquiries often look backward as well as forward once information exchange begins.
Classification Is Driven by Activity, Not LabelsNone of these frameworks care about whether something is called a DAO, a protocol, a dApp, or a token. They classify actors based on what those actors do. FATCA attaches to U.S. persons and to entities with substantial U.S. ownership or control. CRS attaches to entities classified as Financial Institutions, which generally means entities that hold, manage, or administer assets for others. CARF attaches to Crypto Asset Service Providers, which broadly means entities whose systems facilitate exchange, transfer, custody, or settlement of crypto assets for others. This classification logic is why overlap is common. A single company can be treated as a CASP under CARF because it routes swaps, treated as a Financial Institution under CRS because it provides custodial wallets, and treated as within FATCA scope because U.S. persons are involved. Reporting flows from role, not from intent, and role is inferred from observable activity.
CARF itself exists because CRS did not consistently capture crypto intermediaries. Finalized by the OECD in 2022, CARF targets the places where crypto activity becomes legible as a service rather than a private act of self custody. It covers obvious actors like exchanges and brokers, but it also extends into any entity whose infrastructure makes value move between parties in a way that resembles intermediation. The founder trap is believing that decentralization marketing language changes this. If an entity sits in the middle of user value flows, CARF becomes relevant regardless of whether the product team describes it as software, a frontend, or a DAO interface. The system does not need to care about blockchains in the abstract, because it can care about what the entity does with them in practice.
Structural Separation Is the Only Durable BoundaryThe fastest way to become accidentally reportable is to pile too many functions into one entity. Founders often combine protocol development, frontend operation, and treasury or custody handling inside a single company because it feels simpler. But doing so erases the line regulators care about most: whether an entity is merely publishing software or sitting in the middle of value flows. Once an entity holds user assets, routes swaps, executes transfers, or maintains keys that move funds, it begins to look like a service provider, which is exactly what CARF and CRS are built to classify.
When an entity is treated as reportable, the consequences are practical. Customer identification, tax residence collection, and transaction reporting become expected operational capabilities. What feels like sudden enforcement is usually just the structure expressing its true role.
Control matters as much as ownership. A foundation may technically own tokens, but if an operating company initiates transfers, approves multisig transactions, or runs signing infrastructure, that company can be seen as controlling the assets. This is why wallet architecture and multisig design quietly influence where reporting obligations land.
Mature projects avoid surprises by separating functions. A non custodial development entity writes code. A foundation or issuer entity holds treasury and sets policy. Any unavoidable custody or exchange activity lives in a scoped service entity designed to carry reporting duties. The objective is not to eliminate reporting everywhere, but to make it limited, predictable, and intentional.
CRS and FATCA still operate alongside CARF. Custody oriented models can fall under CRS even before CARF applies, and U.S. persons or U.S. control can still trigger FATCA regardless of offshore incorporation. CARF, CRS, and FATCA target different dimensions of the same reality, and treating them as substitutes is how founders misread their exposure.
Mapping Activity to Entity ArchitectureSpindipper operates at the layer where activity is mapped to entity architecture before launch. The practical work is helping founders decide which entity, if any, should ever touch user assets, which entity should hold treasury, and which entity should remain a pure development or IP holder, so that reporting obligations attach where expected rather than where accidental. This is less about paperwork and more about designing clear boundaries between development, stewardship, and service functions, because those boundaries are what CARF, CRS, and FATCA ultimately respond to when they infer classification from real world activity.
If you are building something that will move value between users, hold assets even briefly, or operate infrastructure that looks like exchange or settlement, it is worth examining how your current activity maps to CARF, CRS, and FATCA surfaces. The earlier you do that mapping, the easier it is to keep reporting predictable and to prevent a single operational shortcut from pulling the entire structure into a reporting profile you never intended.
DisclaimerThis article provides general information only and does not constitute legal, tax, or financial advice. Reporting and classification outcomes depend on specific facts, jurisdiction, and how entities operate in practice. Consult qualified legal and tax professionals before making structuring decisions. Last updated January 2026.
If you need help thinking through how reporting regimes interact with your structure, feel free to get in touch for a friendly, no-pressure conversation.
If you have a question that we have not answered, please
get in touch!
CARF, the Crypto Asset Reporting Framework, exists because CRS was built around traditional financial accounts and the institutions that administer them, which meant crypto activity often sat in a reporting blind spot. The OECD created CARF to capture the same economic reality that CRS targets, but through the crypto layer, by focusing on intermediaries that facilitate exchange, transfer, custody, or settlement of crypto assets. In other words, CARF is not a replacement for CRS, it is an extension designed to produce functional parity so that using wallets and stablecoins instead of bank accounts does not change whether reporting happens, only where it attaches.
Yes, and this is where many founders misread the landscape. CARF can apply because an entity operates a crypto service surface, CRS can apply because the same structure looks like a Financial Institution when it holds or administers assets for others, and FATCA can apply because U.S. persons are involved through ownership, control, or beneficial interest. These are layered regimes with different triggers and different reporting channels, so a structure can be simultaneously in scope of all three without any contradiction, simply because the entity performs multiple roles and has multiple nexus points.
Yes, because CARF was written for exactly that fact pattern. If an entity facilitates user transactions, even entirely on chain, by routing swaps, operating a hosted interface that executes transfers, holding assets in custody, or maintaining keys that can move funds, the activity starts to resemble an intermediary rather than a software publisher. CARF is designed to attach to that intermediary role regardless of whether the project ever uses a bank account, and once it attaches, the reporting question becomes which entity is performing the service and which jurisdiction that entity sits inside, not whether fiat rails exist at all.
No, because these regimes do not classify marketing language, they classify operational reality. A project can be decentralized in governance and still have an entity that runs the frontend, collects fees, operates relayers, or controls treasury execution, and those are the things regulators and tax authorities can observe. If an entity is in the middle of value movement or exercises control over user assets or transactions, it can be treated as a reportable service provider under CARF or a reportable Financial Institution under CRS, regardless of whether the project calls itself a DAO, a protocol, or an autonomous network.
CARF risk usually appears at the moment an entity stops being a builder of tools and starts being an operator of flows. Operating exchange or brokerage like systems, providing custodial wallets, running infrastructure that executes transfers for users, aggregating liquidity, routing swaps, settling transactions, or maintaining key material that makes value move between parties are the kinds of activities that look like facilitation rather than publication. The common thread is that the entity is doing something for others that affects the movement, settlement, or custody of value, which is exactly the behavior CARF was designed to capture.
CRS still matters because it does not disappear when CARF arrives, and because its scope has expanded to better capture custodial crypto arrangements that resemble traditional account administration. If an entity holds crypto for customers, administers assets on behalf of others, or sits in a custody like role that looks financially institutional, it can be pulled into CRS classification even before CARF becomes the dominant reporting layer for crypto specific flows. In practice, CRS is often the regime that bites custody and treasury administration models first, while CARF expands visibility across a broader set of crypto service behaviors that CRS historically missed.
FATCA still matters because it is driven by U.S. person status and U.S. control, not by where an entity is incorporated or whether activity happens through banks. If U.S. founders, beneficial owners, or controllers sit behind an offshore company, the structure can still trigger FATCA obligations through ownership thresholds or control indicators, and counterparties that are themselves compliant institutions will often require FATCA style self certification and documentation as part of onboarding. Offshore formation may change operational convenience or tax planning in specific cases, but it does not remove U.S. nexus reporting exposure when U.S. persons are involved.
Ownership is not the whole story, because reporting regimes often follow control and functional authority over assets and transactions. A foundation may technically own a treasury, but if an operating company’s staff initiate transfers, approve multisig actions, run signing infrastructure, or maintain key material, the operating company can look like the real controller of value movement. That matters because CARF logic can treat control as a sufficient basis for classifying an entity as a reportable service provider, which means wallet architecture and governance execution design can quietly relocate reporting obligations into jurisdictions you never intended, even when corporate paperwork suggests otherwise.
They reduce accidental exposure by separating functions so that reportable activity is confined to the entity designed to carry it. A development entity remains non custodial and focuses on publishing code and receiving grants, a foundation or issuer entity holds treasury and sets policy without becoming an intermediary, and any custody or exchange like activity is placed into a deliberately scoped service entity that can handle onboarding, documentation, and reporting where required. This separation works because the regimes infer classification from activity boundaries, so when those boundaries are clear, reporting becomes predictable and limited instead of spreading across the entire structure.
Not really, because delays change timing, not the direction of travel. CARF enters first wave implementation from January 1, 2026 in many jurisdictions, with first exchanges of information expected in 2027, and OECD members have committed to adoption by 2027. Even where a jurisdiction implements later, transaction histories remain visible and counterparties may already be collecting information, so the idea that slow adoption creates permanent non reporting space tends to fail once exchange begins and historical activity can be examined. Founders get more durable outcomes by designing clear activity boundaries and choosing where those activities sit, rather than relying on the hope that a jurisdiction stays slow forever.
We're always happy to answer your questions. Not sure which structure is right for you? Click the button below to get in touch for a friendly, no-pressure conversation. We're here to help you make the right choice.
