Как мы запускали и калибруем риск-триггеры Часть 1.

Мы разработали и запустили в работу пакет из семи риск-триггеров для контроля входящего платежного трафика. Их цель на данном этапе — не автоматическая блокировка операций, а фиксация аномалий и выделение транзакций с потенциальными признаками фрода

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

Сценарии, заложенные в основу триггеров Каждый триггер создавался под фиксацию конкретного типа аномалии в режиме реального времени. Мы выделили семь основных платежных метрик:

• Высокая частота пополнений за короткий временной интервал

• Аномальная активность учетных записей с минимальным возрастом аккаунта

• Серийные попытки платежей с одного идентификатора устройства

• Перекрестные связи между несколькими аккаунтами при пополнении

• Цепочки отказов по операциям, завершающиеся успешной оплатой

• Резкое отклонение объемов пополнения от исторического профиля пользователя

• Нетипичные сочетания сумм, частоты и используемых платежных инструментов

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

Этап предварительной проверки на исторических выгрузках Перед переносом в продакшен-контур логика работы каждого триггера тестировалась ретроспективно на исторических данных из базы. На этапе бэктестинга оценивались следующие параметры:

• Ожидаемый объем суточных срабатываний и часы пиковых нагрузок на систему

• Пересечение с уже существующими методами мониторинга (фиксирует ли триггер новые аномалии)

• Влияние потенциального входящего потока задач на текущий SLA команды ручного разбора

• Точность сопоставления: проверка того, чтобы запрос на выгрузке и антифрод-движок обрабатывали временные окна, статусы транзакций и связи между сущностями абсолютно идентично.

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

Широкий охват на старте позволяет собрать репрезентативную базу примеров, увидеть реальное поведение клиентов и зафиксировать стартовую долю подтвержденного фрода в общей массе срабатываний. Это не показатель того, что триггеры работают неверно, а необходимый этап накопления данных

Как сейчас проходит калибровка триггеров Анализ общей эффективности полезен, но мониторинг требует разбора каждого маркера в отдельности. Мы оцениваем характер выявляемых аномалий, объем ложных срабатываний и влияние изменения порогов на точность детекции

Параметры триггеров корректируются точечно:

• Изменяются лимиты по суммам и длительность временных окон

• Вводятся исключения для доверенных подсетей и белые списки

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

Вывод

Запуск триггеров в режиме наблюдения (Shadow Mode) позволил нам подсветить слепые зоны в платежном трафике без риска заблокировать честных пользователей. Наша цель сейчас — не искусственно снизить объем срабатываний, а поэтапно повышать точность каждого из семи индикаторов

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