Опыт: Travel Rule для криптокомпаний в Кыргызстане: внедрение

Какая ситуация привела клиента к необходимости внедрения Travel Rule?

Клиент — криптообменник, зарегистрированный как ОсОО в Бишкеке и действующий в статусе резидента ПВТ. На момент обращения компания работала около восьми месяцев по VASP-лицензии Финнадзора, обслуживала клиентов из КР, России и нескольких стран Центральной Азии. Среднесуточный объём трансферов превышал 500 операций, из которых около трети приходилось на переводы между кошельками сторонних платформ.

Плановая проверка AML-комплаенса выявила критический пробел: система компании фиксировала данные отправителя, однако не передавала их контрагентному VASP в момент трансфера. Вместо этого идентификационные сведения хранились локально и предоставлялись Финнадзору только по запросу. Такой подход не соответствует FATF-стандарту, на который ориентируется кыргызское регулирование: данные должны следовать вместе с трансфером, а не храниться отдельно.

Финнадзор направил компании предписание об устранении нарушений в течение 60 дней. Параллельно ГСФР инициировала запрос информации по нескольким подозрительным транзакциям. У клиента фактически не оставалось времени на медленное изучение рынка решений — требовалось чёткое техническое и юридическое задание для разработчика, понятная политика и обученная команда.

ПВТ-резидентство даёт экономию налоговой нагрузки около 80% против общего режима, однако само по себе не снимает регуляторных требований Финнадзора. Налоговые льготы и AML-обязательства существуют параллельно, и нарушение вторых ставит под угрозу в том числе первое: отзыв VASP-лицензии влечёт пересмотр статуса резидента ПВТ.

Что именно требует Travel Rule от VASP по кыргызскому законодательству?

Закон «О виртуальных активах» и сопутствующие нормативные акты Финнадзора устанавливают: при трансфере виртуальных активов VASP-отправитель обязан собрать, верифицировать и передать данные об отправителе VASP-получателю до завершения операции или одновременно с ней. Порог срабатывания — эквивалент $1 000 в единственной транзакции или нескольких связанных операциях.

Минимальный набор данных об отправителе включает: полное имя, идентификационный номер счёта (адрес кошелька), физический или зарегистрированный адрес либо дату рождения и место рождения. Для получателя достаточно имени и адреса кошелька. Если контрагент — неприсоединившаяся к FATF юрисдикция или неунарегулируемая платформа, требования к верификации ужесточаются.

Отдельный блок — операции с унохостед кошельками (self-hosted wallets). Финнадзор ориентируется на подход FATF: при трансфере на унохостед-кошелёк VASP обязан применить усиленную проверку и установить, что получатель — реальный бенефициар. Это требование на практике означает либо дополнительную процедуру верификации, либо отказ от операции при невозможности верификации.

Travel Rule обязателен для всех VASP в Кыргызстане — без него лицензия под угрозой. Платёжная лицензия НБКР и VASP-лицензия Финнадзора — разные документы для разных видов деятельности: лицензия НБКР не освобождает от обязанностей по Travel Rule в части криптоактивов.

Как БЕКЕМ сформулировал задачу для технической реализации?

Первым шагом стал аудит существующей AML-политики клиента. Документ содержал правильные декларации о KYC и мониторинге транзакций, однако не включал ни одного упоминания о Travel Rule как отдельном обязательстве. Раздел о трансферах фактически описывал внутреннюю фиксацию данных — процедуру, которая соответствует требованиям ведения записей, но не заменяет реальную передачу сведений контрагенту.

На основании аудита БЕКЕМ подготовил gap-анализ из пяти блоков: техническая передача данных, верификация контрагентных VASP, работа с унохостед-кошельками, хранение и защита переданных данных, отчётность перед Финнадзором. По каждому блоку был сформулирован конкретный вопрос для разработчика: что именно нужно реализовать, какие данные передавать, в какой момент, в каком формате.

Параллельно был проведён анализ технических протоколов передачи данных. На момент обращения клиента на рынке существовало несколько конкурирующих стандартов: TRISA, TRP, OpenVASP и ряд проприетарных решений. Критерий выбора — не «лучший» протокол в абстракции, а наибольшее число партнёрских VASP клиента, уже использующих данный стандарт. Анализ контрагентской базы показал, что TRISA покрывает около 70% регулярных партнёров компании.

Техническое задание для разработчика было сформировано как юридически ориентированный документ: каждое требование снабжалось ссылкой на конкретное обязательство из законодательства КР или рекомендаций FATF. Это позволило разработчику понять не только «что делать», но и «почему именно так» — что критично при настройке пограничных случаев (трансферы ниже порога, цепочки мультихоп, частичные трансферы).

Каков порядок верификации контрагентного VASP при трансфере?

Travel Rule обязывает не только передавать данные, но и верифицировать, что получатель — действительно лицензированный VASP, а не псевдо-платформа. Без этой проверки передача данных сама по себе не выполняет задачи FATF: риск отмывания через нелицензированные обменники остаётся нераскрытым.

БЕКЕМ разработал для клиента трёхуровневую процедуру проверки контрагента. Первый уровень — реестровая проверка: входит ли контрагентный VASP в реестр лицензиатов соответствующей юрисдикции. Для кыргызских партнёров это реестр Финнадзора; для иностранных — реестры регуляторов их стран. Результаты проверки фиксируются и обновляются не реже одного раза в квартал.

Второй уровень — техническая верификация: подтверждает ли контрагент, что использует совместимый протокол и корректно настроен для приёма Travel Rule данных. На практике это означает тестовый трансфер с минимальной суммой до начала регулярной работы с новым партнёром. Третий уровень — оценка AML-зрелости контрагента: наличие публично доступной AML-политики, данные о регуляторных взысканиях, репутационные факторы.

Для унохостед-кошельков применяется отдельная процедура: клиент обязан подтвердить владение кошельком путём подписи сообщения. Эта процедура добавляет к операции в среднем 2–5 минут, однако позволяет выполнить требование о верификации бенефициара без отказа от операции.

Финнадзор в 2025 году отозвал лицензии у ряда VASP именно из-за дефектов AML-политик — в том числе из-за отсутствия документированной процедуры верификации контрагентов. Наличие описанной процедуры в политике компании стало в практике БЕКЕМ обязательным условием при любом обновлении AML-документации для VASP-клиентов.

Как была обновлена AML-политика и внутренние процедуры клиента?

AML-политика компании была переработана по структуре «матрица рисков + процедуры + контроль». Раздел по Travel Rule занял отдельную главу объёмом около 12 страниц. Документ прошёл согласование с compliance-офицером компании и был утверждён советом директоров — это обязательное условие для предоставления Финнадзору при проверке.

Матрица рисков Travel Rule разбита по четырём осям: тип контрагента (лицензированный VASP / нелицензированная платформа / унохостед-кошелёк / юрисдикция повышенного риска), сумма трансфера (ниже порога / в пороговом диапазоне / выше порога), тип актива (стейблкоин / токен / основные криптовалюты), и история взаимодействия с контрагентом (новый / регулярный / с нарушениями). Каждая комбинация факторов присваивает операции уровень риска и определяет набор обязательных действий.

Процедурная часть описывает пошаговый алгоритм для каждого сценария. Особое внимание уделено пограничным случаям: что делать, если контрагентный VASP не отвечает на запрос Travel Rule данных в течение установленного времени; как действовать при техническом сбое протокола передачи; каков порядок действий при выявлении совпадения в санкционных списках после начала трансфера.

Контрольный блок определяет метрики и периодичность внутреннего аудита Travel Rule: ежемесячная выборочная проверка 5% трансферов, квартальный полный аудит процедур, годовой внешний аудит. По каждой метрике установлен порог — отклонение выше порога автоматически запускает эскалацию к compliance-офицеру.

Какие технические решения были реализованы для передачи данных?

После принятия решения о TRISA как основном протоколе разработчик компании интегрировал TRISA-ноду в существующую инфраструктуру. Нода была развёрнута на серверах, физически расположенных в Кыргызстане — это обязательное требование Закона «О виртуальных активах»: серверная инфраструктура VASP должна находиться на территории КР. Перенос части инфраструктуры за рубеж нарушил бы лицензионные условия.

Параллельно была настроена fallback-процедура для партнёров, не поддерживающих TRISA: для них используется TRP с ручной верификацией данных до проведения транзакции. Около 30% контрагентов клиента на момент внедрения не поддерживали ни один автоматический протокол — для них временно введён режим manual Travel Rule с усиленной проверкой и более длительным сроком обработки.

Критическим техническим моментом стала интеграция с AML/KYT-провайдером. Финнадзор требует наличия обязательного поставщика AML/KYT-услуг — компания уже использовала одного из таких провайдеров, однако его API не был подключён к потоку Travel Rule данных. После интеграции каждый трансфер автоматически получает скоринг от KYT-провайдера ещё до передачи Travel Rule данных контрагенту: трансферы с высоким риском блокируются для ручной проверки.

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

Как прошло взаимодействие с Финнадзором по итогам внедрения?

После завершения внедрения клиент направил в Финнадзор отчёт об исполнении предписания. Документ включал: обновлённую AML-политику с разделом по Travel Rule, технический отчёт о внедрении TRISA-ноды, результаты тестирования системы за три недели, и план регулярного внутреннего аудита. К отчёту прилагались скриншоты успешных тестовых трансферов с партнёрскими VASP как доказательство технической работоспособности системы.

Финнадзор рассмотрел отчёт в течение примерно трёх недель и направил уведомление о снятии предписания. Отдельно регулятор запросил уточнение по процедуре работы с унохостед-кошельками — документацию этой процедуры пришлось дополнить конкретными примерами из тестового периода. После предоставления дополнений вопросы регулятора были закрыты.

Запрос ГСФР по подозрительным транзакциям, инициированный параллельно с предписанием, был закрыт отдельно: компания предоставила полную цепочку KYC-данных и историю коммуникаций по запрошенным транзакциям. Наличие документированных процедур и фиксированных записей значительно ускорило ответ на запрос — по сравнению с аналогичными ситуациями у клиентов без выстроенного комплаенса разница в сроках подготовки ответа составила, как правило, от двух до четырёх раз.

Финнадзор в 2025 году проводил тематические проверки AML/Travel Rule у нескольких десятков VASP. Компании, прошедшие такую проверку без предписаний, как правило, имели три общие черты: документированную процедуру верификации контрагентов, техническую интеграцию с KYT-провайдером, и обученный compliance-персонал. Именно эти три элемента стали основой выстроенной системы клиента.

Каких ошибок удалось избежать благодаря юридическому сопровождению?

Первая типичная ошибка — выбор технического протокола без анализа контрагентской базы. Ряд VASP внедрял OpenVASP или проприетарные решения, не убедившись, что их ключевые партнёры поддерживают тот же стандарт. Результат — технически работающая система, которая не взаимодействует с реальными контрагентами. Анализ базы партнёров до выбора протокола сэкономил клиенту время на переработку интеграции.

Вторая ошибка — трактовка Travel Rule как исключительно технической задачи. Компании, передавшие внедрение только разработчику без участия юриста, получали технически корректную систему передачи данных, но с AML-политикой, не описывающей пограничные случаи. Финнадзор при проверке смотрит в первую очередь на документы, а затем на систему — несоответствие между ними само по себе является нарушением.

Третья ошибка — игнорирование требования о серверной локализации. Несколько VASP разворачивали Travel Rule инфраструктуру на зарубежных облачных платформах, экономя на стоимости хостинга. Закон «О виртуальных активах» явно требует размещения серверов в КР — нарушение этого условия является самостоятельным основанием для предписания, независимо от качества AML-политики.

Четвёртая ошибка — отсутствие процедуры для трансферов ниже порога. Компании нередко считают, что операции до $1 000 не требуют никакого внимания с точки зрения Travel Rule. Однако несколько связанных операций могут образовывать трансфер выше порога (structuring), и именно эта ситуация требует отдельного алгоритма действий — иначе compliance-офицер просто не замечает нарушения.

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

Какой результат получил клиент по итогам работы?

Предписание Финнадзора было снято в течение установленного 60-дневного срока. Система Travel Rule перешла в рабочий режим с охватом около 85% трансферов в автоматическом режиме — остальные 15% обрабатываются по процедуре manual Travel Rule с плановым переводом на автоматику по мере подключения партнёров к TRISA.

Запрос ГСФР по подозрительным транзакциям закрыт без возбуждения производства: предоставленная документация подтвердила соответствие всех запрошенных операций внутренним процедурам и KYC-данным. Наличие полной цепочки записей — ключевое условие для такого исхода.

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

Клиент сохранил VASP-лицензию и статус резидента ПВТ. Налоговый режим ПВТ (0% НП, 0% НДС, 5% подоходный, 1% в Дирекцию) остался нетронутым — что при обороте компании составляет существенную экономию. По состоянию на 10 января 2026 г. система функционирует без регуляторных замечаний.