План расследования падения доли одобренных платежей

Вчера компания одобряла 86% попыток оплаты. Сегодня доля одобренных платежей снизилась до 74%. Одновременно увеличилась очередь ручной проверки, служба поддержки начала получать больше жалоб, а один из мерчантов сообщил, что добросовестные покупатели больше не могут завершить оплату.

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

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

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

Цель расследования

По итогам проверки необходимо получить точные ответы на четыре вопроса:

— действительно ли доля одобрений снизилась

— какие операции сформировали изменение

— какое событие или нарушение стало причиной

— какое исправление можно применить, не создавая новую уязвимость

Семь этапов расследования причины

Расследование должно последовательно пройти путь от подтверждения показателя до проверки исправления. Если пропустить первые этапы, команда рискует изменить не ту часть платёжного процесса и скрыть настоящую причину.

Подтвердить снижение

Проверить расчёт, состав операций и сравниваемые периоды до поиска возможной причины.

Выделить затронутую часть потока

Найти минимальную группу мерчантов, каналов, стран или клиентов, где сосредоточено падение.

Найти предшествовавшее изменение

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

Отделить решение от технического сбоя

Определить, является ли результат запланированным действием защиты или следствием ошибки.

Сопоставить защиту и ущерб

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

Применить обратимое исправление

Ограничить изменение проблемной областью и сохранить возможность вернуть прежнее состояние.

Проверить итоговый результат

Убедиться, что доля одобрений восстановилась без возвращения исходного риска.

Шаг 1. Подтвердить реальность снижения

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

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

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

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

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

Искать причину следует только после подтверждения снижения на сопоставимом и полном массиве операций.

Шаг 2. Выделить затронутые операции

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

Затронутые операции необходимо разделить по следующим признакам:

— мерчант и категория деятельности

— страна и география клиента

— способ оплаты и банк, выпустивший карту

— мобильный канал, браузер и прямое подключение

— новые и постоянные клиенты

— диапазоны сумм операций

— сработавшие правила, уровни риска и конечные действия

— точное время начала изменения

Цель состоит в том, чтобы найти минимальную осмысленную группу, внутри которой падение сохраняется. Если общий показатель снизился с 86% до 74%, но доля одобрений постоянных клиентов остаётся на уровне 87%, расследовать нужно прежде всего поток новых клиентов, а не всю систему.

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

Шаг 3. Установить предшествовавшее событие

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

К возможным причинам относятся:

— включение нового правила защиты от мошенничества

— изменение порога правила или итоговой оценки риска

— новая версия расчёта либо дополнительный признак

— изменение состава данных или соответствия полей

— выпуск новой версии мобильного приложения или платёжной страницы

— подключение нового мерчанта или маршрута обработки

— изменение дополнительного подтверждения или ответа платёжного партнёра

— сбой внешнего источника данных

Совпадение по времени ещё не доказывает причинную связь, но существенно сужает поиск. Если доля одобрений начала падать в 14:10, а новое правило было включено в 14:05, его нужно проверить в первую очередь. Если ухудшение началось несколькими часами раньше, первоначальное предположение может оказаться ошибочным.

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

Шаг 4. Отделить решение от сбоя

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

Внутреннее правило может намеренно отклонять операцию. Итоговая оценка риска может переводить платежи выше порога ручной проверки или отказа. Обязательное поле может отсутствовать, из-за чего применяется запасное защитное действие. Внешняя система подтверждения может не отвечать. Банк или платёжная система способны отклонить операцию независимо от внутренней защиты компании.

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

Для выборки затронутых операций необходимо восстановить весь путь решения:

— сведения, полученные в начале оплаты

— применённые правила и признаки риска

— ответ системы дополнительного подтверждения или внешней службы

— внутреннее решение и указанный код причины

— ответ обработчика платежа или банка

— окончательный результат, который увидели клиент и мерчант

Такая проверка отделяет правильное защитное действие от неисправного платёжного процесса. Без неё команда может ослабить полезное правило и одновременно оставить техническую ошибку без исправления.

Шаг 5. Сопоставить защиту и последствия

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

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

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

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

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

Шаг 6. Применить ограниченное исправление

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

В зависимости от причины команда может:

— временно вернуть прежний порог

— исключить один мерчант или один канал

— заменить отказ дополнительным подтверждением или ручной проверкой

— исправить передачу данных или повторный подсчёт одного события

— установить безопасное действие при отсутствии обязательных сведений

— ограничить правило определённой страной, суммой или группой клиентов

— назначить срок автоматического прекращения временной настройки

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

Шаг 7. Проверить восстановление показателя

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

В течение периода проверки следует сравнивать:

— общую долю одобрений и показатели отдельных групп

— количество срабатываний правил и отказов

— объём и срок ожидания ручной проверки

— подтверждённое мошенничество и подозрительную активность

— ошибки дополнительного подтверждения и технические сбои

— жалобы клиентов и сообщения мерчантов

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

Ответственные и необходимые доказательства

Этап расследования	Основной ответственный	Необходимые доказательства	Результат этапа
Подтверждение показателя	Специалист по анализу рисков	Порядок расчёта, полные периоды и исходный массив операций	Подтверждённое снижение и точное время начала
Выделение затронутой группы	Команда защиты от мошенничества	Разделение по мерчантам, странам, каналам, клиентам и правилам	Точно определённая группа операций
Поиск предшествовавшего изменения	Продуктовая или техническая команда	Журналы включения, история правил и записи настроек	Перечень наиболее вероятных причин
Проверка причины	Специалисты по данным и мошенничеству	Путь операций, значения полей и причины решений	Подтверждённое защитное решение или технический сбой
Выбор временной меры	Руководитель направления рисков	Возможные потери, влияние на клиентов и доступные варианты	Согласованное обратимое исправление
Проверка восстановления	Специалист по проверке качества	Показатели после изменения, результаты и новая выборка	Закрытие, дополнительная настройка или передача руководству

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

Практическая ситуация

После изменения правила падают мобильные одобрения

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

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

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

Немедленный возврат старого порога скрыл бы проблему с данными. Сохранение новой настройки продолжило бы блокировать обычных покупателей.

Временная мера

Заменить автоматический отказ ручной проверкой для затронутой версии приложения.

Техническое исправление

Объединять повторные запросы одной операции до подсчёта попыток клиента.

Проверка результата

Повторно проверить правило на настоящих операциях до возвращения окончательного отказа.

Когда расследование можно завершить

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

Доля одобрений добросовестных операций должна вернуться к приемлемому уровню, а первоначальный риск — остаться под контролем. Итоговую настройку, ответственного, изученные доказательства и период последующего наблюдения необходимо зафиксировать.

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

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

Вывод: сначала расследовать, потом отменять

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

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

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

Команды, которым нужен последовательный подход к построению, испытанию, запуску, контролю и улучшению мер защиты от мошенничества, могут изучить курс по внедрению антифрод-системы от Riskscenter.