Санкции в результате AML

Результат проверки отвечает на два разных вопроса, и их легко спутать друг с другом: внесен ли этот адрес в санкционный список и получал ли этот адрес когда-либо средства, прошедшие через фигуранта такого списка. На этой странице объясняется, какое поле отвечает на каждый из них и почему значения не всегда совпадают.

Относится к POST /apiv2/screening.

Два источника, намеренно разделенные

Где	Что это такое
sanctions.*	Наша собственная детализация результата провайдера: внесен ли сам адрес в списки, насколько близка связь, какую долю средств она покрывает
provider_data	Собственные выводы провайдера в его собственных формулировках, включая его единственный флаг санкций

Флаг провайдера оставлен в исходном виде. На нем были построены существующие интеграции, и изменение его смысла привело бы к их незаметным сбоям. Вместо этого параллельно публикуется детализация.

Почему флаг и детализация расходятся

Флаг представляет собой сводный итог, а два используемых провайдера формируют итоги по-разному.

BitOK не поднимает свой флаг при объеме воздействия (exposure) менее одного процента. Наша детализация не применяет этот порог: сообщается о любой связи с указанием ее доли рядом. За всю историю проверок насчитывается 331 результат, где детализация выявляет связь с санкциями, а флаг провайдера не установлен. Ни один из них не является ошибкой с той или иной стороны — это ответы на два разных вопроса.

У Elliptic есть правило под названием Sanctioned, TF & CSAM, которое также срабатывает по признаку страны и категории сущности. Результат нельзя назвать прямым попаданием под санкции только потому, что в нем фигурирует это правило. Наша детализация производит отбор по триггеру, который провайдер прикрепляет к каждому источнику средств, а не по названию правила.

Что сообщает детализация

Поле	Значение
sanctions.self	Проверяемый адрес является подсанкционным субъектом
sanctions.self_entities	Названия его собственных подсанкционных сущностей
sanctions.exposure	Самая крупная единичная связь — то, что следует выносить в строку сводки
sanctions.items	Каждая связь с санкциями, начиная с наибольшей доли
sanctions.related	Только BitOK: биржи под санкциями ЕС или Великобритании, учитываемые отдельно от самого санкционного списка

Поле sanctions имеет значение null, когда результата для анализа еще нет. Пустой список items со значением self: false означает, что анализ был выполнен и ничего не обнаружил.

Близость связи (Proximity)

Поле proximity повторяет столбец Closest Proximity в отчетах Elliptic:

Значение	Значение
screened_address	Сам адрес является триггером
counterparty	Прямой контрагент проверяемого адреса
indirect	Связь через посредников — см. hops
mixed	Как прямые, так и косвенные потоки к одной и той же сущности

Это различие важнее, чем сама доля. Адрес, который сам внесен в списки, и адрес, получивший 0,03 % через двух посредников, представляют собой совершенно разные выводы, однако флаг провайдера вернёт true для обоих.

Распределение по всем проверенным на сегодняшний день результатам: сам адрес в списках — 18; прямой контрагент — 141; смешанная связь — 605; косвенная — 5 929.

Доли

Каждая доля — share_fraction, десятичная строка от "0" до "1".

Интерпретация результата

Вердикт, основанный исключительно на флаге провайдера, присваивает адресу, который однажды получил копеечную погрешность округления с подсанкционной биржи, ту же метку, что и адресу из санкционного списка. Более практичный подход к интерпретации:

1. sanctions.self — адрес находится в списках. Это критический случай;
2. sanctions.exposure.proximity = counterparty — прямое взаимодействие с подсанкционным субъектом;
3. indirect с небольшим значением share_fraction — связь через посредников. Установите собственный осознанный порог для таких случаев и зафиксируйте его в правилах.

Уровень риска в risk.level не может служить заменой этой проверке. Это общая оценка адреса провайдером, и незначительное санкционное воздействие может присутствовать даже внутри результата со значением low.