Антифрод в банке начинает сыпаться в тот момент, когда решение по операции нужно вернуть прямо сейчас, а данные вокруг этой операции ещё не собрались в одну картину. Часть событий уже пришла. Часть запаздывает. Часть противоречит друг другу. Ручной разбор начинает подменять автоматику. В этот момент выясняется, что у банка не “плохой скоринг”, а слабая архитектура принятия решений.
В публичной статистике это видно без особой романтики. По данным Банка России, в 2025 году объём операций без добровольного согласия клиентов составил 29,3 млрд рублей. При этом банки предотвратили 134,16 млн мошеннических операций на 13,9 трлн рублей. Для крупных банков доля остановленных мошеннических переводов держалась на уровне 99,85%. Это уже не история про отдельные кейсы. Это потоковая производственная задача, где ошибка в архитектуре быстро превращается либо в пропущенный фрод, либо в лишнее трение для нормального клиента.
Параллельно меняется сама поверхность атаки. Денежный фрод никуда не делся, но к нему плотно прилипли атаки на вход в систему: поддельные документы, deepfake в удалённой идентификации, synthetic identity (поддельная личность), более сложные сценарии захвата аккаунта. В отчёте Entrust за 2025 год deepfake уже выделены как один из самых быстрорастущих классов identity fraud: попытки шли в среднем раз в пять минут, а цифровые подделки документов выросли на 244% год к году. Всемирный экономический форум в недавнем обзоре отдельно вынес cyber-enabled fraud и phishing в число главных рисков для бизнеса.
Из этого и растёт тема статьи. Не “какую модель взять”, а как вообще собрать антифрод-платформу, которая выдерживает поток событий, считает признаки без рассинхрона, сводит модельный риск с правилами и отдаёт решение в тот момент, когда оно ещё что-то значит.
Бизнес-контекст антифрода в банке
Объёмы и тренды фрода 2025-2026
Если смотреть на антифрод глазами презентации, всё сводится к росту угроз и к разговору про ИИ. Для банка картина другая. Есть поток решений. Есть стоимость ложной блокировки. Есть потери от пропущенного фрода. Есть ручная очередь, которая либо успевает переварить сомнительные случаи, либо уже стала аварийным клапаном для дыр в автоматике.К концу 2025 года средняя сумма одной операции без добровольного согласия клиента снизилась до 18,6 тыс. рублей, а число предотвращённых операций почти удвоилось. Это плохой сигнал для архитектуры: атаки становятся более массовыми, более дешёвыми в запуске и лучше масштабируются. Система начинает чаще сталкиваться не с редким тяжёлым кейсом, а с плотным потоком событий, который надо быстро сортировать по риску.
Отдельно видно, что банк уже не может держать антифрод только вокруг карточной операции или перевода. Банк России в итогах за 2025 год отдельно подчёркивает эффект периода охлаждения для кредитов и займов: объём похищенных кредитных денег у клиентов крупных банков снизился на 39,2%, до 7,8 млрд рублей. Сам по себе этот факт важен не только для регуляторной повестки. Он показывает, что точка принятия антифрод-решения смещается в кредитный и онбординговый контур, а не остаётся только в платёжном.
С удалённой идентификацией история ещё жёстче. В российской публичной статистике этот слой виден хуже, чем переводы и ОБДС, но это не значит, что его можно вынести за скобки. Наоборот, здесь банк чаще всего получает самый неприятный класс ошибки: проблема возникает не в момент списания денег, а сильно раньше - когда система вообще признала клиента “нормальным” и пустила его в жизненный цикл продукта. Рост deepfake и подделок документов как раз об этом. Это уже не локальная задача проверки селфи или паспорта. Это вопрос, на каком этапе платформа должна начать считать риск и сколько независимых сигналов ей для этого нужно. Это уже архитектурный вывод из того, что показывает отчёт
Типы мошенничества и почему они ломают архитектуру по-разному
Ошибка многих антифрод-систем в том, что разные типы фрода пытаются засунуть в один общий “риск операции”. На бумаге удобно. В эксплуатации быстро выясняется, что это разные задачи с разным временем реакции и разной памятью системы.CNP-фрод, то есть операции без физического предъявления карты, обычно бьёт по транзакционному контуру. Здесь важны сумма, получатель, торговец, история клиента, устройство, сессия, частота действий. Это короткий цикл. Сигнал живёт рядом с операцией. Если архитектура данных в порядке, такой риск можно считать быстро и довольно стабильно.
Захват аккаунта, или ATO, устроен иначе. Денежная операция здесь часто уже финал. До неё злоумышленник успевает зайти в канал, сменить устройство, восстановить доступ, добавить нового получателя, подвинуть лимиты или перестроить путь подтверждения. Если антифрод включается только на платеже, он приходит слишком поздно. Ему уже приходится ловить не подготовку атаки, а её денежный выхлоп. В отчёте Sumsub за 2025 год ATO прямо фигурирует среди заметных third-party fraud схем, что хорошо совпадает с банковской практикой последних лет.
Synthetic identity ломает архитектуру ещё сильнее. Здесь нет одного яркого события, которое хочется немедленно отклонить. Наоборот, система видит клиента, который постепенно выглядит всё правдоподобнее. В отчёте Entrust synthetic identity описана ровно так: злоумышленник комбинирует реальные и вымышленные данные и собирает новую личность, которая затем проходит проверки как будто она настоящая. Для банка это означает неприятную вещь: одной транзакционной модели мало. Нужны длинные признаки, связи между сущностями, история устройства, повторяемость атрибутов, сопоставление заявок, документов и поведения по времени.
Deepfake KYC (использование дипфейков для обхода процедур проверки личности (Know Your Customer - "Знай своего клиента"), которые применяются банками, криптобиржами и смежными сервисами.) добавляет сюда ещё один слой. Если раньше удалённая идентификация часто жила как отдельная проверка “на входе”, теперь она напрямую влияет на последующий денежный риск. По тому же отчету от Entrust, deepfake уже заняли значимую долю биометрического фрода, а в числе наиболее атакуемых отраслей оказались кредитование и традиционные банки. Для архитектуры это означает простую вещь: контур проверки личности, контур скоринга по устройству и транзакционный антифрод больше нельзя проектировать как три независимые системы.
Архитектура данных
Источники событий (каналы, транзакции, сессии)
Первая ошибка в банковском антифроде - думать, что источником данных для решения является сама транзакция. Для платёжного контура это звучит естественно, но в живой системе решение почти никогда не строится вокруг одного события. Денежная операция - только один из фактов. Рядом с ней есть сессия, устройство, история входа, смена получателя, попытки подтверждения, данные по счёту, результаты проверки личности, ответ внешнего провайдера, действия оператора, следы прошлых ручных решений. Если эти куски живут отдельно и склеиваются на лету прямыми вызовами в чужие системы, антифрод превращается в набор сетевых зависимостей с красивым названием.
Поэтому у нормальной платформы есть жёсткое правило: решение не должно зависеть от того, успела ли соседняя система ответить по сети в текущую миллисекунду. Источники публикуют события. Антифрод забирает их из шины, приводит к общей форме, раскладывает по сущностям и уже на этой базе считает признаки и риск. Это скучнее, чем “сходить в пять API и получить всё сразу”, но только такой подход держит нагрузку и даёт воспроизводимость.
У источников при этом разный статус. АБС или процессинг - источник истины для денежного факта. Канал дистанционного обслуживания - источник истины для сессии и клиентского действия. Сервис device intelligence - для признаков устройства. KYC-провайдер - для результата проверки документа, биометрии и качества захвата. Контакт-центр - для разговорного и операционного контекста. Антифрод не должен подменять эти системы. Его задача - собрать из их событий решение, а не “изобрести” собственную правду о клиенте.
Здесь же всплывает проблема, которую обычно недооценивают в начале проекта: у разных систем разное время. Есть время совершения события. Есть время его записи в исходной системе. Есть время публикации в шину. Есть время, когда антифрод вообще увидел этот факт. Для расследования это важно. Для расчёта признаков - критично. Если платформа путает время события со временем доставки, она начинает считать скорость и последовательность действий по мусору.
Поэтому каноническое событие должно нести не только полезную нагрузку, но и служебный каркас: идентификатор события, тип, время возникновения, время приёма, источник, ключевые сущности, след трассировки, версию схемы. Без этого дальше невозможно ни корректно дедуплицировать поток, ни понять, что именно система знала в момент решения.
Минимальный каркас события обычно выглядит так:
JSON:
{
"event_id": "8f5c3e6a-2d41-4d73-9d64-...",
"event_type": "payment.initiated",
"event_time": "2026-02-14T09:31:22.413Z",
"ingest_time": "2026-02-14T09:31:22.587Z",
"source_system": "mobile-bank",
"customer_id": "c_10482",
"account_id": "a_77821",
"session_id": "s_99123",
"device_id": "d_45119",
"trace_id": "tr_7ab1...",
"payload_version": 3,
"payload": {
"amount": 18500,
"currency": "RUB",
"recipient_id": "r_55103",
"channel": "mobile"
}
}Первая - повторная доставка. В банковских контурах одно и то же событие легко приезжает дважды: повтор публикации, сетевой сбой, ретрай продюсера, повторная доставка после аварии потребителя. Если антифрод считает не по
event_id, а по факту получения сообщения, он сам себе рисует аномалию.Вторая - частичная правда. Одно событие знает сумму, но не знает итог аутентификации. Другое знает устройство, но не знает получателя. Третье приходит позже и уточняет статус операции. Если эти сообщения не связаны общими идентификаторами, платформа не собирает контекст, а угадывает его.
Третья - эволюция схемы. Поля меняются. Новые источники добавляются. Старые сигналы становятся неактуальными. Если версия полезной нагрузки не управляется явно, то через полгода половина признаков начинает считаться уже не по тем полям, по которым модель обучалась.
Для банка с несколькими каналами и несколькими продуктами полезно разделять события не по “техническим системам”, а по доменам риска. Отдельно денежные события. Отдельно аутентификация и сессии. Отдельно устройство и среда исполнения. Отдельно KYC и онбординг. Отдельно ручные решения и результаты расследований. Такой разрез упрощает и потоковую обработку, и повторный расчёт признаков, и разбор причин решения.
Потоковая обработка: зачем здесь Kafka и Flink
В антифроде Kafka обычно пытаются описывать как очередь. Для банка это слишком слабое описание. Здесь она нужна не только для доставки, а как опорный журнал событий, из которого несколько контуров читают один и тот же факт в своём темпе. Один поток нужен скорингу. Тот же поток нужен расчёту признаков. Тот же поток нужен расследованию. Потом он же нужен для обучения и пересчёта истории. Если событие прожило только в памяти одного сервиса и исчезло после ответа, антифрод потом не сможет ни объяснить решение, ни пересобрать прошлое состояние.Но Kafka не снимает архитектурные решения. Самое болезненное - выбор ключа для разделов. Для операций удобно группировать по счёту или карте. Для поведенческого анализа - по клиенту. Для онбординга - по заявке или устройству. Для графовых связей - по получателю или общему идентификатору сущности. Один ключ не закроет все задачи сразу. Поэтому обычно приходится раскладывать поток на несколько доменных топиков, а не сваливать всё в один “fraud-events”, который потом все мучительно перечитывают и фильтруют.
Плохой вариант здесь выглядит так: один огромный универсальный топик, смешанные типы сообщений, нечёткая схема, у потребителей своя трактовка полей, часть сервисов считает по времени доставки, часть - по времени события. На первых стендах это даже работает. На реальной нагрузке начинается каша: пропавший порядок внутри сущности, тяжёлые повторные чтения, ошибки в окнах, слишком дорогой повторный расчёт.
Flink в этой схеме нужен не ради слова “real-time”. Он нужен там, где антифроду требуется состояние. Не просто “увидели событие и посчитали балл”, а удержали короткую память по сущности, собрали окно, дождались второго сигнала, связали события из разных потоков, сработали по таймеру, досчитали агрегат, отдали результат дальше. Это и есть обычная банковская работа: число новых получателей за 30 минут, резкий рост суммы по устройству за последние 10 минут, серия неудачных попыток до успешного входа, аномальная плотность действий после смены SIM, цепочка “логин -> смена лимита -> новый шаблон -> перевод”.
Хранилище признаков: место, где банк либо собирает систему, либо окончательно её ломает
Когда в антифроде появляется несколько моделей, несколько потоков и хотя бы один нормальный цикл переобучения, почти сразу возникает одна и та же проблема: признаки в обучении и в бою начинают расходиться. В ноутбуке всё было аккуратно. В рабочей системе часть признаков считается по другому окну, часть обновляется реже, часть приходит из другого сервиса, часть вообще стала называться иначе после обновления схемы. После этого можно сколько угодно обсуждать качество модели, но причина деградации уже не в ней. Причина в том, что платформа подаёт на вход разные вещи.Хранилище признаков нужно именно против этого. Не как отдельная модная коробка, а как контракт на расчёт и выдачу признаков. У каждого признака должна быть нормальная биография: из каких событий он считается, по какой формуле, на какой сущности, с каким окном, как быстро обновляется, в какой версии доступен, как выглядит его историческое значение на момент прошлого решения.
Здесь важно не перепутать роли. Хранилище признаков не должно становиться источником истины по сырым данным. Истина лежит в исходных событиях. Хранилище признаков держит производные величины. Это принципиальная разница. Если платформа начинает относиться к признакам как к первичным данным, она теряет возможность нормально пересчитывать историю после исправления логики.
Практически антифрод почти всегда делит признаки на две группы. Первая нужна в горячем контуре. Это то, что должно отдаваться за миллисекунды рядом со скорингом. Вторая нужна для обучения, анализа и длинной памяти. Эти группы часто пересекаются по смыслу, но живут в разном режиме.
Ниже типовой набор:
| Сущность | Пример признака | Где считается | Где нужен |
|---|---|---|---|
| Клиент | число новых получателей за 24 часа | потоковый слой | скоринг операции |
| Устройство | число аккаунтов на устройстве за 30 дней | пакетный слой | скоринг захвата аккаунта |
| Получатель | сумма входящих переводов за 1 час | потоковый слой | скоринг P2P |
| Заявка | число неуспешных KYC-проверок за 7 дней | пакетный + потоковый слой | онбординг, кредит |
Признак по получателю с окном в час нужен немедленно и должен обновляться почти сразу. Признак по устройству с горизонтом в 30 дней тяжёлый, но не требует пересчёта на каждой операции с нуля. Признак по KYC вообще может собираться из двух разных контуров: горячего и исторического.
Самая неприятная часть здесь - корректность по времени. Для обучения нельзя брать “самое свежее значение признака”, если в момент прошлого решения этого значения ещё не существовало. Это классическая ловушка. Модель выглядит сильной на истории просто потому, что в неё тихо утекло будущее. В антифроде такая ошибка особенно опасна: метки часто приходят с лагом, подтверждение фрода живёт отдельно, ручной разбор закрывает кейс через часы или дни, часть правды появляется только после спора по операции. Если этот лаг не встроен в подготовку данных, обучение превращается в красивую, но бесполезную математику.
Скоринговый слой
ML-модели: обучение и выдача оценки
Главная ошибка здесь - пытаться натянуть все сценарии на один общий балл риска. У транзакционного фрода, захвата аккаунта, KYC и synthetic identity разный горизонт наблюдения, разные признаки и разная цена ошибки. Поэтому в бою обычно живут несколько моделей: отдельно на операцию, отдельно на захват аккаунта, отдельно на онбординг и удалённую идентификацию, иногда отдельно на устройство или получателя.Транзакционный контур обычно держится на табличных признаках: сумма, канал, получатель, устройство, сессия, поведение клиента в коротком окне. Здесь чаще всего работают бустинговые модели. Аномальный детектор нужен для другого - подхватить новый сценарий, по которому ещё нет нормальной разметки. Он не заменяет основной скоринг, а добавляет отдельный сигнал.
Обучение и боевой расчёт нужно жёстко разводить. В обучении можно позволить себе длинную историю и сложную подготовку меток. В бою доступны только те признаки, которые реально успевают приехать до решения. Если модель обучалась на одном составе данных, а в проде получает другой, проблема уже не в качестве модели, а в контуре данных.
Выход модели сам по себе банку не нужен. Нужны калиброванный риск, версия модели, версия набора признаков и причины решения. Иначе любой спорный кейс превращается в разбор чёрного ящика.
Rule engine
Правила никуда не деваются. Они просто перестают быть центром системы.Их первая задача - жёсткие ограничения: стоп-листы, скомпрометированные реквизиты, обязательные проверки, технические блокировки. Это не надо предсказывать моделью.
Вторая задача - быстрый ответ на новый сценарий. Пока данные не собраны и модель не переобучена, правило закрывает дыру здесь и сейчас.
Третья задача - перевести риск в действие. Один и тот же уровень риска для перевода, кредита и KYC означает разную реакцию: где-то достаточно дополнительного подтверждения, где-то нужен ручной разбор, где-то отказ.
Критичен не сам набор правил, а управление ими. У каждого правила должны быть владелец, версия, причина появления и дата пересмотра. Иначе платформа быстро обрастает старыми условиями, которые продолжают резать поток уже после того, как сценарий фрода умер.
Hybrid scoring
Гибридный скоринг нужен там, где одного сигнала недостаточно. Модель по операции видит денежный риск. Модель по устройству - среду исполнения. Модель по аккаунту - контекст последних действий. Аномальный детектор ловит то, чего ещё нет в разметке. Правила переводят всё это в действие.
Плохая схема - усреднить всё подряд и назвать это ансамблем. Хорошая - явно определить роль каждого сигнала. Что повышает риск. Что требует дополнительного подтверждения. Что сразу ведёт в ручной разбор. Что блокирует операцию без обсуждений.
На выходе банку нужен не общий fraud score, а решение, которое можно разложить назад: какие признаки были доступны, какие модели сработали, какие правила применились и почему операция ушла именно в этот маршрут. Без этого гибридный скоринг быстро превращается в место, куда складывают всю неясность платформы.
Операционный слой
Case management
Ручной разбор нужен не для того, чтобы “досмотреть всё подозрительное”. Его задача уже: забрать дорогие и спорные случаи, где ошибка автоматики обходится слишком дорого. Если в ручную очередь уходит всё, что модель не поняла, значит у банка не операционный слой, а слив проблем из автоматического контура в людей.
Хороший кейс собирается вокруг решения, а не вокруг одной операции. Аналитику нужны сама операция, профиль клиента, цепочка последних действий, устройство, сессия, получатель, сработавшие правила, вклад моделей и история похожих случаев. Если этого нет, ручной разбор превращается в поиск по разным системам, а не в расследование.
Здесь же появляется ещё один обязательный слой - причины решения. Не балл риска, а нормальное объяснение, почему кейс попал в очередь: новое устройство, нетипичный получатель, всплеск активности, конфликт между KYC и поведением, плохой сигнал по документу, пересечение с уже известными сущностями. Без этого очередь быстро заполняется кейсами, которые аналитик всё равно начинает проверять с нуля.
Case management должен возвращать в платформу не комментарий свободным текстом, а структурированный результат. Тип фрода, источник подтверждения, итоговое решение, уровень уверенности, время закрытия кейса. Иначе ручной разбор не улучшает систему, а просто живёт рядом с ней.
SLA и эскалация
У ручного контура всегда есть соблазн забрать на себя слишком много. Особенно после всплеска фрода, когда банку проще добавить людей в очередь, чем чинить модель, признаки или правила. Это тупик. Очередь должна быть ограничена по смыслу и по времени.Обычно без трёх классов приоритета не обойтись. Первый - быстрые кейсы, где решение нужно почти сразу: переводы, критичные платёжные операции, возможный захват аккаунта. Второй - средний горизонт: сложный KYC, спорные кредитные заявки, подозрительные изменения профиля клиента. Третий - длинные кейсы: ретроспектива, связность по сущностям, dispute, friendly fraud, кольца получателей.
SLA нужен не как управленческая формальность. Он задаёт верхнюю границу, после которой ручной разбор уже не помогает бизнесу. Если кейс по переводу лежит слишком долго, деньги уже ушли. Если заявка на продукт висит часами без причины, банк сам режет воронку. Если аналитик работает без жёсткого времени реакции, ручной контур перестаёт быть частью антифрода и становится архивом подозрительных событий.
Эскалация должна срабатывать не только по уровню риска, но и по цене ошибки. Крупная операция, новый клиент с дорогим продуктом, конфликт между сильным модельным сигналом и “чистыми” правилами, повторяемый паттерн в нескольких каналах - всё это повод поднимать кейс выше, даже если формально он не самый высокий по баллу. И наоборот: поток мелких однотипных кейсов нельзя бесконечно таскать по верхним линиям разбора только потому, что система не умеет их нормально маршрутизировать.
Если коротко, операционный слой нужен не для подстраховки модели, а для работы там, где автоматическое решение уже упирается в цену ошибки, неполный контекст или необходимость расследования. Во всех остальных местах ручной разбор - симптом того, что основной контур ещё не собран как надо.
Во что это собирается в бою
Если смотреть на такую платформу целиком, у неё довольно приземлённая задача. Не “поймать весь фрод”. Не “поставить самую умную модель”. Ей нужно вовремя собрать вокруг события достаточно контекста, посчитать риск, выбрать действие и оставить после себя след, который потом можно проверить, объяснить и использовать повторно. Всё остальное - Kafka, Flink, feature store, модели, правила, ручной разбор - это не отдельные победы, а части одного контура.Банк обычно проигрывает в трёх местах. Первое - данные: событие уже пришло, а нужный контекст ещё нет. Второе - решение: модель, правила и маршрут обработки живут отдельно и дают разный ответ на одну и ту же ситуацию. Третье - обратная связь: кейс разобрали, но результат не вернулся в обучение, признаки и правила. После этого система не развивается, а просто каждый день заново встречает один и тот же класс проблем.
Если статья и должна оставить после себя одну полезную мысль, то она простая. В банке антифрод - это уже не “модель рядом с процессингом”. Это отдельная архитектура принятия решений. И если она собрана слабо, это очень быстро становится видно по потерям, очередям и по тому, сколько хороших клиентов система режет вместе с плохими.
