Riset terverifikasi sumber: OECD CARF XML Schema
Isi artikel ditampilkan dalam bahasa Inggris asli yang telah diverifikasi. Terjemahan ditambahkan setelah tinjauan sumber.
Verified Fact Boundary
1. OECD describes CARF as designed to collect and automatically exchange information on transactions in relevant crypto-assets. 2. OECD describes CARF as including rules and commentary, a competent authority agreement and an electronic XML format. 3. OECD announced XML schemas and user guides for CARF and amended CRS to support transmission of information between tax authorities. 4. OECD schema materials say the XML schema can also be used for domestic reporting by Reporting Crypto-Asset Service Providers where domestic law permits. 5. CARF documentation does not by itself prove a specific exchange's user-facing tax report, jurisdictional filing status or private account classification. 6. A public readiness article must avoid collecting or displaying private identity documents, tax identifiers, full transaction histories or balances.
Tampilkan lebih sedikit
Decision Matrix
Tabel artikel: gulir secara horizontal atau fokuskan area tabel dan gunakan tombol panah.
| Check | What it means | Practical action | Unknown to keep explicit |
|---|---|---|---|
| Data object | CARF turns crypto-asset activity into reportable schema fields | map user, asset, transaction and correction objects separately | domestic implementation details by jurisdiction |
| Reporting party | the provider, tax administration and user have different obligations | avoid telling users an exchange has filed unless official evidence exists | private provider status and account classification |
| Schema readiness | XML support is not the same as operational filing completion | separate schema availability from product export readiness | live exchange implementation timeline |
| Privacy boundary | tax reporting evidence can expose sensitive identity and transaction data | publish only non-secret process checks and official links | individual tax treatment and legal advice |
| Stop condition | do not claim CARF compliance from a help article alone | pause when jurisdiction, provider status or schema field mapping is unclear | future filing dates and corrections remain jurisdiction-specific |
Source Map
- OECD: Crypto-Asset Reporting Framework: Introduction (oecd-carf-intro)
- OECD: OECD releases IT format for CARF and amended CRS (oecd-carf-schema-announcement)
- OECD: Crypto-Asset Reporting Framework XML Schema (oecd-carf-schema-pdf)
- OECD: Crypto-Asset Reporting Framework: 2025 Monitoring and Implementation Update (oecd-carf-monitoring)
Control Notes
1. Data object
Data object is the point where public documentation must become an operating rule. In this package, it means CARF turns crypto-asset activity into reportable schema fields. The practical action is to map user, asset, transaction and correction objects separately. The unresolved edge is domestic implementation details by jurisdiction, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.
2. Reporting party
Reporting party is the point where public documentation must become an operating rule. In this package, it means the provider, tax administration and user have different obligations. The practical action is to avoid telling users an exchange has filed unless official evidence exists. The unresolved edge is private provider status and account classification, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.
The operating test is narrow.
3. Schema readiness
Schema readiness is the point where public documentation must become an operating rule. In this package, it means XML support is not the same as operational filing completion. The practical action is to separate schema availability from product export readiness. The unresolved edge is live exchange implementation timeline, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.
The operating test is narrow.
4. Privacy boundary
Privacy boundary is the point where public documentation must become an operating rule. In this package, it means tax reporting evidence can expose sensitive identity and transaction data. The practical action is to publish only non-secret process checks and official links. The unresolved edge is individual tax treatment and legal advice, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.
The operating test is narrow.
5. Stop condition
Stop condition is the point where public documentation must become an operating rule. In this package, it means do not claim CARF compliance from a help article alone. The practical action is to pause when jurisdiction, provider status or schema field mapping is unclear. The unresolved edge is future filing dates and corrections remain jurisdiction-specific, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.
The operating test is narrow.
Known Unknowns
- domestic implementation details by jurisdiction
- private provider status and account classification
- live exchange implementation timeline
- individual tax treatment and legal advice
- future filing dates and corrections remain jurisdiction-specific
Practical Takeaway
The OECD CARF XML schema turns crypto-asset tax transparency from a policy headline into a data-readiness problem for reporting service providers and tax administrations. OECD materials describe CARF as a framework for collecting and automatically exchanging information on relevant crypto-asset transactions, with an XML schema that can support exchange between authorities and, where domestic law permits, domestic reporting by Reporting Crypto-Asset Service Providers. The user-relevant decision is whether an exchange can map account identity, transaction classification, schema fields, correction workflow and jurisdiction-specific effective rules without exposing private tax or identity data in a public article. The article stops at the evidence boundary. It helps the reader decide what to inspect next without converting public documentation into a promise that a private account, wallet, API key, pool route, stablecoin balance, tokenized asset or policy framework will work under every future condition.