Привет, Хабр! На связи Владимир Сыропятов, Senior Analyst в Garage Eight. Все же в детстве слушали сказки? Так вот, я бы хотел вспомнить одну из них — про мальчика и волков. В ней ребенок так часто зря кричал «Волки!», что жители деревни перестали реагировать на предупреждения. А когда волки пришли по-настоящему, ему никто не поверил.
Я это всё к тому, что в антифроде эта история повторяется регулярно, только вместо мальчика — система мониторинга, вместо деревни — операционная команда, а вместо волков — реальный фрод, который незаметно «подкрадывается», пока все заняты ложными тревогами. Именно такую картину я обнаружил на одной из платформ для управления инвестициями, когда пришел туда как антифрод-аналитик.
В статье расскажу, как перегруженная система мониторинга привела нас к модели превентивного поиска мошенников через граф связей.
Акт первый: система против самой себя
Что меня ждало на месте
Как только я присоединился к команде инвестиционной платформы, я стал изучать устройство системы мониторинга. Она выглядела довольно солидно: десятки правил под каждый известный критерий фрода — от крупных выводов средств и нетипичной активности до смены реквизитов и аномальной частоты операций. Под каждую конкретную угрозу существовало свое технически корректное правило.
Если в поведении пользователей прослеживались определенные паттерны, в систему поступали алерты. Но поскольку все критерии были в полной изоляции друг от друга, в общей очереди они появлялись отдельно.
Например, если система считала пользователя подозрительным по четырем признакам, она отправляла оператору четыре алерта вместо одного со всеми критериями внутри. Чтобы понять, что речь идет об одном и том же случае, нужно просматривать все строки — никто, конечно же, этого не делал. Да и очередь не располагала. Хотя если бы оператор видел сразу все нарушенные пользователем правила, он мог бы принять другое решение.
Часть критериев пересекалась друг с другом. Представьте: один критерий триггерит крупный вывод, другой — вывод выше среднего исторического значения по конкретной платежной системе. Для клиента с большим средним чеком алерт бы сработал дважды, что только увеличило бы очередь запросов.
Были и неактуальные исторически сложившиеся правила: например, верифицированный клиент с историей больше года автоматически получал сниженный фрод-приоритет на ряд критериев, потому что его уже считали надежным. Но в таком случае система упускала одну очень важную деталь: мошенник может завладеть любым аккаунтом, даже если пользователь пять лет работает с платформой. Так у злоумышленника появлялся шанс временно укрыться от системы мониторинга.
Что происходило с командой
Операционный департамент каждый день получал, казалось, бесконечный поток алертов, которые приоритизировались только по субъективным критериям операторов. С утра команда зарывалась в очередь, разбирала всё, что накопилось за ночь, — фактически работала в авральном режиме, особенно после праздников и крупных событий. При этом в течение дня нагрузка была нерегулярной.
Оперативно обрабатывать все алерты было физически невозможно, поэтому у команды выработалась неформальная стратегия — в первую очередь разбираться с тем, что кажется опаснее. Вначале обращать внимание на большие суммы, если остается время — на знакомые паттерны, а дальше уже на непривычные алерты. Но до последних руки часто не доходили, а в некоторых случаях именно они могли быть самыми серьезными, даже если на первый взгляд, в отрыве от других критериев, так не казалось.
Почему нельзя просто почистить алерты
Когда видишь такую перегруженную систему, первым делом хочется ее почистить: убрать дубли, поднять трешхолды, добавить фильтры. Я сам чуть не пошел этим путем, но меня остановила одна деталь: кто-то когда-то заметил конкретный паттерн фрода и написал правило именно под него. Именно поэтому, например, если поднять трешхолд, можно пропустить пограничные кейсы.
Чистка помогла бы снизить шум, но не решила бы главную проблему — нерегулярный поток задач с локальными пиками. Сотрудники то сидели практически без работы, то зашивались с очередью — и по-прежнему узнавали бы о фроде уже постфактум, в лучшем случае в момент инцидента, и снова разгребали бы завал в авральном режиме. Нужно было думать, как изменить логику алертов в целом.
Акт второй: от алертов к графу
Когда произошел переломный момент
Я стал разбирать подтвержденные фродовые кейсы (те, что уже расследовали и закрыли) и начал замечать паттерн. Мошенники редко действовали в полной изоляции: у фродера почти всегда находились пересечения с другими клиентами. По отдельности они ни о чём не говорили, но в совокупности складывались в понятную мошенническую схему.
Я задался вопросом: а если не ждать, пока эти связанные клиенты станут подтвержденными фродерами, а находить их заранее и проверять до того, как те успеют реализовать свои мошеннические схемы и превысить трешхолды алертов?
Как работает система
В итоге я перенастроил систему мониторинга. Теперь, когда какой-то клиент получает статус подтвержденного фродера, алгоритм ищет всех, кто имел с этим клиентом пересечения. Алгоритм работает по набору параметров, которые я определил как маркеры связи — комбинацию признаков, которая отличает значимую связь от случайной.
Найденные клиенты не получали статус фродеров автоматически: они попадали в очередь на превентивную проверку. У каждого был свой контекст: откуда взялся кейс, с кем нашлись пересечения, по каким параметрам. Операционная команда просматривала таких клиентов и сама принимала решение, фродер перед ней или нет.
Важно, что такие кейсы не создают пиковой нагрузки: они накапливаются в системе и распределяются равномерно — команда просматривает их в плановом режиме. От этого меняется и качество разбора: оператор принимает более взвешенные решения, а не пытается сделать хоть что-то, лишь бы разгрести завал до конца смены. Далее мы анализируем результаты работы операторов по найденным кейсам и на их основе повышаем точность модели.
Что изменилось
Результатов оказалось несколько, и не все из них мы предвидели:
Исчезли пики нагрузки. Вместо 200+ алертов утром, которые нужно было срочно разгребать, мы выстроили равномерный поток кейсов. Команда перестала начинать день в режиме аврала.
Качество проверок выросло. Оператор видит не изолированный алерт, а всю историю. Он понимает, откуда кейс появился, с кем связан исходный фродер и почему система решила, что связь значимая. Сотруднику интересно распутывать такой клубок и проводить собственное расследование.
Система начала находить фрод на упреждение. Часть клиентов из превентивной очереди оказалась мошенниками — и проверка помогла предотвратить инциденты до того, как они превысили пороги.
Появилась обратная связь для модели. Основываясь на работе операторов, мы меняем критерии и их веса для модели, тем самым увеличиваем ее точность. Именно поэтому каждый подтвержденный кейс из превентивной очереди помогает совершенствовать принципы работы модели.
Акт третий: главное о таком подходе
Хотелось бы обратить внимание на самые важные моменты:
-
Качество системы полностью зависит от качества исходного кейса. Если подтверждение фродера было ошибочным, запускается волна проверок от ложной точки. Чтобы это предотвратить, нужно задавать высокие стандарты верификации исходного кейса — нетривиальная задачка.
-
Нужно постоянно проверять полноту и точность модели. Полноту мы отслеживаем на исторических кейсах, которые выявили ранее вручную и автоматически. А точность контролируем с помощью дополнительной проверки кейсов, которые модель находит через операторов.
-
Пересечения бывают случайными. Часть кейсов из превентивной очереди окажется false-positive, и это нормально. Важно, чтобы этот процент оставался приемлемым и не создавал лишней нагрузки на команду.
Эпилог
Мошеннические схемы чаще всего имеют характерные черты: похожие методы, общие инструменты, иногда прямые связи между участниками. Если найти точку входа, появляется возможность раскрутить весь клубок фрода. Благодаря превентивному подходу вы будете искать не симптомы проблемы, а потенциальные условия, при которых она может проявиться.
И давайте вернемся к сказке про мальчика. Если бы он не кричал «Волки!» по поводу и без, а изучил следы и заранее расставил ловушки, история закончилась бы иначе. Так мы и поступили: перестали кричать «Волки!» после каждого алерта и начали искать волчьи тропы.
Если работали с похожими задачами, интересно обсудить их в комментариях. Особенно вопрос про масштабирование графа: где проводите границу? Как не дать превентивной очереди разрастись до тех же размеров, что и старая система алертов?
ссылка на оригинал статьи https://habr.com/ru/articles/1051030/