CARF 2027: подготовка VASP — пошаговое руководство

Key Management Insights (TL;DR)

Deadline — January 1, 2026: From this date, Virtual Asset Service Providers (VASPs) are required to begin data collection for the first report in 2027. Delay is not an option.
Budget and Resources: Immediately allocate the 2025 budget for audits, software procurement (or development), legal support, and staff training.
Technical Readiness: Key challenges include the correct valuation of complex transactions (crypto-to-crypto, DeFi, NFT) and the integration of data collection into existing systems.
Legal Risks: Ensure legal grounds for data collection and cross-border transfer in compliance with GDPR (or equivalents) by conducting risk assessments (DPIA/TIA).
Consequences: Non-compliance risks multi-million dollar fines, license revocation, and personal liability for management.

Introduction: Purpose, Audience, and Structure

Article Purpose: To provide a detailed practical guide for implementing the Crypto-Asset Reporting Framework (CARF) — the new OECD standard for the exchange of tax information, focusing on technical, legal, and operational aspects.

Target Audience:

Crypto-Service Executives (VASPs): CEOs, CISOs, CTOs, and Compliance Officers (CCOs) of centralized exchanges (CEX), brokers, crypto-ATM operators, and DeFi protocols with elements of centralized control.
Crypto-Asset Owners: Private investors, traders, and funds who need to understand what data about them will be reported.

Structure: The guide covers the legal context of CARF, detailed asset valuation rules, a step-by-step implementation plan with specific tasks, data security requirements, and contains practical examples, templates, and checklists.

What is CARF and What is its Legal Context?

Crypto-Asset Reporting Framework (CARF) is an international OECD standard for the automatic exchange of tax information on transactions with crypto-assets¹. Its goal is to enhance tax transparency and supplement the existing Common Reporting Standard (CRS), which covers traditional financial accounts.

Key Dates:

January 1, 2026: Commencement of data collection by VASPs in jurisdictions that have implemented the standard.
December 31, 2026: Conclusion of the first reporting period.
By December 31, 2027: First automatic exchange of data between the tax authorities of 48 participating countries.

Distinction Between CARF, DAC8, and AML/CFT

CARF (OECD): Global standard for tax reporting.
DAC8 (EU): EU Council Directive² that implements CARF into European Union law, creating a legal framework for administrative cooperation between tax authorities.
AML/CFT and FATF Regulations: Anti-money laundering measures. Requirements such as the Travel Rule mandate VASPs to collect data to counter financial crimes, not for taxation purposes. The data partially overlaps, allowing for optimized collection. Violations in adjacent areas already lead to fines. For instance, OFAC fined CoinList $1.2 million for sanctions compliance violations³, highlighting the severity of regulatory oversight. To minimize risks, it is recommended to consider insurance (Cyber Liability, Professional Indemnity).

Data Subject to Collection, Valuation, and Aggregation

VASPs are required to collect, validate, and transmit the following data to tax authorities.

1. Customer Identification Data (KYC)

Full name, address, date of birth.
Jurisdiction(s) of tax residence.
Taxpayer Identification Number (TIN) for each jurisdiction.

2. Aggregated Transactional Data (for the Reporting Period)

Data is aggregated by crypto-asset type and transaction type:

Acquisition and Disposal of crypto-assets in exchange for fiat.
Exchange of one crypto-asset for another (crypto-to-crypto).
Transfers to wallets not associated with a VASP (self-hosted wallets) and transfers from other VASPs.

3. Valuation Rules

This is the most complex aspect. A VASP must document and consistently apply its valuation policy.

Asset/Operation Type	Valuation Method	Calculation Example
Crypto-to-Fiat	Based on the actual transaction price in fiat currency.	Sale of 1 BTC for 60,000 EUR. `GrossProceeds` = 60,000 EUR.
Crypto-to-Crypto	Two-stage conversion through a reference fiat currency (USD/EUR) using a reliable data source (major exchange API, aggregator). Using VWAP/TWAP over 1–5 minutes is recommended.	Exchange of 1 BTC for 20 ETH. BTC price = $60,000, ETH price = $3,000. Disposal: 1 BTC for the amount of $60,000. Acquisition: 20 ETH for the amount of $60,000.
NFT and Unique Tokens	Based on the price of the last transaction. If the price is undefined, the acquisition price or an independent expert valuation (in rare cases) is used.	Purchase of an NFT for 10 ETH. ETH price at transaction = $3,000. NFT acquisition cost = $30,000.
Stablecoins / Wrapped Tokens	Valued at face value (1:1 to the underlying asset, e.g., USDC = 1 USD), unless there is a significant de-peg.	Exchange of 1000 USDC for 1000 EUR. Disposal: 1000 USDC for the amount of $1000. Acquisition: fiat for the amount of 1000 EUR.
Staking, Airdrops, Farming	Rewards and airdrops are classified as acquisition at fair market value at the time they are credited to the customer's account.	0.1 ETH received as a staking reward. ETH price at time of credit = $3,000. Acquisition: 0.1 ETH for the amount of $300.
Refunds and Adjustments	Reflected by decreasing the corresponding aggregated amount for the reporting period. A detailed journal of such operations must be kept for audit purposes.	A customer was mistakenly credited 0.1 ETH, then it was debited. The operation is adjusted and does not appear in the final report.

4. Accounting for Fees (Gas) and Timestamps

Fees: GrossProceeds (gross revenue) from asset disposal is reported before the deduction of fees and gas. Fees paid by the customer can be accounted for by them independently when filing a tax return. If a fee is paid by a third party, it is not reflected in the customer's report.
Timestamps: All transactions must have an accurate timestamp, preferably based on block timestamp in UTC format. This is critical for determining the fair market value at the moment of the operation.

Who Falls Under CARF?

The standard applies to Virtual Asset Service Providers (VASPs) that, as a business, provide exchange, transfer, or custody services for crypto-assets.

Responsibility Determination Algorithm for DEX and DeFi

CARF targets intermediaries who possess “sufficient control”. Use the following decision tree:

Does your team or DAO control key smart contracts via administrative keys that allow for modifications or suspension of operations?
- Yes: The project is likely a VASP.
Is your user interface (UI/Frontend) the primary means of accessing the protocol, and can you restrict access to it (e.g., via geo-blocking)?
- Yes: The interface operator is a VASP.
  Example: Uniswap frontend managed by Uniswap Labs.
Does your project collect fees (take-rate) into centralized wallets controlled by the team/DAO?
- Yes: High probability of classification as a VASP.

Conclusion: If the answer is "Yes" to at least one of these questions, the project will likely be recognized as a VASP.

Practical Implementation Plan for VASPs

Detailed Timeline

Period	Key Tasks	Owner / Responsible Parties	Readiness Criteria (Definition of Done)
Q3–Q4 2024	Initiation and Planning	CCO, CTO, CEO	Working group formed. Gap analysis conducted. Solution selected (SaaS/in-house). 2025 budget approved.
Q1–Q2 2025	Development and Integration	CTO, DPO, Legal	IT system integrated with reporting module. Legal documents (Policy, Agreement) updated. DPIA conducted.
Q3–Q4 2025	Testing and Preparation	CTO, CCO	UAT conducted (including complex scenarios). Staff trained. Customers notified of Privacy Policy changes.
Q1 2026	Launch of Data Collection	CTO, CCO	Data collection started on January 1. Data quality monitoring system (dashboards) launched and operating correctly.
Q1–Q2 2027	Report Generation and Filing	CCO	Report generated, validated against XSD schema, and successfully filed with the tax authority before the deadline.

Data Management: Security and Legal Grounds

1. Data Flow & Ownership

Roles and responsibilities must be clearly defined at each stage of the data lifecycle.

Stage	Responsible Role	Key Actions	SLA / Control
Data Collection	CTO / Engineers	Integration with KYC systems and transaction databases.	ETL processes run without failure >99.9% of the time.
Validation and Cleaning	CCO / Data Analyst	Checking KYC completeness (TIN), format correctness.	Data error rate <0.1%.
Aggregation and Valuation	CTO / CCO	Application of the approved Valuation Policy.	Calculations pass internal audit; discrepancies <0.01%.
Storage and Encryption	CISO / DevOps	Encryption at-rest (AES-256) and in-transit (TLS 1.3). Key management (HSM).	Quarterly access audit. Key rotation as scheduled.
Generation and Submission	CCO / Legal	XML report generation, signing, transmission via secure channel.	Report filed on time. Confirmation received from regulator.

2. Legal Grounds for Cross-Border Data Transfer (GDPR Context)

Data transfer to tax authorities outside the EU/EEA requires robust legal grounds. Article 6(1)(c) of the GDPR (compliance with a legal obligation) is the primary ground, but not always sufficient.

Need for Local Legal Expertise: Requirements may vary depending on the jurisdiction of the VASP and the customer. Conflicts of legal grounds must be resolved before the transfer begins.
Adequacy Assessment: If data is transferred to a country not recognized by the EU as providing an adequate level of protection, additional measures are required.
Legal Transfer Mechanisms:
- Adequacy Decision: For countries like the UK, Switzerland.
- Standard Contractual Clauses (SCCs): Required when transferring to jurisdictions without an adequacy decision. The VASP is obliged to conduct a Transfer Impact Assessment (TIA).
- International Agreements (CARF/DAC8): May serve as a legal basis for transfer but do not override general GDPR principles. The VASP is obliged to conduct a Data Protection Impact Assessment (DPIA) to document risks. (See checklist in Appendix 2).

3. Data Retention and Deletion Policy

Retention Period: Data must be stored for the period established by tax and AML legislation (typically 7–10 years after the end of the customer relationship) for audit purposes.
Secure Deletion: Upon expiration of the retention period, data must be permanently deleted using cryptographic erasure or physical destruction of media.
Logging: All operations of access, modification, and deletion of CARF data must be logged in immutable logs (WORM logs) for auditing.

Testing and Interaction with Tax Authorities

Internal Testing (UAT): Verification of collection correctness, aggregation logic, and XML file generation for compliance with the current **OECD XSD (v1.0)**⁴. (See test case examples in Appendix 1).
Integration Testing: Tax authorities will provide test environments (sandboxes) to debug the submission process. Access to test endpoints must be requested in advance.
End-to-End Testing: Conducting a full cycle — from report generation to successful upload and validation on the regulator's side.

KPIs for Compliance Monitoring

KPI	Goal	Measurement Methodology
Completeness of KYC Data for CARF	>99.8%	% of customers with valid TIN and full address (CRM/KYC system; Weekly).
Data Quality Score	<0.05% errors	% of records failing internal XML validation (Reporting system; Monthly).
Reporting Readiness	100% by Q4 2026	% of completed tasks from the internal compliance plan (Project tracker; Quarterly).
SLA on Regulatory Requests	< 48 hours	Average time from request receipt to response transmission (Ticketing system; As occurring).

Conclusion: 90-Day Action Plan

Implementing CARF requires immediate action.

Appoint a Lead: Designate a Project Owner with the authority to coordinate CCO, CTO, Legal, and DPO.
Initiate Gap Analysis: Conduct an audit of IT architecture and KYC processes to identify gaps. Assess whether a SaaS solution will suffice or if in-house development is required.
Formulate 2025 Budget: Allocate costs for software, external legal and tax consultants, as well as potential staff expansion.
Start Updating the Legal Framework: Consult with lawyers to prepare the DPIA and update the User Agreement and Privacy Policy.

Glossary

CARF (Crypto-Asset Reporting Framework): OECD standard for reporting on crypto-assets.
CRS (Common Reporting Standard): OECD's uniform reporting standard for financial accounts.
DAC8 (Directive on Administrative Cooperation): Eighth version of the EU Directive implementing CARF.
DPIA (Data Protection Impact Assessment): Assessment of the impact on data protection.
TIA (Transfer Impact Assessment): Assessment of the impact of data transfer.
VASP (Virtual Asset Service Provider): Provider of virtual asset services.
VWAP (Volume-Weighted Average Price): Volume-weighted average price.

Sources and Useful Links

Source verification date: October 2024

OECD (November 2023), Joint Statement on the Crypto-Asset Reporting Framework.
Council of the EU (October 2023), Council Directive (EU) 2023/2226 (DAC8).
OFAC (February 2024), OFAC Settles with CoinList Markets, Inc. for $1,207,830.
OECD (October 2023), Crypto-Asset Reporting Framework XML Schema (Version 1.0) and User Guide. Available at: OECD.org

Appendix 1: Technical Specifications and Test Cases

Format: XML. Schema: CARF XML Schema v1.0.
Edge-Case Handling:
- Data Correction: Erroneous reports must be corrected by filing a correcting report indicating the DocRefId of the original document.
- Duplicate Reporting: If multiple VASPs are involved in one transaction, each reports the portion they serve. Implement reconciliation mechanisms to avoid discrepancies.

XML Fragment Example for Crypto-to-Crypto Swap

Exchange of 1 BTC for 20 ETH. The report reflects this as two events: BTC disposal and ETH acquisition.

<CarfBody>
  <Transaction>
      <AssetType>BTC</AssetType>
      <GrossProceeds>60000.00</GrossProceeds>
      <Quantity>1.00000000</Quantity>
  </Transaction>
  <Transaction>
      <AssetType>ETH</AssetType>
      <GrossAmountPaid>60000.00</GrossAmountPaid>
      <Quantity>20.00000000</Quantity>
  </Transaction>
</CarfBody>

UAT Test Case Examples

Scenario	Expected Result	What is Verified
Simple Swap (BTC → ETH)	Two records created in the XML report: `TotalDisposals` for BTC and `TotalAcquisitions` for ETH with identical `GrossProceeds`/`GrossAmountPaid`.	Valuation logic, correct handling of two-sided trades.
Adding Liquidity to a Pool (ETH/USDC)	Two `TotalDisposals` records created (for ETH and USDC) and one `TotalAcquisitions` record for the LP token.	DeFi operation handling, LP token valuation.
Refund to Customer	Aggregated `TotalDisposals` or `TotalAcquisitions` amounts for the period are correctly reduced. No negative values in the report.	Adjustment and aggregation logic.
Customer without TIN	Record marked as incomplete, process initiated to request TIN from customer. Record does not enter the final report without a TIN.	Data validation at the ETL level, compliance processes.

Appendix 2: Templates and Checklists

(Samples, require adaptation to your jurisdiction and legal consultation)

1. User Agreement Clause Template

11. Data Collection and Transmission in accordance with CARF/DAC8
11.1. In accordance with the international Crypto-Asset Reporting Framework (CARF) standard and applicable legislation, we are required to collect and annually report information regarding your identity and transactions to tax authorities. The legal basis for such processing is our compliance with a legal obligation (e.g., Article 6(1)(c) of the GDPR).
11.2. The information transmitted includes your personal data (Full Name, address, TIN) and aggregated transaction data. In cases provided for by law, your data may be transferred to tax authorities outside your jurisdiction. We apply all necessary legal and technical measures to protect your data during such transfers.

2. Brief DPIA/TIA Checklist

Transfer Description: What data is being transferred? To whom (to which country)? For what purpose?
Legal Basis: Is the basis defined under GDPR (Art. 6) and the mechanism for transfer (Arts. 44–50), e.g., Adequacy Decision or SCCs?
Recipient Country Legislation Assessment: Could legislation (e.g., surveillance laws) prevent the data recipient from complying with SCC obligations?
Additional Measures: Are additional technical (e.g., end-to-end encryption) or organizational measures required to protect the data?
Necessity and Proportionality Assessment: Is the transfer necessary to achieve the goal? Is the volume of data transferred minimized?
Risks to Data Subjects: What are the potential risks to customers in case of unauthorized access or misuse of their data?
Final Decision: Documented decision on the admissibility of the transfer considering all factors.

Preparing for CARF 2027: A Guide for VASPs