把 KYT API 接进加密交易所

一次 KYT API 接入，会在每一笔入金与出金上调用筛查端点、解析返回的风险评分，并在资金动之前给这笔交易分流。批量筛查与持续监控叠在它上面，负责历史数据与地址漂移。这个 API 属于交易流程里面，而不是跑在它旁边——因为实时检查在结算之前抓到高风险活动，而批量任务与监控覆盖两者之间的一切。本文为一家加密交易所走完这三种模式。更宽的工作流见 Phalcon Compliance。本页属于加密反洗钱合规中心。

交易所为什么需要 API 级的实时筛查

一家交易所选定的筛查节奏，同时也就是它接受下来的那个洗钱窗口。一个按周或按日跑的批处理任务，筛的是批处理运行那一刻的所有地址；但每一笔在两次批处理之间到达的入金，都会毫无阻碍地进入钱包。资金可以在那道缝隙里落地、转移、提现出去。API 级的实时筛查把这道缝隙合上，因为每一笔入金与出金都在交易被放行之前被检查过。

推动它的不只是运营考虑。FinCEN 要求货币服务企业（含加密交易所）维持一套反洗钱体系（31 CFR 1022.210）并报送可疑交易（31 CFR 1022.320），并结合其2019 年虚拟货币指引（FIN-2019-G001）一起读。实操上，正是这个组合使持续监控成为必需，而不是设定了某个固定的实时阈值。FATF 面向虚拟资产服务提供商的风险为本方法收敛到同一个要求上——它要求 VASP 持续监控交易，而不是在开户时做一次检查。一家交易所满足这两者的方式，是在每一笔入金与出金上保持一道活着的控制措施——而这恰恰是下面讲的实时 API 模式所提供的东西。一个只有批量节奏的做法，会在「监控义务」与「实际在跑的控制措施」之间留下一段可被察觉的距离，而检查官会把这段距离读成体系缺陷，而不是部署偏好。

这个问题的开发一侧，本身是另一重约束。在那些现成的第三方工具真正拿到内部系统的访问权限之前，任何组合都不会贴合一家交易所的使用场景——所以被低估的那场仗是接入，而不是功能数量。一个无法与入金流程、出金流程和告警分派路径对话的筛查引擎，改变不了这家交易所能抓到什么，它只改变了一个看板。正是接入这件工作，把一项筛查能力变成一个筛查体系。

接入前的准备：风险阈值、告警分派、系统访问

在写任何 API 调用之前，有三个决定必须先定下来。它们决定了这套接入上线之后实际做什么；而在部署之后再改它们，意味着 API 客户端与下游告警路径都要返工。这三个决定坐在更大的加密交易所反洗钱合规体系里面——那篇覆盖风险评估、筛查、分流与可审计记录。本页聚焦的是那套体系里的 API 接入层，而不是体系结构本身。

第一个决定是风险阈值规则集。KYT API 返回一个风险评分，但这个分值在交易所决定「哪些分值区间触发哪个动作」之前什么都不做。一个常见的形状是三档：低风险自动放行，中风险挂起交易待人工复核，高风险拦截交易并开出告警。这些阈值必须被定义成代码、而不是定义成政策，因为 API 客户端会以程序方式按它们分流。

第二个决定是告警分派。当一个风险评分越过阈值时，这条告警必须到达一个人或一个队列。分派设计要覆盖：哪个渠道承载这条告警——是一个进 Slack 或 Telegram 频道的 webhook、一个案件管理工具里的工单，还是一个内部队列里的条目。平台支持含 webhook 的多渠道通知，而分派路径必须在接入上线之前就映射好，不是在第一条告警漏掉之后再补上去。

第三个决定是套餐门槛。API 访问只在 Scale 档（699 美元/月起）与 Enterprise 档提供；免费档、筛查包与 Essential 档不含 API 访问。一个想把筛查嵌进自家入金或出金流程的团队，需要先到 Scale 档。在接入开始之前确认这一点，能避免「代码是对着一个团队实际用不了的档位写的」这种局面。至于多席位团队协作——如果合规职能需要不止一个人同时在工具里作业——只在 Enterprise 档提供。这道门槛如何坐在更宽的加密反洗钱合规体系里，在中心页上有铺陈。

接入 Phalcon Compliance 的 KYT 与 KYA API：三种模式

Phalcon Compliance 的 API 支持实时检查、异步 CSV 批量筛查、持续监控。实时检查覆盖入金与出金。批量筛查覆盖历史地址与积压。Monitor 盯住此前已筛查过的地址、观察其风险变化。交易所可以按「在哪里、什么时候需要筛查」把这三种模式组合起来。

一家交易所的入金与出金流程有三种筛查需求，而它们不会合并成一种。一笔活着的交易需要在被放行之前拿到答案，这意味着一次同步的、低延迟的调用。一批历史地址需要在不阻塞实时流量的前提下批量筛查，这意味着一个异步任务。而一个首次筛查时干净的地址，日后可能与一个高风险交易对手交易，这意味着对已筛查地址的持续观察，而不是一次性的裁决。

Phalcon Compliance 以三种模式开放它的筛查 API，对应上述三种需求。实时单次检查模式覆盖入金与出金闸口。异步 CSV 批量模式覆盖积压与历史筛查。持续的 Monitor 模式按动态周期重新分析已筛查过的地址。三种模式共享同一个已认证的接口面，于是单个 API key 就管控对它们全部的访问，而交易所是逐次调用地挑模式，不必维护几套独立的接入。

三种模式的接入顺序是一样的。客户端用平台签发的 API key 完成认证；带上地址或交易标识调用筛查端点；解析返回的风险评分，包括附着在分值上的风险指标与敞口数字；按接入前定下的阈值规则分流；并在阈值被越过时，通过已配置的 webhook 或通知渠道发出告警。筛查 API 按每个 API key 每分钟 50 次调用限流，超限的调用会收到 HTTP 429，所以客户端必须以退避方式处理 429，而不是遇错就重试。

BlockSec 把实时单次检查的延迟标注为毫秒级。把它当作一个需要拿团队自己的流量去确认的数字：把接入建成能容忍延迟的形态，而不是假定某个具体的毫秒目标；交易所设定的任何内部 SLA，都要拿生产流量去量。

速率限制、额度与套餐门槛：工程要点

速率限制是接入最先撞上的那个工程约束。筛查 API 按每个 API key 每分钟 50 次调用限流，超限的调用会收到 HTTP 429。对一条活着的入金流程，这很少构成实际约束，因为入金是一笔一笔到的，而一次实时检查会在下一次调用之前跑完。但对一次批量操作它就是约束了，因为同步地筛几千个积压地址，几分钟就会把限额烧穿。CSV 批量模式的存在，正是为了把这份负载从同步路径上移走。CSV 地址筛查每文件最多接受 100 个地址，CSV 交易筛查每批最多接受 400 笔交易。于是积压是被异步处理的，不会与实时闸口争抢速率限额。

额度模型是第二个约束。筛查会扣减一个余额，而扣减按一个既定顺序发生：订阅额度每个周期重置，然后消耗充值筛查额度，然后是推荐奖励，然后是筛查包。接入本身不需要挑用哪个余额；但掌管预算的合规团队确实需要理解这个顺序，因为它决定了哪个余额先被耗尽、以及什么时候必须充值。Monitor 模式是例外：它按动态周期运行，在已筛查地址的风险发生变化时重新筛查它们，而且不消耗筛查额度——所以把 Monitor 一直开着，不会占用单次检查的预算。

套餐门槛是第三个约束，而且不可协商。如上文所述，API 访问需要 Scale 档（699 美元/月起）或 Enterprise 档；免费档、筛查包与 Essential 档不含 API 访问。在这道门槛之外，还有两项附加能力会影响范围：webhook 访问落在 Scale 或 Enterprise 档；自定义风险引擎配置从筛查包档位起可用（筛查包 3 个引擎、Essential 10 个、Scale 20 个、Enterprise 不限）；而工具内的多席位协作是 Enterprise 的功能。这些档位背后的定价细节在专门那篇定价 spoke 里讲；本页只覆盖影响 API 接入规划的那部分门槛。

阅读 Phalcon Compliance 的 API 文档

一次 KYT API 接入，不是在第一个调用返回一个分值时就算完成了。它算完成，是当实时闸口、积压路径与 Monitor 观察三者都被接进了这家交易所的入金与出金流程：阈值被定义成代码、告警分派到一个真实队列、套餐门槛在第一个调用之前就已确认。阅读 Phalcon Compliance 的 API 文档，查端点参考、webhook 契约与 Scale 档的试用路径。