Граф транзакций антифрод: как вручную отличить фрод-паттерн от совпадения

Пятнадцать счетов, пятнадцать разных email-адресов, пятнадцать разных ФИО. В таблице транзакций — независимые клиенты с чистой историей. Стоило построить граф по device fingerprint (цифровой отпечаток устройства — набор параметров браузера или телефона, по которому можно опознать конкретное устройство), и картина перевернулась: все 15 аккаунтов выходили в систему с двух телефонов. Классическая мульная сеть. В плоской таблице её не увидеть — хоть сортируй, хоть фильтруй. Ниже — разбор того, как строить граф транзакций антифрод вручную, чем фрод-паттерн отличается от совпадения и почему этот этап нельзя перескочить, даже если у вас уже стоит ML-модель.

Почему анализ транзакционных связей начинается не с модели

Модель машинного обучения работает с признаками (features) — числовыми характеристиками, которые кто-то должен придумать, проверить и разметить. Подать ей сырые строки из БД — значит обучить на шуме. Антифрод-аналитик строит граф связей транзакций вручную, чтобы своими глазами увидеть, какие связи между счетами, устройствами и IP-адресами настоящие, а какие — артефакты данных.

Граф (graph) — структура, где сущности (клиенты, счета, устройства) — это узлы (nodes), а взаимодействия между ними — рёбра (edges). Таблица показывает строки. Граф показывает связи. Мошенничество прячется именно в связях.

Хоп (hop) — один шаг по ребру графа. «Клиент в 2 хопах» означает: между ним и известным мошенником — два промежуточных перевода или общих атрибута.

По оценке Nilson Report, которую цитирует NVIDIA в AI Blueprint по финансовому фрод-детекшну, мировые потери от мошенничества с кредитными картами за следующие 10 лет составят $403.88 млрд. Большинство этих схем — сетевые: мошенники работают группами, эксплуатируют цепочки аккаунтов и устройств. Табличный анализ пропускает цепочки, потому что рассматривает каждую транзакцию изолированно. Как если бы вы искали организованную группу, допрашивая каждого по одному и не сопоставляя показания.

Построение графа мошенничества: из таблиц в узлы и рёбра

Какие данные становятся узлами и рёбрами

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

Узлы (то, что «существует» как отдельная сущность): — Клиентский аккаунт — Банковская карта (маскированный номер или hash PAN) — Устройство (device fingerprint) — IP-адрес или подсеть /24 — Email-домен отправителя/получателя — Телефонный номер

Рёбра (то, что связывает узлы между собой): — Транзакция (перевод от A к B) — с атрибутами суммы, времени, валюты — «Использует» (аккаунт → устройство) — «Привязан к» (аккаунт → карта) — «Зарегистрирован с» (аккаунт → email)

В референсном решении AWS для Neptune Analytics используется открытый датасет IEEE CIS: 500 000 транзакций, около 3.5% из которых размечены как мошеннические. Каждая транзакция связана с типами карт (поля card1–card6), кодами продуктов, адресами и email-доменами. Один узел-транзакция может иметь рёбра к десяткам атрибутных узлов — и именно через эти атрибуты обнаруживаются скрытые связи между «независимыми» переводами.

Чем больше типов узлов вы включаете, тем выше шансы найти пересечение. Если в графе только аккаунты и переводы — видны прямые цепочки. Добавили устройства — увидели, что «разные люди» делят один телефон. Добавили IP — увидели, что всё координируется из одной точки.

Минимальный набор для первого графа

Если вы только начинаете осваивать выявление мошенничества графовым анализом — стартуйте с трёх типов узлов: аккаунт, устройство, транзакция. Этого хватит, чтобы поймать самые частые паттерны — мульные сети и расшаренные устройства. Расширять граф (IP, email, карты) стоит после того, как научитесь уверенно читать компоненты на минимальном наборе. Не пытайтесь впихнуть всё сразу — утонете в ложных связях.

Ищем фрод-паттерн в транзакциях: пошаговый разбор

Практический блок. Понадобится Python 3.9+ и библиотека NetworkX (установка: pip install networkx). Данные — синтетический пример, повторяющий структуру реального кейса.

Делай раз: загрузи данные в граф

Допустим, есть выгрузка: 6 аккаунтов, 3 устройства, переводы между аккаунтами. Задача — загрузить это в граф и увидеть, кто с кем связан.

import networkx as nx

G = nx.Graph()
# Привязка аккаунтов к устройствам
G.add_edges_from([
    ("acc_1", "dev_A"), ("acc_2", "dev_A"), ("acc_3", "dev_A"),
    ("acc_4", "dev_B"), ("acc_5", "dev_B"),
    ("acc_6", "dev_C"),
])
# Переводы между аккаунтами (acc_5 → acc_1 замыкает кольцо)
G.add_edges_from([
    ("acc_1", "acc_4"), ("acc_4", "acc_5"), ("acc_5", "acc_1"),
])
print(f"Узлов: {G.number_of_nodes()}, рёбер: {G.number_of_edges()}")

Ожидаемый вывод: Узлов: 9, рёбер: 9. Девять узлов — 6 аккаунтов + 3 устройства. Девять рёбер — 5 привязок «аккаунт → устройство» + 3 перевода, один из которых замыкает кольцо (acc_5 → acc_1). Если вывод отличается — проверьте, нет ли дублей в данных.

Делай два: найди связанные компоненты

Связанная компонента (connected component) — группа узлов, между которыми можно пройти по рёбрам. Если два аккаунта в одной компоненте — между ними есть путь, пусть даже через несколько промежуточных узлов. Зачем это нужно: компонента — кандидат на «группу». Один аккаунт сам по себе ни о чём не говорит, но если он связан через устройства и переводы с десятком других — это повод присмотреться.

Вызовите list(nx.connected_components(G)) — получите список компонент. В нашем примере acc_1 через dev_A связан с acc_2 и acc_3, а через кольцо переводов — с acc_4 и acc_5 (которые также связаны через dev_B). Результат: одна большая компонента из 8 узлов и одна маленькая — acc_6 + dev_C.

На реальных данных вы получите сотни или тысячи компонент. Большинство — маленькие (1-3 узла): обычные клиенты без пересечений. Аномально большие компоненты (10+ узлов) — первые кандидаты на ручной разбор.

Делай три: проверь — паттерн или совпадение

Вот тут начинается настоящая работа. Вы нашли крупную компоненту. Это фрод или семья с общим планшетом?

Степень вершины (degree) — количество рёбер, выходящих из узла. Если dev_A имеет degree 12 (привязаны 12 аккаунтов) — это ненормально. Обычный пользователь имеет 1-3 аккаунта на устройстве. Двенадцать — это или интернет-кафе, или дроп-ферма.

Сигналы «скорее фрод»:

Сигналы «скорее совпадение»: — Общее устройство, но аккаунты зарегистрированы с разницей в годы (семья) — Переводы между двумя аккаунтами с типичными P2P-суммами и частотой (коллеги скидываются на обед) — Общий IP — но это корпоративная подсеть или публичный Wi-Fi

Главное правило: один признак — не приговор. Фрод-паттерн — совокупность 3+ сигналов на одной компоненте графа. Совпадение — единичный сигнал с бытовым объяснением. Я встречал компоненту из 20 узлов, которая оказалась студенческим общежитием с одним роутером. Всё решила проверка дат регистрации: аккаунты создавались на протяжении трёх лет, а не за одну ночь.

Кольцевые схемы транзакций и другие графовые паттерны

Графовый анализ для выявления мошенничества опирается на несколько классических паттернов. Вот те, что встречаются чаще всего.

Кольцевой перевод (cycle). Деньги уходят от A к B, от B к C, от C обратно к A. Цель — создать видимость оборота или запутать происхождение средств. На графе это замкнутый путь. В блоге NebulaGraph алгоритм cycle detection описывается как ключевой для AML-задач (Anti-Money Laundering — противодействие отмыванию денег): деньги перемещаются по цепочке счетов и возвращаются к отправителю. Зачем мошеннику это нужно: кольцо создаёт «историю операций» для аккаунта — банк видит активного клиента с оборотом, а не свежий пустой счёт.

Для поиска циклов в Neo4j (графовая база данных с языком запросов Cypher) можно использовать запрос:

MATCH path = (a:Account)-[:TRANSFER*3..6]->(a)
WHERE ALL(r IN relationships(path) WHERE r.amount > 1000)
RETURN path, length(path) AS cycle_length
ORDER BY cycle_length DESC LIMIT 20

Запрос ищет замкнутые пути длиной от 3 до 6 переводов, где каждый перевод больше 1000 единиц. *3..6 — глубина обхода. Если Neo4j вернул результаты — перед вами кандидат на расследование. Пустой результат при *3..6 не означает отсутствие колец: попробуйте увеличить диапазон или снизить порог суммы.

Мульная сеть (money mule network). Мул (дроп) — человек, который получает деньги на свой счёт и переводит дальше за процент. На графе это звёздная топология: центральный узел (организатор) с высоким degree связан с 5-20 мулами, каждый из которых делает один-два перевода и исчезает. Характерный признак — высокий degree организатора при низком degree мулов плюс короткое время жизни аккаунтов мулов (дни, не месяцы).

Дробление сумм (structuring / smurfing). Разбиение крупной суммы на несколько мелких, чтобы не сработал порог мониторинга. На графе — веер рёбер от одного узла к нескольким с суммами чуть ниже лимита. Паттерн виден при агрегации: сумма всех исходящих переводов за период кратно превышает каждый отдельный перевод. Если лимит мониторинга 15 000 ₽, а вы видите пять переводов по 14 800 ₽ за сутки с одного аккаунта — это не совпадение.

По данным TigerGraph, графовый подход обнаруживает «indirect or hidden connections between users, accounts, and transactions» и «repeating network motifs such as transaction loops or degree anomalies». Motifs (повторяющиеся структурные фрагменты) — то, что табличный анализ физически не может увидеть.

Ручная разметка фрода: что и зачем передавать модели

Скоринг транзакций (scoring) — присвоение каждой транзакции числовой оценки риска от 0 до 1. Чтобы модель научилась скорить, ей нужны размеченные примеры: «это фрод», «это легитимно». Без разметки модель не знает, что искать.

Ручная разметка — самая трудоёмкая и самая ценная часть работы антифрод-аналитика. Берёте подозрительную компоненту графа, проверяете по чек-листу из таблицы выше, запрашиваете дополнительные данные (логи входов, историю создания аккаунтов, IP-геолокацию) и выносите вердикт.

Три правила качественной разметки:

1. Размечайте компоненту целиком. Если 5 из 8 аккаунтов в кольце подтверждены как фрод, оставшиеся 3 нуждаются в отдельной проверке, а не в автоматической метке «чисто». Соблазн дорисовать метки «по аналогии» — прямой путь к отравлению обучающей выборки.

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

3. Записывайте признаки, которые привели к решению. Degree устройства, длина цикла, временной интервал между регистрациями — всё это станет feature engineering (процесс создания признаков для ML-модели). То, что вы заметили глазами на графе, модель должна получить в виде чисел.

В датасете IEEE CIS около 3.5% транзакций размечены как мошеннические. Типичная пропорция — сильный дисбаланс классов. Модель, обученная без графовых признаков, просто предсказывает «не фрод» в 96.5% случаев и формально показывает высокую точность. При этом пропускает почти все реальные схемы. Accuracy 96.5% — и ноль пойманных мошенников. Красивая метрика, бесполезный результат.

Граф для модели антифрода: какие признаки извлекать

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

NVIDIA в AI Blueprint комбинирует GNN-эмбеддинги (Graph Neural Network — нейросеть, которая обучается на графовой структуре и генерирует числовые представления узлов) с XGBoost (градиентный бустинг на деревьях решений). GNN автоматизирует то, что аналитик делает при визуальном разборе компонент: извлекает структурные признаки — кто с кем связан, через сколько хопов, в каком сообществе. XGBoost затем использует эти признаки для финального скоринга. Комбинация даёт более высокую точность при меньшем числе ложных срабатываний по сравнению с моделями на одних табличных данных.

Но нюанс: GNN учится на вашей разметке. Кривая разметка — кривая модель. Этап ручного разбора графа — не «устаревший ручной труд», а фундамент для всего ML-решения.

Одна и та же ошибка повторяется в командах, которые внедряют граф транзакций антифрод: ставят Neo4j, подключают GNN и ждут результатов. Через квартал — ложных срабатываний больше, чем при старых правилах. Причина всегда одна: никто не разобрал вручную хотя бы сотню компонент графа, не понял, как выглядит фрод-паттерн именно в их данных, не создал качественную разметку. Модель обучилась на мусоре и предсказывает мусор.

Мой подход — минимум две недели ручного анализа до первого запуска модели. Это не масштабируется, но это единственный способ понять, какие связи информативны, а какие — шум. Команды, которые перескакивают этот этап, тратят потом полгода на «тюнинг модели», а по факту доделывают feature engineering, который должен был быть готов с самого начала.

Через пару лет GNN-решения станут коробочными, порог входа снизится. Но потребность в аналитике, который умеет читать граф руками и отличать паттерн от артефакта, никуда не денется — мошенники адаптируют схемы быстрее, чем переобучается модель. Если хочешь начать двигаться в сторону антифрода — на IB Basics показывают не теорию, а как джуны реально решают рабочие задачи.