Всем привет! Меня зовут Иван Логинов, я аналитик данных в команде антифрода в Авито. Антифрод — направление на стыке бизнеса, продуктовых команд, пользователей и юридических ограничений, где любое решение требует тонкого баланса.
Рост продукта неизбежно увеличивает риски: чем масштабнее продукт, тем выше вероятность фрода. Задача антифрода — контролировать уровень этих рисков и не тормозить развитие бизнеса. Например, антифрод-системы нашей компании обрабатывают 50 миллиардов действий ежедневно — это огромное количество.
Для пользователей антифрод — это одновременно защита и источник потенциального негатива из-за санкций. При этом точное и быстрое воздействие на недобросовестных участников напрямую повышает доверие к платформе.
В статье разберу требования к антифрод-системам и шаги, которые помогают удерживать баланс между безопасностью, ростом и требованиями законодательства. Текст будет полезен аналитикам, разработчикам, которые работают с подобными системами, а также тем, кто только подступается к таким задачам.
Содержание:
Зачем продуктам антифрод-системы и какие сценарии они закрывают
Явные и неявные связи антифрода с бизнесом: в чём разница и как это влияет на требования к АС
Зачем продуктам антифрод-системы и какие сценарии они закрывают
Краткий ликбез по терминам. Антифрод-система (АС) — это алгоритм или фреймворк, направленный на противодействие определённому типу фрода в определённом наборе продуктов.
Глобально у нас есть две мотивации для проектирования АС — мы предполагаем, что в каком-то продукте ещё на этапе проектирования есть слабые места с точки зрения антифрода или уже случился кейс какого-то фродового сценария. Разумеется, основная цель антифрод-команд — не допускать второй случай.
В зависимости от сценария нужно провести следующие шаги:
Сценарий: как закрывать потенциальные уязвимости
Определить продукт.
Чётко сформулировать уязвимость.
Разработать гипотезы, которые позволили бы её нивелировать.
Собрать архитектуру решения.
Создать техническое решение сбора данных.
Создать техническое решение обработки данных.
Создать систему логирования.
Настроить мониторы и алерты.
Сценарий: как закрывать конкретные фродовые кейсы
Чётко сформулировать уязвимость и её критичность.
Разработать гипотезы, которые позволили бы её нивелировать.
Если уязвимость критичная — разработать и интегрировать быстрое решение.
Разработать и интегрировать целевое решение.
Теперь рассмотрим требования к каждому этапу, в которые мы стремимся попасть при разработке АС.
Явные и неявные связи антифрода с бизнесом: в чём разница и как это влияет на требования к АС
Все связи антифрода и бизнеса можно разделить на две части.
В случае явных связей мы говорим о кейсах фрода, которые напрямую влияют на выручку компании. Например, попытки обхода какой-либо монетизационной услуги с фиксированной платой.
Здесь точность детекта будет приоритетнее, чем полнота. Это обуславливается тем, что любой задетектированный кейс приносит деньги компании, однако любая ошибка значительно влияет на пользовательский опыт.
Кейсов фрода с неявными связями гораздо больше — тут и межпользовательское взаимодействие, и монетизационные механики с неявной оплатой, и кейсы фрода, когда бизнес несёт юридические риски.
Как и кейсы, подходы к проектированию АС тоже могут быть разными и зависят от рисков. Если фрод связан с коммуникацией пользователей или юридическими рисками, то полнота нашего детекта будет важнее.
Задача по оценке влияния фрода на бизнес в большинстве случаев не решается очевидными способами и требует разработки либо прокси-метрик, либо реализации нестандартных математических подходов.
Например, вот базовый набор метрик, на которые стоит смотреть при различных фродовых сцерариях:
наиболее подходящая денежная метрика;
коэффициент оттока (Churn rate);
частотность происхождения фродовых сценариев.
Разумеется, метрики выше не могут обеспечивать показатели работы антифрода в 100% случаев, поэтому аналитикам, которые борются с кейсами фрода, часто нужно разрабатывать неочевидные метрики и пути анализа влияния на бизнес. Но это тема для отдельной статьи.
Три главных требования к антифрод-системам
Попробуем рассмотреть все особенности на конкретном примере. Предположим, у нас есть магазин игрушек и перед нами стоит задача обеспечить безопасность нашего бизнеса.
При проектировании АС пойдём от важных нефункциональных требований. Условие и основные требования для такого кейса:
В нашем магазине завёлся вор, который крадёт мягкие игрушки. Очевидное решение — поставить камеры, вычислить вора и в момент, когда он снова придёт в магазин, поймать его.
Но если воров несколько? А если он не вернётся в магазин или он мастер маскировки? В таком случае наша основная цель — построить меры, которые работают не постфактум, а в момент совершения фродовой операции. Отсюда вытекает наше первое требование.
Производительность. Из-за того, что наши меры должны срабатывать не после операции, а во время — практически во всех АС real-time проверки сущностей — это nord star.
Однако любая такая разработка требует достаточно много времени на реализацию и, как следствие, воры смогут вынести все мягкие игрушки из магазина, пока мы развиваем решение.
Следовательно, на этапе MVP будет полезно разработать решение, которое будет работать в офлайн-режиме. Этим мы закрываем ряд важных задач: определяем, эффективны ли наши алгоритмы, снижаем потери бизнеса и выигрываем время на разработку целевой АС, так как ворам придётся менять своё поведение — маскироваться или привлекать ещё ресурсы.
Допустим, в нашем магазине игрушек воры похищают конкретно мягкие игрушки гусей. На это может влиять несколько факторов: стеллажи с ними расположены близко к выходам, они дороже стоят или их легче продать.
Кажется логичным сосредоточить защиту на конкретном стеллаже. Но что делать, если воры начинают забирать игрушки ещё и с других полок? Здесь нам поможет второй критерий.
Масштабируемость. Поскольку фродеры постоянно адаптируются к мерам защиты, ищут новые уязвимости и маскируются под честных пользователей, архитектура антифрод-системы должна быть масштабируемой:
вширь — под новые фрод-кейсы,
вглубь — под изменения уже известных сценариев,
операционно — под рост количества кейсов во времени.
Ну и, конечно, не можем допускать ситуаций, когда мы пропускаем фродовые кейсы из-за отказов или сбоев системы. Поэтому она должна быть надёжной.
Надёжность. Это базовое требование для любой антифрод-системы. Каждый пропущенный фрод-кейс увеличивает риски для компании.
Основные подходы к проектированию систем антифрода
Чаще всего они строятся сверху вниз: сначала формируется целевое видение, затем решение разбивается на блоки, расставляются приоритеты и составляется план работ.
Поскольку антифрод-система — почти всегда продолжение продуктовой системы, такой подход позволяет видеть решение целиком, снижать риски интеграции и заранее учитывать, как может измениться поведение недобросовестных пользователей.
На примере магазина зададим основной вектор антифрод-системы. В качестве базовой задачи по-прежнему рассматриваем противодействие воровству товаров. Целевое видение в этом случае — система, которая в реальном времени выявляет потенциальных нарушителей и не даёт им возможности совершить кражу.
Далее эта задача декомпозируется на следующие части:
Определить, какие данные нам нужны для построения системы: записи с камер, рамки детекта и тому подобное.
Разработать алгоритмы обработки данных.
Разработать эффективные санкции. Вариантов может быть множество: от общения с нарушителем до запрета на посещение магазина.
Оценить время на разработку каждой части.
В отдельных случаях разработка ведётся снизу вверх — как правило, это происходит при постепенном наращивании количества кейсов, закрытых простыми и недорогими алгоритмами.
Чем антифрод-системы отличаются от классических продуктов
При проектировании АС мы всегда должны учитывать, что наше влияние будет распространяться на 2 типа пользователей: условно «хороших» и условно «плохих».
Следовательно:
любые метрики качества нашей системы должны учитывать оба сегмента;
«хороших» пользователей всегда будет больше, чем плохих. Это вносит дисбаланс классов при обучении ML-моделей;
любая антифрод-система будет терять свою актуальность. Это может быть связано как с её эффективностью — злоумышленникам просто становится невыгодно вести свою деятельность на площадке, и фрод прекращается.
Так и с потерей её эффективности — пользователи обходят правила или модели, и защита становится слабой. Чтобы такого не происходило, любая система должна иметь развитую систему логирования и мониторов.
Подозрение на фрод — чувствительная тема для любого пользователя. И одно из лучших решений для минимизации влияния антифрода на «хороших» пользователей — это ручная модерация. Такой ресурс, очевидно, ограниченный и стоит достаточно дорого. Альтернативой, например, может стать хорошо обученная LLM-модель.
А теперь про общие отличия от продуктовых команд:
АС в 99% случаев требует нестандартного решения. Если продуктовые команды во многом могут полагаться на А/Б-тесты и стандартные метрики, то антифрод-команды достаточно часто ищут новые подходы как для построения АС, так и для их дальнейшего развития;
АС очень часто работает с большим количеством данных, вследствие чего для разработки требуется хранилище данных или налаживание связей с другими системами;
для АС почти всегда остро стоит вопрос быстродействия.
Пайплайн разработки антифрод-системы и наши метрики
Разработка сверху вниз — всегда нетривиальная задача.
1. Для построения пайплайна мы стремимся ответить на следующие вопросы:
Кто целевой объект нашего воздействия сейчас и кто может быть им в будущем?
Возвращаясь к нашему примеру с магазином, кажется очевидным, что объектом воздействия должны стать покупатели, и вот мы ставим охранников, которые обыскивают всех потенциальных нарушителей.
Но если мы замечаем, что кража происходит только около отдельных стеллажей или отдельных игрушек? Тогда изменение объекта воздействия с покупателей на сами игрушки может положительно сказаться на наших покупателях. Мы улучшим пользовательский опыт, снизим косты на систему противодействия, так как избавимся от охранников в пользу магнитных защит, и повысим качество взаимодействия.
Аналогично примеру выше АС должна быть масштабируема на анализ различных сущностей.
Какие кейсы текущего или потенциального фрода мы планируем закрыть системой?
Охранники на входе нашего магазина могут помочь не пропустить воров, которые заходят через дверь, но не будут справляться, если воры будут забираться через окно.
Камеры в зале могут детектировать преступников, однако не будут накладывать никаких санкций. Закрытые окна и двери предотвратят любой фрод, но бизнес не будет зарабатывать. Таким образом, АС должна отвечать на 4 важных вопроса:
Какой фрод мы хотим победить.
Как мы хотим его детектировать.
Как мы хотим его победить.
Как это повлияет на бизнес.
Какой экономический эффект мы ожидаем в перспективе?
Ответ на этот вопрос важен, чтобы обосновать бизнесу работу антифрода. В частности, бывают случаи, когда фродеры даже увеличивают выручку — например, если в нашем магазине игрушек они начнут продавать сигареты. Скорее всего, оборот магазина вырастет, но юридические риски того не стоят.
Какие логические блоки нужны в первую очередь?
Для ответа на этот вопрос необходимо понимать качество предлагаемого детекта и эффективность вариантов устранения фрода. Так, для проблемы воровства игрушек отлично подойдут магниты + рамки, а против намеренной порчи — камеры и охранники.
Насколько быстро нам это нужно?
Всегда стоит стремиться к наилучшей системе защиты, однако иногда даже самая примитивная оборона может сохранить компании миллиарды рублей.
2. Также важно выделить сегменты нашего воздействия. На все вопросы выше невозможно ответить, не согласуясь с влиянием наших действий на различные когорты пользователей. В общем случае можем выделить два сегмента: «плохих», то есть фродеров и «хороших» — тех, кто ведёт себя целевым образом на площадке. Разрезы «плохих» и «хороших» пользователей очевидным образом должны быть согласованы с нашими действиями.
Ссегмент «хороших» не должен замечать наших действий, то есть точность нашего воздействия должна стремиться к 100%, а сегмент «плохих» должен в полной мере ощущать влияние антифрода — полнота также должна стремиться к 100%.
Конечно, такой утопичный сценарий невозможен, но мы можем сформировать метрику:
Где А и B — некоторые коэффициенты влияния ошибок первого и второго рода. Их значения могут подбираться на основании различных принципов: сложившейся практики, консенсуса со стороны команды аналитиков, UX-исследований, проведённых А/Б или иных оценок влияния. На основании этой формулы смещаются акценты в сторону точности или полноты.
Фрод в продуктах быстро меняется, чтобы обходить защиту. Поэтому антифрод-система должна быть готова к внедрению новых эвристик, моделей или способов сбора данных. Обычно это достигается через продуманную архитектуру сервиса и декомпозицию системы на логические блоки.
Хотя создание real-time АС кажется очевидной целью, это требует больших затрат на разработку, анализ и логирование. В большинстве случаев для проверки работоспособности достаточно анализа данных в офлайн-режиме.
Что в итоге
Построение антифрод-систем — нетривиальная задача для любого аналитика или инженера. Нужно учитывать множество мелочей: от способов получения данных до объектов воздействия. Следить за множеством метрик: от бизнесовых до поведенческих. Дополнительная сложность — потенциальные фродеры всегда стремятся менять своё поведение, чтобы АС потеряла свою эффективность.
Исходя из всего этого можно сказать, что работа в антифрод-команде требует постоянного исследовательского процесса и формирования нестандартных аналитических или технических подходов. Это позволяет всем участникам команды расти профессионально и минимизирует рутинные и скучные процессы.
Ещё больше о работе разных аналитиков в Авито читайте в телеграме: «Коммуналка аналитиков».
Вся статья кратко
Антифрод-системы выявляют и предотвращают фродовые сценарии в продуктах — как потенциальные уязвимостей, так и уже реализованные атаки.
Фрод может влиять на бизнес напрямую или косвенно. В первом случае пользователи обходят платные услуги, во втором — влияние происходит через репутационные и юридические риски или ухудшение пользовательских взаимодействий.
Эффективная АС должна быть: производительной, масштабируемой и надёжной.
Антифрод чаще всего проектируется сверху вниз: от целевого видения к декомпозиции на логические блоки — сбор данных, детект, санкции и мониторинг.
На ранних этапах допустимы офлайн-решения, которые позволяют быстро снизить ущерб и проверить гипотезы перед внедрением real-time систем.
Антифрод-системы отличаются от классических продуктов. Они работают сразу с двумя сегментами пользователей — «хорошими» и «плохими», что усложняет оценку качества и обучение моделей из-за дисбаланса классов.
Такие системы быстро теряют актуальность без постоянного мониторинга, логирования и итеративных улучшений, а ошибки детекта особенно чувствительны для пользовательского опыта.
Узнать больше о задачах, которые решают инженеры AvitoTech, можно по этой ссылке. А вот тут мы собрали весь контент от нашей команды — там вы найдете статьи, подкасты, видео и много чего еще. И заходите в наш TG-канал, там интересно!