FATF Travel Rule: где ломается обмен данными между VASP
Перевод между двумя площадками проходит за минуты, а сведения о плательщике и получателе догоняют его часами или не приходят вовсе. Формально требования FATF Travel Rule описывают, что именно нужно передавать, но не описывают, как это делать технически, — поэтому каждая пара VASP договаривается о формате обмена сама.
Первый разрыв — неполные поля. Одна сторона отправляет имя и адрес кошелька, другая ждёт идентификатор клиента в своём формате; свободный текст вместо структурированного поля не проходит проверку на приёме, и запрос уходит на ручную доработку.
Второй — порог срабатывания перевода. Он задан в разных валютах и считается по разным правилам: где-то от суммы, где-то от эквивалента на момент операции. Перевод, пороговый для одной площадки, для другой оказывается обычным, и пакет сведений не формируется вовсе.
Третий — ручные запросы между VASP. Пока у площадок нет общего канала, подтверждение данных получателя идёт через почту и веб-формы: ответ приходит через сутки, операция висит в статусе ожидания, а служба контроля вручную сверяет каждый шаг. Обмен данными между площадками через Notabene снимает часть боли — маршрутизация и шаблоны полей есть, — но некастодиальные кошельки остаются вне контура, и сведения по ним собирают вручную.
Что даёт настроенный обмен данными: эффект в измеримых показателях
Настроенный обмен данными превращает Travel Rule из ручной переписки в регламентный поток: правила маршрутизации сами определяют, какому контрагенту и в каком объёме уходит набор сведений об отправителе и получателе. На типовой конфигурации Notabene доля операций без ручного разбора выходит на 85–95%, а остаток — это обращения к некастодиальным кошелькам и нетиповые случаи, где решение осознанно принимает специалист по контролю.
Время обработки перевода сокращается за счёт того, что запрос уходит контрагенту автоматически вместе с транзакцией, а не отдельным письмом после разбора. Ответ по стандартному запросу приходит за минуты вместо часов, и очередь переводов, ожидающих подтверждения сведений, перестаёт расти к концу дня.
Качество данных контрагента держится на валидации на входе: обязательные поля проверяются до отправки, справочник контрагентов хранит актуальные адреса и форматы приёма, а расхождения помечаются сразу. Это снимает главную причину возвратов — неполный или не в том формате набор сведений о сторонах перевода.
Снижение отказов по переводам — отдельный измеримый итог: уходит класс задержек, вызванных неполными сведениями, и уменьшается доля операций, которые приходится поднимать вручную повторно. По переводам на некастодиальные кошельки эффект скромнее — там обмен строится на подтверждении владения адресом, — но и этот путь перестаёт быть узким местом.
Способы передачи данных по Travel Rule: сравнение вариантов
Стандарт задаёт, какие сведения о плательщике и получателе должны ехать вместе с переводом между VASP, но не фиксирует, по какому каналу их передавать. На практике сложились четыре линии передачи: общая платформа-посредник, прямой канал между участниками, открытый реестр адресов и ручная передача по защищённому каналу. От выбора линии зависит, сколько интеграций вам поддерживать и как быстро снимается удержание на исходящем переводе.
| Способ передачи данных Travel Rule | Когда подходит | Ограничения |
|---|---|---|
| Платформа-посредник обмена (например, Notabene) | Контрагенты разбросаны по юрисдикциям, прямых договорённостей нет | Работаете только внутри покрытия сети, правила платформы обязательны для обеих сторон |
| Прямой канал между участниками | Стабильный объём переводов с конкретным контрагентом и общий формат данных | Каждая пара участников — отдельная интеграция, свой справочник ключей и поддержка на обеих сторонах |
| Открытый реестр адресов | Исходящие на собственные и внесетевые кошельки, нужно снять часть ручных проверок | Сведения о сторонах не передаёт, подтверждает только принадлежность адреса |
| Ручная передача сведений | Разовые переводы и контрагенты вне сети | Не масштабируется, ошибки ввода, нет машинного подтверждения доставки |
Линии обычно комбинируют: платформа закрывает длинный хвост контрагентов, прямой канал — основной объём, ручная передача остаётся резервом. Реестр адресов работает поверх любой схемы и снижает долю запросов, на которые некому ответить. Ключевой критерий выбора — не удобство отправки, а подтверждение доставки: без него перевод для проверяющего выглядит как непереданный, поэтому журналирование запросов и повторная отправка закладываются в схему сразу.
Этапы внедрения: от аудита потоков до передачи регламентов
Внедрение обмена сведениями по FATF Travel Rule отличается от обычной интеграции: сведения должны дойти до контрагента, который может работать на другом провайдере или вообще без него.
- Аудит переводов и правил. Разбираем входящие и исходящие потоки, отмечаем, где теряются сведения о плательщике и получателе, сверяем внутренние правила с требованиями регулятора по порогам.
- Инвентаризация контрагентов. Собираем перечень VASP с оборотом, определяем, кто готов принимать сведения, и фиксируем, как каждая сторона трактует некастодиальные кошельки.
- Схема маршрутизации данных. Описываем состав полей и формат сообщения, маршрут отправки — через провайдера Notabene или напрямую между узлами, — и поведение при молчании контрагента: удержание или повторный запрос.
- Правила отбора операций. Задаём условия срабатывания: сумма, актив, юрисдикция, участие некастодиального кошелька. Через обмен идёт нужный поток, а не весь трафик.
- Стыковка с контрагентами. Согласуем реквизиты взаимодействия, тестовые ключи и порядок разбора расхождений.
- Тестовые сценарии перевода. Прогоняем обычный перевод, операцию ниже порога, отсутствие ответа, расхождение в данных и отправку на некастодиальный кошелёк — с проверкой записи в журнале и выгрузке.
- Передача регламентов команде. Отдаём схемы потоков, матрицу правил, инструкции дежурной смены и порядок эскалации при отказе узла или массовом удержании.
Приёмка — воспроизводимый разбор любого перевода: по какому правилу он отобран, куда ушли сведения и что осталось сделать вручную.
Что остаётся у заказчика: конфигурации, схемы и регламенты
Мы не оставляем заказчику «доступ к панели» — в его контуре остаётся рабочий комплект, по которому обмен Travel Rule можно эксплуатировать и развивать без нашего участия. Все артефакты версионируются вместе с кодом в репозитории заказчика.
- Конфигурация правил обмена — пороги и направления, по которым запрашиваются данные, сопоставление полей между форматами, исключения для отдельных контрагентов и порядок их правки.
- Схема потоков данных — от кошелька клиента до узла Notabene и обратно: где формируется запрос, где хранится ответ, что уходит в аналитику.
- Политики доступа и роли — кто видит персональные данные, кто меняет правила, кто подтверждает исключения; журнал действий по каждой роли.
- Регламент обработки обращений — сроки ответа на входящие запросы, эскалация, сценарий при отказе контрагента предоставить данные.
- Документация по интеграции — вызовы, форматы сообщений, коды ошибок, поведение при недоступности контрагента, тестовый контур со сценариями.
- Процедура для unhosted-кошельков — как подтверждается владение адресом, какие доказательства принимаются, что делать при их отсутствии.
- План деградации — что отключается первым, чтобы обмен продолжал идти, а не падал целиком.
Комплект закрывает вопросы регулятора и внутреннего аудита: видно, почему отправлен запрос, кто имел доступ к данным и как менялись правила. Новый инженер входит в обмен по документации, а не по переписке.
Кейс: обмен с unhosted-кошельками без ручных запросов
Обмен с кошельками без кастодиана — самый затратный участок комплаенса. У входящего перевода на unhosted-кошелёк нет контрагента, у которого можно запросить данные отправителя: адрес приходится сверять вручную, писать клиенту и ждать ответа. При потоке в несколько тысяч операций в сутки доля переводов с ручным подтверждением доходила до трети, разбор одного занимал 20–30 минут, а часть операций висела в ожидании больше суток.
Что изменили
Первым шагом разметили поток: отделили переводы между собственными клиентами, операции с внешними VASP и переводы на адреса без кастодиана. Для последних собрали правила — порог суммы, автоматическая сверка адреса с базами риска и запрос сведений у отправителя через Notabene. Доставку сделали отказоустойчивой: очередь повторных попыток с нарастающими интервалами, журнал по каждому запросу и переиспользование уже полученных ответов, чтобы не дублировать обращения к одному контрагенту.
Что стало
Доля ручного разбора упала с трети до единиц процентов — типовые переводы закрываются автоматически. Среднее время обработки сократилось с получаса до секунд, а операции, зависшие более суток, ушли из отчётности. Ответы контрагентов приходят сами в большинстве случаев; если адресат молчит, заявка уходит в очередь повторов и не блокирует остальной поток. Ручной разбор остался только для срабатываний санкционных списков и расхождений в данных отправителя.
Чем hosted-кошелёк отличается от unhosted и что это меняет
Hosted-кошелёк — счёт, ключи от которого держит лицензированный поставщик услуг. На другой стороне перевода стоит контрагент с собственными процедурами идентификации, поэтому сведения о клиенте передаёт он, а мы лишь сверяем полученный пакет с отправленным.
Unhosted — ключи у самого клиента, и собирать сведения приходится нам. Автообмена здесь нет: идентификацию владельца строим на доказательствах контроля — подпись сообщения закрытым ключом, тестовый микроперевод, разовая сверка адреса с реквизитами клиента.
| Сторона перевода | Кто передаёт сведения | Что требуется | Ограничения |
|---|---|---|---|
| Hosted, кастодиальный сервис | Партнёрский узел, автоматически | Совместимый формат обмена | Зависит от готовности партнёра поддерживать обмен |
| Unhosted, кошелёк клиента | Мы, по данным клиента | Доказательство контроля над адресом | Ручная проверка, автообмен недоступен |
Для кастодиальной стороны достаточно подключить обмен в инструменте класса Notabene и согласовать набор полей. Для кошелька под контролем клиента тот же инструмент закрывает только исходящую часть — проверку владельца и хранение доказательств.
Сценарии без контрагента — перевод на собственный адрес, смарт-контракт или адрес вне зоны действия правил — передачу сведений не запускают. Но обоснование решения всё равно сохраняем: при проверке оно показывает, почему данные не передавались.
Технические сомнения: доступы, журналы, отказоустойчивость
Доступы к данным Travel Rule разграничиваем по ролям: комплаенс-офицер видит перевод и сведения о сторонах, аналитик — только метаданные обмена без персональных данных, поддержка — статусы доставки без содержимого. Каждое действие с записью попадает в неизменяемый журнал: кто запросил, когда, что вернул контрагент, какой адрес помечен как некастодиальный. Так журналирование операций обмена становится доказательством для регулятора, а не набором логов приложения.
Если контрагент недоступен, перевод не зависает: запрос уходит в очередь с повторами по нарастающей паузе, а после исчерпания попыток помечается как необработанный с уведомлением ответственного специалиста. Повторная обработка перевода идемпотентна — ключом служит идентификатор исходной операции, поэтому повторная доставка не создаёт дубль записи и не искажает сведения.
Как хранятся переданные сведения и что с их удалением?
Переданные сведения лежат в отдельном контуре с шифрованием и настраиваемым сроком хранения. По истечении политика удаления обезличивает запись, сохраняя факт и время обмена для отчётности.
Что произойдёт при повторной доставке перевода?
Обработчик сверяет ключ идемпотентности и возвращает ранее сохранённый результат вместо новой записи. Журнал фиксирует попытку отдельной строкой, поэтому расследование видит всю историю доставки.
Обсудим вашу схему обмена данными и вернёмся с планом
Чтобы оценка объёма работ опиралась на факты, а не на предположения, нам нужны вводные по вашему контуру: как сегодня устроен обмен данными с контрагентами, кто инициатор перевода и как вы трактуете некастодиальные (unhosted) кошельки. Без этого нельзя ни выбрать схему маршрутизации запросов, ни понять, какие доработки потребуются в вашей инфраструктуре.
Что достаточно прислать для первого разбора:
- схему движения переводов: юрисдикции отправителя и получателя, доли фиатного и криптовалютного плеча, средний и пиковый объём операций;
- перечень контрагентов-VASP и их провайдеров обмена данными — например, Notabene или собственные решения;
- как вы определяете принадлежность адреса: признаки владения, политика по некастодиальным кошелькам, основания для отказа от перевода;
- пороги срабатывания и правила исключений, а также требования к сроку ответа на входящий запрос;
- роли и доступы: кто ведёт переписку с контрагентами, кто подтверждает персональные данные и как это логируется;
- форматы выгрузок для отчётности и порядок разбора спорных переводов;
- ограничения: что нельзя менять в текущих процессах и какие внешние системы трогать нельзя.
По итогам разбора вернём оценку объёма работ, план внедрения обмена с этапами подготовки к стыковке с контрагентами и перечень проверок перед запуском. Опишите ваш контур в общих чертах — вернёмся с оценкой и планом.
