Интеграция Notabene: Travel Rule compliance для криптобирж

Travel Rule compliance для криптобирж: где рвётся обмен данными

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

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

Цена растёт быстро. Возврат согласуют обе стороны, средства замирают на неопределённый срок, а разбор ложится на комплаенс-службу: она сверяет переписку, ищет контакт контрагента и восстанавливает поля вручную. Один такой случай — часы работы специалиста и оборванный сценарий клиента.

Отдельный пласт — несовпадение правил: пороговые суммы и перечень обязательных полей различаются по юрисдикциям, часть контрагентов подключает протокол обмена через посредника, часть не поддерживает вовсе. Криптобиржа без маршрутизации по каждому контрагенту застревает здесь, а не в самой блокчейн-части. Слой Notabene закрывает этот участок: единая точка подключения, приведение данных к общей схеме, распределение сообщений по адресатам.

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

Что меняет внедрение: сроки подключения, отказы, простои

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

Второй показатель — доля отклонённых переводов. Основная причина отказов — неполные или несовпадающие данные отправителя и получателя: оператор ловил расхождение вручную и уже после отправки. Предварительная проверка до списания и правила сопоставления переводят долю отказов из двузначных значений в единицы процентов.

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

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

Метрики снимаем до и после внедрения и отдаём отчётом по каждому контрагенту — видно, где ещё остаётся ручная работа и что дорабатывать дальше.

Способы подключения: свой узел, сервис-посредник, гибрид

Обмен данными о переводе между биржами строится одним из нескольких способов, и выбор здесь не бинарный. Критерии — объём исходящих операций, требование регулятора к тому, где лежат персональные данные отправителя, и готовность контрагентов держать прямой канал.

Локальное хранение данных — не отдельный способ обмена, а режим, который накладывается на любой из первых трёх: полный набор полей остаётся у вас, наружу уходит подтверждение. На практике чаще собирают гибрид — прямой канал для крупных контрагентов и посредник для остальных. Схему закладываем так, чтобы переход между вариантами не требовал переписывания логики проверок.

Этапы внедрения: от разбора схемы до передачи регламентов

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

1. Аудит маршрутов переводов. Собираем карту потоков: активы, сети, юрисдикции сторон, контрагенты, с которыми уже требуется обмен данными. Отмечаем, на каком шаге сведения об отправителе теряются в текущем процессе.
2. Схема интеграции. Определяем момент запроса данных, поведение системы при отказе контрагента отвечать, сопоставление полей сообщения с внутренней моделью транзакции. Итог этапа — согласованная схема и перечень доработок учётной системы.
3. Настройка обмена. Подключаем канал, заполняем справочник контрагентов, задаём правила маршрутизации и ведём журнал сообщений для последующего аудита.
4. Проверка на пилоте. Прогоняем реальные сценарии: совпадающие данные, расхождения в написании имени, запрос без ответа, откат к ручному разбору. Смотрим, что происходит с транзакцией в каждом случае и корректно ли закрывается исключение.
5. Передача регламентов. Описываем действия оператора в типовых и спорных ситуациях, порядок эскалации, критерии остановки перевода. Передаём документацию и обучаем команду поддержки.
6. Сопровождение. Следим за долей ручных разборов и статистикой отказов, обновляем правила при смене требований и подключении новых контрагентов.

Что передаём на руки: конфигурации, схемы, регламенты

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

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

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

Кейс: как биржа сняла блокировки переводов после внедрения

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

Как было устроено до внедрения

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

Что изменили

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

Ручных разборов стало около 3% от потока вместо 12%, подтверждение по типовым маршрутам занимает 2-4 минуты, отмены переводов клиентами почти прекратились, а на смене вместо трёх офицеров остался один — на нестандартных случаях. Отдельно ушёл класс отказов, когда перевод отклонялся из-за потерянного ответа контрагента.

Как проходит проверка compliance при подключении контрагента?

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

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

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

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

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

Технические сомнения: журналы, хранение данных, ложные срабатывания

Каждое событие Travel Rule — отправка набора данных контрагенту, ответ его сервиса, подтверждение или отказ — попадает в неизменяемый журнал операций. Запись идёт асинхронно: недоступность внешнего узла не блокирует вывод средств, событие фиксируется со статусом «ожидает подтверждения» и доигрывается при восстановлении канала.

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

Что будет с переводом, если канал до контрагента лёг?

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

Не утонем ли в ложных срабатываниях?

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

Обсудим задачу: вернёмся с оценкой и планом подключения

Оценка и план подключения собираются под ваш контур: какие активы и юрисдикции в периметре, как устроен учёт клиентов, кто выступает контрагентом по переводам. Сначала смотрим текущий процесс — где данные о плательщике и получателе уже есть, а где их придётся собирать, и только после этого фиксируем объём работ и порядок этапов.

Что войдёт в план работ и в пробное подключение одного контрагента:

• Схема сопоставления: как записи из вашей учётной системы превращаются в исходящее сообщение по требованию Travel Rule и что делать с неполными полями.
• Правила маршрутизации: кому передаём данные напрямую, для кого используем общий реестр соответствия, на каком шаге включается ручная проверка.
• Настройка обмена с Notabene: справочник контрагентов, форматы сообщений, обработка отказов и повторных попыток отправки.
• Матрица ролей и доступов: кто подтверждает отправку, кто разбирает расхождения, чьи действия попадают в неизменяемый журнал.
• Пробное подключение одного контрагента на живом, но ограниченном потоке переводов — видно, как ведёт себя маршрутизация и что показывает интерфейс оператора.
• Регламент разбора исключений и сопровождение после запуска: обновление справочников, реакция на изменения требований, контроль доли успешно переданных данных.
• Комплект документации: схемы потоков данных, инструкции для операторов, чек-лист приёмки.

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