Антифрод: как продукт защищает деньги и не мешает честным клиентам

Половина путаницы в теме возникает до первого технического вопроса. Слово одно, систем три, и задачи у них не пересекаются.

Каталог сценариев зависит от того, что в вашем сервисе можно превратить в деньги. Обычно набор такой.

Любая система защиты ошибается двумя способами, и обе ошибки стоят денег.

Пропущенный фрод. Мошенник прошёл, компания потеряла товар, бонус или выплату. Эту потерю видно в отчёте, поэтому её считают всегда.

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

Вторая ошибка почти всегда дороже, и вот почему. Мошенник вернётся другим способом и попробует снова, а честный клиент, которому отказали на оплате, уходит к конкуренту и часто больше не возвращается. К прямой потере заказа добавляется стоимость его привлечения и обращение в поддержку.

Посчитать это можно на своих числах. Магазин с оборотом 50 млн ₽ в месяц, средним чеком 5 тыс. ₽ и долей фрода 0,5% теряет на мошенничестве около 250 тыс. ₽. Правило, которое заодно режет 3% честных заказов, отнимает 300 сделок, то есть 1,5 млн ₽ выручки и около 375 тыс. ₽ маржи при рентабельности 25%. Вторая ошибка тут дороже первой в полтора раза, и это ещё без учёта стоимости привлечения потерянных клиентов.

Отсюда единственный правильный ориентир настройки. Считаем не «сколько фрода поймали», а сумму двух потерь, и настраиваем систему так, чтобы эта сумма была минимальной. Обычно оптимум находится там, где часть мелкого фрода сознательно пропускают: ловить его дороже, чем терять.

Решение принимается на данных, и здесь проекты чаще всего спотыкаются: нужных событий просто нет в базе.

Про клиента. История заказов, оплат, возвратов и обращений. Возраст аккаунта, подтверждённые контакты, поведение до текущего действия.

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

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

Про связи. Совпадения между аккаунтами по адресу, телефону, платёжному средству, адресу доставки. Именно связи ловят промо-абьюз и фрод на выплатах, и именно их обычно нигде не считают.

Все четыре группы должен писать бэкенд, причём писать заранее. Данные для антифрода нельзя собрать задним числом. Если события не сохранялись, обучать и настраивать нечего, и проект начинается с полугода накопления истории. Из чего вообще состоит серверная часть продукта, разобрано в материале про бэкенд.

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

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

Рабочий набор правил отличают от свалки три вещи.

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

Правила поверх настроек означают, что менять их может аналитик без разработчика. Иначе каждая новая мошенническая схема ждёт релиза.

Порог перехода вполне конкретный. Правил стало столько, что их взаимное влияние никто не держит в голове, и каждое новое ломает два старых.

Скоринг заменяет набор условий одной оценкой риска. Модель учится на истории размеченных случаев и выдаёт число, а правила остаются сверху для того, что регулируется вручную.

Без трёх условий модель не нужна.

• Размеченная история. Нужны подтверждённые случаи фрода и подтверждённые честные операции. Без разметки модель учиться не на чем.
• Объём. Мошеннических случаев всегда мало относительно нормальных, и на редких событиях модель переучивается на шум.
• Обратная связь. Решения аналитика должны возвращаться в обучающую выборку, иначе модель устареет за сезон.

Практика такая: скоринг почти никогда не заменяет правила целиком. Он берёт на себя серую зону, где человек не может сформулировать условие, а правила остаются там, где решение диктует бизнес или регулятор.

Между «пропустить» и «заблокировать» лежит несколько вариантов, и хорошая система использует их все.

• Пропустить с пометкой. Операция проходит, но попадает в отчёт для последующего анализа. Подходит для слабых сигналов.
• Запросить подтверждение. Дополнительный шаг проверки для клиента. Стоит дёшево, отсекает часть автоматических атак, но раздражает при частом применении.
• Задержать. Операция ставится в очередь на несколько минут или до подтверждения оплаты. Мошеннику это ломает сценарий, честному клиенту почти незаметно.
• Урезать. Заказ проходит, но без рассрочки, без оплаты при получении или без применения промокода. Часто лучший вариант: сделка сохраняется, риск снимается.
• Отправить на разбор. Решение принимает человек. Дорого, поэтому применяется к дорогим операциям.
• Отклонить. Крайняя мера для сильных сигналов и высоких сумм.

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

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

На одном экране аналитику нужны сама операция, история клиента, сработавшие правила с весами, связанные аккаунты и итоговая оценка риска. Если для решения нужно открыть три системы, разбор занимает двадцать минут, и очередь копится быстрее, чем разбирается.

Второе требование — действия в один клик. Подтвердить, отклонить, запросить документы, добавить в список исключений, отметить как подтверждённый фрод. Последнее особенно важно: именно эти отметки становятся разметкой для будущей модели.

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

Третье — обратная связь клиенту. Отказ без объяснения превращает честного покупателя во врага. Формулировка не должна раскрывать логику проверки, но должна давать понятный следующий шаг.

Четыре цифры, и первые две обязаны идти в одном отчёте.

Цифры регулятора полезны как фон. Они объясняют, почему давление растёт, и задают ожидания клиентов.

По данным Банка России, за 2025 год объём операций без добровольного согласия клиентов составил 29,3 млрд ₽ — на 6,4% больше, чем годом раньше. Число таких операций выросло на 31,2%, до 1,6 млн. Банки вернули клиентам 1,7 млрд ₽, то есть 5,9% похищенного, и предотвратили 134,2 млн мошеннических операций.

Разделите одно на другое, и получится средняя сумма около 18 тыс. ₽. Для продуктового антифрода это главный вывод: массовый фрод состоит из множества мелких операций. Защита, рассчитанная на редкие крупные атаки, такой поток не видит.

Ещё показательнее история с быстрыми платежами. Во втором квартале 2026 года через Систему быстрых платежей похитили 2,74 млрд ₽ при более чем 129 тыс. случаев, и это максимум за всё время наблюдений. Доля возмещения по таким операциям упала до 2,1%: перевод инициирует сам клиент, и развернуть его почти невозможно.

Регуляторная рамка тоже сдвинулась. С 1 января 2026 года применяется новый перечень признаков перевода без добровольного согласия клиента — приказ Банка России от 05.11.2025 № ОД-2506, заменивший прежний приказ 2024 года. Перечень расширен, в нём появились признаки для цифрового рубля, а признак совпадения получателя со сведениями государственной информационной системы противодействия правонарушениям применяется с 1 марта 2026 года.

Разграничение полезно проговорить до проекта, потому что часть ожиданий не сбудется ни при каком бюджете.

Что делаете вы. Правила и скоринг по своим событиям, решения по заказам, регистрациям, возвратам, бонусам и выплатам. Рабочее место аналитика. Обмен сигналами с платёжным провайдером в том объёме, который он предоставляет.

Чего вы не сделаете. Не увидите правила банка и не оспорите его решение по конкретной операции. Не получите доступ к базе Банка России о подозрительных получателях. Не остановите перевод, инициированный клиентом в его банке. Не закроете подмену телефонного номера — это телеком-слой.

Что делают за вас. Банк и платёжный провайдер применяют требования регулятора и держат свою проверку на стороне платежа. Проверка защищённости кода и инфраструктуры — это аудит кода и архитектуры, отдельная работа с отдельным результатом.

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

Объём работ задают три параметра. Число защищаемых операций, число сигналов, которые уже собираются, и наличие ручного разбора.

По нашим работам: заказная система под процесс — от 1,7 млн ₽, бэкенд и веб-часть с рабочим местом аналитика — от 1 млн ₽, скоринг на своих моделях — от 1,8 млн ₽, отдельная интеграция с платёжным провайдером или внешним сервисом проверки — от 150 тыс. до 1,5 млн ₽, аудит существующей защиты и данных — от 200 до 600 тыс. ₽. Точную цифру считаем по вашим сценариям: оценка проекта бесплатная.

Порядок бюджета можно прикинуть заранее — бесплатный калькулятор оценки собирает вилку по составу работ за несколько минут.

Считают только пойманный фрод. Отчёт красивый, а сколько честных клиентов ушло на оплате, не знает никто.

Правила живут в коде. Каждая новая схема мошенника ждёт релиза, и защита всегда отстаёт на две недели.

Новое правило включают сразу в бой. Режима наблюдения нет, и правило неделю режет нормальные заказы, прежде чем кто-то заметит.

Единственное действие — блокировка. Систему настраивают между «пропустить» и «отклонить», хотя задержка и урезание закрыли бы половину случаев без потери сделки.

События начинают собирать вместе с проектом. Истории нет, скоринг обучать не на чем, и первые полгода уходят на накопление данных.

Первое — посчитать потери по источникам. Чарджбэки, возвраты, бонусы, выплаты партнёрам и промокоды считаем отдельными строками. Одна общая сумма ничего не подсказывает. Обычно выясняется, что основная потеря там, где её не искали.

Второе — измерить отказы. Сколько операций отклонено за месяц и какая часть из них была нормальной. Достаточно выборки в сто случаев, разобранных руками, чтобы понять масштаб второй ошибки.

Третье — проверить события. Пишутся ли устройство, история и связи между аккаунтами, и сколько истории уже накоплено. Ответ на этот вопрос определяет, начинаете вы с правил или сначала со сбора данных.