6.4. Тонкая настройка обнаружения мошеннических платежей

6.4.1. Снижение уровня ложного срабатывания системы

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

Для снижения уровня ложного срабатывания необходимо:

  • определить список правил, которые наиболее часто формируют ложное срабатывание

  • определить массовость проблемы - т.е. относится ли ложное срабатывание ко всем клиентам, либо ярко выражена только среди определенных клиентов

  • скорректировать настройки профиля обнаружения мошеннических платежей (либо создать новый профиль, если проблема не является массовой)

Для определения наиболее часто срабатывающих правил, в системе FraudWall предусмотрен удобный интерфейс получения аналитических и статистических отчетов по срабатыванию правил (пункт «Статистика - правила» меню «Аналитика»).

Для определения массовости проблемы необходимо воспользоваться интерфейсом поиска платежей (Пункт «Все» меню «Платежи»). В критериях поиска платежей необходимо задать номер анализируемого правила:

Рисунок 62. Поиск документов по правилу с заданным номером

Поиск документов по правилу с заданным номером

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

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

Привязать профиль к клиенту можно через интерфейс просмотра аналитики по клиентам банка (интерфейс «Плательщик» меню «Аналитика»):

Рисунок 63. Установка профиля на уровне клиента банка

Установка профиля на уровне клиента банка

6.4.2. Повышение вероятности обнаружения мошеннических платежей

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

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

  • Устанавливать параметр «уровень использования встроенных правил» в максимальное, а для особо важных клиентов - в параноидальное значение.

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

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

  • Устанавливать значения диапазонов сумм в свойствах профиля исходя из особенностей региона, где работает каждый филиал

  • Если клиенту не требуется платить в пользу платежных шлюзов, рекомендуется установить небольшое значение (100 - 200 рублей) в поле «сверхбольшая сумма платежей в пользу платежных шлюзов».

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

6.4.3. Использование утилиты fw_forecast

В процессе своей работы на каждом сервере FraudWall в директории /var/log/archive/statistics формируются обезличенные лог-файлы обработки платежных поручений. Эти файлы могут быть проанализированы с целью поиска оптимальных значений параметров обнаружения как на стороне банка, так и на стороне технической поддержки.

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

Для ее запуска необходимо выполнить команду: fw_forecast -i ID

где ID - идентификатор профиля, настройки которого будут анализироваться - его можно посмотреть в Web-интерфейсе "Система\Конфигурирование\Профили". Чтобы оценить уровень ложного срабатывания с настройками по умолчанию, укажите значение "0".

Внимание

Для наиболее достоверной оценке уровня ложного срабатывания необходимо, чтобы в директории /var/log/archive/statistics были журналы событий минимум за месяц эксплуатации на реальных данных.