接受数字货币钱包之前如何进行筛查

第 1 步：在准入前核查地址

从一个地址、一次核查开始。在 BlockSec 网站注册，用每月 3 次免费核查中的一次来核查该地址，然后查看几秒内返回的五级风险评级：无、低、中、高或极高。接下来，由你们成文的策略、而不是一时的感觉，来决定这个等级对该客户意味着什么。

扫描是容易的那一半，真正考验纪律的是决策规则：在开始之前，就写明团队在每个等级下该怎么做。一种常见的做法是：无和低风险直接接受，中风险进入审核，高和极高风险拒绝或上报。但合适的做法取决于你们的风险偏好和监管机构的要求。工具给出评级，策略给出判断。

这个顺序之所以重要，是因为第一次筛查是你在这段业务关系中能做的成本最低的一次筛查。在资金流动之前、在用户与你产生任何往来记录之前、在一次错误的接受演变成纠纷之前，你能干净地看一眼这个地址做过什么。金融行动特别工作组（FATF）将此表述为风险为本的方法：核查的深度应当与你面对的风险相匹配。

这项核查与身份核验并列进行，而不是排在其后。KYC 回答的是这个人声称自己是谁；地址筛查回答的是他的钱包一直在做什么。只做前者而跳过后者，平台就会出现这样的局面：客户身份完全核实，充值却来自与盗窃相关的钱包。两项核查在同一道门口进行，依据的是不同的证据。

第 2 步：用 API 扩大核查规模

当每日核查量超出一个人能做好的范围时，就把核查移入你的业务流程。批量筛查接口可以接收整份地址列表，API 密钥对调用进行认证，同样的五级风险评级以结构化结果返回，你的系统可以直接据此处理，无需任何人复制粘贴。

进入这一步的触发条件不是某个神奇的数字，而是第一次因为没时间而跳过核查。那一天，人工筛查就不再是一种控制手段，而只是一种侥幸。API 路径还能让输出标准化，这对最后的记录步骤很重要。

动手开发之前，有三个问题决定了方案设计。我们每天实际要做多少次核查，按峰值而不是平均值算？结果落在哪里，是客户档案、工单，还是单独的日志？当流程把一笔充值标记为待审核时，由谁负责处理这个例外？在第一周回答这些问题，可以避免两种典型的失败形态：没人看的筛查任务，和没人负责的审核队列。

从接口到速率限制的集成细节，详见自动化地址筛查：API、Webhook 与告警渠道。有一个规划层面的事实值得在这里重申：API 接入仅在 Scale 与 Enterprise 套餐中提供，所以在你的开发依赖它之前请先确认。

第 3 步：批准后配置监控

大多数团队在批准后就止步了，而这恰恰是监控应当开始的地方。一个今天筛查结果干净的钱包，今晚就可能收到被盗或受制裁的资金。你接受的地址会进入监控名单，风险等级变化会把告警推送到团队真正会看的渠道。

开启你工作流的风险为本方法，同样要求它持续进行：OFAC 近期动态按自己的节奏更新，一个地址可能在接入你的平台很久之后才被列入名单。真正重要的事件，是已批准地址的风险等级发生变化，并附带变化前后的等级以及事件经过的时间线。

干净的钱包为何会变得有风险，包括标签更新与新活动的机制，是一个独立的主题：数字货币钱包在干净之后还会变得有风险吗？。本手册要讲的是习惯：每个被接受的地址都要持续监控，每条告警都要有一个决定，哪怕这个决定只是继续观察。

让渠道适配团队，而不是反过来。常驻群聊的合规团队，就应该在群聊里收到告警；实行轮值的团队，就应该让告警落到轮值人员盯着的工具里。机制上最重要的是，变化前后的等级要与时间线一起送达，这样做决定的人就不必再去还原等级为什么变动。

第 4 步：保留经得起审计的记录

每一次核查、每一次批准、每一次告警响应都会留下记录：地址、日期、输入、评级以及决策理由。把这些记录放在一起，监管问询就从重建变成了检索，你的合规项目也能不断改进，因为你终于能看清它一直以来在做什么。

要达到的标准说起来很简单。当检查人员问你为什么在六个月前允许了一笔充值时，团队里有人能在几分钟内给出答案，并附上当时有效的证据。风险时间线和告警历史承担了大部分整理工作，因为它们记录了筛查看到了什么，以及何时看到的。

一个有用的演练是：每季度随机挑一个已接受的钱包，把检查人员的问题大声问出来。我们为什么接受了这笔充值？如果凭现有记录几分钟就能回答，说明这套机制行之有效。如果需要花一个下午去重建，那么这个缺口就在修复成本还低的时候暴露了出来。

记录也为可疑案件画上闭环。当活动从有风险越界到需要报告时，你一直保留的档案就成为可疑活动报告（SAR）的骨架。这类报告的标准由 FATF 框架确立，它把你的工作流与报告层衔接起来，相关内容见如何撰写数字货币 SAR 或 STR。

完整的四步框架（一页即可看完，无需滚动）在钱包筛查中心中有全景呈现，同时还介绍了面向上个月业务量刚刚激增的团队的自动化路径。