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 або власні рішення;
- як ви визначаєте належність адреси: ознаки володіння, політика щодо некастодіальних гаманців, підстави для відмови від переказу;
- пороги спрацювання та правила винятків, а також вимоги до строку відповіді на вхідний запит;
- ролі та доступи: хто веде листування з контрагентами, хто підтверджує персональні дані і як це логується;
- формати вивантажень для звітності та порядок розбору спірних переказів;
- обмеження: що не можна змінювати в поточних процесах і які зовнішні системи не можна чіпати.
За підсумками розбору повернемо оцінку обсягу робіт, план впровадження обміну з етапами підготовки до стикування з контрагентами та перелік перевірок перед запуском. Опишіть ваш контур у загальних рисах — повернемося з оцінкою та планом.
