一、CARF 进入执行期 交易所的税务合规成本从何而来

2026 年 8 月 27 日，加密财税服务商 FinTax 宣布完成种子轮融资，由 YZi Labs 旗下 EASY Residency S4 领投，投后估值为 4000 万美元。 该融资发生在加密税务信息申报进入执行阶段之际。英国已从今年 1 月起实施 OECD 加密资产报告框架 CARF 的相关规则；欧盟同期开始适用与 CARF 衔接的 DAC8 加密资产申报规则。对于这些市场的相关交易所，用户税务资料收集和交易数据留存已经是当年的工作，而不只是为明年做准备。

截至 2026 年 9 月，距离年底只剩三个多月。不过，“存量用户尽调不足四个月”需要一个前提：平台适用的是从今年初开始实施、要求在十二个月内完成存量用户尽调的规则。CARF 并没有给全球交易所设定同一个截止日。 OECD 框架与规则解说

交易所每天都在处理大量账户和交易数据，为什么增加一项税务申报，仍然可能需要改造整套业务流程？因为税务申报对用户身份、交易分类和历史记录的要求，与撮合成交或核对余额并不相同。这些差异决定了平台需要补齐哪些数据，以及每年为此投入多少人力和系统资源。

二、做过 KYC，为何还要重新提交资料

交易所已有的 KYC 体系可以帮助 CARF 尽调，但两者关注的问题并不完全重合。身份证件能够支持身份核验，却不能单独回答用户在哪些地区属于税收居民、对应税号是什么，以及公司账户背后是否有需要识别的控制人。

交易所进入 CARF 实施后，首先需要识别哪些用户属于应报告用户。CARF Section III 要求 RCASP 取得用户自我证明，据此确定其税收居民身份，并结合已有资料确认自我证明的合理性。个人用户需提供姓名、居住地址、税收居民辖区、对应 TIN 和出生日期；实体用户需提供法定名称、地址、税收居民辖区和 TIN，并说明其是否属于活跃实体或排除人士。如实体不属于上述两类，还需识别控制人，并取得其姓名、居住地址、税收居民辖区、TIN、出生日期及控制人身份。对于存量用户，上述尽调原则上应在 CARF 规则生效后 12 个月内完成，首批法域即 2026 年 12 月 31 日。

这一过程可以较大程度复用交易所已有的 AML/KYC 体系。CARF 允许 RCASP 将已有客户信息预填至自我证明，但税收居民辖区仍需由用户自行确认；此前为 CRS、FATCA 或其他税务申报取得的自我证明，如已包含 CARF 要求的信息，也可以继续使用。交易所同时需要利用 KYC 资料对自我证明进行合理性核验；如申报的税收居民地与现有地址、身份资料等存在冲突，则需取得新的自我证明，或补充能够解释差异的说明和证明材料。

存量用户补采需要建立明确的追收和异常处理机制。以 Coinbase 为例，用户申报的税收居民地如与账户地址、手机号所属国家或出生地不一致，需要补充说明并接受进一步审核；OKX 则设置了 TIN 无法提供时的例外选项，并对逾期未完成税务信息更新的账户采取限制措施。对拥有数百万注册用户的交易所而言，补采不是一次表单改造，而是一场需要追收流程、异常队列和限权规则配合的运营战役。

三、单笔币币成交，为何需要两端记录

CARF Section II 要求 RCASP 针对每一名应报告用户，按每一种相关加密资产及交易类型汇总报告其在报告期内发生的相关交易，包括：

· 以法币取得和处置相关加密资产；

· 以其他相关加密资产取得和处置相关加密资产；

· 应报告零售支付交易；

· 以及其他转入和转出。

其中，对于交易所已知性质的转移，还需按照空投、质押收益、贷款等转移类型进一步分类；向交易所无法确认属于虚拟资产服务提供商或金融机构的钱包地址转出的资产，也需要单独汇总。上述信息均按应报告用户、相关加密资产和交易类型进行年度汇总。

在交易所具体业务中，这些类别基本对应用户日常产生的几类资金流和资产流：法币购买或出售加密资产对应法币兑换交易；BTC 兑换 ETH 等现货币币交易需要分别记录一种资产的处置和另一种资产的取得；充值、提现以及部分质押、借贷、奖励分发等业务可能形成相关加密资产的转入或转出；支付业务在满足条件时进入应报告零售支付交易。对于币币交易，一笔交易在 CARF 口径下需要拆分为取得和处置两端，并分别按照交易发生时的公允价值计量。

交易所需要在底层保留能够生成上述汇总结果的数据。多数交易所现有的数据仓按风控和财务口径搭建，能算出”用户全年成交多少”，未必能反推”这笔成交在成交时刻两端各值多少法币、对手地址是否属于 VASP”，这一层颗粒度往往需要补建。

四、从内部数据到申报文件的转换难题

完成用户识别和交易数据归集后，交易所需要将分散在 KYC、账户、撮合、钱包、支付、质押、借贷等系统中的数据统一关联，并转换为 CARF 要求的标准化申报结构。OECD CARF XML Schema 以 RCASP、Crypto-Asset User 和 Relevant Transactions 为核心层级，因此交易所需要建立内部数据模型与 CARF 字段之间的映射关系，将用户身份、税收居民信息、相关加密资产、交易类别、交易笔数、资产数量、金额、报告币种及估值方式等信息准确落入对应字段。对于币币交易、转入转出、外部钱包转移等场景，还需要按照 CARF 规定拆分交易方向和类型，确保汇总结果能够回溯至底层交易记录。

在数据生成阶段，需要配置字段完整性、代码值、数据类型及逻辑关系校验，例如税收居民辖区与 TIN 的对应关系、货币代码、金额与资产数量格式，以及交易分类和估值方法是否符合 Schema 要求。通过校验后的数据再按照申报辖区采用的 XML Schema 或本地兼容格式生成申报文件，并保留 DocSpec、MessageRefID 等记录标识，以支持后续更正、删除和版本追踪。

这一层是纯工程，也是前两层质量的最终裁判：字段对不上、拆分口径不一致，都会在此被打回。

五、持续维护更新：首次申报之后才是常态

CARF 不是一次性项目，三类变化会持续触发规则和映射的更新。

用户事实变化。 用户的地址、税收居民地、TIN、实体性质或控制人等信息发生变化后会改变原有的应报告用户判断。交易所需要将 CARF 尽调与现有 KYC 和账户信息更新机制衔接，对可能影响税务身份的信息变化设置触发规则，并根据 CARF 要求重新取得或确认自我证明、补充证明材料，更新相应用户主数据。

业务及数据变化。 交易所持续上线新的代币、质押、借贷、支付、托管或代币化资产等产品，原有的资产分类和交易映射规则也需要同步更新。新增产品或交易场景上线前，应重新判断涉及资产是否属于相关加密资产、相关资金流是否构成相关交易，并相应调整交易类型、转移类型、估值方法和字段映射，确保新增业务能够进入既有 CARF 数据处理链路。

规则及申报要求变化。 各辖区 CARF 落地进度、申报字段、XML Schema、本地技术接口及校验规则可能持续调整。交易所需要建立规则跟踪和版本管理机制，及时更新申报规则库、字段映射和技术配置，并保留历史版本及申报记录，以支持后续更正、补报和数据追溯。

结语

对于加密货币交易所而言，CARF 落地涉及用户识别、交易判断、数据归集、字段映射、技术报送和持续维护等多个环节。随着业务类型和产品形态不断扩展，申报工作的关键在于将 CARF 规则稳定嵌入现有 KYC、交易、钱包和数据治理体系。对于跨辖区经营的平台，还需要进一步协调不同法律实体、报告连接点和本地申报要求，确保同一套业务数据能够按照相应辖区规则准确转化并完成报送。

把这些环节叠起来看，CARF 对交易所的真实成本不是一份合规意见，而是一条需要长期维护的数据链路。自建需要三种能力同时具备：对 CARF 条文的精确理解、对交易所各业务系统的工程适配、对多辖区申报接口的持续跟踪。多数交易所具备第二种，缺第一和第三种。在这个过程中 FinTax 可提供将判断沉淀为可复核、可持续更新的申报流程。

首批法域存量用户尽调 2026 年 12 月 31 日截止。