Утром менеджер видит десяток «заказов»: оплата картой, доставка в разные города, суммы выше средних, аккаунты созданы час назад. Через неделю приходят чарджбэки — платежи были по краденым картам, а магазин остаётся и без денег, и со штрафом от банка. Или тише: кто-то регистрирует сотни аккаунтов, чтобы собрать приветственные бонусы и промокоды, и маркетинговый бюджет утекает мимо реальных клиентов.
Эта статья — о том, как выстроить антифрод для интернет-магазина на 1С-Битрикс: с чего начать, какие сигналы риска собирать, как работает скоринг заказа, где проходит граница между простыми правилами и машинным обучением и как всё это связано с проактивной защитой и WAF. Разберём практично, без магии «нейросети всё решат», и покажем, где помогает автоматизация на 1С.
Коротко
- Фрод — это не только потери денег, но и чарджбэки, штрафы и слитый маркетинговый бюджет; защищать нужно оборот.
- Начинайте с правил и данных заказа, а машинное обучение подключайте, когда правил слишком много и мошенники подстраиваются.
- Скоринг превращает сигналы заказа в оценку риска: низкий — авто, средний — на проверку, высокий — блок или верификация.
- WAF и проактивная защита Битрикс закрывают уровень запросов, антифрод заказов — уровень бизнес-логики; нужны оба слоя.
Что такое фрод и во что он обходится
Фрод — это любые мошеннические действия вокруг заказа, оплаты и акций магазина. В отличие от «обычного» брака или ошибок, фрод целенаправлен: кто-то пытается получить товар, деньги или выгоду обманом. Коварство в том, что прямые потери — лишь верхушка. Платёж по краденой карте оборачивается чарджбэком: банк возвращает деньги владельцу карты, а магазин теряет и товар, и сумму, да ещё платит штраф. Высокая доля чарджбэков грозит повышенными комиссиями и даже отключением эквайринга.
Поэтому антифрод — это про экономику, а не про паранойю. Задача — не «поймать всех плохих», а держать потери от мошенничества на приемлемом уровне, не мешая честным покупателям. Это баланс: чрезмерная строгость режет выручку, чрезмерная мягкость — открывает дыру.
Виды мошенничества в магазине
Прежде чем защищаться, полезно понимать, от чего именно. Типовые сценарии в e-commerce:
- Платежи по краденым картам. Оплата чужой картой с последующим чарджбэком — самый дорогой вид фрода.
- Злоупотребление промо и бонусами. Массовая регистрация ради приветственных бонусов, промокодов, реферальных наград.
- Фейковые заказы наложенным платежом. Заказы, которые никто не собирается выкупать, — потери на логистике.
- Злоупотребление возвратами. Возврат подменённого или использованного товара, «профессиональные возвращенцы».
- Атаки на аккаунты. Брутфорс паролей, перехват личных кабинетов, кража накопленных бонусов.
- Накрутка и парсинг. Массовые запросы к каталогу, скликивание, автоматизированные боты.
Разные сценарии требуют разной защиты: где-то работает WAF, где-то — скоринг заказа, где-то — верификация оплаты. Единой «кнопки антифрода» нет, есть слои обороны.
Правила против машинного обучения
Главный вопрос новичка — «нужна ли нам нейросеть». Почти всегда ответ: не сразу. Сравним подходы.
| Критерий | Правила | Машинное обучение |
|---|---|---|
| Старт | Быстро, понятно | Нужны данные и время |
| Прозрачность | Легко объяснить решение | Оценка часто «чёрный ящик» |
| Сложные связи | Плохо ловит комбинации | Улавливает неявные паттерны |
| Адаптивность | Меняется вручную | Переобучается на новых данных |
| Поддержка | Простая, но правил много | Сложнее, нужен процесс |
Разумный путь — эволюция. Сначала набор понятных правил по данным заказа; они ловят очевидный фрод и дают статистику. Когда правил становятся десятки, они конфликтуют, а мошенники подстраиваются — подключают ML, который работает поверх тех же сигналов и находит сложные комбинации. Машинное обучение не заменяет правила, а дополняет их.
Какие сигналы риска собирать
Качество антифрода определяется набором сигналов. В магазине на 1С-Битрикс их можно собрать из объекта заказа, данных пользователя, событий и технических параметров запроса:
- Параметры заказа. Сумма, состав, способ оплаты и доставки, несовпадение города плательщика и получателя, необычно крупный первый заказ.
- Поведение. Возраст аккаунта, история заказов и возвратов, скорость оформления, число неудачных попыток оплаты.
- Технические данные. IP и гео, признаки прокси/VPN, отпечаток устройства, частота заказов с одного IP или устройства.
- Платёжные сигналы. Оценки риска от эквайринга и платёжного провайдера, результаты 3-D Secure.
- Связи между заказами. Один адрес доставки на много аккаунтов, повторяющиеся телефоны и карты.
Многие из этих сигналов формируются в связке сайта и учётной системы: история клиента, возвраты, платёжная дисциплина живут не только на сайте. Свести данные воедино помогает автоматизация продаж и склада на 1С — тогда скоринг видит полную картину клиента, а не обрывок.
Как устроен скоринг заказа
Скоринг — это превращение сигналов в решение. Каждому заказу присваивается оценка риска: число (например, 0–100) или класс «низкий / средний / высокий». Дальше по порогам определяется судьба заказа.
- Сбор признаков. В момент оформления собираются сигналы заказа, пользователя и запроса.
- Оценка. Правила или модель превращают признаки в оценку риска.
- Решение по порогам. Низкий риск — авто-подтверждение; средний — ручная проверка; высокий — блок или дополнительная верификация.
- Обратная связь. Итог (фрод/не фрод, чарджбэк, выкуп) возвращается в систему и улучшает будущие оценки.
Ключевой нюанс — не блокировать всё подряд. Для спорных заказов лучше мягкий сценарий: попросить подтвердить оплату, позвонить, включить 3-D Secure. Жёсткая блокировка — только для явного риска. Так вы ловите фрод, не теряя честных клиентов на ложных срабатываниях.
Проактивная защита и WAF Битрикс
Ниже уровня заказов работает защита уровня запросов — и в 1С-Битрикс она встроена. Проактивная защита и WAF (веб-фаервол) фильтруют вредоносный трафик до того, как он дойдёт до бизнес-логики.
- WAF. Отсекает инъекции, XSS, попытки эксплуатации уязвимостей на уровне HTTP-запросов.
- Проактивный фильтр. Экранирует потенциально опасные данные во входящих параметрах.
- Ограничение частоты. Защита от брутфорса паролей и массовых обращений к формам.
- Контроль сессий и админки. Одноразовые пароли, привязка сессии, журналирование действий.
WAF не оценивает «честность» заказа — он не даёт перебирать пароли, долбить формы и эксплуатировать дыры. Антифрод заказов делает работу выше. Вместе они образуют эшелонированную оборону. Как выстраивать безопасные точки входа для внешних систем, мы разбираем в статье про REST, вебхуки и безопасность в Битрикс — уведомления от платёжных и антифрод-сервисов приходят именно так, и их нужно защищать.
ML-слой: обучение и признаки
Когда правил становится слишком много, подключают модель. Машинное обучение здесь — это классификатор, который по набору признаков заказа предсказывает вероятность фрода. Важно понимать инженерную сторону.
- Обучение офлайн. Тяжёлое обучение идёт не на боевом сайте, а в отдельном процессе на исторических данных о заказах и подтверждённом фроде.
- Признаки те же. Модель питается сигналами из предыдущего раздела — качество признаков важнее «крутости» алгоритма.
- Быстрый инференс. В момент оформления вызывается готовая модель или внешний антифрод-API; оценка должна быть быстрой.
- Регулярное переобучение. Мошенники меняют тактику, поэтому модель периодически обновляют на свежих данных.
На стороне сайта ML-скоринг удобно оформить как асинхронный вызов или обращение к сервису, чтобы не тормозить оформление. Доступ к данным заказа для формирования признаков в современном Битрикс делают через ORM. Как работать с данными правильно и производительно, мы описали в материале про D7 и ORM в Битрикс.
Интеграция с платёжными провайдерами
Не нужно изобретать весь антифрод самим — значительную часть работы делают платёжные системы и эквайринг. У них есть собственные модели риска, доступ к данным по картам и обязательные механизмы вроде 3-D Secure. Магазину важно правильно этим пользоваться:
- Включите 3-D Secure. Подтверждение платежа переносит часть ответственности за чарджбэк на банк-эмитент.
- Используйте оценки провайдера. Многие эквайринги возвращают уровень риска транзакции — учитывайте его в скоринге.
- Обрабатывайте статусы честно. Не выдавайте товар до подтверждённой оплаты по рисковым заказам.
- Защищайте вебхуки об оплате. Уведомления о платеже подписываются и проверяются, иначе их подделают.
Комбинация «оценка провайдера + собственный скоринг + WAF» закрывает большинство сценариев без дорогой самописной ML-системы. Собственную модель добавляют, когда объёмы и потери это оправдывают.
Метрики: точность против ложных блокировок
Антифрод без метрик — это стрельба вслепую. Нужно измерять две вещи одновременно: сколько фрода вы ловите и сколько честных заказов теряете по ошибке. Слишком строгие пороги дают красивую «пойманность», но режут выручку ложными блокировками; слишком мягкие — пропускают фрод.
| Метрика | О чём говорит | Риск перекоса |
|---|---|---|
| Доля пойманного фрода | Сколько мошенничества перехвачено | Гонка за 100% режет честных |
| Доля ложных блокировок | Сколько нормальных заказов зря отклонено | Прямые потери выручки |
| Доля на ручной проверке | Нагрузка на менеджеров | Слишком много — не справятся |
| Уровень чарджбэков | Итоговый финансовый результат | Главный ориентир баланса |
Практичный ориентир — не максимальная «пойманность», а минимальные общие потери: сумма ущерба от пропущенного фрода плюс упущенная выручка от ложных блокировок плюс стоимость ручных проверок. Пороги настраивают под этот баланс, а не под красивую цифру.
Внедрение пошагово
- Включите базовую защиту. Проактивная защита и WAF Битрикс, ограничение частоты, защита админки.
- Соберите сигналы. Данные заказа, поведения и запроса складывайте так, чтобы их можно было анализировать.
- Опишите правила. Понятные пороги риска по данным заказа с мягкими и жёсткими реакциями.
- Подключите провайдера. 3-D Secure и оценки риска эквайринга, защищённые вебхуки об оплате.
- Настройте очередь проверки. Спорные заказы уходят менеджеру, а не блокируются молча.
- Измеряйте. Считайте пойманный фрод, ложные блокировки, чарджбэки и нагрузку на проверку.
- Добавьте ML при необходимости. Когда правил слишком много — модель поверх собранных данных, обучаемая офлайн.
Чтобы правила и модели можно было безопасно менять и откатывать, полезен налаженный процесс выкладки. Как его выстроить, мы описали в статье про CI/CD и деплой в Битрикс.
Частые ошибки
- Сразу браться за нейросеть. Без данных и правил ML не взлетит и съест бюджет.
- Жёсткая блокировка без проверки. Честные клиенты уходят на ложных срабатываниях.
- Нет метрик. Непонятно, ловите вы фрод или режете выручку.
- Игнор 3-D Secure. Магазин берёт на себя чарджбэки, которых мог избежать.
- Незащищённые вебхуки об оплате. Поддельное уведомление «оплачено» открывает дыру.
- Скоринг тормозит оформление. Синхронный тяжёлый расчёт в момент заказа.
- Данные только с сайта. Без истории клиента из 1С скоринг видит половину картины.
Чек-лист
- Базовая защита включена. WAF, проактивный фильтр, ограничение частоты, защита админки.
- Сигналы собираются. Заказ, поведение, техданные и история клиента доступны для анализа.
- Правила описаны. Пороги риска с мягкими и жёсткими реакциями.
- Провайдер подключён. 3-D Secure, оценки риска, защищённые вебхуки.
- Есть очередь ручной проверки. Спорные заказы уходят менеджеру.
- Метрики считаются. Пойманный фрод, ложные блокировки, чарджбэки, нагрузка.
- ML — по необходимости. Модель добавляется, когда правил слишком много и это окупается.
Вывод
Антифрод — это не одна нейросеть, а слоёная оборона: WAF и проактивная защита на уровне запросов, скоринг заказов на уровне бизнес-логики, механизмы платёжного провайдера на уровне оплаты. Начинать нужно с чистых данных и понятных правил, а машинное обучение подключать, когда мошенники подстраиваются, а правил становится слишком много. Главная метрика — не «поймать всех», а минимальные общие потери с учётом выручки, которую вы не хотите терять на честных клиентах.
Соберите сигналы, свяжите сайт с историей клиента в 1С, включите базовую защиту и мягкую верификацию для спорных заказов — и вы срежете большую часть фрода ещё до того, как задумаетесь о собственной модели.
