Транзакционный антифрод
Антифрод на базе Accelera объединяет анализ поведения, проверку операций по правилам и ручное расследование подозрительных случаев. Команда противодействия мошенничеству настраивает признаки риска и логику реакции, используя модули платформы.
Решение предназначено для руководителей антифрод-направления, аналитиков и специалистов по расследованиям. Оно применяется к финансовым и нефинансовым операциям, для которых доступны необходимые данные и определён способ исполнения решения.
Какие задачи решает
- Проверка операции до исполнения: оценить параметры запроса и контекст клиента, вернуть решение вызывающей системе.
- Выявление подозрительной последовательности событий: например, смена устройства с последующим переводом новому получателю.
- Подготовка признаков риска: хранить характеристики клиента и использовать агрегаты его активности за заданный период.
- Ручное расследование: создать инцидент, передать его специалисту и продолжить обработку с учётом результата.
- Анализ срабатываний: сопоставлять решения и сработавшие правила с результатами расследований для изменения конфигурации.
Конкретные схемы выявления мошенничества, пороги и наборы признаков определяются при настройке решения.
Как работает решение
В решении связаны два процесса: подготовка контекста по событиям и синхронная проверка операции.
Подготовка контекста. Flow и Segments формируют индивидуальные профили клиентов и других объектов — например, устройств, счетов и получателей переводов — и фиксируют динамические ситуации, важные для проведения операций. Flow обрабатывает события в реальном времени, а Segments рассчитывает характеристики и выявляет ситуации по накопленным данным. Например, в контексте можно зафиксировать недавнюю смену устройства или изменение активности клиента. К моменту проверки операции подготовленные характеристики и признаки ситуаций доступны для принятия решения.
Учёт индивидуального поведения. Подготовленный профиль позволяет оценивать операцию с учётом привычного поведения клиента: сумм и частоты операций, получателей, устройств и географии. Например, одна и та же сумма перевода может быть обычной для одного клиента и нетипичной для другого. Какие характеристики накапливать и какие отклонения учитывать, определяется настройками сценариев и правил.
Проверка операции. До исполнения операции внешняя система обращается к модулю «Решения по операциям». Модуль распознаёт тип события, дополняет запрос данными профиля и агрегатами скользящих окон, применяет таблицы решений и возвращает ответ в том же запросе.
Исполнение и расследование. Система, которая обрабатывает операцию, применяет полученный ответ. При настроенной передаче результата во Flow сценарий может создать инцидент в Case Management. Специалист рассматривает его; результат завершения задачи передаётся в сценарий для дальнейших действий.
Отправка результата во Flow, создание инцидента и реакция на итог расследования требуют настройки. Возврат кода решения сам по себе не блокирует операцию и не создаёт задачу специалисту.
Состав решения
| Компонент | Роль в антифроде |
|---|---|
| Решения по операциям — Sync Decision / Online Engine | Синхронная проверка запроса, обогащение данными, выполнение правил и возврат решения |
| Flow | Индивидуальное профилирование и фиксация динамических ситуаций на потоке событий в реальном времени; запуск действий |
| Профиль клиента | Хранение настроенных характеристик, которые используются при проверке |
| Скользящие окна | Агрегаты активности за заданный период: например, количество и сумма операций |
| Segments | Индивидуальное профилирование, выявление и фиксация динамических ситуаций по накопленным данным; подготовка списков контроля |
| Case Management | Очереди инцидентов, экран расследования, работа специалиста и передача результата |
| FinCert — для банковского решения | Загрузка и обновление данных ФинЦЕРТ Банка России для использования в антифрод-проверках |
| Адаптеры и действия | Получение событий, подключение систем и выполнение настроенной реакции |
| Журнал решений и аналитические данные | Разбор запросов и срабатываний таблиц решений |
Для проверки операции используется синхронный модуль и необходимые ему данные. Flow, сегментация и Case Management подключаются в соответствии с процессом. Состав поставки и доступность функций уточняются для выбранной версии и установки.
Пример: смена устройства и перевод новому получателю
Это пример конфигурации, а не готовое правило, автоматически включённое во всех установках.
- Система дистанционного обслуживания передаёт событие смены устройства с идентификатором клиента и временем события.
- Сценарий Flow записывает соответствующий признак в профиль. Срок актуальности признака определяется логикой сценария.
- При попытке перевода система-источник отправляет запрос на проверку: клиент, сумма, получатель и другие согласованные параметры.
- Модуль решений получает признаки из профиля и доступные агрегаты активности. Признак нового получателя должен быть подготовлен из истории или передан в запросе.
- Таблицы решений проверяют сочетание признаков: недавняя смена устройства, новый получатель, необычная сумма или частота операций. Условия и пороги задаёт антифрод-команда.
- Вызывающая система получает решение и применяет согласованную реакцию.
- Если требуется расследование, настроенный сценарий создаёт инцидент с данными операции и контекстом проверки. Результат работы специалиста используется в дальнейшей обработке.
Для этого сценария важно, чтобы событие смены устройства успело обновить профиль до проверки перевода. Приём события и доступность нового признака в синхронном запросе — разные этапы; их порядок проверяется при интеграции.
Решение и действие по операции
| Результат проверки | Что происходит дальше |
|---|---|
| Разрешить | Вызывающая система продолжает обработку операции |
| Отказать | Вызывающая система применяет отказ согласно согласованному контракту |
| Направить на расследование | Настроенный процесс создаёт инцидент; вызывающая система определяет судьбу операции на время проверки |
Названия результатов описывают бизнес-смысл. Формат ответа и коды зависят от адаптера и интеграционного контракта. Задержка операции до окончания расследования и её последующее возобновление требуют поддержки со стороны системы обработки операций.
Работа аналитика и специалиста
Антифрод-аналитик настраивает распознавание операций, условия правил, веса и пороги таблиц решений. Для проверки новой логики предусмотрен режим таблицы-«молчуна»: таблица рассчитывается и фиксируется в журнале, но не влияет на итоговое решение.
Специалист по расследованиям работает с очередью инцидентов в Case Management: берёт задачу, изучает данные, сохраняет результаты или завершает рассмотрение. Состав экрана и действия при завершении задаются конфигурацией.
Для разбора оснований решения аналитик использует журнал запросов и результатов применения таблиц решений: сопоставляет данные операции со срабатываниями проверок и выясняет, что повлияло на результат. Эти сведения помогают разбирать инциденты и корректировать правила.
Изменение правил и анализ расследований образуют рабочий процесс команды. Автоматическое обучение модели по итогам расследований в это описание не входит.
Какие данные и интеграции нужны
| Данные или подключение | Для чего используются |
|---|---|
| Запрос на проверку операции | Передача параметров до исполнения и получение синхронного ответа |
| События поведения | Обновление контекста и запуск сценариев |
| Устойчивые идентификаторы клиента и связанных объектов | Связывание запроса, профиля, истории и инцидента |
| Профиль и история операций | Подготовка признаков и агрегатов для правил |
| API или действия внешних систем | Исполнение реакции и продолжение процесса после расследования |
| Результаты расследований | Анализ качества правил и разбор ложных срабатываний |
При использовании СБП применяется соответствующий адаптер. Поддерживаемые сообщения и формат ответа описаны в API Системы быстрых платежей.
FinCert в банковском решении
В состав антифрод-решения для банка входит модуль FinCert. Он загружает данные ФинЦЕРТ Банка России и обновляет их в таблицах базы данных. Подключение этих данных к проверкам операций определяется конфигурацией решения. Установка и настройка описаны в руководстве по интеграции с ФинЦЕРТ.
Работа банка с данными регулятора имеет нормативное основание. Статья 27 Федерального закона № 161-ФЗ предусматривает формирование базы данных Банка России, передачу участниками сведений о случаях и попытках переводов без добровольного согласия клиента и получение информации из этой базы. Банк России также относит наличие реквизитов получателя в своей базе к признакам мошеннического перевода, которые банки обязаны учитывать при проверке операций. См. разъяснения Банка России.
Регулятор устанавливает требования к процессам банка и информационному обмену. Модуль FinCert является компонентом Accelera для реализации части этих процессов; использование конкретного программного продукта законом не предписано.
В имеющейся документации модуля подтверждена загрузка и актуализация входящих данных. Отправку сведений в Банк России, полноту поддерживаемых форматов и выполнение всех применимых требований необходимо отдельно определить в составе банковского внедрения. При настройке также определяют, как данные поступают в правила проверки, как контролируется их актуальность и что происходит при ошибке обновления.
Условия запуска и ограничения
До запуска фиксируют проверяемые операции, источники признаков, правила реакции и границы ответственности систем. Отдельно согласуют поведение при отсутствии данных, ошибке и превышении времени ожидания ответа.
Недостаточная история клиента. При настройке определяют, каких данных и какой глубины истории достаточно для оценки привычного поведения. Для новых клиентов и объектов с неполной историей отдельно задают применимые проверки и пороги. Переход к общим порогам должен быть предусмотрен правилами; он не подразумевается автоматически.
Для проверки готовности решения используют следующие ситуации:
- обычная операция получает ожидаемое решение и корректно обрабатывается системой-источником;
- подозрительная комбинация признаков приводит к ожидаемому срабатыванию;
- таблица-«молчун» записывает результат, не меняя решение;
- операция с отсутствующим профилем или обязательным признаком обрабатывается по согласованной политике;
- при недоступности модуля или тайм-ауте вызывающая система выполняет согласованное действие;
- инцидент создаётся, доступен специалисту, а завершение расследования запускает требуемое продолжение;
- задержки и производительность проверены на выбранных правилах, объёме данных и целевой нагрузке.
В текущем описании модуля решений отсутствие поля приводит к невыполнению соответствующего условия, а нераспознанное событие — к ответу «пропустить». Поэтому покрытие типов операций и полноту данных необходимо проверить перед включением правил.
Синхронный модуль читает профиль и скользящие окна; их обновление выполняется другими компонентами. Он также не выполняет отложенную повторную проверку пропущенных запросов.
Время ответа и пропускная способность зависят от конфигурации и подтверждаются нагрузочными испытаниями. Это описание не задаёт универсальные значения SLA и не подтверждает соответствие регуляторным требованиям: для этого нужны отдельные основания по конкретной поставке и процессу.
Как оценивать результат
Для оценки решения можно использовать долю операций с отказом и направлением на расследование, долю подтверждённого мошенничества среди рассмотренных инцидентов, долю ложных срабатываний, время расследования, время ответа и количество технических ошибок.
Это предлагаемые показатели оценки, а не перечень готовых отчётов интерфейса. Для расчёта нужны данные о решениях, фактическом исполнении операций и результатах расследований.
Документация для настройки
- Решения по операциям — обзор — правила, таблицы решений и ограничения синхронной обработки.
- Flow — событийные сценарии.
- API Online Engine — контракт обращения за решением.
- Case Management — работа с инцидентами и настройка экранов.
- Интеграция и API — подключение источников и внешних систем.
Установка, администрирование и общие функции описываются в единой документации Accelera.