一次性检测只告诉你一个事实：你提问的那一刻，这个地址是什么状态。但地址不会静止不动。一月份还干干净净的钱包，三月可能收到勒索软件赃款，六月可能被归入 OFAC 即将列名的集群。KYT——Know Your Transaction，了解你的交易——正是为此而生：它是把检测从一张静态照片变成一个持续信号的连续监控。本文将说明 KYT 监控究竟做了什么、什么会触发预警、它与 KYC 有何本质差异、哪些地址值得纳入监控，以及如何围绕它建立一套不会把团队淹没在噪音里的实用流程。
为什么一次性检测远远不够
设想你在六个月前检测过一位客户的地址，结果干干净净。没有命中任何制裁名单，没有混币器暴露，与任何已标注实体都没有关联。你记录了结果，然后继续处理别的事——在当时，这完全是正确的做法。
但区块链不会停下来。在随后的六个月里，那个地址从一个后来被证实属于投资骗局的钱包收到了两笔转账，随后又把部分余额发往了一个混币器。这些在你的报告里一个字都没有，因为你的报告描述的是一月，而现在已经是七月。
这不是理论问题。在真实调查中，上一次检测与问题浮出水面之间的那段空白，恰恰是损失累积的地方。更糟糕的是，你通常是从第三方那里得知的：一家代理行、一个监管机构，或者一名记者。持续监控把这个顺序颠倒了过来。
KYT 监控究竟做了什么
当你把一个地址纳入 KYT 监控，它就进入了一个重新分析的排期。不再是一次检测，而是周期性地重新评估——最高可达每两小时一次——依据的仍是那套100 多个制裁与风险来源和700 万个已标注实体的数据库。
每个周期里，引擎都会把当前画面与上一次的画面做比对，寻找两样东西：改变了风险画像的新交易，以及数据本身的变化。第二种情况比人们通常认为的更重要：一个地址可能完全没有发生任何交易，却依然变成高风险，因为它一年前交互过的某个钱包刚刚被卷入一宗刑事调查。
当变化超过你设定的阈值时，你会收到预警。这就是本质区别：检测回答的是你主动提出的问题；而 KYT 是在答案发生变化时，不等你问就主动告诉你。
KYT 与 KYC：两个截然不同的问题
这两者经常被混为一谈，但它们回答的问题完全不同。KYC 问的是：这个人是谁？它通过证件、生物特征核验和监控名单比对来确认身份。通常在注册时做一次，最多每隔几年重做一遍。
KYT 问的是：这笔钱在做什么？它并不关心钱包属于谁，只关心资金从哪里来、到哪里去，以及模式是否发生了变化。它天然就是持续性的。
实际差别在于：一份完美的 KYC 无法阻止一位真实客户在日后收到被盗资金；而一份干净的 KYT 也无法告诉你钱包背后的人是否真的是他自称的那个人。一套严肃的合规体系两者都需要，而且理由完全不同。
什么会触发预警
预警不是随机产生的。主要触发条件有四类。
- 新增直接暴露：该地址从受制裁地址收到资金或向其发送资金，或与被标注为混币器、暗网市场、已知骗局的实体发生了交互。这是最高优先级。
- 间接暴露恶化：地址本身没有变化，但可追溯至风险来源的资金比例超过了你的阈值。
- 数据重新分类：该地址此前交互过的某个实体刚刚被标记为高风险。没有新交易——变化的是认知。
- 模式异常：出现了对该地址而言在金额或频率上都不寻常的突发活动。
阈值按你的风险偏好设定。一家零售平台可能在间接暴露达到 5% 时预警；而一个服务机构客户的 OTC 柜台可能会把它设在 1%。
团队真正处理得过来的预警量
KYT 最常见的错误就是把阈值设得过于敏感。一个每天收到四十条预警的团队，两周之内就会停止阅读它们；到那个时候，你花钱买到的是安全感，而不是安全本身。
实用准则：把阈值调到让进入人工复核的数量，正好等于一个人在一个工作日内真正能调查完的量。如果你只有一位兼职分析师，那么每天五条被认真调查的预警，比五十条被自动关闭的预警更有价值。
从保守开始——高阈值、少预警、优先处理直接暴露——等你摸清究竟多大比例的预警值得上报后，再逐步收紧。反过来做，也就是一上来就高度敏感然后再放松，会在你有机会校准之前就先摧毁团队的信任。
记录每一条预警及其关闭决定，哪怕决定是「无需处理」。一份显示你复核了四十条预警、并以书面理由关闭其中三十八条的记录，远比完全没有记录要有力得多。
每晚的报告与审计链条
除了即时预警，监控还会生成一份每晚的 PDF 报告，汇总所有受监控地址的风险状况。它并不是预警的副本，而是服务于另一个目的。
预警用来处理事件。每晚的报告则是你拿给审计师、代理行和董事会看的东西。它证明你确实在监控、以什么频率监控、以及发现了什么。当合作银行询问你的风控措施时，一整年按日期排列的报告序列，其说服力远不是口头描述政策所能比拟的。
把这些报告归档保存。审计师很少质疑一个有理有据的决定；他们质疑的永远是缺乏证据。
哪些地址值得纳入监控
监控一切既昂贵又没有必要。要分清优先级。
必须长期监控：业务合作方的结算地址——做市商、流动性提供方、支付处理商、OTC 柜台。这些是高交易量的持续性关系，其风险画像的变化会直接影响到你。
阶段性监控：首次检测得分为中等、你有所保留地接受了的客户地址。把它们纳入九十天监控；如果什么都没出现，就撤下来。
有选择地监控：你自己的资金库钱包。不是因为你信不过自己，而是因为流入的资金可能污染它们，而你希望比你的银行更早知道这件事。
无需监控：一次性且已结束的交易地址。交易当时的检测已经足够。
成本：为什么监控比检测更便宜
这一点常让人意外：每一个监控周期的花费都明显低于一次全新的完整检测。原因是结构性的——重新分析复用了已经建好的基础设施和已存储的结果，不需要从零开始重建图谱。
实际意义在于：把一个地址持续监控整整一个月，可能比在同一时期做几次零散的手动检测还要便宜——而且覆盖度好得多，因为它不留任何时间空档。
Arya Crypto 的计费基于代币：每个监控周期都从你用于检测、KYC 和 KYB 的同一个余额中扣除。没有单独的订阅，也没有按用户计费的月租，而且你可以随时把某个地址移出监控。
通过 API 部署 KYT
通过控制台登记适用于几十个地址。规模再大就该用 API：一个 POST 请求把地址纳入监控，另一个把它移出，再用 Webhook 在预警产生的瞬间接收它。
常见做法是把登记动作绑定到业务关系的生命周期上：接入新合作方时自动登记其结算地址，关系终止时自动撤销。这样监控名单无需人工维护就能与实际情况保持一致。
把 Webhook 预警接入你的工单系统，而不是一个共享邮箱。落进公共收件箱的预警会消失；而指派给具体某个人的工单会被关闭。
不做过度工程地起步
不要一上来就建系统。先从十个你真正在意的地址开始——多半是你的结算合作方——用控制台把它们纳入监控。观察一个月，看看会收到什么。
你会学到两件事：你的真实业务量会产生多少预警，以及哪类预警值得占用团队的时间。自动化应该建立在这些认知之上，而不是建立在事先的猜测之上。
第一个月结束后再逐步扩大范围，用 API 把登记流程自动化，并写一份简短的书面政策，明确谁负责复核预警、在多长时间内复核、以及上报的判断标准。一页纸就够了，但把它写下来，正是把一个工具变成真正风控措施的关键一步。
实例复盘：那条真正起了作用的预警
某 OTC 柜台监控着十二家合作方的结算地址。在一个再普通不过的日子里，一条预警到达：其中一家合作方的地址，在两跳距离之外收到了来自某个集群的资金，而那个集群三天前刚在一起交易所盗窃案调查中被标注。占比不大——约为近期流入的 4%——但时间非常新。
合作方对此毫不知情；这笔资金来自他自己的一位客户。但由于预警是在几小时内而不是几个月后到达的，柜台得以暂停结算、要求合作方说明资金来源，并在更多批次累积之前把一切都记录在案。
结局并不戏剧化：那位客户是受害者而非作案者，一周后业务关系恢复了。但档案里如今留下了一份完整记录，证明柜台是自己发现问题并立即采取了行动。这正是一家管理良好的机构，与一家坐等银行来通知的机构之间的差别。
KYT 解决不了的问题
监控告诉你链上发生了什么，但不会告诉你为什么。一条关于新增混币器暴露的预警，可能意味着洗钱，也可能意味着一位注重隐私的用户，还可能意味着一家在汇总客户资金流的交易所。解读信号始终是人的工作——正因如此，分析师的专业水平比参数调得多细更重要。
监控也覆盖不了完全发生在链下的事情。同一家交易所内部账簿上的划转不会体现在区块链上，因此 KYT 看不见。这是结构性的边界，而不是产品缺陷：链上分析看到的恰恰是链上写下的内容，一个字节都不会多。
最后，KYT 无法弥补制度的缺失。一个生成预警却无人阅读、也不按书面规则上报的工具，是一笔开支，而不是一项风控措施。价值来自两者的结合：信号，以及依据信号采取行动的流程。
监控频率：多久一次才算够
并非所有地址都需要相同的频率，把这一点调好能在不牺牲覆盖度的前提下省下真金白银。
活跃合作方的高交易量结算地址，值得使用可用的最高频率——最快每两小时一次——因为在那种交易量下，未被发现的问题会迅速滚大。两小时内发现与一天后发现之间的差距，可能就是几十笔额外交易。
对于中等评分后出于审慎而纳入观察的客户地址，每日一次的频率完全足够。这类地址通常活动稀少，观察它们的目的是捕捉趋势，而不是捕捉某个瞬间。
你自己的资金库钱包处于中间位置：平时每日监控，在月度结算或并购之后等高强度活动期提高频率。
总的原则是：让频率匹配损害累积的速度，而不是匹配你焦虑的程度。这个分配每季度复核一次——几个月前看似边缘的合作方可能变得举足轻重，反过来也完全一样。
本周就能开始的简短清单
如果你想把这篇文章变成行动，以下这些事情在一周内完全可以做完，而且不需要任何工程投入。
- 第一天：列出所有你会定期向其转账或从其收款的业务合作方。这份名单通常比你以为的要短。
- 第二天：收集他们的结算地址，对每一个执行一次检测，建立一条有记录的基准线。
- 第三天：通过控制台把每一个纳入 KYT 监控，阈值刻意设得保守一些。
- 第四天：指定一位负责阅读预警的人，并用一页纸写清楚预警在什么情况下、向谁上报。
- 第五天：建立一个共享文件夹用于归档每晚的报告，并确认它们确实送达了。
一个月之后，你就掌握了关于自身预警量的真实数据——这才是后续任何自动化的正确基础。
把第一个地址纳入 KYT 监控 — 定价 · 服务 · KYT · KYC · KYB · Exchange · Prop