Проектирование контрольной точки допуска операций по KYB/KYC и санкционным требованиям

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

Для маршрута $A\to S\to R$ недостаточно установить, что EUR поступили на счёт $S$. До разрешения на выпуск или доставку цифрового актива нужно ответить на другой набор вопросов: кто именно участвует в операции, кто контролирует компании, кто вправе давать распоряжения, откуда поступили средства, зачем они переводятся в цифровой актив, какие страны и санкционные режимы затронуты.

Итог урока — проект контрольной точки, которая выдаёт не токен, а проверяемое решение: разрешить, направить на усиленную проверку, удержать или отклонить операцию.

---

Контрольная точка — не один «KYC-чек»

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

Её следует расположить между заявкой на операцию и любым необратимым действием:

Заявка на финансирование / выпуск
        ↓
Сбор и проверка данных о сторонах
        ↓
Санкционный и юрисдикционный анализ
        ↓
Оценка происхождения и назначения средств
        ↓
Решение по риску и документирование
        ↓
Разрешение на выпуск
        ↓
Только затем: выпуск или доставка при подтверждённом банковском обеспечении

Здесь важно сохранить границу, установленную в прошлом уроке:

• комплаенс-допуск отвечает: «можем ли мы принять эту операцию в рамках нашей политики и применимого права?»;
• банковское доказательство отвечает: «были ли средства действительно зачислены и доступны в согласованной модели?»;
• разрешение на выпуск отвечает: «выполнены ли оба набора условий для конкретного количества токенов?».

Ни KYC, ни подтверждение SWIFT, ни положительный ответ санкционного скрининга по отдельности не должны запускать mint.

---

Риск-ориентированная модель вместо формального набора документов

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

Для вашей архитектуры лучше не сводить риск к одному числу, например risk_score = 73. Число может быть удобным для маршрутизации кейсов, но не должно скрывать основание решения. Храните профиль факторов риска.

Измерение	Примеры вопросов
Клиент и структура владения	Понятна ли корпоративная структура? Есть ли сложная цепочка владения, номинальные лица, трасты или необъяснимые промежуточные компании?
Продукт	Какой актив выпускается, допускается ли вторичный оборот, возможен ли перевод на внешний кошелёк?
Операция	Соответствуют ли сумма, частота и валюта ожидаемому профилю $A$? Почему фиат почти сразу становится цифровым активом?
География	Где зарегистрированы и действуют стороны, их банки, VASP/кастодианы, конечный получатель и контролирующие лица?
Канал и технология	Как получены документы? Кто контролирует кошелёк $R$? Используется ли регулируемый кастодиан или внешний адрес?
Качество данных	Проверены ли сведения независимыми источниками, не противоречат ли они друг другу, актуальны ли они?

Повышенный риск не равен запрету. Он означает, что стандартной проверки недостаточно: нужны дополнительные документы, независимое подтверждение, более глубокий анализ и, возможно, решение старшего уполномоченного сотрудника. Напротив, реальный санкционный запрет или отсутствие необходимого разрешения — не вопрос «баллов риска», а основание для остановки операции по применимой процедуре.

---

Не путать получателя токена и бенефициарного владельца

В схеме $A\to S\to R$ слово «бенефициар» может создать опасную путаницу. Для контроля нужны как минимум три разных понятия:

Понятие	Вопрос контроля
Конечный получатель цифрового актива $R$	Кому фактически доставляется токен, на какой счёт или кошелёк, в какой роли и в какой юрисдикции?
Бенефициарный владелец компании $UBO$	Какое физическое лицо в конечном счёте владеет или контролирует $A$, $S$, $R$, VASP либо иной юридический субъект?
Бенефициар банковского платежа	Кто является владельцем счёта, кредитуемого в банковском контуре, например $S$?

Эти роли иногда пересекаются, но их нельзя автоматически считать одной и той же личностью. Например, $R$ может быть юридическим лицом, а его UBO — физическим лицом, которое не является получателем токена на своём личном кошельке. Или $A$ может принадлежать одному лицу, но платёж подписан другим уполномоченным директором.

Для компании $A$ контрольная точка должна собрать и связать:

1. юридическое наименование, регистрационный номер, статус и страну инкорпорации;
2. юридический и операционный адреса;
3. директоров, лиц с правом подписи и их полномочия;
4. прямых и конечных владельцев, включая цепочку владения и контролирующих лиц;
5. характер бизнеса и ожидаемый платёжный профиль;
6. банковский счёт-источник и его связь с $A$;
7. договорное и экономическое основание перевода.

---

KYB, KYC и полномочия подписанта: три отдельных проверки

Можно представить, что компания успешно прошла KYB, но конкретный сотрудник не имел права подписывать распоряжение на данную сумму. Или что личность подписанта проверена, но он представляет другую компанию с похожим названием. Поэтому контрольная точка должна разделять три слоя.

1. KYB: существует ли и понятна ли компания?

Для $A$, а при необходимости и для корпоративного $R$, система проверяет:

• существование юридического лица в достоверном реестре;
• актуальный статус: действует ли организация, не находится ли в ликвидации или ином ограниченном статусе;
• юридическое имя и регистрационный номер;
• структуру владения и контроля;
• характер бизнеса и его связь с заявленной операцией;
• соответствие счёта-источника заявленному плательщику.

Если компания $A$ направляет EUR, а получателем токена становится несвязанная третья сторона $R$, это не обязательно недопустимо. Но тогда должно существовать объяснение: договор купли-продажи, агентская модель, инвестиционное соглашение, расчёт за услугу либо иной документированный экономический смысл.

2. KYC: кто именно действует и получает актив?

KYC относится к физическим лицам:

• подписанту $A$;
• UBO и контролирующим лицам, в объёме, требуемом правилами и политикой;
• физическому лицу $R$, если токен получает физическое лицо;
• представителю корпоративного $R$;
• лицам, чьи роли создают контроль над активом или операцией.

Проверка личности — это не только изображение документа. В дистанционной модели важны достоверность источника, целостность документа, сопоставление данных и признаки подмены. Однако даже качественная идентификация не доказывает право действовать за компанию.

3. Проверка полномочий: вправе ли этот человек дать именно это распоряжение?

Контроль полномочий должен отвечать на четыре вопроса:

1. Кто подписывает?
   Личность должна быть установлена и связана с учётной записью, сертификатом или иным способом аутентификации.

2. От чьего имени?
   Подписант должен быть связан с конкретным юридическим лицом $A$, а не только с группой компаний или исторической записью в реестре.

3. На каком основании?
   Нужны применимые документы: уставная роль, доверенность, решение органа управления, список уполномоченных лиц или матрица подписей.

4. На какую операцию и лимит?
   Полномочие может быть ограничено суммой, валютой, периодом действия, типом сделки или требованием двух подписей.

Полезное правило проектирования:

Полномочие подписанта, банковская аутентификация и право использовать поступившие средства — три разных утверждения.

Банк может принять инструкцию, подписанную пользователем корпоративного интернет-банка. Но эмитент токена всё равно должен установить, что операция $A\to S\to R$ соответствует договорной модели и внутренней политике выпуска.

---

Происхождение средств и назначение операции

Здесь также полезно различать два похожих, но разных понятия.

• Источник средств (source of funds) — откуда берутся деньги в этой конкретной операции. Например: выручка по контракту, продажа актива, инвестиционный раунд, дивиденд, погашение займа.
• Источник благосостояния (source of wealth) — каким образом лицо или владелец накопили ресурсы в более широком смысле: предпринимательская деятельность, доля в бизнесе, инвестиции, наследство и т.д.

Для корпоративного плательщика $A$ типовой набор проверки происхождения средств может включать:

• договор, инвойс или иной документ, объясняющий коммерческую цель;
• финансовую отчётность или банковские документы в степени, пропорциональной риску;
• подтверждение происхождения значительной суммы: продажа актива, привлечение капитала, кредитный договор;
• объяснение связи между $A$, $S$ и $R$;
• проверку, что сумма и частота операции соответствуют заявленной деятельности.

Назначение средств направлено вперёд: что будет происходить после получения EUR? В этой архитектуре ответ «мы переводим средства в криптоиндустрию» слишком широк. Контрольной точке нужен более точный ответ:

• какой цифровой актив будет выпущен или передан;
• кто будет его держателем и экономическим выгодоприобретателем;
• возможна ли доставка на внешний кошелёк;
• кто контролирует этот кошелёк;
• используется ли кастодиан или VASP;
• для чего актив приобретается: расчёт, инвестиция, доступ к сервису, токенизация актива, погашение обязательства;
• какие ограничения на перевод и погашение действуют для этого продукта.

Быстрая конвертация «фиат поступил — токен выдан — актив выведен» не является сама по себе доказательством нарушения. Но такая последовательность увеличивает важность объяснения цели, анализа получателя и мониторинга дальнейшего поведения.

---

Санкции и юрисдикции: сначала факт, затем решение

Санкционный скрининг нельзя проектировать как простую функцию:

совпало имя → отказ

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

Практически полезны четыре состояния:

Результат скрининга	Что делает система
Нет совпадений	Продолжает риск-оценку, фиксируя использованные списки и время проверки
Потенциальное совпадение	Ставит операцию на hold и создаёт кейс для разрешения совпадения
Подтверждённое совпадение или применимый запрет	Блокирует дальнейшее действие и запускает процедуру, определённую юристами и комплаенсом
Неполные данные	Не считает проверку завершённой; запрашивает данные или направляет на ручную оценку

Скрининг должен охватывать не только $A$ и $R$, но и применимых:

• UBO и контролирующих лиц;
• подписанта и представителей;
• $S$, если она не является уже полностью проверенной внутренней стороной;
• VASP, кастодиана и других контрагентов;
• адреса кошельков, если политика и используемые инструменты предусматривают такой анализ.

Юрисдикционный анализ также шире страны регистрации. Для каждого участника отделите:

1. юридическую юрисдикцию — где субъект зарегистрирован;
2. операционную юрисдикцию — где он реально ведёт деятельность;
3. юрисдикцию физического лица — гражданство, резидентность, фактическое местонахождение в релевантном объёме;
4. платёжную географию — страны банков, корреспондентская цепочка, валюта и платёжная система;
5. юрисдикцию цифрового контура — где лицензирован VASP или кастодиан, какие рынки обслуживает продукт.

Например, в сценарии «британская компания $A$ переводит EUR европейской организации $S$, а цифровой актив получает $R$, связанный с Боливией» нельзя сделать вывод только из названия стран. Нужно установить факты: где находятся $A$, $S$ и $R$, кто их UBO, какова роль европейского корреспондента, какой VASP или кастодиан участвует, разрешён ли продукт для соответствующего клиента и какие санкционные режимы применимы к участникам и сделке.

Схема полезна как логика процесса, но не как универсальный rulebook: конкретные основания для EDD, SDD, удержания средств и отчётности определяются применимым правом, лицензией, договорной моделью и внутренней политикой.

---

Данные из криптоконтура: сигнал риска, а не автоматический приговор

В цифровой среде у VASP или кастодиана могут появляться дополнительные данные: история операций клиента, профиль кошелька, данные устройства, IP-история, обращения в поддержку, сведения о контрагенте и результаты блокчейн-аналитики. Они могут усилить либо поставить под сомнение объяснение клиента.

Это особенно важно для получателя $R$. Связь внешнего кошелька с рискованным кластером может быть причиной остановить доставку токена и запросить объяснение. Но она не доказывает автоматически, что $R$ владеет всей кластерной инфраструктурой или совершил правонарушение. Архитектура должна сохранять:

• источник сигнала;
• дату и версию аналитического правила;
• уровень уверенности;
• доказательства, которыми разрешён или подтверждён сигнал;
• решение аналитика и его обоснование.

---

Проект решения: автоматизированный маршрут с контролируемым человеком

Удобно разделить систему на три слоя.

Слой 1. Сбор доказательств

Система должна принимать не только сведения, введённые пользователем, но и метаданные:

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

Например, «директор компании подтверждён» — плохая запись. Лучше:

Entity: Company A
Person: Ivan Petrov
Role: authorised signatory
Evidence: corporate registry extract + board resolution
Authority scope: tokenisation funding up to agreed threshold
Verified at: timestamp
Reviewer: compliance officer ID
Expiry / re-check trigger: date or corporate change event

Слой 2. Машинные правила

Автоматизация уместна для повторяемых, объяснимых действий:

• проверить обязательность полей;
• выявить истёкшие документы;
• сопоставить имя компании с реестром;
• проверить наличие UBO-цепочки;
• запустить списки санкций и внутренние блок-листы;
• сравнить заявленную сумму с лимитами;
• обнаружить, что банковский плательщик не совпадает с проверенным $A$;
• направить кейс в EDD при определённой комбинации факторов.

Но система не должна автоматически «объяснять» сложные случаи. Пример: небольшая разница между адресом в реестре и адресом в банковской выписке может быть допустима, а может означать устаревшие документы или подмену. Это не задача простого правила равенства строк.

Слой 3. Решение человека с зафиксированной ответственностью

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

Решение	Значение	Что разрешено системе
Approved	Риск находится в пределах политики; данные достаточны	Продолжить к ожиданию банковского доказательства
Approved with conditions	Допуск есть только при ограничениях	Выпускать не более лимита, только на разрешённый кошелёк или через указанного кастодиана
EDD required	Недостаточно данных для решения	Не выпускать и не доставлять актив
Hold	Есть санкционный, fraud или иной критический сигнал	Заморозить процесс до разрешения кейса
Declined	Сделка вне риск-аппетита либо не соответствует требованиям	Не принимать как основание для выпуска

Для высокорисковых кейсов полезно требовать принцип четырёх глаз: один сотрудник готовит анализ, другой с надлежащими полномочиями утверждает решение. Это особенно важно, если операция создаёт необратимый токен или предполагает перевод на внешний кошелёк.

---

Минимальный объект «admission case»

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

Минимальная структура может выглядеть так:

Блок данных	Что должно быть сохранено
Идентификация кейса	Внутренний case ID, время создания, тип операции, сумма, валюта, продукт
Участники	$A$, $S$, $R$, банки, VASP/кастодиан, представители, UBO и их роли
KYB/KYC	Версии документов, реестровые результаты, данные проверки личности и юридического статуса
Полномочия	Кто действовал от имени компании, основание полномочия, лимиты, срок действия
Экономический смысл	Описание цели, договоры, инвойсы, связь между сторонами
Источник средств	Заявление клиента, подтверждающие документы, связь с ожидаемым профилем
Санкции и география	Списки и версии, дата проверки, кандидаты совпадений, результат разрешения, юрисдикционная карта
Цифровая доставка	Разрешённый получатель, адрес кошелька или кастодиальный счёт, статус проверки адреса
Решение	Риск-факторы, причина решения, условия, лица-утвердители, срок действия
Связь с платежом	funding case ID, UETR и банковские references, когда они станут доступны

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

---

Как контрольная точка применяется к сценарию A → S → R

Представим, что $A$ — компания из Великобритании, $S$ — европейская организация, управляющая обеспечением и выпуском, а $R$ должен получить цифровой актив, связанный с Боливией.

Контрольная точка должна сформировать не общее заключение «клиент проверен», а конкретную цепочку утверждений:

1. Компания $A$ существует и идентифицирована.
   Установлены её регистрационные данные, деятельность, UBO и профиль ожидаемых операций.

2. Подписант $A$ уполномочен.
   Проверены его личность, роль, полномочия и лимит именно для рассматриваемой операции.

3. Средства принадлежат допустимому источнику.
   Плательщик в банковском контуре согласуется с $A$, а происхождение EUR объясняется документами и бизнес-профилем.

4. Цель перевода понятна.
   Система знает, почему $A$ финансирует выпуск, почему получателем актива будет $R$, а также какая договорная связь соединяет стороны.

5. Получатель $R$ и контур доставки допустимы.
   Проверены личность или KYB $R$, применимые UBO, кошелёк либо кастодиан, связанные VASP и ограничения продукта.

6. Санкционные и юрисдикционные проверки завершены.
   Все потенциальные совпадения разрешены, а участие соответствующих стран и лиц соответствует утверждённой правовой позиции и политике.

7. Решение ограничено по времени и условиям.
   Например, разрешение действует до конкретной даты, только для определённой суммы, валюты, получателя и адреса доставки.

После этого дело может получить статус eligible pending funding. Оно ещё не становится разрешением на выпуск. Следующая обязательная проверка — наличие подтверждённого банковского зачисления, сверенного с этим конкретным кейсом.

---

Итоги

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

Ключевые принципы:

• разделяйте KYB компании, KYC физического лица и полномочия подписанта;
• не смешивайте конечного получателя токена, бенефициарного владельца и банковского бенефициара;
• анализируйте источник средств и назначение операции как два самостоятельных вопроса;
• трактуйте санкционный скрининг, юрисдикции и блокчейн-сигналы как процесс принятия обоснованного решения, а не как набор поверхностных совпадений;
• храните версионный admission case с доказательствами, основаниями решения, условиями и сроком действия;
• не позволяйте положительному комплаенс-решению заменить доказательство банковского зачисления, и наоборот.

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