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

Движок правил, який ухвалює рішення. Правило можна перевірити на історичних даних, запустити в тіньовому режимі (рахує, але не впливає на результат) і лише потім увімкнути в бойовому. Стартовий набір — 41 правило, перенесене з Covery. На переданому пілотом наборі (150 підтверджених шахраїв і 145 чесних гравців) рішення збіглися з Covery у 93% випадків.

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

Розпізнавання пристрою: система бачить, що за новим акаунтом стоїть той самий пристрій, навіть якщо змінено всі дані й увімкнено VPN. Скрипт для сайту клієнта займає 16 КБ при бюджеті 30 КБ. Повний замір якості розпізнавання на реальному трафіку потребує ліцензій на бази IP-адрес — вони ще не придбані.

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

Частина правил спирається на поведінку гравця за останні 30 днів, але накопичення цієї статистики ще не увімкнене в робочому середовищі — тому такі правила поки не впливають на рішення. Фаза вмикає накопичення, зберігає обґрунтування кожного рішення (аналітик бачить, чому подію заблоковано), виводить збої оцінки в сповіщення і підключає перевірку IP-адрес. Завершується контрольним заміром якості детекції на робочому середовищі — перед підключенням пілота.

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

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

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

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

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

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

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

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