Інтеграція AML-скринінгу (Chainalysis, Elliptic, Crystal) під ключ

AML-скринінг криптовалют: де ламається комплаєнс

Поки обсяг операцій невеликий, перевірку транзакцій ведуть руками: аналітик відкриває адресу в оглядачі блоків, звіряє із санкційними списками, пише коментар у таблицю.

Поки за добу проходить десяток виплат, затримка виведення коштів непомітна — на сотнях операцій черга зростає швидше, ніж її розбирають, і строк відповіді клієнту зсувається з годин на добу.

Друга точка відмови — хибні спрацьовування. Автоматичні правила позначають підозрілими перекази, опосередковано пов'язані з міксером або біржовим гаманцем, і до 80% таких позначок закриваються як безпідставні.

Аналітик витрачає день на розбір шуму, а справді ризикова транзакція проходить повз: увага вже вичерпана.

Далі підключається зовнішній контур. Партнер із ліквідності або банк-кореспондент бачить непрозору історію операцій і блокує рахунок до з'ясування — виплати зупиняються повністю, а не по одному клієнту.

На аудиті криптооперацій з'ясовується, що рішення щодо минулих позначок ніде не зафіксовані: незрозуміло, хто і на якій підставі пропустив транзакцію.

Саме тут губляться ризики комплаєнсу — не у відсутності скринінгу, а в його ручному режимі.

Розбираємо, як це закривається: Chainalysis та аналогічні сервіси дають оцінку адреси, але ефект з'являється лише тоді, коли оцінка вбудована в сам процес виплат і залишає слід для перевіряючого.

Що дає автоматичний скринінг: ефект у вимірюваних величинах

Скринінг вбудовується в момент зарахування або виведення, тому кожна операція отримує оцінку ризику до руху коштів, а не заднім числом.

Швидкість обробки операцій задає пропускна здатність сервісу, а не кількість аналітиків у зміні: потік адрес перевіряється автоматично, і ручна робота залишається лише на спрацьовуваннях.

Частка хибних спрацьовувань — керована величина. Оцінка будується на даних провайдерів аналітики блокчейну, наприклад Chainalysis, а пороги ризику налаштовуються під профіль ваших клієнтів, географію платежів і типові суми.

Після налаштування сигнали піднімають справді нестандартні маршрути, а не кожного нового контрагента — це розвантажує розбір і знижує кількість випадків, де доводиться запитувати документи у клієнта.

Час розбору випадку скорочується завдяки готовій картці: адреса відправника, контрагент, маршрут коштів, прив'язка до відомих сервісів та історія минулих перевірок.

Аналітик підтверджує рішення замість збору даних вручну — рутинний кейс закривається за хвилини замість години з гаком.

Головний ефект — усунений клас відмов. Операції, які банк-партнер або біржа відхиляли через непрозоре джерело коштів, проходять із підтвердженим ризиком та обґрунтуванням.

Вартість простою скорочується разом із цим: заморожений депозит або виведення — це години й дні без операцій, і такий простій закривається до того, як він почався.

Способи інтеграції перевірки: порівняння режимів роботи

Режим перевірки визначається тим, де в потоці операцій стоїть виклик аналітичного сервісу і що відбувається з операцією до отримання вердикту.

Перевірка на вході оцінює адресу відправника до зарахування коштів, перевірка на виході — перед формуванням виплати, щоб транзакція не пішла на санкційну або високоризикову адресу.

Гібридна схема поєднує обидва контури й додає періодичний перегляд історії: адреса, чиста на момент входу, переоцінюється в міру оновлення даних постачальника. Режими різняться ціною затримки та покриттям ризику.

Щоб режими не розповзалися по коду, підключення аналітичних сервісів — Chainalysis, Elliptic, Crystal — роблять через єдиний адаптер: нормалізований вердикт, кеш оцінки за адресою, повтор запиту в разі недоступності.

Тоді зміна постачальника або додавання другого — правка конфігурації, а не переписування логіки перевірок.

Етапи впровадження: від аудиту операцій до передачі в роботу

Впровадження скринінгу — це не встановлення готового модуля, а налаштування процесу під те, як реально рухаються кошти у вашому продукті. Нижче — етапи, які ми проходимо разом із командою замовника: від аудиту операцій до передачі контуру в експлуатацію.

1. Аудит операцій. Розбираємо вхідні та вихідні потоки: поповнення, виведення, перекази між рахунками, обмін. Фіксуємо, де потрібна повна перевірка адреси, а де достатньо звірки із санкційними списками.

2. Профіль ризику. Визначаємо критерії підозрілої операції: юрисдикція, джерело коштів, вік адреси, частка надходжень із міксерів і майданчиків без перевірки клієнта.

3. Проєктування схеми. Підбираємо провайдера під ваші мережі та активи — Chainalysis, Elliptic або Crystal, — і описуємо дії у разі спрацьовування: блокування, ручна перевірка, запит документів.

4. Підключення та пороги спрацьовування. Перевірка вбудовується в момент створення транзакції та у фоні, щоб не затримувати платежі. Пороги задаємо не за замовчуванням, а від вашого профілю ризику та допустимої частки хибних спрацьовувань.

5. Перевірка на історичних даних. Проганяємо накопичені транзакції через готові правила й дивимося, скільки спрацьовувань припадає на реальні ризики, а скільки — на шум. Тільки так пороги калібруються до запуску.

6. Регламент і передача. Описуємо дії аналітика за кожним класом ризику та зберігання доказів для звітності, передаємо конфігурацію та інструкції — і залишаємося на підтримці під час підключення нових мереж.

Що залишається у вас на руках: конфігурація та регламенти

Після здачі проєкту у вашої команди залишаються не лише працюючий сервіс, а й повний набір артефактів, за якими його можна експлуатувати, розвивати та передавати новим інженерам.

Конфігурація лежить у вашому репозиторії з історією змін, рішення задокументовані — інтеграція не тримається на підряднику.

• Схема інтеграції — шлях від адреси або транзакції до вердикту скринінгу: де викликається перевірка, як обробляється таймаут провайдера і що йде в резервний канал.
• Конфігурації — пороги ризику, списки довірених адрес, маршрутизація за провайдерами для різних мереж і активів, окремі набори для тестового та робочого середовищ.
• Регламент розбору спрацьовувань — рівні ризику, строки реакції, кому ескалюється знахідка і як фіксується ухвалене щодо неї рішення.
• Політики доступу — ролі, розподіл прав на зміну порогів і на перегляд даних перевірок, журналювання дій операторів.
• Інструкції для підтримки — що робити в разі недоступності провайдера, як перевірити статус конкретної перевірки, розбір типових звернень клієнтів.
• Звітність за операціями — вивантаження за перевірками, відмовами та ескалаціями за період у форматі, який приймає комплаєнс.
• План розвитку — як підключаються нові мережі та провайдери, як змінюються правила без зупинки сервісу.

Кожен пункт передаємо з розбором на дзвінку та в записі — щоб черговий інженер міг діяти за документом, а не з пам'яті.

Кейс: як скоротили ручні розбори на потоці операцій

Клієнт — платіжний сервіс із потоком вхідних і вихідних переказів у кількох блокчейнах і зобов'язанням перевіряти джерело коштів за кожною адресою.

Скринінг було підключено, але він працював як «чорна скринька»: правила спрацьовували на весь трафік підряд, а рішення ухвалювали люди.

Що було до

Алерти падали в одну загальну чергу без пріоритету, і аналітики розбирали їх підряд. До 71% спрацьовувань виявлялися хибними: депозитні адреси великих майданчиків, гаманці самих клієнтів, легальний обіг через сервіси обміну.

Черга зростала швидше, ніж її чистили, а виплата клієнту чекала вердикту до 26 годин — за пікового навантаження довше.

Що змінили

Розвели потік за рівнями ризику й додали дедуплікацію: адреса з одного кластера більше не піднімала новий алерт щоразу. Довірені адреси та відомі сервісні гаманці перейшли в автоматичне закриття, а на розбір потрапили лише операції з непокритою історією.

Поріг спрацьовування налаштували за методикою оцінки кластерів — вона відкрито описана в матеріалах Chainalysis, а не виставлений «на око».

Ручні розбори впали майже в шість разів, строк виведення скоротився більш ніж на порядок.

Ключовий наслідок — на перевірку почали потрапляти операції, які справді цього потребують, а кожне рішення залишилося в журналі з обґрунтуванням: на запит від банку або регулятора вивантаження збирається за хвилини, а не за тижні листування.

Чим відрізняється вбудована перевірка від ручного розбору?

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

Щоб укластися в вікно обробки, оцінки кешуються, а звірка йде за вже розміченою базою атрибуції, без перерахунку кластерів на кожен запит.

Відкладена перевірка збирає операції в пакет і розбирає їх за розкладом або на запит — з повним кластерним аналізом на кілька переходів і розбором історії. Точність вища, але результат приходить із затримкою, а кожна знахідка лягає в чергу ручного розбору.

Вибір визначає точка контролю, а не зручність. У потоці перевіряють те, що не можна скасувати: зарахування, виведення, додавання адреси до білого списку.

Відкладено — періодичну перевірку клієнтської бази, розбір історії та вибірки для звітності, де важливіша повнота, ніж швидкість.

Навантаження на аналітика відрізняється на порядок. У потоці чергу формують лише спрацьовування вище порогу, типові випадки закриваються правилами автоматично — за налаштованих порогів до восьми з десяти спрацьовувань не потребують людини.

Відкладений розбір дає потік ручної роботи, пропорційний кількості операцій: кожну знахідку розбирає людина.

На практиці AML-скринінг криптовалют не зводиться до вибору одного режиму: потік закриває операції на вході та виході, відкладений розбір — глибину та періодичність. Ризик ловиться в момент операції, а час команди йде на неочевидні випадки, а не на механічну звірку.

Часті технічні питання щодо впровадження перевірки

Перед стартом інтеграції замовники ставлять одні й ті самі питання: вони стосуються не вибору сервісу, а стикування з працюючою інфраструктурою. Нижче — п'ять сумнівів, які найчастіше гальмують рішення.

Чи можна замінити аналітичний сервіс без втрати історії?

Зміна постачальника — це перенесення вердиктів, а не чисте встановлення. Звіряємо шкали ризику двох систем, спірні адреси перевіряємо вручну, щоб після міграції статус клієнтів не «поїхав».

Як відсікати хибні спрацьовування?

Міксери, адреси даркнету та частковий збіг за кластером дають шум. Налаштовуємо пороги та чергу розбору: частина випадків закривається автоматично за атрибутами, складні йдуть аналітику з готовим контекстом.

Що запитують банки та контрагенти?

Підтвердження походження коштів. Звіт формується у форматі, який приймає комплаєнс-служба контрагента, разом із журналом перевірок та історією вердиктів за адресою.

Куди йдуть дані клієнтів?

Назовні передається лише адреса або хеш операції, а не персональні дані. Вердикти, історія та журнал доступу залишаються у вашому контурі: рольова модель, строк зберігання та вивантаження за політикою.

Обговоримо задачу: які дані потрібні для оцінки та плану

Чим точніші вихідні дані на старті, тим менше припущень в оцінці. Нижче — мінімальний набір, після якого ми повертаємося з планом впровадження за етапами та строками робіт, а не з «уточнимо по ходу».

• Перелік мереж і активів: які блокчейни в роботі, включно з L2 та сайдчейнами, які токени й стандарти — від цього залежить покриття ризик-оцінки адрес.
• Типи операцій під перевірку: вхідні депозити, виведення, внутрішні перекази між клієнтами, P2P та обмінні сценарії.
• Поточна інфраструктура: де зберігається історія транзакцій і адрес клієнтів, чи є власні вузли або сервіс індексації, у якому вигляді ведеться облік.
• Політика ризику та пороги: з якого рівня ризику операція йде на ручну перевірку, хто ухвалює рішення і як фіксується обґрунтування.
• Вимоги аудиту та регулятора: склад звітності, строки зберігання даних, чи потрібні вивантаження в узгодженому форматі.
• Точки інтеграції та доступи: тестові ключі сервісу аналітики (наприклад, Chainalysis), доступ до тестового контуру, ролі для наших інженерів.
• Обмеження: санкційні списки, географія клієнтів, правила обробки персональних даних.

За цими пунктами ми оцінюємо обсяг, збираємо план впровадження й називаємо строки робіт. Опишіть задачу — повернемося з оцінкою та планом.