AML 结果中的制裁信息
筛查结果解答了两个不同的问题，而且这两者很容易被混淆：该地址是否在制裁名单上，以及该地址是否曾收到过流经制裁对象的资金。本页解释了哪个字段解答了哪个问题，以及为什么两者并不总是保持一致。
同样适用于 POST /apiv2/screening 和 POST /apiv2/aml。
两个来源，刻意区分
| 位置 | 具体含义 |
|---|---|
sanctions.* | 我们对服务商结果的自主细分：地址本身是否被列入名单、关联有多紧密、涉及资金比例有多大 |
provider_data | 服务商自身的检测结果，采用服务商自身的表述 |
is_sanctioned（仅限第 1 版） | 服务商提供的单个布尔值 |
服务商的标志位保持完全原样。现有集成是基于它构建的，更改其含义会导致这些集成发生无感知中断。细分数据则在旁边一并发布。
为什么标志位与细分数据不一致
该标志位是一个汇总指标，而两家服务商的汇总方式各不相同。
BitOK 对低于百分之一的风险敞口不会触发其标志位。我们的细分数据则不采用该阈值：任何关联都会被报告，并在旁边标出其所占比例。在整个历史检查记录中，有 331 个结果中细分数据发现了制裁关联，而服务商的标志位并未置位。 这两方面都没有错误——它们针对的是两个不同的问题。
Elliptic 有一条名为 Sanctioned, TF & CSAM 的规则，该规则也会针对国家和实体类别触发。仅仅因为结果中出现了该规则，并不能将其定性为命中制裁。我们的细分数据是根据服务商附加到每笔贡献上的触发原因进行筛选，而不是根据规则名称。
细分数据说明了什么
| 字段 | 含义 |
|---|---|
sanctions.self | 被筛查的地址本身就是被制裁实体 |
sanctions.self_entities | 其自身所属被制裁实体的名称 |
sanctions.exposure | 单个最大关联——可用于摘要展示行 |
sanctions.items | 所有制裁关联，按占比从大到小排序 |
sanctions.related | 仅限 BitOK：受到欧盟或英国制裁的交易所，与制裁名单本身区分开来 |
当尚无结果可供分析时，sanctions 为 null。带有 self: false 的空 items 列表意味着分析已执行且未发现任何关联。
关联亲疏度 (Proximity)
proximity 对应 Elliptic 报告中的 Closest Proximity 列：
| 值 | 含义 |
|---|---|
screened_address | 地址本身即为触发源 |
counterparty | 被筛查地址的直接交易对手方 |
indirect | 通过中间节点触达——参见 hops |
mixed | 与同一实体同时存在直接和间接资金往来 |
这种区分比所占份额更重要。一个本身被列入名单的地址，与一个通过两个中间节点接收了 0.03 % 资金的地址，并不是同一种检测结论，而 is_sanctioned 对两者都会返回 true。
截至目前所有筛查结果的分布情况：地址本身被列入名单——18；直接交易对手方——141；混合——605；间接——5 929。
份额占比
在第 2 版中，每个份额占比均为 share_fraction，是一个介于 "0" 到 "1" 之间的小数字符串。在第 1 版中，相同的值以百分比形式表示为 share。底层数值是完全相同的；仅表示法有所不同。
解读结果
仅依据 is_sanctioned 作出的判定，会将曾经从受制裁交易所收到极微小舍入误差金额的地址，与名单上的地址完全等同对待。更有效的解读方式是：
sanctions.self——地址已被列入名单。属于严重情况；sanctions.exposure.proximity=counterparty——曾与被制裁实体直接进行交易；indirect伴随极小的share_fraction——通过中间节点产生的关联。请明确为此类情况设定您自己的阈值并做好记录。
risk.level 中的风险等级不能替代该分析。它是服务商对地址整体的评估，微小的制裁风险敞口完全可能出现在 low 评级的结果中。