Часть 2. Жизненный цикл антифрод-правила: от гипотезы до продакшена

Когда наши риск-триггеры собрали достаточно данных и прошли первичную калибровку, мы начинаем формировать на их основе полноценные риск-правила. Запуск правил с жесткими действиями напрямую влияет на бизнес-метрики: ошибка в коде может либо пропустить атаку, либо заблокировать тысячи легитимных клиентов (False Positive)

Чтобы минимизировать риски, мы стандартизировали процесс перевода триггеров в статус правил и разбили его на четкие этапы

Как мы формализуем и описываем правила

На этом шаге мы объединяем калиброванный триггер с дополнительным контекстом и переводим логику на язык математических условий или SQL-запросов. Наша задача — максимально ограничить область действия правила, чтобы не зацепить нормальных пользователей

В каждое правило мы закладываем три обязательных компонента

• Триггер: событие, которое запускает проверку (например, клик на кнопку «Купить»)

• Условия: набор фильтров и параметров (возраст аккаунта, совпадение IP/ASN, история клиента)

• Вес или действие: финальное решение системы — пропустить (Allow), отправить на дополнительную проверку (Challenge/Step-up) или заблокировать (Deny)

Тестирование на исторических выгрузках (Backtesting)

Мы никогда не выкатываем правила в продакшен в активном режиме сразу после написания кода. Сначала мы запускаем их ретроспективно на выгрузке логов из нашей базы за последние 30–90 дней

Этот тест помогает нам ответить на два главных вопроса:

• Эффективность (Catch Rate): видит ли наше новое правило те атаки, которые действительно происходили у нас в прошлом?

• Уровень шума (False Positive Rate): сколько реальных клиентов мы бы заблокировали, если бы это правило работало тогда в реальном времени?

Если исторический тест показывает высокий уровень ложных срабатываний, мы оптимизируем параметры: сужаем условия, добавляем исключения (белые списки) или комбинируем правило со смежными триггерами

По какому чек-листу мы переводим правило в активный статус

Автоматические блокировки включаются только после того, как логика докажет свою точность на практике. При переходе от тестов к активным действиям мы ориентируемся на пять основных технических параметров:

1. Правило стабильно находит подтвержденный фрод с приемлемым уровнем ложных срабатываний

2. Оно не дублирует смежные триггеры и находит уникальные кейсы, которые мы раньше пропускали

3. Поток задач от этого правила не превышает возможности нашего текущего штата аналитиков

4. Логика понятна и однозначно интерпретируется при аудите конкретного кейса

5. Движок антифрода обрабатывает это правило на реальном live-потоке без инфраструктурных задержек

Поэтапный раскат (Rollout) и регулярный пересмотр

После успешных тестов мы переводим правило в активный режим, но раскатываем его постепенно. Сначала включаем логику только на небольшой процент случайных пользователей (например, 5–10%), затем тестируем на отдельных сегментах трафика и только при стабильных метриках выводим на 100% нашего live-потока

Мошенники постоянно адаптируются и меняют паттерны, как только натыкаются на наши блокировки. Поэтому мы не оставляем правила работать вечно в исходном виде. Мы регулярно проводим аудит на предмет деградации точности: устаревшие правила, которые перестали собирать фрод, но продолжают нагружать систему, мы своевременно отправляем в архив.

Наш главный вывод

Мы не можем настроить антифрод один раз и забыть о нем. Для нас безопасность — это процесс постоянной проверки гипотез

Переход от простой фиксации аномалий (триггеров) к автоматическим блокировкам (правилам) всегда требует от нас бэктестов и проверки в теневом режиме. Только так нам удается вовремя ловить новые схемы мошенничества и при этом не мешать нормальным клиентам пользоваться сервисом

МЕНЮ

В этом посте были ссылки, но мы их удалили по правилам Сетки