加密财税服务商 FinTax 于 2026 年 8 月 27 日宣布完成种子轮融资，由 YZi Labs 旗下 EASY Residency S4 领投，投后估值为 4000 万美元。融资发生时，围绕加密资产税务信息申报的合规要求已经进入执行阶段。
CARF 开始执行，交易所的税务成本从哪里产生
英国已从 2026 年 1 月起实施 OECD《加密资产报告框架》CARF 的相关规则，欧盟同期开始适用与 CARF 衔接的 DAC8 加密资产申报规则。对这些市场的相关交易所来说，用户税务资料收集和交易数据留存已经是当年的工作，不是为下一年提前准备。
截至 2026 年 9 月，距离年底只剩三个多月。不过，所谓「存量用户尽调不足四个月」有一个前提，即平台适用的是从年初开始实施、并要求在 12 个月内完成存量用户尽调的规则。CARF 并没有为全球交易所设定统一截止日。
交易所每天都在处理大量账户和交易数据，但新增税务申报后，平台仍可能需要改造整套业务流程。原因在于，税务申报对用户身份、交易分类和历史记录的要求，与撮合成交或余额核对并不相同。平台需要补齐哪些数据、每年投入多少人力和系统资源，也由这些差异决定。
已有 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、本地技术接口及校验规则都可能持续调整。交易所需要建立规则跟踪和版本管理机制，及时更新申报规则库、字段映射和技术配置，并保留历史版本及申报记录，以支持后续更正、补报和数据追溯。
FinTax 所对应的需求
文章认为，对加密货币交易所来说，CARF 落地涉及用户识别、交易判断、数据归集、字段映射、技术报送和持续维护等多个环节。随着业务类型和产品形态扩展，申报工作的关键在于把 CARF 规则稳定嵌入现有 KYC、交易、钱包和数据治理体系。
对于跨辖区经营的平台，还需要协调不同法律实体、报告连接点和本地申报要求，确保同一套业务数据能够按照相应辖区规则准确转化并完成报送。
把这些环节叠加起来看，CARF 对交易所的真实成本，不是一份合规意见，而是一条需要长期维护的数据链路。自建这套体系，需要同时具备对 CARF 条文的精确理解、对交易所各业务系统的工程适配，以及对多辖区申报接口的持续跟踪。文章称，多数交易所具备第二种能力，但缺少第一种和第三种。在这一过程中，FinTax 可提供将判断沉淀为可复核、可持续更新的申报流程。
首批法域存量用户尽调的截止时间为 2026 年 12 月 31 日。