Travel Rule compliance для криптобірж: де рветься обмін даними
Travel Rule вимагає, щоб разом із переказом понад порогову суму контрагенту йшли відомості про відправника й отримувача: ім'я, номер рахунку або адреса гаманця, ідентифікатор транзакції.
У мережі транзакція та супровідні дані йдуть різними каналами — і рветься обмін даними про перекази саме на стику.
Типовий збій: клієнт ініціює виведення, криптобіржа формує транзакцію, а повідомлення або не збирається через незаповнене поле, або йде в структурі, яку приймальна сторона не розбирає — замість IVMS101 вільний текст, замість ідентифікатора рахунку лише адреса.
Контрагент відхиляє повідомлення, і переказ зависає: у мережі він виконаний, у отримувача не зарахований.
Ціна зростає швидко. Повернення узгоджують обидві сторони, кошти завмирають на невизначений строк, а розбір лягає на комплаєнс-службу: вона звіряє листування, шукає контакт контрагента і відновлює поля вручну. Один такий випадок — години роботи фахівця і обірваний сценарій клієнта.
Окремий пласт — невідповідність правил: порогові суми та перелік обов'язкових полів різняться за юрисдикціями, частина контрагентів підключає протокол обміну через посередника, частина не підтримує взагалі.
Криптобіржа без маршрутизації за кожним контрагентом застрягає тут, а не в самій блокчейн-частині. Шар Notabene закриває цю ділянку: єдина точка підключення, приведення даних до спільної схеми, розподіл повідомлень за адресатами.
Нижче розбираємо, як це закривається: від розбору потоку переказів і порогових сум до маршрутизації повідомлень і автоматичних сценаріїв на завислі платежі.
Що змінює впровадження: строки підключення, відмови, простої
Перший вимірюваний зсув — строк підключення нового контрагента. Раніше ми узгоджували формат повідомлень, тестовий контур і правила зіставлення реквізитів з кожним адресатом окремо: листування розтягувалося на дні, частина контрагентів так і залишалася поза обміном.
Після підключення до Notabene адреси та дані звіряються за спільним довідником, а обмін відбувається за єдиним форматом — новий контрагент піднімається за години, а не за тиждень.
Другий показник — частка відхилених переказів. Основна причина відмов — неповні або невідповідні дані відправника й отримувача: оператор ловив розбіжність вручну і вже після відправлення.
Попередня перевірка до списання та правила зіставлення переводять частку відмов із двозначних значень в одиниці відсотків.
Третій — ручний розбір операцій. Черга запитів додаткових даних скорочується завдяки автоматичним сценаріям: типові розбіжності закриваються без участі оператора, людині залишаються тільки спірні випадки.
Окремо рахуємо простої каналу обміну.
Черги повідомлень, повторні відправлення та обробка недоставлених пакетів налаштовані так, що у разі збою одного вузла обмін піднімається автоматично: простій скорочується з годин до хвилин, а повна історія повідомлень зберігається для аудиту.
Метрики знімаємо до та після впровадження і віддаємо звітом за кожним контрагентом — видно, де ще залишається ручна робота і що доопрацьовувати далі.
Способи підключення: власний вузол, сервіс-посередник, гібрид
Обмін даними про переказ між біржами будується одним із кількох способів, і вибір тут не бінарний. Критерії — обсяг вихідних операцій, вимога регулятора до того, де лежать персональні дані відправника, і готовність контрагентів тримати прямий канал.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Власний вузол обміну | Сталий круг контрагентів, вимога зберігати листування в себе, незалежність від третьої сторони | Кожен партнер підключається вручну, ротація ключів на вашій стороні, недоставлені повідомлення розбирає ваша підтримка |
| Сервіс-посередник | Довгий хвіст партнерів, запуск у стислий строк, немає ресурсу на супровід каналів | Дані проходять через третю сторону, охоплення залежить від її мережі, гнучкість формату повідомлень обмежена |
| Гібридна схема | Великі контрагенти на прямому каналі, решта — через посередника | Дві логіки маршрутизації, потрібен єдиний журнал і відсікання дублів, щоб не задвоювати перевірки |
| Локальне зберігання даних | Персональні дані не повинні виходити за ваш контур | Контрагент зобов'язаний підтримати цей режим, звірка та розбір спірних переказів ускладнюються |
Локальне зберігання даних — не окремий спосіб обміну, а режим, який накладається на будь-який із перших трьох: повний набір полів залишається у вас, назовні йде підтвердження. На практиці частіше збирають гібрид — прямий канал для великих контрагентів і посередник для решти. Схему закладаємо так, щоб перехід між варіантами не вимагав переписування логіки перевірок.
Етапи впровадження: від розбору схеми до передачі регламентів
Впровадження вимоги Travel Rule зачіпає всі перекази між провайдерами, а не окремий сценарій: якщо дані про відправника губляться по дорозі, транзакція зависає на стороні контрагента або йде в ручний розбір. Тому роботи йдуть за етапами — від інвентаризації потоків до передачі внутрішніх регламентів.
- Аудит маршрутів переказів. Збираємо карту потоків: активи, мережі, юрисдикції сторін, контрагенти, з якими вже потрібен обмін даними. Позначаємо, на якому кроці відомості про відправника губляться в поточному процесі.
- Схема інтеграції. Визначаємо момент запиту даних, поведінку системи в разі відмови контрагента відповідати, зіставлення полів повідомлення з внутрішньою моделлю транзакції. Підсумок етапу — узгоджена схема та перелік доопрацювань облікової системи.
- Налаштування обміну. Підключаємо канал, заповнюємо довідник контрагентів, задаємо правила маршрутизації та ведемо журнал повідомлень для подальшого аудиту.
- Перевірка на пілоті. Проганяємо реальні сценарії: збіжні дані, розбіжності в написанні імені, запит без відповіді, відкат до ручного розбору. Дивимося, що відбувається з транзакцією в кожному випадку і чи коректно закривається виняток.
- Передача регламентів. Описуємо дії оператора в типових і спірних ситуаціях, порядок ескалації, критерії зупинки переказу. Передаємо документацію та навчаємо команду підтримки.
- Супровід. Стежимо за часткою ручних розборів і статистикою відмов, оновлюємо правила при зміні вимог і підключенні нових контрагентів.
Що передаємо на руки: конфігурації, схеми, регламенти
Інтеграція Travel Rule не закінчується успішним тестовим переказом. Далі система живе в операційному контурі: контрагенти змінюють адреси приймання, регулятори розширюють набір обов'язкових полів, а чергова зміна має розуміти, що робити із завислим запитом. Тому передаємо не доступи й записи дзвінків, а комплект, за яким супровід працює без нас.
- Пакет конфігурацій — профілі середовищ, ключі підпису та порядок їх ротації, ліміти за обсягами й частотою звернень, шаблони повідомлень під різні типи переказів.
- Схеми потоків даних — шлях від ініціювання виведення до підтвердження приймальною стороною, з позначеними точками відмови та місцями, де дані про бенефіціара губляться.
- Правила маршрутизації — якому контрагенту і через який канал іде запит, пріоритети, поведінка при недоступності адресата та порядок повторних спроб.
- Регламенти комплаєнсу — строки відповіді на вхідні запити, ескалація в разі відмови контрагента, правила зупинки переказу при неповних даних.
- Матриця вимог за напрямами — обов'язковий набір полів для кожної юрисдикції та порядок дій у разі розбіжності з вимогами контрагента.
- Інструкції для чергової зміни та комплаєнсу — чек-листи на типові інциденти: зростання черги необроблених запитів, масові відмови, розсинхронізація статусів.
Кожен артефакт перевіряємо на стенді: сценарії з недоступним контрагентом, зміненим форматом відповіді, відкликаним ключем. Комплект прийнято, коли черговий закриває типовий інцидент за інструкцією, не залучаючи розробників.
Кейс: як біржа зняла блокування переказів після впровадження
Клієнти бачили не відмову, а підвішений переказ: кошти списані, зарахування немає, підтримка відповідає «уточнюємо дані в контрагента».
Так виглядав комплаєнс-процес до інтеграції — кожен восьмий вихідний переказ ішов у ручний розбір, медіана відповіді на запит про походження коштів трималася близько 40 хвилин, а в пікові години черга сягала кількох годин.
Як було влаштовано до впровадження
Розбір ішов у листуванні: комплаєнс-офіцер вручну звіряв контрагента зі списком, запитував у нього дані відправника й отримувача, збирав їх у таблицю і лише потім підтверджував транзакцію.
При зростанні потоку втричі зміна не масштабувалася — збільшувалися тільки затримки та частка помилкових відхилень, бо частина відповідей губилася між поштою і внутрішньою системою.
Що змінили
Обмін даними за Travel Rule перевели на Notabene: адресна книга контрагентів із правилами маршрутизації, автоматичне зіставлення власників гаманців, шаблони запитів і підтверджень.
Для провайдерів із підтвердженою інфраструктурою дані йдуть і приймаються без людини, решта потрапляють у єдину чергу з повним контекстом переказу.
Ручних розборів стало близько 3% від потоку замість 12%, підтвердження за типовими маршрутами займає 2-4 хвилини, скасування переказів клієнтами майже припинилися, а на зміні замість трьох офіцерів залишився один — на нестандартних випадках. Окремо зник клас відмов, коли переказ відхилявся через втрачену відповідь контрагента.
Як проходить перевірка комплаєнсу при підключенні контрагента?
Перевірка комплаєнсу при підключенні контрагента починається раніше за перший обмін даними: сторони звіряють, чи є у другої сторони робочий процес Travel Rule compliance, у якій юрисдикції вона працює і чи готова передавати відомості про відправника й отримувача.
Зазвичай це коротка анкета плюс пробний обмін на тестовому контурі — видно, як контрагент відповідає на запити і що робить із полями, яких у нього немає.
Далі йде обмін списками. Кожна сторона публікує реєстр адрес, прив'язаних до її інфраструктури: кастодіальні гаманці, адреси біржі, адреси клієнтів.
З ним вхідна транзакція одразу розпізнається як своя, і запит даних не йде туди, де він не потрібен — падає кількість хибних спрацювань і ручних розборів.
Підтвердження адреси — найчутливіша частина. Якщо переказ іде на адресу, приналежність якої нам невідома, формується запит контрагенту: підтвердіть, що адреса ваша і за нею стоїть конкретний клієнт.
Поки відповіді немає, транзакція залишається непідтвердженою, і внутрішня політика вирішує — призупинити її або пропустити з флагом ризику.
Розбіжності неминучі: адресу не знайдено в реєстрі, контрагент відповідає іншою юрисдикцією, поля не збігаються за форматом. Їх обробляють як чергу інцидентів: правила маршрутизації, автоматичні повтори, ескалація співробітнику комплаєнс-контролю після вичерпання спроб. Кожна розбіжність потрапляє до журналу з причиною — це основа звітності перед регулятором.
Зв'язку між контрагентами бере на себе Notabene: маршрутизація запитів і формати даних. Наше завдання — описати внутрішні правила та винятки, щоб перевірка комплаєнсу не перетворювалася на ручний конвеєр.
Технічні сумніви: журнали, зберігання даних, хибні спрацювання
Кожна подія Travel Rule — надсилання набору даних контрагенту, відповідь його сервісу, підтвердження або відмова — потрапляє до незмінного журналу операцій.
Запис відбувається асинхронно: недоступність зовнішнього вузла не блокує виведення коштів, подія фіксується зі статусом «очікує підтвердження» і дограється при відновленні каналу.
Нижче — те, що найчастіше спливає на прийманні: строки зберігання, вивантаження за запитом, поведінка при збоях і налаштування порогів чутливості.
Скільки зберігаються журнали і як вивантажити їх за запитом регулятора?
Строк зберігання задається політикою: гарячий шар для оперативного розбору інцидентів, холодний архів — для тривалої відповідності вимогам. Вивантаження формується в машиночитному вигляді за довільний період, із фільтрами за контрагентом, напрямом переказу та статусом.
Записи незмінні: ручне виправлення й дострокове видалення не передбачені, доступ розмежовано за ролями.
Що буде з переказом, якщо канал до контрагента впав?
Черга повторних спроб із наростаючою затримкою та розділенням тимчасових і постійних помилок відповіді. Переказ не зависає: він або доходить після відновлення зв'язку, або йде в ручний розбір із повним контекстом усіх спроб. Недоступність зовнішнього сервісу не зупиняє приймання депозитів і внутрішні операції.
Чи не потонемо в хибних спрацюваннях?
Пороги налаштовуються за сценаріями окремо: сума, юрисдикція, тип контрагента, історія відносин, джерело коштів.
Правила калібруються на реальному потоці — спочатку режим спостереження, де спрацювання лише логуються, потім переведення в блокувальний режим за тими сценаріями, де частка шуму близька до нуля. Так черга ручного розбору залишається оглядовою.
Обговоримо задачу: повернемося з оцінкою та планом підключення
Оцінка та план підключення збираються під ваш контур: які активи й юрисдикції в периметрі, як влаштовано облік клієнтів, хто виступає контрагентом за переказами.
Спочатку дивимося поточний процес — де дані про платника й отримувача вже є, а де їх доведеться збирати, і лише після цього фіксуємо обсяг робіт і порядок етапів.
Що увійде до плану робіт і в пробне підключення одного контрагента:
- Схема зіставлення: як записи з вашої облікової системи перетворюються на вихідне повідомлення за вимогою Travel Rule і що робити з неповними полями.
- Правила маршрутизації: кому передаємо дані напряму, для кого використовуємо загальний реєстр відповідності, на якому кроці вмикається ручна перевірка.
- Налаштування обміну з Notabene: довідник контрагентів, формати повідомлень, обробка відмов і повторних спроб відправлення.
- Матриця ролей і доступів: хто підтверджує відправлення, хто розбирає розбіжності, чиї дії потрапляють до незмінного журналу.
- Пробне підключення одного контрагента на живому, але обмеженому потоці переказів — видно, як поводиться маршрутизація і що показує інтерфейс оператора.
- Регламент розбору винятків і супровід після запуску: оновлення довідників, реакція на зміни вимог, контроль частки успішно переданих даних.
- Комплект документації: схеми потоків даних, інструкції для операторів, чек-лист приймання.
Пробне підключення знижує ризик: один контрагент і обмежений потік показують поведінку системи до того, як через неї піде весь обсяг переказів. Опишіть задачу — повернемося з оцінкою та планом підключення.
