Інтеграція Elliptic для AML-скринінгу транзакцій і гаманців

Інтеграція Elliptic: де ламається ручний AML-скринінг

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

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

Друга проблема — рішення не відтворювані. Ризик-бал адреси один оператор трактує як привід для ручного розбору, інший пропускає платіж, бо поріг «сірої зони» кожен тримає в голові.

Один і той самий гаманець проходить на ранковій зміні й застрягає на нічній — не через рівень ризику, а через те, хто сидів на перевірці.

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

У сумі це три класи витрат: простій у черзі виведення, розмиті критерії та доказовість, яку важко пред’явити банку-партнеру. Інтеграція Elliptic закриває їх не гаслом «прискоримо операторів», а переведенням AML-скринінгу транзакцій в автоматичний контур із фіксованим результатом. Розбираємо, як це влаштовано і де свідомо залишається ручне рішення.

Що змінюється після впровадження: швидкість, ризик, звітність

Частка ручних перевірок падає до цільового порогу

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

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

Час обробки виведення скорочується до одного циклу

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

Журнал рішень закриває питання аудиту

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

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

Історія перевірок транзакцій зберігається на будь-яку глибину

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

Порівняння підходів: ручний контроль, власний реєстр, готовий сервіс

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

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

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

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

Як проходить інтеграція Elliptic: етапи робіт

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

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

Етапи впровадження скринінгу

1. Аудит потоків та інвентаризація адрес. Збираємо карту клієнтських, кастодіальних і гарячих гаманців, позначаємо потоки через проміжні адреси та контракти.
2. Проєктування точок перевірки транзакцій. Фіксуємо, що перевіряється на вході, на виведенні та у фоні: вхідний депозит, вихідний переказ, зміна адреси в особистому кабінеті.
3. Налаштування порогів ризик-балу. Низький бал проходить автоматично, середній іде на ручний розбір, високий блокує операцію до рішення відповідального за комплаєнс.
4. Автоматичні дії за адресою. Прописуємо політики: позначка в базі, обмеження виведення, блокування, повторний скринінг за розкладом.
5. Інженерна обв’язка. Асинхронна черга запитів, повторні спроби при недоступності сервісу, сховище вже перевірених адрес, журнал усіх рішень для аудиту.
6. Випробування на реальних даних. Проганяємо історичні транзакції, вимірюємо частку хибних спрацьовувань і калібруємо пороги під ваш профіль клієнтів.
7. Передача в експлуатацію. Регламенти ручного розбору, панель моніторингу, інструкції для підтримки, порядок оновлення правил.

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

Що залишається у команди замовника після запуску

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

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

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

Кейс: зниження частки ручних перевірок і часу відповіді

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

Що було до впровадження

За зміну надходило 400–600 запитів на перевірку, і вони накопичувалися: одна й та сама адреса переперевірялася повторно, якщо траплялася в іншому платежі.

Автоматика закривала близько 38% випадків, решта висіла в черзі — середній час відповіді клієнту становив 6–8 годин, у пікові дні доходило до доби. Основний клас відмов був не про заборону, а про мовчання: користувач бачив «виведення в обробці» і не розумів, чого чекати.

Що змінили і що це дало

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

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

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

Частка автоматичних рішень зросла з 38% до 91%, середній час відповіді за спірними операціями скоротився з 6–8 годин до 12–20 хвилин. Ручних перевірок стало вчетверо менше, а звернень у підтримку на тему «де моє виведення» — втричі.

Окремий ефект — зник клас відмов-сюрпризів: клієнт отримує причину та посилання на рішення, а не тиху затримку.

Чим відрізняється блокування адреси від зниження ризик-балу

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

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

У Elliptic і подібних джерелах скорингу адреса отримує числову оцінку за сукупністю ознак: близькість до міксерів, зв’язок із санкційними переліками, кількість «рук» від джерела коштів.

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

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

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

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

Технічні сумніви перед підключенням скринінгу

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

Що вважається частковим ризиком адреси?

Відповідь надходить не «чисто чи брудно», а з часткою ризику та ознаками, з яких вона зібрана: зв’язок із міксером, потрапляння до санкційного переліку, контрагент без процедур перевірки.

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

Які дані клієнтів ідуть назовні?

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

Хто відповідає за хибні спрацьовування?

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

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

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

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

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

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