FinTax, a crypto tax and accounting service provider, announced on Aug. 27, 2026 that it had completed a seed round led by EASY Residency S4 under YZi Labs, giving the company a post-money valuation of $40 million. The financing arrived as crypto tax reporting rules moved into the execution phase across parts of the market.
CARF is no longer a planning exercise for exchanges
The U.K. began implementing rules tied to the OECD Crypto-Asset Reporting Framework, or CARF, in January 2026. The European Union started applying DAC8 crypto-asset reporting rules aligned with CARF over the same period. For exchanges operating in those markets, collecting user tax information and retaining transaction data has already become current-year work rather than preparation for the following year.
As of September 2026, a little more than three months remained before year-end. Still, the idea that exchanges have less than four months to complete due diligence on pre-existing users only applies where the platform is subject to rules that took effect at the start of the year and require that work to be finished within 12 months. CARF does not impose one single global deadline on all exchanges.
Exchanges already process large volumes of account and transaction data every day. Even so, adding tax reporting can still force a broad redesign of business processes. Tax reporting asks for a different set of user identity details, transaction classifications, and historical records than those needed for trade matching or balance reconciliation. Those differences shape what data a platform still needs to collect and how much staffing and system capacity it must commit each year.
Why KYC alone is not enough
An exchange’s existing KYC framework can support CARF due diligence, but the two are not aimed at exactly the same questions. Identity documents may verify who a user is, yet they do not by themselves establish where that user is a tax resident, what tax identification number applies, or whether a corporate account has controlling persons that must be identified.
Once CARF applies, an exchange first needs to determine which users are reportable users. Under CARF Section III, a Reporting Crypto-Asset Service Provider, or RCASP, must obtain a self-certification from the user, use it to determine tax residency, and check whether the self-certification is reasonable in light of information already on file.
Individual users must provide their name, residential address, jurisdiction of tax residence, relevant TIN, and date of birth. Entity users must provide their legal name, address, jurisdiction of tax residence, and TIN, and state whether they qualify as an active entity or an excluded person. If an entity falls into neither category, the exchange must identify controlling persons and obtain each person’s name, residential address, jurisdiction of tax residence, TIN, date of birth, and status as a controlling person.
For pre-existing users, this due diligence should in principle be completed within 12 months after the CARF rules take effect. For the first jurisdictions, the deadline is Dec. 31, 2026.
Much of this process can reuse an exchange’s existing AML and KYC setup. CARF allows an RCASP to pre-fill a self-certification with customer information already held by the platform, but the jurisdiction of tax residence still has to be confirmed by the user. Self-certifications previously collected for CRS, FATCA, or other tax reporting regimes may also continue to be used if they already contain the information required under CARF.
At the same time, exchanges must test the reasonableness of the self-certification against KYC records. If the declared tax residence conflicts with an address, identity document, or other information already held, the platform must obtain a new self-certification or collect explanations and supporting documents that account for the discrepancy.
Collecting missing information from pre-existing users also requires a clear follow-up and exception-handling process. The report uses Coinbase as an example: if a user’s declared tax residence does not match the account address, the country tied to the phone number, or the place of birth, the user may need to provide an explanation and go through additional review. OKX, meanwhile, offers exception options where a TIN cannot be provided and applies restrictions to accounts that fail to update tax information on time. For exchanges with millions of registered users, this is not just a form update. It becomes an operational campaign involving collection workflows, exception queues, and account restriction rules.
Why one crypto-to-crypto trade may need two records
Under CARF Section II, an RCASP must report, for each reportable user, annual aggregated transactions by relevant crypto-asset and transaction type. Those categories include:
- acquisitions and disposals of relevant crypto-assets for fiat currency;
- acquisitions and disposals of relevant crypto-assets for other relevant crypto-assets;
- reportable retail payment transactions; and
- other inbound and outbound transfers.
Where the exchange knows the nature of a transfer, it must further classify that transfer by type, such as an airdrop, staking reward, or loan. Assets transferred to wallet addresses that the exchange cannot confirm as belonging to a virtual asset service provider or a financial institution must also be aggregated separately. All of this is reported annually by reportable user, relevant crypto-asset, and transaction type.
In day-to-day exchange operations, these categories map onto the flows users generate all the time. Buying or selling crypto with fiat falls into fiat exchange transactions. Spot trades such as swapping BTC for ETH require the platform to record the disposal of one asset and the acquisition of the other. Deposits, withdrawals, and some staking, lending, and reward distribution activities may create inbound or outbound transfers of relevant crypto-assets. Payment activity can fall into reportable retail payment transactions when the conditions are met.
For crypto-to-crypto trades, one transaction may need to be split into an acquisition leg and a disposal leg under CARF, with each side measured at fair market value at the time of the trade.
That creates a data problem at the infrastructure level. Many exchanges built their data warehouses around risk control and finance reporting. They may be able to calculate how much a user traded over a year, but not necessarily reconstruct how much each side of a trade was worth in fiat at the execution timestamp or whether the counterparty address belonged to a VASP. That level of granularity often has to be built from scratch.
Turning internal records into reportable files
After user identification and transaction aggregation are complete, exchanges still need to connect data scattered across KYC, account, matching, wallet, payment, staking, and lending systems, then convert it into the standardized reporting structure required by CARF.
The OECD CARF XML Schema is built around RCASP, Crypto-Asset User, and Relevant Transactions. Exchanges therefore need a mapping between internal data models and CARF fields so that user identity, tax residency information, relevant crypto-assets, transaction categories, transaction counts, asset quantities, amounts, reporting currency, and valuation methods all land in the correct fields.
For crypto-to-crypto trades, inbound and outbound transfers, and external wallet transfers, the exchange must also split transaction direction and type in line with CARF rules so that the aggregated output can be traced back to the underlying transaction records.
At the data generation stage, platforms need validation rules for field completeness, code values, data types, and logical relationships. That includes checks on the relationship between tax residency jurisdictions and TINs, currency codes, amount and asset quantity formats, and whether transaction classifications and valuation methods comply with schema requirements. Once validated, the data can be turned into reporting files using the XML Schema adopted by the reporting jurisdiction or a locally compatible format. Exchanges also need to retain identifiers such as DocSpec and MessageRefID to support later corrections, deletions, and version tracking.
This layer is pure engineering, but it is also where the quality of the earlier steps is tested. If fields do not line up or transaction splitting rules are inconsistent, the reporting process fails here.
Maintenance begins after the first filing
The report says CARF should not be treated as a one-off project. Three kinds of change can keep forcing updates to rules and mappings.
Changes in user facts
If a user’s address, tax residence, TIN, entity status, or controlling persons change, the original determination of whether that user is reportable may also change. Exchanges need to connect CARF due diligence with existing KYC and account update mechanisms, set trigger rules for information changes that may affect tax status, and obtain or reconfirm self-certifications and supporting documents where required.
Changes in products and data
Exchanges continue to launch new tokens and products tied to staking, lending, payments, custody, or tokenized assets. Existing asset classification and transaction mapping rules need to be updated at the same time. Before a new product or transaction scenario goes live, the platform should reassess whether the asset involved is a relevant crypto-asset, whether the related fund flow is a relevant transaction, and whether transaction types, transfer types, valuation methods, and field mappings need to be adjusted so the new business line can enter the existing CARF data pipeline.
Changes in rules and reporting requirements
Jurisdictions may keep changing their CARF rollout schedules, reporting fields, XML Schema versions, local technical interfaces, and validation rules. Exchanges need rule-tracking and version-management processes so they can update reporting rule libraries, field mappings, and technical configurations in time, while preserving historical versions and filing records for corrections, supplemental filings, and data traceability.
What demand this creates for FinTax
For crypto exchanges, CARF implementation spans user identification, transaction determination, data aggregation, field mapping, technical submission, and ongoing maintenance. As business lines and product types expand, the key task is to embed CARF rules into existing KYC, trading, wallet, and data governance systems in a stable way.
Platforms operating across jurisdictions face another layer of work. They need to coordinate different legal entities, reporting connection points, and local filing requirements so that one set of business data can be converted accurately under each jurisdiction’s rules and submitted correctly.
Viewed together, the report says the real cost of CARF for exchanges is not a single compliance opinion. It is a data pipeline that has to be maintained over time. Building that internally requires three capabilities at once: precise interpretation of CARF rules, engineering adaptation across exchange systems, and ongoing tracking of multi-jurisdiction reporting interfaces. The article says most exchanges have the second capability, but not the first and third. In that process, FinTax can provide a reporting workflow that is reviewable and can be updated on an ongoing basis.
The deadline for due diligence on pre-existing users in the first jurisdictions is Dec. 31, 2026.