Как мы прокачивали анти-фрод

Упростив жизнь внутренних сотрудников
и сократив финансовые потери

Как мы прокачивали анти-фрод

Продукт

BackOffice продукт — Pays, в котором работает платежный отдел. Занимаются обработкой платежей, скорингом клиентов и анти-фродом

Контекст

Основным триггером стал запуск продукта в новом регионе. Проведение большого количества маркетинговых кампаний, раздача халявы и многократный прирост новой аудитории

«За первые три месяца после запуска в новом регионе количество подозрительных аккаунтов выросло — в 4 раза. Очередь на проверку увеличилась до двух дней, а ~30% аккаунтов с бонусхантингом обнаруживалось уже после использования бонусов»

Проблемы

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

Все это порождало:

Потери бюджета маркетинга на мультиаккаунтах

Потенциальный рост операционных расходов

Обход блокировок
и ограничений

Ухудшение опыта честных клиентов

Финансовые потери

Сейчас пользователи

Вручную по косвенным причинам сравнивают данные в разных разделах

Инсайты

Пообщавшись с отделом платежей, старшими и рядовыми сотрудниками выявил, что:

Существуют аккаунты для:

1) Фарма бонусов
2) Обхода ограничений и блокировок

3) Создания вилок

Сейчас анти-фрод существует, как параллельный «поломанный» сценарий в рамках обработки заявок и скоринге клиентов

Каждый клиент рассматривается, как уникальный случай

Не все клоны невыгодны компании

Не на всех клонов накладываются ограничения

  • В разделе заявок отображаем триггер у конкретных заявок

    Показываем триггер
    в карточке заявки
    с новым разделом

    Выводим саммари
    по совпадениям клиентов

    Пользователь видит результаты и принимает решение

    Накладывает
    ограничения

    Присваивает новую метку

    Имплементация в сценарий заявок

  • В разделе клиентов отображаем триггер у конкретных клиентов

    Показываем триггер
    в карточке клиента
    с новым разделом

    Выводим саммари
    по совпадениям клиентов

    Пользователь видит результаты и принимает решение

    Накладывает
    ограничения

    Присваивает новую метку

    Имплементация в сценарий скоринга

Валидация

Решения прошли несколько этапов модерируемых тестов →
выявил финальный скоуп

Добавляем несколько триггеров

Имплементируем сценарий анти-фрода
в текущие сценарии

Создаем единую точку входа

Создаем новую метку

Проводим всю работу за пользователя — выдаем саммари

Решение

В персональной карточке клиента сделал новый раздел «Клоны»
с триггером по количеству совпадений c другими клиентами

Решение

Имплементировал триггеры в разделы с ключевыми сценариями пользователей — обработкой платежей и скорингом клиентов. Сценарий стал бесшовным

Имплементировал триггеры в разделы с ключевыми сценариями пользователей — обработкой платежей и скорингом клиентов. Сценарий стал бесшовным

Разбил раздел на «поисковик совпадений» и хранилище клонов. В таблице маппим данные по ключевым параметрам — из выборки подсвечиваем совпадения и общий процент метча клиентов

Разбил раздел на «поисковик совпадений» и хранилище клонов. В таблице маппим данные по ключевым параметрам — из выборки подсвечиваем совпадения и общий процент метча клиентов

Сделал добавление клона через контекстное меню с диалогом
и логированием причины для истории клиента

Сделал добавление клона через контекстное меню с диалогоми логированием причины для истории клиента

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

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

Результаты

Спустя две недели после запуска получили:

Медиана времени проверки

Было

18 мин

Стало

6 мин

AVG от появления клона до принятия решения

Было

~2 дня

Стало

~2 часа

Меток «клон» у клиентов

+10к

Таргетных ограничений клиентов

+28к

Потери от бонусхантинга на 1 000 участников акций

-18%