用于交易前筛查的实时 KYT API

实时 KYT API 只在唯一还能改变结果的那一刻回答一个问题：这笔交易放行之前。链上转账是不可逆的，所以一笔入金或出金一旦广播出去，剩下的选项只有调查与报送。交易前筛查把这个决策往前挪，挪进那个仍然可以拦下或挂起高风险交易对手的窗口里。本文只谈这个交易前窗口——它为什么要紧、延迟要求是多少、API 如何返回一个决策、拦截/挂起/放行这套处置、实时与批量与监控三种模式各自的适用场景，以及一份交易前接入清单。KYT 的完整能力面见 Phalcon Compliance。本页属于 KYT 资源中心。

交易前筛查为什么要紧

链上转账的不可逆性，是交易前筛查存在的结构性原因。一笔法币电汇可以通过代理行体系撤销、追回或冻结，一笔链上转账不能。它一旦被确认，资金就归收款方所有，剩下的救济手段只有事后调查、执法请求，或者提交一份 STR——而到那时资金往往已经又动过了。一道只在交易结算之后才跑的控制措施，实际上就是一道在损害发生之后才跑的控制措施。

交易后监控替代不了交易前检查。FATF 面向虚拟资产服务提供商的风险为本方法要求 VASP 对交易进行持续的、对风险敏感的监控，而不是在开户时做一次检查。FinCEN 在其面向货币服务企业的反洗钱体系规则（31 CFR 1022.210）下对持续反洗钱监控义务的界定，对加密交易所及其他美国货币服务企业指向的是同一个方向。两个框架都没有规定一个硬性的延迟数字，但都期望这道控制措施真的跑在它所管辖的那笔交易上。一个只在资金动完之后才发现风险的体系，留下的缺口会被检查官读作体系薄弱，而不是部署偏好。

经济账也偏向更早的那个决策。在闸口拦下一笔高风险入金，成本是一次 API 调用；追同一笔入金穿过三跳混币服务，成本是一个分析师好几天，而且追回来的概率很低。交易前筛查，正是「一道能预防的控制措施」与「一道只能报告的控制措施」之间的差别。

一次筛查调用必须多快返回

交易前筛查的边界是用户体验，不是厂商能力。一笔出金因为要跑筛查而卡两秒，用起来就像坏了；一笔入金因为分析师要复核而被挂十秒，用起来就像被冻结了。所以交易前决策的延迟预算很紧，是以数百毫秒计的，不是以秒计。一个常见的可用上限是端到端大约 500 毫秒——从交易抵达闸口，到放行、挂起或拦截的决策返回。在这个上限之下，筛查对用户是不可见的；超过它，筛查就开始显得像摩擦，而摩擦会驱使用户绕开这道控制措施。

理想目标要更低。API 自身做到 100 毫秒以内的响应，才给闸口剩下的部分留出余地：网络往返、内部路由、日志、阈值判断，都要在原始 API 调用之上再吃掉一部分预算。如果 API 一家就吃掉 300 毫秒，栈里剩下的部分就没得用了。延迟不是规格表上的一个功能项，它是「一道与交易同步运行的控制措施」和「一道与交易赛跑的控制措施」之间的差别。

BlockSec 为其实时筛查 API 标注的是毫秒级延迟。把它当作一个需要在生产流量上确认的目标，而不是一个可以据以设定内部 SLA 的既定事实。一道假设 50 毫秒、实际看到 400 毫秒的闸口，会在第一条告警触发之前就先垮掉。闸口必须去量那个真实数字，并在没达到时优雅降级。

实时 KYT 筛查 API 是怎么运作的

实时 KYT 筛查 API 坐在交易的决策路径上，而不是它旁边。整个流程有四步，而且必须在延迟预算内跑完。客户端完成认证并提交地址或交易标识；API 拿这个地址去比对它的风险数据，返回一个风险评分以及背后的证据；随后客户端的闸口用以代码定义的阈值把分值映射成一个处置动作——拦截、挂起或放行——并据此放行或截住这笔交易。这个调用是同步的、单地址的，因为决策必须在交易放行之前回来。

Phalcon Compliance 的实时筛查 API 就是这个形状。访问由单个 API key 管控。调用返回一个风险评分、支撑它的敞口数字，以及驱动这个分值的那些风险指标。风险数据建立在超过 6 亿个带标签地址与 17 个以上风险指标类别之上，覆盖行为模式、对已知非法服务的敞口，以及交易对手风险。分值是闸口据以分流的东西；而指标与敞口数字，是交易被挂起复核时分析师会读的东西——也正是它们让这个决策可审计而不是不透明。

有两个约束条件决定了这个 API 怎么用。第一，访问门槛在 Scale 档（699 美元/月起）与 Enterprise 档。免费档、筛查包与 Essential 档是给通过平台界面做交互式筛查用的，不是给嵌进交易闸口用的。一个要搭交易前筛查的团队，在写第一个调用之前就必须已经在 Scale 或 Enterprise 上。第二，那个延迟数字——实时 API 的毫秒级响应——决定了这个 API 能不能服务一道交易前闸口，还是只能退回去做交易后监控。在团队自己的负载下确认这个真实数字，是上线的一部分，不是上线之后的形式手续。

拦截、挂起还是放行：在资金动之前决定

一次实时筛查只有在闸口知道拿这个答案做什么时才有用。适配交易前筛查的框架是一套三档分层处置，而不是「放行还是标记」的二元判断。各档由风险评分划定，每一档都带一个闸口无需等人就会执行的具体动作。

第一档是放行。低风险地址在延迟预算内自动、同步地放行，而这一档必须占绝大多数流量。第二档是挂起。中风险地址既不放行也不拦截：交易被暂停，一条告警被送进复核队列，分析师在面前摆着风险指标与敞口数字的情况下决定处置。挂起接住的是那些分值本身模糊、值得为人工判断付出延迟代价的情形。第三档是拦截。高风险地址在放行前被截住，交易不被广播，同时开出一条带完整证据链的告警。拦截这一档干的，正是交易后监控干不了的那份预防工作。

这套框架的分量在审计链上，而不只在那个决策上。每一个处置结论都必须可复现：返回的是哪个分值、它落进哪一档、由哪些指标驱动、闸口采取了哪个动作。一次拦截必须能作为「基于证据的决策」被论证，而不是一条拍脑袋的经验规则。一次挂起必须可审计为「一次确实被复核并结掉的暂停」，而不是一笔被悄悄丢掉的交易。风险指标与敞口数字，正是让这条链完整的东西。没有它们，处置就只是一个裁决；有了它们，它是一个检查官或审计人员读得懂的、有据可查的决策。

实时、批量、监控——什么时候用哪个

交易前筛查不是唯一的筛查模式，而把这几种模式搞混是一个常见的失败模式。实时 KYT API 有三种运行模式，各自回答一个不同的问题。实时单次检查回答「这笔交易现在放行安不安全」。批量筛查回答「这批积压的风险画像是什么样」。监控回答「一个我们已经筛过的地址，自上次看过之后风险变了没有」。三者不会合并成一个，用错了要么白烧额度，要么漏掉风险。

实时单次检查是交易前那个模式：同步、低延迟，在闸口上每笔交易跑一次。批量筛查是异步的，跑在 CSV 上传的历史积压上，不跑在交易路径里。监控是持续的：它按动态周期重新分析已筛查过的地址，并在一个此前干净的地址风险发生变化时触发——比如某个交易对手后来被列入制裁名单。

实际分工是：实时管现场闸口，批量管历史积压，监控管风险漂移。只跑实时的体系，对第一次筛查之后才浮现的风险是盲的；只跑监控的体系，没有交易前决策；只跑批量的体系，两样都没有。稳妥的配置是三种都用，各守其道。特别值得一提的是，监控模式不消耗筛查额度，所以把它一直开着，不会占用实时与批量所依赖的那份单次检查预算。本页只谈实时这条道；把三者一起接进一个交易所流程，是另一个接入话题。

交易前筛查的接入清单

一道交易前筛查闸口算做完，是当它对任意一笔交易都能回答：采取了什么处置、为什么、以及这个决策花了多久。下面这份清单是实时视角，聚焦闸口本身。

1. 确认 API 档位。 实时 API 访问需要 Scale 档（699 美元/月起）或 Enterprise 档。写第一个调用之前先确认。

2. 把延迟预算写进代码。 为整条筛查路径定一个上限（常见约 500 毫秒），并在生产流量上量真实往返时间。把官方公布的毫秒级响应当作一个待确认的目标，而不是一个假设。

3. 把阈值分档定义成代码。 拦截、挂起、放行必须是程序化的，按返回的风险评分分流。只活在文档里、不活在闸口里的政策，不会跑在交易上。

4. 上线前先接通告警路径。 挂起与拦截必须真的落进一个队列——webhook、工单或内部频道。等第一条告警漏掉之后再补分流，那已经是一次失败了。

5. 每个处置结论都要落存证据。 分值、阈值档位、风险指标、敞口数字，都必须与交易记录一起存下来。这个处置在几个月后必须仍然可复现。

6. 建好降级路径。 如果 API 超出延迟预算或报错，闸口必须朝一个既定方向失败——挂起待复核，或者放行但打上交易后监控标记——而不是把交易悄悄丢掉。

7. 处理速率限制。 筛查 API 按 key 限流，超限的调用返回 HTTP 429。客户端必须做退避，而不是遇错就重试。

8. 为风险漂移打开监控。 交易前筛查抓的是闸口那一刻的风险，监控抓的是之后才浮现的风险。监控不消耗筛查额度，所以可以一直开着而不占用实时的预算。

一道过了这份清单的闸口，会把交易前决策跑在交易路径里：阈值会触发、告警会到人手上、证据会留存、降级路径会安全失败。这就是实时交易前筛查在实践中的样子。阅读 Phalcon Compliance 的 KYT API 文档，查端点参考、Scale 档的接入路径，以及完整的风险指标 schema。