Риск-метка blockchain-аналитики

01 Blockchain-факт и Risk Score

В blockchain можно независимо проверить:

• 01 TXID;
• 02 блок;
• 03 адрес отправления;
• 04 адрес назначения;
• 05 значение операции;
• 06 timestamp / порядок включения;
• 07 calldata;
• 08 события smart contract;
• 09 комиссию;
• 10 последовательность переходов состояния.

Это первичный технический слой.

Но blockchain сам по себе не говорит:

• 01 «это биржа»;
• 02 «это mixer»;
• 03 «это darknet»;
• 04 «эти 400 адресов принадлежат одному лицу»;
• 05 «актив на 38% связан с санкционным источником».

Такие выводы появляются на аналитическом уровне.

Система использует:

Первичные данные + Attribution + Clustering + External intelligence + метод распространения риска.

Поэтому принципиальное разграничение:

TXID — факт.

Entity — атрибуция.

Risk Score — результат модели.

Смешивать эти уровни нельзя.

03 Direct / Indirect Exposure и Hops

Первый вопрос:

Клиент взаимодействовал с риск-источником напрямую?

Direct Exposure

Риск-источник → клиент

Это сильная техническая связь.

Но даже она не доказывает автоматически:

• 01 умысел;
• 02 знание;
• 03 согласованность;
• 04 экономическую цель;
• 05 личность оператора исходного адреса.

Например, публичный адрес способен получить unsolicited transfer без согласия владельца.

Indirect Exposure

Риск-источник → A → CEX / AMM / bridge → B → клиент

Здесь критично уже не только число шагов.

Критично:

Что представлял каждый узел.

Один промежуточный адрес, контролируемый тем же субъектом, практически ничего не меняет.

Но:

• 01 крупный CEX;
• 02 AMM;
• 03 агрегатор;
• 04 независимый контрагент;
• 05 общий кастодиальный пул

могут существенно менять характер причинной связи.

Поэтому:

7 Hops ≠ автоматическая «чистота»

и:

1 Hop ≠ автоматическая вина.

Универсального правового порога Hops не существует.

04 Ошибки Attribution и Cluster

Самый дорогой вопрос риск-скоринга часто находится не в математике процентов, а раньше:

Правильно ли вообще определен исходный субъект?

Платформа может объединять адреса в Entity / Cluster на основе:

• 01 транзакционных паттернов;
• 02 common-input;
• 03 внешних источников;
• 04 сервисной инфраструктуры;
• 05 собственного intelligence;
• 06 закрытых эвристик.

Common-input

В UTXO-сетях совместное расходование нескольких входов может быть признаком общего контроля.

Но такая гипотеза требует дополнительной проверки при:

• 01 CoinJoin;
• 02 collaborative transactions;
• 03 кастодиальных выплатах;
• 04 сервисной агрегации.

Поэтому:

Common Input ≠ доказанно один владелец.

Hot Wallet / Omnibus

Общий адрес CEX способен обслуживать множество клиентов.

Следовательно:

Одна infrastructure ≠ один бенефициар.

Критический дефект возникает, когда:

Предположение о Cluster

становится:

Основанием для нового категорического Risk Score.

05 Temporal Conflict и конфликт вендоров

Два дефекта логично рассматривать вместе: кто присвоил статус и когда.

Cross-Vendor Conflict

У разных систем могут различаться:

• 01 категории;
• 02 границы Entity;
• 03 первоисточники attribution;
• 04 даты обновления;
• 05 глубина трейсинга;
• 06 правила наследования риска.

Один адрес может быть:

Exchange

в одной базе,

High-Risk Exchange

в другой,

и не иметь подтвержденной Entity в третьей.

Но:

Разные результаты ≠ автоматически ошибка конкретного поставщика.

Расхождение доказывает другое:

Классификация требует проверки исходного основания.

Temporal Conflict

Нужно различать:

T₁ — дата операции

и:

T₂ — дата Attribution / Sanctions / Risk label.

Адрес может быть идентифицирован значительно позже исторической транзакции.

Следовательно:

Метка на T₂ ≠ доказанная осведомленность на T₁.

Но и обратная формула:

«метки тогда не было — значит адрес был объективно безопасным»

неверна.

Проверяется:

• 01 фактический статус;
• 02 дата возникновения risk-event;
• 03 информация, доступная в соответствующий момент;
• 04 поведение конкретного участника.

06 Инфраструктурные и сервисные искажения графа

Этот блок объединяет четыре ситуации, которые нет смысла растягивать на самостоятельные главы.

AMM / Liquidity pool

Пользователь взаимодействует со smart contract пула, в котором сосуществуют активы множества участников.

Поэтому:

Общий AMM ≠ прямое экономическое взаимодействие со всеми предыдущими поставщиками ликвидности.

Но присутствие риск-актива в пуле может быть релевантно для AML-модели.

Проверяются:

• 01 тип пула;
• 02 конкретный вход;
• 03 конкретный выход;
• 04 время;
• 05 объем;
• 06 экономическая функция контракта.

CEX pooling

На централизованных платформах могут использоваться:

• 01 hot wallets;
• 02 omnibus wallets;
• 03 sweeps;
• 04 batch withdrawals;
• 05 internal netting.

Поэтому:

История CEX-адреса ≠ история одного клиента.

Если требуется точная атрибуция, нужны:

• 01 UID;
• 02 Deposit Record;
• 03 Withdrawal Record;
• 04 Internal Ledger;
• 05 timestamps;
• 06 mapping внутреннего события на blockchain.

Gas / fee layer

Современная операция может включать:

• 01 relayer;
• 02 paymaster;
• 03 bundler;
• 04 sequencer;
• 05 fee payer.

Следовательно:

Gas payer ≠ автоматически экономический контрагент.

Нужно отделять:

Value transfer

от:

Infrastructure execution.

Dust / Spam / address Poisoning

На публичный адрес можно отправить актив без предварительного согласия владельца.

Поэтому:

Inbound transfer ≠ волеизъявление получателя.

Проверяются:

• 01 инициатор;
• 02 объем;
• 03 тип токена;
• 04 subsequent interaction;
• 05 claim;
• 06 использование полученного актива.

Escrow / vesting / timelock

Smart contract может разделять:

возникновение сделки

↓ lock

↓ ожидание

↓ release / claim

За это время risk-статус контрагента может измениться.

Поэтому анализ должен учитывать всю хронологию, а не только финальный transfer.

При этом:

Дата lock ≠ автоматически дата перехода права.

07 Математика Taint / Proportional / FIFO

Здесь нас интересует один вопрос:

Как именно выбранная модель меняет количественный вывод?

Предположим:

99 единиц без установленной risk-связи

+ 1 единица с подтвержденной exposure

= 100 единиц смешанного баланса.

Taint / Poison-подобный подход

В предельно консервативной модели наличие связанного входа способно распространить risk-category на значительно больший последующий объем.

Это не означает, что физически стало больше исходного риск-актива.

Это означает:

Модель расширила область аналитической атрибуции.

Proportional / Haircut

Экспозиция распределяется пропорционально смешанному объему.

В условном примере:

1 / 100 = 1% exposure.

Такой подход не «очищает» средства.

Он ограничивает количественную долю аналитической связи.

FIFO-подобная модель

Атрибуция распределяется по последовательности поступления и выбытия.

Следовательно, одинаковые исходные транзакции при разных моделях способны дать разные значения exposure для последующих выходов.

Форензик-вопрос

Не:

«Какая модель лучше?»

А:

Почему к конкретному графу применен именно такой способ распределения?

Проверяются:

• 01 архитектура сети;
• 02 смешение;
• 03 функция промежуточного узла;
• 04 входные объемы;
• 05 выходные объемы;
• 06 последовательность событий;
• 07 доступная методология платформы.

Главная аксиома:

Метод распространения Exposure ≠ фактическое увеличение объема исходного risk-asset.

Мы не утверждаем без источника, какую именно модель использует конкретный коммерческий поставщик.

08 Sanctions Exposure и официальный санкционный статус

Здесь особенно важно не смешивать аналитику и право.

Минимум три разных уровня.

1. Прямой санкционный статус

Лицо или имущество подпадает под конкретный санкционный режим.

Цифровой адрес может быть прямо указан компетентным органом как идентификатор связанной инфраструктуры.

2. Blocked Status без отдельной строки в SDN

Отсутствие названия организации в SDN List не означает автоматически отсутствие blocked status.

Для OFAC действует 50 Percent Rule: имущество и интересы в имуществе организации, которой одно или несколько blocked persons прямо или косвенно владеют в совокупности на 50% и более, считаются blocked. При этом сама 50 Percent Rule относится именно к ownership, а не просто к control.

Поэтому:

Не указан в SDN ≠ гарантированно не blocked.

3. Analytics Exposure

Коммерческий сервис показывает графовую связь с санкционным источником.

Это может называться:

• 01 Sanctions Exposure;
• 02 Indirect Exposure;
• 03 Secondary Exposure;
• 04 иным термином конкретного поставщика.

Такая характеристика:

Не равна сама по себе юридическому статусу клиента.

Но и отсутствие direct listing не означает автоматически отсутствия санкционной проблемы: отдельные санкционные программы могут запрещать прямые или косвенные операции с blocked persons, а юридическая квалификация зависит от применимого режима.

Поэтому blockchain-форензик должен установить:

• 01 исходный санкционный объект;
• 02 Direct / Indirect;
• 03 Hops;
• 04 ownership / control context, если релевантно;
• 05 дату;
• 06 характер операции;
• 07 фактическую blockchain-связь.

А санкционно-правовая квалификация проводится отдельно.

но:

Нет прямого listing ≠ автоматически нет санкционного режима.

09 Проверяемость black-box моделей

Закрытая коммерческая методология:

Не делает отчет автоматически недопустимым.

По ст. 67 ГПК РФ суд самостоятельно оценивает доказательства, а никакое доказательство не имеет заранее установленной силы. Оцениваются относимость, допустимость, достоверность, достаточность и взаимная связь.

Поэтому сильная процессуальная позиция строится не на формуле:

«Алгоритм закрыт — отчет не существует».

Правильный вопрос:

Как проверить критические предпосылки вывода?

Например:

• 01 какой исходный адрес;
• 02 почему он классифицирован именно так;
• 03 какая Entity;
• 04 какой путь;
• 05 сколько Hops;
• 06 какую функцию выполняют узлы;
• 07 когда появилась метка;
• 08 как получен Exposure %;
• 09 существуют ли альтернативные объяснения.

Если эти ключевые элементы не раскрываются или не могут быть независимо сопоставлены с первичными данными, доказательственный вес категорического вывода требует отдельной оценки.

Black box ≠ автоматически недопустим

но:

Непроверяемый категорический вывод ≠ самодостаточное доказательство.

10 Анатомия ситуации

11 Проверьте свой сценарий

Это не автоматическая оценка законности актива. Значение имеет совокупность первичных blockchain-данных, методологии, хронологии и экономического контекста.

13 Что нельзя считать доказанным автоматически

• High Risk ≠ доказанная вина
• Analytics Report ≠ судебная экспертиза
• Sanctions Exposure ≠ автоматически SDN Status
• Нет SDN-listing ≠ автоматически нет blocked Status
• Direct transfer ≠ доказанный умысел
• Indirect Exposure ≠ соучастие
• N Hops ≠ автоматическое обнуление риска
• AMM ≠ прямая сделка со всеми участниками пула
• Dust ≠ согласие получателя
• Gas payer ≠ экономический контрагент
• CEX Hot wallet ≠ один пользователь
• Поздняя метка ≠ ранняя осведомленность
• Cross-Vendor Conflict ≠ автоматическая ошибка вендора
• Taint / Proportional / FIFO ≠ юридическая квалификация
• Black box ≠ автоматически недопустимо
• Красный индикатор ≠ завершенная причинно-следственная цепь

14 Форензик-контур Бюро

Бюро не начинает с вывода:

«Скоринг ошибочен».

Сначала раскладывается сама конструкция.

Уровень 1. Первоисточник

Какой address / Entity является исходным risk object.

Уровень 2. Attribution

Почему этому объекту присвоена соответствующая категория.

Уровень 3. Граф

Как построена связь с клиентом:

• 01 Direct;
• 02 Indirect;
• 03 CEX;
• 04 AMM;
• 05 bridge;
• 06 fee layer;
• 07 unsolicited event.

Уровень 4. Хронология

Сопоставляются:

• 01 T₁ операции;
• 02 T₂ attribution;
• 03 дата санкционного / criminal / security event.

Уровень 5. Quantitative model

Как распределена exposure внутри смешанного потока.

Уровень 6. Экономическая реальность

• 01 Source of Funds;
• 02 Source of Wealth;
• 03 договор;
• 04 CEX/P2P;
• 05 хозяйственная цель.

Уровень 7. Доказательственный статус

Разделяется:

Факт

Вероятностный вывод

Непроверяемая предпосылка

Опровергнутая связь.

Финальная архитектура:

Risk Mark → Source → Attribution → Graph → Time → model → Economic context → Evidentiary Status.

15 Что остается закрытым

На публичной странице не раскрываются:

• 01 алгоритмы обратной декомпозиции графов Контура М4;
• 02 внутренние правила проверки Entity / Cluster boundaries;
• 03 модели межвендорского сопоставления attribution;
• 04 формулы распределения mixed / commingled exposure;
• 05 количественные модели сравнения Taint / Proportional / FIFO;
• 06 внутренние фильтры AMM / bridge / fee / service layer;
• 07 алгоритмы temporal reconstruction;
• 08 процедуры отделения unsolicited / poisoning noise;
• 09 правила CEX off-chain / on-chain reconciliation;
• 10 шкалы значимости Direct / Indirect Exposure;
• 11 алгоритмы ранжирования альтернативных гипотез;
• 12 протоколы Institutional Compliance;
• 13 веса;
• 14 матрицы;
• 15 пороги;
• 16 критерии достаточности доказательственного файла.

Публичный слой отвечает:

Что подлежит проверке.

Закрытый слой:

Как именно Бюро проводит проверку и ранжирует результат.

16 Чего нельзя делать

Не перемещать актив только ради изменения Risk Score

Не создавать искусственные Hops

Не использовать mixer для сокрытия происхождения

Не подделывать CEX / P2P / blockchain-материалы

Не считать любой High Risk доказательством преступления

Не считать любой коммерческий отчет незаконным

Не приписывать конкретному вендору Poison / FIFO / Haircut без подтверждения

Не смешивать Sanctions Exposure и официальный blocked status

Не считать отсутствие SDN-listing универсальным освобождением от санкционного режима

Не считать CEX hot wallet личным адресом клиента

Не превращать Cross-Vendor Conflict в единственное доказательство ошибки

Не обещать удалить blockchain-историю или гарантированно снять ограничения

17 Пять этапов деконструкции

Этап 1. Фиксация

Сохраняются:

• 01 отчет;
• 02 дата;
• 03 TXID;
• 04 адрес;
• 05 category;
• 06 exposure;
• 07 Hops;
• 08 уведомление платформы.

Этап 2. Source + Attribution

Устанавливаются:

Исходный риск-объект

и:

Основание его классификации.

Этап 3. Graph + Time + model

Проверяются:

• 01 Direct / Indirect;
• 02 функции узлов;
• 03 CEX / AMM / bridge;
• 04 fee layer;
• 05 dust;
• 06 T₁ / T₂;
• 07 количественная модель exposure.

Этап 4. Economic context

Добавляются:

• 01 Source of Funds;
• 02 Source of Wealth;
• 03 договор;
• 04 CEX/P2P;
• 05 банковские документы;
• 06 хозяйственная хронология.

Этап 5. Доказательственный файл

Формируются четыре отдельные категории:

Установлено

Вероятно

Не проверяется по представленным данным

Опровергнуто.

После этого готовится адресный файл для:

• 01 CEX;
• 02 банка;
• 03 суда;
• 04 иной применимой процедуры.

18 Что получает клиент

Для первого анализа достаточно целевого набора:

• 01 спорного TXID;
• 02 публичных адресов;
• 03 Risk Report;
• 04 уведомления банка / CEX;
• 05 Source of Funds;
• 06 документа по исходной сделке.

Результат:

Source Risk Map → Attribution Map → True path Map → Direct / Indirect analysis → Node Function analysis → Temporal Map → AMM / CEX / bridge / fee-layer квалификация → Cluster Audit → Cross-Vendor Review, если доступен → Quantitative Exposure Review → Source of Funds Reconciliation → Evidence Matrix → Forensic Evidence File.

Принципиальная позиция Бюро

Бюро не занимается:

• 01 «очисткой» blockchain-истории;
• 02 техническим стиранием Risk Score;
• 03 сокрытием преступного происхождения;
• 04 обходом AML/KYC;
• 05 обходом санкционных ограничений;
• 06 созданием искусственной «чистой» истории.

Но Бюро также не принимает презумпцию:

«Если программа показала красный цвет — факт уже доказан».

Мы отделяем:

Blockchain

от:

Attribution

от:

Clustering

от:

Exposure model

от:

Risk Score

от:

Compliance Decision

от:

Юридического доказывания.

И проверяем каждое соединение между этими уровнями.

Официальные и методологические источники

FATF — Risk-Based Approach to Virtual Assets and VASPs

Risk-based approach предполагает оценку конкретного риска и применение соразмерных мер, а не механическое превращение одного аналитического сигнала в окончательный юридический вывод.

OFAC — Virtual Currency / 50 Percent Rule

Для санкционного анализа необходимо разграничивать:

• 01 прямой санкционный статус;
• 02 blocked status, возникающий в силу применимых правил;
• 03 коммерческую Sanctions Exposure.

OFAC прямо указывает, что 50 Percent Rule применяется к сущностям, которыми blocked persons владеют прямо или косвенно на 50% и более в совокупности. Само наличие control без соответствующего ownership не создает автоматический blocked status именно по 50 Percent Rule.

Федеральный закон № 115-ФЗ

Определяет российский AML/CFT-контур и систему внутреннего контроля.

Аналитическая blockchain-метка может использоваться как один из факторов оценки, но не заменяет установление фактических обстоятельств конкретной операции.

Федеральный закон от 04.08.2026 № 282-ФЗ

С 1 сентября 2026 года формирует специальный российский контур регулирования цифровых валют и инфраструктуры их обращения.

Федеральный закон № 73-ФЗ

Требования судебно-экспертной деятельности ориентированы на объективность исследования, научную и практическую основу и проверяемость обоснованности выводов.

ГПК РФ — статья 67

Никакое доказательство не имеет для суда заранее установленной силы; доказательства оцениваются по относимости, допустимости, достоверности, достаточности и взаимной связи.

АПК РФ — статья 71

Аналогичный принцип самостоятельной оценки доказательств действует в арбитражном процессе.

Поэтому коммерческий blockchain-report:

Не является автоматически истиной

и:

Не является автоматически недопустимым.