Мобильные транзакции быстро растут. Например, по прогнозам, к 2025 году мировой рынок мобильных платежей достигнет 4,7 триллиона долларов США. В то же время, по оценкам, в 2019 году 75% всех мошеннических транзакций происходили с мобильных устройств. Мошеннические события различаются по типу и исполнителям: захват учетной записи (ATO), подмена местоположения и замена SIM-карты - вот несколько примеров. Мошенничество с использованием ATO имеет место, когда мошенник получает полный доступ к учетным данным законного пользователя и другой информации, необходимой для входа в систему, и, таким образом, может выполнять действия без каких-либо последствий.

Предотвращение ATO может быть реализовано на нескольких этапах пути пользователя, главный из которых - при входе в систему. При решении этой проблемы возникают две основные проблемы: обнаружение попыток мошенничества в системе и предотвращение увеличения трения для законных пользователей. Если обнаруживаются все попытки мошеннического входа в систему, но это приводит к тому, что законные пользователи должны проверять каждую попытку с помощью вторичного фактора, такого как электронная почта, это может нанести вред приложению, вызывая отток пользователей из-за увеличения трения. В то же время принятие всех входов в систему без дополнительных шагов проверки, не обнаруживая при этом большинства попыток мошенничества, нежелательно. Таким образом, хорошие решения по предотвращению ATO должны стремиться к достижению баланса между обнаружением мошенничества и снижением трений.

Проблемы предотвращения АТО

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

  • Большинство попыток входа в систему являются законными, а мошеннические - редкими. Это означает, что ожидается, что наборы данных будут иметь фактор дисбаланса высокого класса, что усложняет процессы обучения и выбора показателей;
  • Показатели успеха варьируются от клиента к клиенту и с течением времени. Классификаторы должны иметь возможность легко настраиваться, чтобы либо увеличить обнаружение мошенничества за счет большего трения, либо уменьшить обнаружение мошенничества, чтобы уменьшить трение;
  • Помеченные наборы данных не являются широко доступными, и даже если бы они были, функции и распределение классов сильно различаются в зависимости от пользовательских баз приложения;
  • Попытки входа в систему обычно подтверждаются максимум за несколько секунд. Таким образом, классификаторы должны обслуживаться через API-интерфейсы с задержкой на уровне миллисекунд и, как правило, легко развертывать и поддерживать в производственной среде.

Обучение классификатора

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

Получение помеченных наборов данных

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

Адаптивность

Вторая проблема заключалась в выборе классификатора, который мог бы справиться с дисбалансом классов и легко настраивался, развертывался и поддерживался. Все это мы нашли в LGBM, фреймворке для повышения градиента, построенном на основе древовидных моделей. В дополнение к древовидным моделям, которые являются хорошей альтернативой для борьбы с дисбалансом классов, LGBM также предлагает простые способы выбора для них различных функций принятия решений, что позволяет пользователям использовать современные функции балансировки классов, такие как Focal Loss. »И опубликованный Cui et. ал ..

Что касается простоты использования, LGBM предоставляет Python API и легко интегрируется с Pandas и Sklearn. Его обучение происходит быстро и может быть распределено, он имеет встроенную поддержку распараллеливания и занимает мало места в памяти, что мы покажем позже. Мы также смогли использовать разные пороговые значения поверх оценки классификатора: один для обнаружения мошенничества, а другой для подтверждения входа в систему, что дает нам много возможностей для настройки, как показывает уравнение 1.

Выбор функций

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

Насколько важна эта функция для результатов работы классификатора? Мы использовали Shapley Additive Explanations (SHAP), теоретико-игровой подход для вычисления важности функций для моделей машинного обучения. По сравнению со стандартными методами вычисления важности функций SHAP предлагает более четкие визуальные объяснения и возможности индивидуального анализа. Затем мы смогли быстро определить и удалить нерелевантные функции.

Насколько легко вычислить эту функцию в производственной среде? Мы нарисовали схемы архитектуры, чтобы понять необходимую рабочую нагрузку для каждой оставшейся функции. Достаточно интересно, что мы заметили, что некоторые из оставшихся наиболее проблемных функций для вычисления в производственной среде были одними из наименее важных с точки зрения SHAP. Те тоже были обрезаны.

Развертывание классификатора

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

Архитектура обучения

Как показано на рисунке 1, конвейер обучения был реализован в двух частях: генерация функций и обучение модели, обе организованные с помощью Rundeck. Генерация функций использует Spark для распределенного вычисления нескольких функций классификатора с использованием нашей инфраструктуры данных. Затем эти функции каталогизируются в нашем озере данных и используются на отдельном, автономном этапе обучения, написанном на Python, который обучает модель, использует Optuna для оптимизации ее гиперпараметров и сохраняет классификатор в определенные сегменты S3.

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

Производственная архитектура

В процессе производства мы реплицировали запросы вычисления функций непосредственно поверх нашей канонической пользовательской базы данных. Мы выполнили несколько тестов на этапе подготовки и подготовки к производству, чтобы подтвердить равенство результатов этих запросов и результатов в конвейере обучения. Затем мы реализовали вторичный API, используя фреймворк FastAPI для обработки этих функций.

Мы выбрали FastAPI, потому что его легко интегрировать с API LGBM, а также из-за его невероятно высокой производительности: наши стресс-тесты показали задержки p99 всего в 5 миллисекунд и объем памяти, включая классификатор LGBM, загруженный в память с помощью joblib, размером 300 МБ. . Задержка была особенно важна для нас из-за бюджета задержки в 200 миллисекунд для оценки риска входа в наш API.

Сначала эвристика!

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

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

Заключительные мысли

В течение 2–3 месяцев мы смогли создать и полностью развернуть классификатор с измеримыми последствиями для наших клиентов: он повысил нашу степень одобрения на 6 процентных пунктов и уровень обнаружения мошенничества почти на 50 процентов. В сочетании с другими нашими доказательствами мы смогли аутентифицировать 93% законных пользователей без каких-либо дополнительных проблем и выявить мошенничество с показателем ложноположительных результатов 0,0013%.

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

В прошлом мы также занимались другими работами, связанными с машинным обучением. Не стесняйтесь проверить некоторые из наших предыдущих публикаций по таким темам, как Дедупликация места и Анализ социального дистанцирования. Если что-то из этого вызвало у вас интерес и вы хотите принять участие в создании ведущего решения для аутентификации с нулевым фактором на основе местоположения, Incognia нанимает!