Користувач натискає «Оплатити» або «Вивести кошти» й очікує простого результату: успішно або відхилено.
Але всередині платіжної системи рішення часто виглядає значно складніше.
Одна й та сама транзакція може пройти автоматично за кілька секунд, а інша — потрапити на manual review. І справа далеко не завжди в сумі платежу.
Risk-команда оцінює не окрему операцію, а контекст навколо неї: хто користувач, як він поводився раніше, звідки прийшли кошти, який платіжний метод використовується, чи змінювалися реквізити та наскільки поточна поведінка відрізняється від звичайної.
Розберімося, як це працює.
Велика сума не дорівнює високому ризику
Одна з найпоширеніших помилок — вважати, що система просто має певний ліміт.
Наприклад:
до 10 000 грн — автоматично;
понад 10 000 грн — перевірка.
У реальних risk-системах усе зазвичай набагато складніше.
Транзакція на 50 000 грн від давно активного клієнта з підтвердженою особою та стабільною платіжною історією може виглядати абсолютно нормально.
Водночас платіж на 2 000 грн нового користувача може викликати значно більше запитань.
Тому правильніше говорити не про «ризикову суму», а про ризиковий контекст.
Що може бачити risk-команда
Залежно від продукту та платіжної інфраструктури набір даних відрізняється, але логіка часто однакова.
Історія транзакцій
Важливо не лише те, що користувач робить зараз, а й те, як він поводився раніше.
Наприклад:
скільки було успішних платежів;
скільки операцій відхилялися;
як часто змінюються платіжні методи;
які суми є типовими;
чи були повернення або chargeback;
як давно існує акаунт.
Якщо людина пів року регулярно проводить однакові операції, чергова схожа транзакція зазвичай не виглядає аномально.
А от різка зміна патерну може стати сигналом.
Зміна поведінки іноді важливіша за сам платіж
Уявімо користувача, який кілька місяців робив операції на 1–3 тисячі гривень.
Потім за один день він:
додає нову картку;
проводить кілька великих платежів;
змінює пристрій;
намагається швидко вивести кошти.
Кожен із цих факторів окремо може бути абсолютно нормальним.
Але їхня комбінація вже створює інший risk-профіль.
Саме тому антифрод рідко працює за принципом:
«побачили один поганий сигнал — заблокували користувача».
Частіше система аналізує сукупність факторів.
Платіжний метод та його власник
Один із найважливіших факторів — відповідність платіжного методу користувачу.
Наприклад, акаунт зареєстрований на одну людину, а платіж надходить з картки іншої.
Причина може бути цілком побутовою: картка чоловіка, дружини, родича.
Для користувача це може виглядати нешкідливо.
Для risk-команди ситуація виглядає інакше.
Вона повинна зрозуміти:
хто фактично проводить операцію;
кому належать гроші;
чи не використовується чужий платіжний інструмент;
чи не був акаунт переданий іншій людині;
чи не йдеться про шахрайську транзакцію.
Тому в деяких сервісах можуть попросити підтвердження картки, банківського рахунку або самої операції.
Чому іноді просять банківську виписку
Для користувача запит банківської виписки часто виглядає надмірним.
Але для risk-команди це може бути просто способом закрити конкретне питання.
Наприклад, потрібно підтвердити:
власника рахунку;
факт проведення транзакції;
дату та суму платежу;
зв'язок між банківським рахунком і користувачем;
походження коштів у межах додаткової перевірки.
Це особливо актуально у сферах із підвищеними фінансовими ризиками, де платежі перетинаються з KYC та AML-процесами.
Сам по собі запит документа ще не означає, що користувача підозрюють у шахрайстві.
Часто це просто спосіб отримати інформацію, якої не вистачає системі для прийняття рішення.
Що таке manual review
Manual review — це момент, коли автоматичної оцінки недостатньо і транзакцію передають людині.
Умовно процес може виглядати так:
Транзакція → автоматичні правила → risk score → додаткова перевірка → рішення
Аналітик дивиться на ширший контекст і намагається відповісти на просте питання:
чи можна безпечно дозволити цю операцію?
При цьому завдання risk-команди — не заблокувати якомога більше транзакцій.
Навпаки.
Якщо система блокує всіх підряд, бізнес швидко втратить нормальних клієнтів.
Тому хороший risk-management завжди балансує між двома проблемами:
fraud losses
та
false positives.
False positive — одна з найбільших проблем антифроду
False positive — це ситуація, коли нормальний користувач помилково виглядає підозрілим.
Наприклад, людина:
змінила телефон;
поїхала в іншу країну;
почала користуватися іншою карткою;
зробила незвично велику покупку.
Для алгоритму це можуть бути аномалії.
А для людини — звичайне життя.
Якщо антифрод занадто агресивний, бізнес отримує:
падіння конверсії;
більше звернень у support;
незадоволених користувачів;
довші платежі;
втрату клієнтів.
Тому якісна risk-система повинна не лише знаходити потенційний fraud, а й мінімізувати кількість помилкових блокувань.
Чому користувач часто не розуміє, що відбувається
Є ще одна проблема — інтерфейс.
Всередині компанії транзакція може пройти кілька етапів:
Created → Risk Review → KYC Review → Manual Review → Approved → Processing
А користувач бачить лише:
«В обробці»
Через годину статус той самий.
Через три години — теж.
Людина не знає:
чи платіж взагалі побачили;
чи потрібні від неї документи;
чи працює над операцією співробітник;
чи проблема вже на стороні банку або PSP.
У результаті навіть нормальна перевірка починає виглядати як проблема.
Тому хороший payment UX — це не лише швидкий процесинг.
Це ще й нормальне пояснення статусів.
Наприклад:
«Операція проходить додаткову перевірку. Від вас поки нічого не потрібно».
Для користувача така фраза набагато корисніша за безкінечне «Pending».
KYC, AML та anti-fraud — це не одне й те саме
Ці поняття часто змішують.
Якщо дуже спростити:
KYC відповідає на питання:
хто цей користувач?
Anti-fraud:
чи не виглядає ця операція шахрайською?
AML:
чи не створює фінансова активність ризиків, пов'язаних із походженням або рухом коштів?
На практиці ці процеси можуть перетинатися.
Наприклад, anti-fraud бачить нестандартну транзакцію.
Після цього виникає потреба повторно підтвердити користувача через KYC.
А якщо питання вже стосується походження значних коштів — може підключитися AML-перевірка.
У сфері онлайн-гемблінгу такі процеси особливо помітні під час великих депозитів та виплат. Просте пояснення того, як працює AML-перевірка та чому можуть запитувати додаткові документи, є на ГемблГід.
Чому автоматизувати все неможливо
Здається логічним: якщо є достатньо даних, нехай алгоритм сам приймає всі рішення.
Але в risk-management завжди залишаються нестандартні ситуації.
Правило може сказати:
використовується новий платіжний метод + велика сума = високий ризик.
А аналітик бачить:
користувач давно верифікований;
стара картка закінчила строк дії;
нова випущена тим самим банком;
ім'я власника збігається;
попередня історія не містить проблем.
Для автоматичного правила це набір тригерів.
Для людини — цілком логічна ситуація.
Саме тут manual review залишається корисним.
Хороший anti-fraud не повинен бути помітним
Парадокс у тому, що користувач майже не помічає якісної risk-системи.
Нормальні операції проходять швидко.
Дійсно ризикові отримують додаткову перевірку.
А сумнівні кейси потрапляють до аналітика замість автоматичного блокування.
Тобто мета risk-management — не створити максимальну кількість перевірок.
Мета — перевіряти саме там, де це дійсно потрібно.
І чим точніше система розуміє контекст користувача, тим рідше звичайна людина взагалі стикається з anti-fraud.
Що в результаті
Ручна перевірка платежу не означає автоматично, що користувач зробив щось погане.
У більшості систем це просто один зі способів працювати з ситуаціями, де алгоритму не вистачає впевненості.
Risk-команда дивиться не лише на суму.
Вона дивиться на історію, платіжний метод, поведінку, відповідність даних, попередні операції та інші сигнали.
І найкраща система — це не та, що блокує найбільше.
А та, яка вміє відрізнити реальний ризик від нормальної поведінки користувача, не вбиваючи при цьому конверсію та customer experience.
