11. Интеграция FraudWall с информационными системами банка

11.1. Общее описание интеграции

11.1.1. С какими системами банка и для каких целей требуется интеграция

FraudWall является аналитической системой, которая для анализа получает следующую информацию:

Таблица 19. Источники данных

тип информации возможные источники
реквизиты платежных поручений, создаваемых посредством систем ДБО база данных ДБО, база данных АБС
реквизиты платежных поручений, создаваемых сотрудниками банка в системе АБС база данных АБС
дамп трафика работы клиентов в системе ДБО, поступающего на WWW-сервер банка WWW-сервер ДБО
история исполненных в АБС платежных поручений клиентов база данных ДБО, база данных АБС
реквизиты платежных поручений, поступающих из других банков база данных АБС
информацию о счетах клиенте банка (перечне его счетов и текущем остатке на счете) база данных ДБО, база данных АБС
контактную информацию о клиенте банка (ФИО, должность и контактный телефон представителей клиента (директор, гл.бухгалтер и т.д.) база данных ДБО, база данных АБС, база данных CRM
информацию о наличии вредоносной активности на стороне компьютера клиента облачные решения Kaspersky Fraud Prevention Cloud, Group-IB Bot-Trek Secure Bank, IBM Trusteer Pinpoint Malware Detection

Примечание

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

Например, информация о наличии вредоносной активности на стороне компьютера клиента требует интеграции с дополнительными решениями от компаний Group-IB, Kaspersky Labs или IBM Trusteer. Если такие решения в банке не внедрялись, FraudWall принимает решение о подозрительности платежа по оставшимся доступным ему данным.

В качестве основных данных для анализа выступает платеж, как до его исполнения в АБС, так и после.

Платежи после исполнения в АБС получаются посредством fraudwall_learn (см.11.3 «fraudwall_learn. Получение платежей, исполненных в АБС»).

Информация о платежах, еще не исполненных в АБС, может поступать из разных источников в зависимости от варианта интеграции:

  • из дампа трафика на стороне WWW-сервера банка

  • из VIEW fraudwall_doc (в режиме анализа платежей во VIEW fraudwall_doc, см. 11.11 «fraudwall_doc. Получение платежей для анализа»)

  • из fraudwall_alert (в режиме анализа платежей в таблице fraudwall_alert)

  • из HTTP/HTTPS-запроса внешней системы

FraudWall может одновременно получать и связывать информацию из нескольких источников данных. Например, один и тот же платеж может быть выявлен сначала в дампе трафика, затем он обнаружен в базе ДБО в VIEW fraudwall_doc, а затем он же обнаружен в базе АБС в таблице fraudwall_alert - для этого одного платежа FraudWall построит и отобразит в интерфейсе цепочку прохождения в разных системах банка.

При этом на всех этапах проверки платежа учитываются особенности, которые есть только на предыдущих этапах. Например, в АБС нет информации об IP адресе, с которого был создан платеж, поэтому при анализе платежа в fraudwall_alert такой информации нет. Но, т.к. до появления платежа в АБС FraudWall еще увидел этот же платеж в базе ДБО (или дампе трафика), в котором информация об IP адресе есть, при анализе платежа в АБС информация об IP адресе будет также учтена.

В качестве вспомогательных данных могут выступать:

  • информация об IP адресе, с которого была сессия клиента

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

  • информация от систем, выявляющих вредоносную активность на стороне компьютера клиента

  • информация о доступных средствах на счету клиента в момент создания платежа

  • и т.д.

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

Результатом работы FraudWall является:

  • статус обработки платежного поручения - является ли оно подозрительным или нет, нужно ли приостановить его дальнейшее исполнение в АБС

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

  • звонок клиенту для подтверждения подозрительного платежа (общение осуществляется полностью в автоматизированном режиме с помощью сервера синтеза и распознавания речи)

11.1.2. Остановка подозрительных платежей

11.1.2.1. Доработка АБС

Примечание

В некоторых случаях остановка подозрительного платежа может быть реализована не в АБС, а в ДБО. Но для удобства ниже по тексту подразумевается, что доработка будет реализована в АБС.

АБС должна выполнять следующие операции:

  • (только при интеграции в режиме анализа платежей в таблице fraudwall_alert) помещать в эту таблицу все платежи, подлежащие проверке, со значением поля статуса, равным "X".

  • блокировать исполнение платежей, реквизиты которых есть в таблице fraudwall_alert, но статус отличен от "g" или "G"

  • для платежей со статусом "j" помимо блокировки исполнения платежей также необходимо блокировать возможность изменения данного статуса в самой АБС на какой-либо другой (изменение данного статуса возможно только через интерфейс FraudWall, который затем выгрузит его в таблицу fraudwall_alert)

  • при открытии в интерфейсе АБС платежа, реквизиты которого есть в таблице fraudwall_alert со статусом "j", выводить на экран алерт с текстом: «Платеж не может быть проведен в АБС, т.к. находится на визуальном контроле в системе FraudWall» (или другой схожий по смыслу текст). Без возможности изменить статус в АБС.

  • при открытии в интерфейсе АБС платежа, реквизиты которого есть в таблице fraudwall_alert со статусом "S", выводить на экран соответствующее сообщение с краткой инструкцией для операциониста - что говорить клиенту, куда обращаться при подтверждении мошеннического платежа, об ответственности операциониста и т.д.С возможностью изменить статус в АБС.

  • запрашивать у операциониста текстовый комментарий с результатами общения с клиентом при изменении статуса в АБС сотрудником банка

  • хранить комментарий в журнале аудита действий сотрудника банка

  • в зависимости от результата общения с клиентом, выставлять статус (G - "создан клиентом", F - "мошеннический", R - "отказан в исполнении, но не мошеннический") в таблице fraudwall_alert для соответствующего платежа (кроме платежей со статусом "j")

Если для сайта указан способ диагностики работоспособности АБС с помощью тестового платежного поручения (см. 11.1.2.4 «Обеспечение надежности механизма интеграции с АБС»), для записи в таблице fraudwall_alert со значением docid, равным 0, выставлять статус "G" (этот статус необходимо выставлять каждый раз, т.к. через некоторое время FraudWall сбрасывает статус такому документу).

11.1.2.2. Конфигурирование FraudWall

Работы по настройке FraudWall необходимо начинать только после того, как были выполнены работы на стороне АБС.

Примечание

В режиме анализа платежей в таблице fraudwall_alert дополнительного конфигурирования FraudWall не требуется.

Примечание

К АБС устанавливает соединение только сервер управления системы FraudWall.

Подключение к базе данных АБС осуществляется посредством механизма ODBC. Процедура установки и конфигурирования ODBC-драйверов приведена в разделе 12.4 «Установка ODBC-драйверов».

После проверки работоспособности ODBC, необходимо открыть WWW-интерфейс администрирования системы, пункт «Сайты» меню «Система», вкладка «Остановка платежей в АБС».

Рисунок 74. Параметры для интеграции с АБС

Параметры для интеграции с АБС

В свойствах сайта необходимо указать параметры интеграции с АБС. FraudWall начнет взаимодействовать с АБС сразу после сохранения настроек.

Журнал событий работы с базой данных АБС находится в файле /var/log/fraudwall/fw_control.log.

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

11.1.2.3. Автоматическое очищение старых записей в fraudwall_alert

Чтобы уменьшить размер таблицы fraudwall_alert, в FraudWall предусмотрен механизм автоматического очищения старых записей (на основе поля updated таблицы). Для этого во вкладке «Остановка платежей в АБС» свойств сайта необходимо указать количество дней, после которых удаляются старые записи о платежах в таблице fraudwall_alert.

Рисунок 75. Срок хранения записей в таблице fraudwall_alert

Срок хранения записей в таблице fraudwall_alert

11.1.2.4. Обеспечение надежности механизма интеграции с АБС

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

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

В FraudWall предусмотрены следующие механизмы, позволяющие обеспечить надежное функционирование интеграции с АБС:

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

  • простой способ проверки

  • расширенный (с помощью тестового платежного поручения)

Простой способ проверки основывается на том, что если платежное поручение уже исполнено в АБС, но в FraudWall его статус все еще находится в состоянии "требует проверки клиентом", значит, АБС не обработала информацию от FraudWall о необходимости остановки платежа. Такая проверка осуществляется ежечасно, поэтому администратор узнает о проблемах на стороне АБС не позже, чем через 90 минут.

Расширенный способ проверки предусматривает не только ежечасную проверку по предыдущему способу, но и создание в таблице fraudwall_alert тестового подозрительного платежного поручения (со статусом "S") каждые 10 минут. В свою очередь, АБС должна при очередном сканировании таблицы fraudwall_alert этой тестовой записи выставить статус "G". Если через 10 минут статус не был обновлен системой АБС, FraudWall считает, что механизм блокирования платежных поручений в АБС неработоспособен, и отсылает администратору соответствующее почтовое сообщение. Такой способ позволяет ускорить обнаружение проблем в АБС, но требует небольших дополнительных доработок в АБС.

11.1.3. Типовой подход к интеграции на этапе тестирования системы

На этапе ознакомительного тестирования системы торможение платежей не требуется - по сути, сервер FraudWall стоит "в стороне" от существующих информационных систем банка и просто читает информацию из их баз данных. При этом, даже если платеж вызвал подозрение в системе FraudWall, он обрабатывается точно также как и до подключения системы FraudWall (т.е. из ДБО выгружается в АБС и исполняется).

FraudWall может быть подключен как к базе ДБО, так и к базе АБС, а также одновременно и к базе ДБО, и к АБС.

11.1.3.1. Работы, которые необходимо выполнить по завершению этапа тестирования

После успешного завершения этапа тестирования системы FraudWall и принятия решения о внедрении системы, необходимо реализовать механизм торможения платежей (см. раздел 11.1.2 «Остановка подозрительных платежей»).

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

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

11.1.4. Снижение нагрузки на сервер анализируемой базы данных

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

Для этого необходимо создать дополнительный сайт с типом "Обучение антифрода платежам из базы данных", указать в нем подключение к репликационному серверу базы данных, а также в параметре "Анализируемые платежи считать созданными в сайте..." указать сайт FraudWall, который занимается анализом платежей.