Антифрод скоринг транзакций: разбираю SIM-swap схему и строю правило детекции

Утром в понедельник у клиента регионального банка отключается мобильная связь. Через 22 минуты с его счёта уходят два перевода на 840 000 рублей — на реквизиты, которых раньше не было в истории операций. Ещё через 12 минут — попытка третьего перевода, уже заблокированная. 34 минуты от подмены SIM до вывода средств. По данным FBI IC3 Annual Report 2022, в том году зафиксировано 2 026 обращений по SIM-swap мошенничеству с совокупным ущербом $72 млн. Британский UK Finance Fraudscape 2025 фиксирует рост числа SIM-swap случаев за 2024 год (точные цифры стоит сверять с первоисточником — независимо верифицировать их не удалось). Эту схему я разобрал по транзакционным логам в ClickHouse и ниже покажу, какое правило антифрод скоринга транзакций её ловит — с фичами, весами и порогом, который переносится в любой движок правил.

Бизнес-логика атаки: зачем мошеннику подмена SIM карты

Прежде чем лезть в данные, разберёмся с мотивацией. Зачем злоумышленник вообще связывается с оператором связи?

Цель одна: перехватить SMS с OTP (one-time password — одноразовый пароль, который банк отправляет для подтверждения перевода или сброса пароля). Большинство российских банков до сих пор используют SMS как второй фактор аутентификации. По классификации OWASP Top 10 (A07:2021 — Identification and Authentication Failures) зависимость от SMS OTP — документированная слабость. Причина простая: канал доставки кода (сотовая сеть) находится вне контроля банка.

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

Если посмотреть на это через MITRE ATT&CK — открытую базу тактик и техник атак, где каждой технике присвоен T-код (идентификатор вроде T1111) — SIM-swap покрывает сразу несколько техник:

• T1111 Multi-Factor Authentication Interception (тактика credential-access) — перехват второго фактора через подмену SIM
• T1598.004 Spearphishing Voice (тактика reconnaissance) — голосовой фишинг: мошенник выманивает у жертвы или её окружения персональные данные для перевыпуска SIM
• T1656 Impersonation (тактика defense-evasion) — выдача себя за клиента при обращении к оператору связи
• T1657 Financial Theft (тактика impact) — конечная цель: вывод денег со счёта

Монетизация прямолинейная: деньги уходят на счета дропов (подставных получателей), дробятся на суммы ниже порогов мониторинга и обналичиваются. По публикациям Group-IB, большинство SIM-swap атак включают несколько переводов подряд — мошенник выжимает максимум за то окно, пока жертва не поняла, что потеря связи — не глюк оператора.

Схема SIM swapping мошенничества: три этапа

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

Этап 1 — сбор данных о жертве. Мошенник собирает персональную информацию: ФИО, дату рождения, последние цифры паспорта, кодовое слово. Источники — фишинговые сайты (основной канал, по данным Group-IB), утечки баз данных, покупка дампов в даркнете. Масштаб проблемы: утечка Facebook 2019 года затронула около 509 млн записей (509 458 528 по данным HIBP), включая даты рождения, геолокацию и адреса электронной почты (номера телефонов не входят в перечень HIBP DataClasses для этой утечки, хотя сторонние публикации 2021 года сообщали об их наличии в найденном датасете). Это именно те поля, которые оператор связи спрашивает при верификации.

Теневой рынок данных тоже не стоит на месте: по оценке IBM X-Force Threat Intelligence Index 2025, в даркнете ежедневно появляется около 6 000 свежих наборов учётных данных (оценочная величина, не точно измеренная).

Этап 2 — перевыпуск SIM у оператора. Мошенник звонит в колл-центр оператора или приходит в салон, представляясь клиентом. Говорит, что потерял телефон, просит перевыпустить SIM. Если верификация слабая — а по данным Europol, организованные группы вербуют инсайдеров в телеком-компаниях — номер переходит к мошеннику. Оригинальная SIM жертвы деактивируется, телефон теряет сеть. Отдельный вектор — eSIM: если мошенник получает доступ к личному кабинету оператора через утечку credentials, он привяжет номер к eSIM на своём устройстве удалённо, без похода в салон.

Этап 3 — захват аккаунтов и вывод денег. Мошенник заходит в мобильный банк, запрашивает сброс пароля через SMS. OTP приходит на его SIM. Он меняет пароль, меняет настройки MFA (многофакторной аутентификации), инициирует переводы. Типичное окно — от 20 до 60 минут, пока жертва не поймёт, что потеря связи — не сбой оператора.

По данным CrowdStrike Global Threat Report 2025, 75% вторжений в 2024 году использовали действительные учётные данные. SIM-swap даёт мошеннику именно их: легитимный номер и OTP.

Паттерн в данных: выявление подозрительных транзакций при SIM-swap

Теперь смотрим на данные глазами фрод-аналитика. Что видно в транзакционных логах фрод-мониторинга банка при подмене SIM карты?

Ниже — конкретные сигналы для построения правила. Набор сформирован на основе анализа реальных инцидентов и методологий Group-IB и FluxForce (источник требует независимой проверки). Ни один сигнал сам по себе не доказывает фрод — сила в комбинации.

Сигналы уровня транзакции

Сигналы уровня аккаунта

Поведенческие сигналы

Поведенческий анализ добавляет третий слой. Три ситуации, на которые стоит обращать внимание:

• Клиент звонит в поддержку с жалобой на потерю связи одновременно с подозрительной активностью на счёте — практически стопроцентный маркер SIM-swap
• Резкое нарушение привычного ритма: вход в нехарактерное время суток, с нового IP другого региона и нового устройства
• Входящие push-уведомления на зарегистрированное устройство остаются без ответа (у жертвы нет связи)

Именно потому, что один сигнал ничего не доказывает, антифрод скоринг транзакций работает как взвешенная сумма — не бинарное «фрод / не фрод», а числовая оценка подозрительности.

Антифрод правила детекции: строим скоринговое правило

Теперь к конкретике. Ниже — правило, которое ловит SIM-swap паттерн. Реализовать его можно в любой антифрод системе банка с движком правил: SAS Fraud Management, FRADM, кастомный движок на Python/SQL.

Предусловия

Перед написанием правила убедитесь, что у вас есть:

• Данные о SIM-событиях — поток уведомлений от оператора связи (carrier SIM-change API) или внутренний флаг: факт смены номера в мобильном банке
• Таблица транзакций с полями: client_id, amount, payee_id, created_at, device_id, ip_geo
• Таблица изменений credentials — когда клиент менял пароль, MFA-метод, контактный номер
• Профиль клиента — средняя сумма исходящих переводов за 90 дней, типичная геолокация, список доверенных устройств

Шесть фичей для SIM-swap правила

Фичи (features) — измеримые признаки транзакции и её контекста, по которым считается скор. Для детекции SIM-swap достаточно шести:

1. sim_change_72h — произошла ли смена SIM или номера в последние 72 часа (бинарный флаг: 0 или 1)
2. min_since_cred_change — сколько минут прошло между последним изменением пароля или MFA и текущей транзакцией
3. new_device — транзакция с устройства, которого раньше не было в профиле клиента (0 или 1)
4. new_payee — получатель перевода новый для этого клиента (0 или 1)
5. amount_ratio — отношение суммы транзакции к средней сумме исходящих переводов за 90 дней
6. geo_mismatch — геолокация входа не совпадает с типичной геолокацией клиента (0 или 1)

Таблица весов

Каждой фиче назначаем вес в баллах. Скор — взвешенная сумма:

Реализация правила скоринга на Python

Функция, которую можно подключить к потоку обработки транзакций. На вход — словарь с фичами, на выходе — число от 0 до 110 (максимум при одновременном срабатывании всех условий с наибольшим весом в каждой ветке if/elif).

def calc_sim_swap_score(tx):
    """Возвращает скор 0-110. Ветки if/elif взаимоисключающие: min_since_cred_change и amount_ratio дают баллы только по одному условию."""
    score = 0
    if tx['sim_change_72h']:        score += 35
    if tx['min_since_cred_change'] < 60:   score += 25
    elif tx['min_since_cred_change'] < 360: score += 10
    if tx['new_device']:            score += 15
    if tx['new_payee']:             score += 10
    if tx['amount_ratio'] > 10:     score += 15
    elif tx['amount_ratio'] > 5:    score += 10
    if tx['geo_mismatch']:          score += 10
    return score  # >= 60 → блок, 31-59 → доп. проверка

Проверяем на кейсе из начала статьи. Транзакция: подмена SIM произошла (sim_change_72h = 1, +35), пароль сброшен 20 минут назад (min_since_cred = 20, +25), новое устройство (+15), новый получатель (+10), сумма в 14 раз выше средней (amount_ratio = 14, +15). Скор: 35 + 25 + 15 + 10 + 15 = 100. Красная зона.

Пороги и действия

Нюанс, который легко упустить: push-уведомление после SIM-swap жертва не получит — телефон без связи. Поэтому для жёлтой зоны при наличии флага sim_change_72h нужен fallback — звонок на альтернативный номер или e-mail-подтверждение.

Делай раз, делай два, делай три: внедряем правило фрод-мониторинга

Делай раз — обогащаем транзакцию фичами

Перед расчётом скора нужно собрать все шесть фичей в одну запись. В SQL это серия JOIN: таблица transactions соединяется с sim_events (факт смены SIM за 72 часа), credential_changes (время последнего изменения пароля), device_log (признак нового устройства), подзапрос по истории transactions (признак нового получателя) и агрегат средней суммы за 90 дней. На выходе — представление enriched_transactions, где каждая строка содержит исходные данные транзакции плюс шесть колонок с фичами.

Как проверить: выполните SELECT * FROM enriched_transactions LIMIT 10. Каждая строка должна содержать шесть дополнительных колонок. Если какая-то из них NULL — проверьте JOIN-условие: скорее всего, LEFT JOIN не нашёл соответствия в таблице-источнике.

Делай два — подключаем функцию скоринга к потоку

Функцию calc_sim_swap_score подключите к потоку обработки транзакций. Варианты в зависимости от архитектуры:

• Кастомный движок на Python — вызывайте функцию синхронно перед авторизацией. Транзакция не проходит, пока не получен скор
• SAS Fraud Management — переведите логику в формат SAS-правила (блоки IF-THEN с теми же условиями и баллами)
• FRADM — создайте новый шаблон правила с шестью параметрами и аналогичной формулой

Как проверить: пропустите через правило 200–300 исторических транзакций с разметкой (fraud / not fraud). Все подтверждённые SIM-swap кейсы должны получить скор >= 60. Если часть попадает в жёлтую зону — пересмотрите веса или добавьте фичу.

Делай три — настраиваем алерт и дашборд

Создайте дашборд в Grafana (или аналогичном инструменте) с двумя панелями:

1. Fraud Score Timeline — средний скор по минутам за последние 24 часа. Источник: таблица enriched_transactions, группировка по toStartOfMinute(created_at) (синтаксис ClickHouse)
2. Red Zone Alerts — количество транзакций со скором >= 60 за текущие сутки, с фильтром по sim_change_72h = 1

Настройте алерт: если красных алертов за час больше трёх — уведомление в Telegram-канал фрод-команды. На первом этапе запускайте правило в shadow mode (параллельно с основным процессом, без реальной блокировки) — так вы оцените уровень ложных срабатываний до включения в боевой режим.

Как понять, что работает: в shadow mode за первую неделю должно накопиться 50+ алертов. Если алертов ноль — либо порог слишком высокий, либо фича sim_change_72h не заполняется (нет данных от оператора).

Калибровка: false positive и тюнинг правила скоринга фрода

Правило бесполезно, если блокирует каждую десятую легитимную операцию. FPR (false positive rate — доля ложных срабатываний) — метрика, за которой нужно следить постоянно.

Алгоритм калибровки:

1. Запустите правило в shadow mode на 2 недели. Скор считается, транзакция не блокируется. Все алерты со скором >= 60 попадают в очередь аналитика
2. Разметьте выборку: для каждого алерта определите — реальный фрод или FP. Достаточно 200–300 записей
3. Посчитайте FPR и recall (полнота — доля пойманных фрод-кейсов от всех реальных). Ориентиры (адаптируйте под риск-аппетит конкретного банка): FPR < 2%, recall > 85%
4. Если FPR > 2% — поднимайте порог красной зоны (с 60 до 65–70). Если recall < 85% — добавляйте фичи или увеличивайте веса ключевых признаков

Типичные источники высокого FPR:

• Клиенты реально часто меняют SIM (путешествия, dual-SIM устройства). Решение: добавить фичу travel_notification — если клиент заранее уведомил банк о поездке, вес sim_change_72h снижается с 35 до 10
• Крупные переводы новым контрагентам (покупка авто, недвижимости). Решение: ввести whitelist категорий получателей — нотариусы, застройщики, автосалоны — с пониженным весом new_payee

Без мониторинга FPR правило превращается из защиты в генератор раздражения клиентов. По OWASP (A09:2021 — Security Logging and Monitoring Failures) отсутствие мониторинга — одна из причин, по которым инциденты остаются незамеченными. Это работает в обе стороны: пропущенный фрод и незамеченная деградация качества самого правила — одинаково плохо.

Graph-анализ связей для детекции мошеннических транзакций

Одиночное правило риск-скоринга ловит конкретную транзакцию. Но SIM-swap атаки часто проводятся организованными группами. По публикации FluxForce (источник требует проверки), характерный паттерн — несколько аккаунтов в одном банке атакуются в окне нескольких дней. Связи между дропами, устройствами и IP-адресами видны только через граф.

Для такого анализа подходит Neo4j — графовая СУБД, которая хранит не таблицы, а связи между сущностями. Узлы графа: клиенты, устройства, IP-адреса, получатели переводов. Рёбра: «использовал устройство», «перевёл на счёт», «входил с IP».

Запрос ниже ищет кластеры аккаунтов, которые после SIM-swap события начали использовать одно и то же устройство — маркер организованной группы:

MATCH (c1:Client)-[:USED_DEVICE]->(d:Device)<-[:USED_DEVICE]-(c2:Client)
WHERE id(c1) < id(c2)
  AND d.first_seen > datetime() - duration('P7D')
  AND EXISTS((c1)-[:SIM_CHANGED]->())
RETURN c1.id, c2.id, d.fingerprint, count(*) AS shared
ORDER BY shared DESC LIMIT 20

Ожидаемый результат: таблица пар клиентов, связанных общим устройством за последние 7 дней. Если один из них — подтверждённый SIM-swap кейс, второй с высокой вероятностью тоже скомпрометирован или является дропом. Этот подход превращает точечную детекцию в сетевую: вместо одного алерта на одну транзакцию вы получаете карту мошеннической сети.

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

Банки, которые в 2026 году строят антифрод систему исключительно вокруг SMS OTP, не борются с SIM-swap мошенничеством — они создают для него идеальные условия. Весь мой опыт разбора таких инцидентов сводится к одному: техническая сложность атаки минимальна. Мошеннику не нужен zero-day и не нужен кастомный malware. Достаточно утечки персональных данных (а по Verizon DBIR 2025, в 38% утечек фигурируют украденные credentials) и одного убедительного звонка оператору связи.

Правило скоринга из этой статьи — не «решение проблемы». Это заплатка на конструктивный дефект: SMS-канал для доставки OTP находится вне периметра банка. Carrier-verified API, когда банк в реальном времени запрашивает у оператора статус SIM — шаг в правильном направлении, но внедрение буксует. Банк в идеале вообще не должен зависеть от SMS как единственного второго фактора — push в собственном приложении плюс биометрия закрывают этот вектор полностью.

При этом навык строить скоринговые правила по транзакционным паттернам не устаревает. Каналы атак меняются каждый год, а принцип «собери фичи — задай веса — откалибруй порог — мониторь FPR» остаётся одинаковым для любого типа транзакционного фрода: от SIM-swap до friendly fraud. Если ищешь джуниор-роль в ИБ или антифроде — IB Basics плюс пара разобранных кейсов вроде этого дают что показать на собеседовании.