VASP 加密合规依赖于五项义务：客户尽职调查、交易监控、记录保存、可疑活动报告，以及制裁筛查。如果你运营一家虚拟资产服务提供商（交易所、托管机构、支付平台），这五项就是每个监管机构会用来审查你的框架。没有任何司法管辖区会因为你的合规团队只有两个人就缩减这些要求。一个小型 VASP 能够掌控的是顺序：哪些义务先站稳，哪些工具承担哪部分负荷，以及每一项的"完成"标准是什么。本清单将全部五项义务映射到相应工具，并规划出一个精简团队在第一季度真正可执行的建设顺序。
VASP 需要承担什么
去掉缩写，这些义务就变得具体：了解你的客户、监视他们的交易、保存记录、提交报告、对照制裁名单进行筛查。这一组义务不是可选菜单：监管机构将其视为一个整体项目，其中一项出现漏洞，就会在所有方面表现为失败。虚拟资产服务提供商是指为他人交换、转移、保管或管理虚拟资产的任何企业；义务附着于活动本身，而非牌照标签。
这些义务不会随人员规模而缩减。企业级的合规人员配置和工具具有两人团队平台无法匹配的预算体量，因此在小型平台上，这些义务并非消失，而是人手不足。风险敞口也不会因此缩小：小型平台会收到与大型平台同样的网络钓鱼所得、与黑客攻击相关的钱包，以及被制裁实体的互动。
小规模所带来的差异在于哪些故障会先出现。监控和报告最先崩溃——没人能处理的警报队列，没人有时间整理的申报文件——因为这两项义务具有持续的量级。下面的清单正是按照这一失败顺序来设计的。
五项义务，映射到相应工具
VASP 的义务映射到相应的工具类别：API 筛查平台承担监控功能，而身份识别和转账信息工具则覆盖其余部分。这个映射很重要，因为没有任何单一工具类别能覆盖全部五项义务，而假装某一个工具能做到，正是平台最终把监控漏洞包装成合规项目的原因。下表是真实的版本：每项义务、满足它需要什么，以及哪个工具类别实际承担这项工作。
| 义务 | 要求内容 | 常见实现方式 | 承担该义务的工具类别 |
|---|---|---|---|
| 客户尽职调查 | 了解你所服务的对象；在入驻时评估风险 | 身份验证流程；风险问卷 | 身份验证供应商及内部流程（身份核验是与链上筛查不同的独立学科） |
| 交易监控 | 监视资金流动中的风险信号；对风险敞口发出警报 | 实时筛查 API；基于规则的警报 | 链上筛查 API（链上层） |
| 记录保存 | 保留筛查和决策记录 | 自动化审计记录；结构化日志 | 平台工具；能自动记录日志的筛查工具 |
| 可疑活动报告 | 在截止日期内整理并提交报告 | 模板化申报流程；案例管理 | 报告工具及流程；筛查提供证据支持 |
| 制裁筛查 | 对交易对手进行制裁指定名单核查 | 基于名单和基于标签的筛查 | 具有标签化情报的链上筛查 API |
表格中体现了三点边界说明。客户尽职调查中的身份验证（文件核查、活体检测、身份解析）是一门独立学科，由身份验证供应商或平台自身流程负责处理；链上筛查工具是对其的补充，而非替代。转账信息义务（在有此要求的司法管辖区）由专门的转账信息工具承担，这又是另一个独立类别。而 PEP 筛查——基于姓名对政治公开人物数据进行核查——同样是一门独立学科，有专门的供应商；链上筛查承担的是该行中制裁与非法风险敞口的那一半，而不是 PEP 的那一半。FATF 制定 VASP 义务体系的依据是《建议15》及其解释性说明，以及《建议16》——即虚拟资产标准和旅行规则——而非管辖另一项义务的 PEP 相关建议。
小型 VASP 团队实际崩溃的地方
对精简团队来说，崩溃点在于监控到报告的流水线，而它崩溃的原因是纯粹的算术问题：警报量随客户数量增长而增长，分析师的处理能力却不会随之增长。手工组装的申报文件——提取证据、重建时间线、撰写叙述——在小团队的人手配置下每份可能就要耗费一个上午。这种吞吐量的天花板会把繁忙的一个季度变成积压，把积压变成未能按时提交的报告。交易监控中过高的误报率会让这个算术问题更加恶化：当队列中大部分是噪音时，队列本身就成了危机。可解释的风险评分如何应对这种噪音，在专门的文章中有详述。
失败的顺序是可预见的。监控开启；警报涌入；团队处理能处理的部分；队列不断增长；申报错过截止日期；被标记内容及原因的记录散落在各个电子表格中。这个顺序中没有一环是政策上的失败。它是一种能力上的失败，而能力上的失败有工具层面的解决方案，而不是政策层面的解决方案。
记录保存也以同样的方式崩溃。该义务要求的是：对任何给定的客户或警报，能够在数月之后按需提供当时筛查了什么、发现了什么、做出了什么决定。按照这一标准进行手工记录汇总，无法支撑不断增长的客户群体。
一份本季度就能执行的顺序化清单
VASP 的建设顺序应先做制裁筛查，其次是监控，第三是报告模板，因为每一层都为下一层提供支撑。单独的筛查环节已经能以最低的集成成本，捕获最难处理的风险敞口——被指定实体和被标记地址。监控将时点性的检查转变为持续性的覆盖。结构化的报告将监控输出转化为能按时提交的申报文件。按此顺序执行的精简团队，能在季末实现两项风险最高的义务的自动化，以及第三项义务的模板化。
按顺序进行的三个步骤，加上一项贯穿始终的实践：
-
首先是制裁筛查。 API 集成是最轻量的工作：在入驻和交易事件时进行一次筛查调用。Phalcon Compliance 对照超过 6 亿个已标记地址进行地址筛查，其类别之一就包括被制裁实体检测；入门路径从免费层级开始，经过信用套餐，随着量的增长升级到订阅模式。仅这一步，就能将最难处理的法律风险敞口置于自动化检查之下。PEP 筛查不属于这一步——基于姓名的 PEP 核查是一门独立学科，有专门的供应商，而链上筛查承担的是制裁那一半。地址侧背后的KYA 学科在一份独立指南中有详细解析。
-
其次是交易监控。 在筛查已上线的基础上，监控进一步延伸：持续监视客户资金流动中的风险转变，例如一个干净的钱包收到了有风险敞口的资金，或者形成了某种交易对手关联。警报分级能让队列保持在分析师处理能力之内；分级是监控与被淹没之间的分界线。
-
第三是报告模板。 在监控产生结构化警报的基础上，申报变成了组装工作而非撰写工作；证据链已经是机器生成的。当筛查记录变成一次查询而非一次重建时，申报流程就会大幅压缩。
-
贯穿始终的记录自动化。 上述每一步在基于 API 工具构建时，都会自行生成审计记录；记录保存的义务由此作为副产品得以满足，而不必作为第四个独立项目去完成。
要开始筛查这一步，打开 Phalcon Compliance 并运行首次筛查：从免费层级开始，随着量的增加追加按需付费的信用套餐，等筛查成为常规操作后再升级到订阅层级。
常见问答：VASP 义务的实践
每家 VASP 从第一天起就需要具备全部五项控制措施吗？ 第一天不需要；这正是为什么要设计顺序。但这些义务是随着客户的出现而生效的，而不是随着团队的准备情况：第一个真实客户到来时，筛查义务立即生效，而监控义务会在第一个增长阶段内随之而来。诚实的说法是：这个顺序会随着量的增长而压缩；它不会等待你准备好。
一个 API 工具能覆盖哪些义务？ 一个链上筛查 API 覆盖的是链上层面：制裁与风险筛查、交易监控，以及两者生成的审计记录。它不覆盖身份验证（那是一门独立学科，有专门的供应商），也不组装申报文件，尽管它为申报提供证据支持。以 Phalcon Compliance 为例，它承担了这三个层面。一个能把五项义务中的三项做好的工具，胜过五个把它们都做得很差的工具。
监管机构来访时，哪些记录能经得起检验？ 四部分答案是：筛查了什么、依据什么情报、发现了什么，以及平台的政策针对这一发现做了什么处置。筛查工具能自动生成前三项；处置日志则是平台自身的记录。需要花一周时间才能组装出来的记录，就是那种回答问题太迟的记录；自动化这一步的存在意义，就是让答案变成一次查询，而不是一个项目。BSA 记录保存规则规定了美国审查人员所依据的五年最低保存期限；FinCEN 的执法行动展示了当记录缺失时执法会是什么样子。
小团队如何应对 SAR 报告的数量？ 靠结构而非靠人数。基于机器生成的筛查记录构建的模板化申报，能大幅压缩单份申报的成本；分级警报能让可审核的队列与处理能力保持相称。能在数量压力下存活下来的团队，把申报当作组装工作来处理：证据已经存在，模板已经存在，分析师做的是确认而非撰写。耗费数小时的申报，是一个有已知解决方案的流程设计问题。
