СПОСОБ И УСТРОЙСТВО ДЛЯ ОБРАБОТКИ СОБЫТИЙ В СИСТЕМЕ ПРОТИВОДЕЙСТВИЯ МОШЕННИЧЕСТВУ Российский патент 2024 года по МПК G06F21/60 G06Q20/40 

ОБЛАСТЬ ТЕХНИКИ

[0001] Заявленное решение относится к области информационной безопасности, в частности, к системам противодействия мошенничеству.

УРОВЕНЬ ТЕХНИКИ

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

[0003] Для эффективной работы систем противодействия мошенничеству недостаточно только данных для анализа из текущих операций, требуется дополнительно получать данные из внешних источников, такие как:

• исторические данные (внутренняя информация финансового учреждения),

• справочные данные,

• данные из компаний, предоставляющих аналитическую информацию (данные по клиентам\компаниям из кредитных бюро и т.п.),

• данные от государственных институтов и учреждений, связанных с ними (ФинЦЕРТ Банка России).

[0004] Стоит особо подчеркнуть, что финансовые учреждения работают с большим объемом данных, т.е. используют высоконагруженную систему с большим количеством событий. Также в рамках законов РФ [1], требований платежных сетей [2], [3], провайдеров платежей, платежных сервисов строго определен регламент работ [4], в том числе время ответа на событие. Таким образом, финансовое учреждение предъявляет строгие требования к нагрузке и времени обработки событий на стороне систем противодействия мошенничеству.

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

[0006] Из уровня техники известна система противодействия мошенническим транзакциям от АО "Кросс Технолоджис" и МКБ [5], предназначенная для повышения эффективности выявления мошенничества и снижения ложных-положительных срабатываний, а также система предотвращения мошенничества, входящая в семейство продуктов СмартВиста от БПС [6].

[0007] Кроме того, из патентной заявки US 2015/0026027 A1 (GUARDIAN ANALYTICS, INC., 22.01.2015) известна система и способ предотвращения мошенничества для использования в предотвращении мошенничества со счетами и кражи личных данных, которые поддерживают сквозной процесс управления рисками в режиме онлайн с помощью моделирования на основе поведения и расширенной аналитики.

[0008] В патентной заявке CN 112862505 A⋅ (INDUSTRIAL AND COMMERCIAL BANK OF CHINA CO., LTD., 28.05.2021) раскрывается способ и устройство для обмена информацией по борьбе с мошенничеством на основе блокчейна.

[0009] В патентной заявке CN 109242107 A⋅ (BEIJING XINDUN TIMES TECHNOLOGY CO., LTD., 18.01.2019) раскрывается система и способ противодействия мошенничеству, основанные на миграционном обучении в электронном банкинге.

[0010] В патентной заявке CN 113837885А⋅ (SHANGHAI CINTEL INTELLIGENCE TELECOM SYSTEM CO., LTD. et al., 24.12.2021) раскрывается система финансового антифрод-сервиса, обеспечивающая обработку и анализ больших данных по борьбе с мошенничеством в области финансов.

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

[0012] Заявленное решение позволяет решить техническую проблему в части повышения точности и скорости выявления мошеннической операции за счет повышения точности и скорости обработки событий в системе противодействия мошенничеству.

[0013] Техническим результатом является повышение точности и скорости обработки событий в системе противодействия мошенничеству.

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

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

b) получают по меньшей мере одно входящее событие,

c) осуществляют парсинг по меньшей мере одного полученного события и преобразуют его в заданный формат,

d) обогащают данные с учетом конфигурации и добавляют обогащенные данные к отформатированному на этапе с) событию, причем конфигурация обновляется в режиме реального времени,

e) анализируют и обрабатывают данные из события и/или витрин данных, необходимые для блока моделей, и добавляют проанализированные и обработанные данные к событию,

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

g) формируют ответное сообщение на основании данных, сохраненных в событии,

h) принимают решение о признании операции мошеннической на основании сформированного ответного сообщения.

[0015] В одном из частных примеров реализации входящее событие является сообщением, содержащим данные в виде совокупности пар «ключ-значение»

[0016] В другом частном примере реализации обогащение данных происходит из памяти, содержащей витрины данных.

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

[0018] В другом частном примере реализации дополнительно рассчитывают предикторы, повышающие предиктивную силу модели, на основе проанализированных и обработанных данных из витрин данных, при этом в качестве предикторов выступают по меньшей мере:

• агрегированные переменные,

• демографические данные,

• справочная информация.

[0019] В другом частном примере реализации этап f) дополнительно включает сравнение итогового значения результата обработки с пороговым диапазоном значений, при этом, если итоговое значение результата обработки соответствует пороговому диапазону значений, то осуществляют дополнительное обогащение данных.

[0020] В другом частном примере реализации дополнительное обогащение данных осуществляют с учетом конфигурации и таблицы соответствия параметров.

[0021] В другом частном примере реализации ответное сообщение дополнительно сохраняется в витрину данных.

[0022] В другом частном примере реализации способ дополнительно содержит этап ограничения доступа пользователя, выполняющего по меньшей мере одну операцию, признанную мошеннической.

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

по меньшей мере один процессор,

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0024] На Фиг. 1 представлена блок-схема компьютерно-реализуемого способа обработки событий в системе противодействия мошенничеству.

[0025] На Фиг. 2 представлена общая схема вычислительного устройства.

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

[0026] Ниже будут описаны понятия и термины, необходимые для понимания настоящего изобретения.

[0027] Система противодействия мошенничеству (также известная как антифрод-система) - система, предназначенная для оценки финансовых и не финансовых событий (карточных транзакций, страховых случаев и страховых выплат, действий пользователя в ДБО, операций с баллами лояльности и проч.) на предмет подозрительности с точки зрения мошенничества и предлагающая рекомендации по их дальнейшей обработке.

[0028] Обогащение данных (от англ. data enrichment) - это процесс дополнения данных новой информацией, чтобы повысить их ценность для анализа.

[0029] Событие - действие, осуществляемое пользователем (например, оплата, перевод, смена учетных данных, вход в интернет-банк).

[0030] Мошенническая операция - это по меньшей мере одно событие, не инициированное или не подтвержденное пользователем (например, осуществляемое с использованием устройства пользователя или учетной записи, принадлежащей пользователю, но без его ведома).

[0031] Парсинг (от англ. parsing) - это автоматизированный сбор и систематизация информации.

[0032] Хранилище данных - это система управления данными, которая поддерживает анализ бизнес-данных и выполнение аналитики для всей организации. Хранилища данных часто содержат большие объемы данных, в том числе исторических. В хранилище данных хранятся структурированные данные с определенными целями [7].

[0033] Озеро данных - это место, где хранятся структурированные и неструктурированные данные, а также метод организации больших объемов очень разных данных, поступающих из различных источников. Озера данных позволяют вносить данные в исходном формате без изменений [7], [8].

[0034] Витрина данных - это простая форма хранилища данных, которое ориентировано на определенную тему или направление деятельности, например, на продажи, финансы или маркетинг [7].

[0035] Итоговое значение результата обработки (также известное как score) - это метрика производительности модели машинного обучения.

[0036] Предиктор [в машинном обучении] (от англ. predictor) - это предсказывающая переменная или характеристика, которая используется для прогнозирования или предсказания результата.

[0037] Брокер сообщений (от англ. message broker) - это программное обеспечение для связи между приложениями, системами и службами, помогающее им обмениваться информацией друг с другом посредством перевода сообщений из одного формального протокола обмена сообщениями в другой [9].

[0038] На Фиг. 1 представлен компьютерно-реализуемый способ (100) обработки событий в системе противодействия мошенничеству. Выполнение способа (100) осуществляется с помощью по меньшей мере одного процессора. В частном примере реализации выполнение способа (100) осуществляется с помощью устройства для обработки событий в системе противодействия мошенничеству, которое может быть реализовано на базе вычислительного устройства, модифицированного в программно-аппаратной части таким образом, чтобы выполнять функции устройства для обработки событий в системе противодействия мошенничеству. Более подробное описание вычислительного устройства раскрыто далее со ссылкой на Фиг. 2.

[0039] На первом этапе (101) загружают по меньшей мере одну конфигурацию, представляющую набор параметров для обогащения данных. Конфигурация содержит уникальный идентификатор, с помощью которого загружают данные из витрин данных, причем уникальный идентификатор соответствует по меньшей мере одной витрине данных, а значение уникального идентификатора получают из входящего события. Уникальный идентификатор позволяет оптимизировать (сократить) время запроса к витринам данных. [0040] Конфигурация может дополнительно содержать, но не ограничиваться указанными примерами, по меньшей мере одно из:

• конфигурации загрузки информации,

• фильтры модели,

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

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

[0042] Пример реализации конфигурации загрузки информации:

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

[0043] Пример демонстрирует получение информации из витрины данных, содержащей данные о средней сумме трат клиента за последние 10 дней (userId_avg_sum_last_10_days), по уникальному идентификатору userId.

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

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

[0046] Фильтры модели позволяют настроить условия для проверки входящего события. Если входящее событие не подходит под условия, то соответствующая модель не будет задействована. Если входящее событие подходит под условия, то в блок моделей для соответствующей модели передаются данные, которые могут включать данные из события и/или обогащенные данные и/или данные из витрин данных. Фильтры модели могут применятся либо выборочно к определенному входящему событию, либо автоматически к каждому входящему событию.

[0047] Пример фильтра (Пример №1):

[0048] В примере проверяются два поля:

1) Поле тип подканала event.subchannel должно быть одним из перечисленных значений: ('ecom', 'UFS.WEBAPI', 'ESA.WEBAPI'), если операция совершается через:

• Интернет ('ecom')

• через канал ('UFS.WEBAPI')

• через канал партнера ('ESA. WEBAPI')

2) Поле event.user_id не должно быть пустым (т.е. событие должно быть связано с конкретным идентифицируемым пользователем).

[0049] Если два условия выполняются, то для входящего события происходит расчет/получение переменных avg_sum_last_10_days и avg_sum_current_day. После расчета, входящее событие отправляется на анализ в блок моделей, при этом к данным события также добавляется наименование модели ecom_filter.

[0050] Фильтры моделей (поскольку они входят в состав конфигурации) можно обновлять (например, изменять, добавлять, удалять) в режиме реального времени, что позволяет сократить время, необходимое для обработки событий в системе противодействия мошенничеству.

[0051] Фильтры модели позволяют оптимизировать набор данных, необходимый для блока модели, т.е. передавать не все данные из входящего события и/или обогащенных данных и/или рассчитанных/проанализированных данных, а только тот набор данных, который влияет на качество итогового значения результата обработки.

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

[0053] На этапе (102) получают по меньшей мере одно входящее событие. В частном примере реализации получают входящее событие в заданном формате взаимодействия, где заданный формат взаимодействия полученного входящего события представляет собой формат JSON (JavaScript Object Notation).

[0054] В одном из альтернативных вариантов воплощения заявленного решения входящее событие является сообщением, содержащим данные в виде совокупности пар «ключ-значение».

[0055] Пример полученного входящего события в формате JSON (Пример №2):

[0056] Каждое событие разделяется сепаратором, представляющим комбинацию заданных символов. В вышеуказанном примере в качестве сепаратора служит комбинация символов - \0. Использование сепаратора позволяет сократить время обработки события.

[0057] В известном уровне техники обычное байтовое сообщение по протоколу TCP/IP начинается с заголовка (header), являющегося блоком информации о входящем событий, который содержит длину сообщения. В начале требуется считать параметр из заголовка, далее вычислить длину и только потом происходит определение размера сообщения.

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

[0059] Описание синтаксиса для первого события из примера №2:

[0060] На этапе (103) выполняют парсинг по меньшей мере одного полученного события и преобразуют его в заданный формат. В качестве заданного формата может выступать, но не ограничиваться указанным примером, модифицированный Java HashMap. В рамках заявленного решения формат Java HashMap был модифицирован таким образом, чтобы обеспечить обращение к полям напрямую. Оригинальный формат Java HashMap не обеспечивает такого функционала, поскольку там обращение к полю идет через массив.

[0061] Пример формата, в который преобразуют событие после парсинга (Пример №3):

[0062] Указанный формат позволяет обращаться к данным напрямую, что сокращает время обработки события и его анализа.

[0063] На этапе (104) обогащают данные с учетом конфигурации и добавляют обогащенные данные к событию, отформатированному на предыдущем этапе (103).

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

[0065] Рассмотрим пример обогащения для вышеуказанного события (см. Пример №3). По уникальному идентификатору userId обращаемся к соответствующей витрине данных userId_avg_sum_last_10_days. Значение уникального идентификатора userId равно 10001, это значение извлекается из отформатированного входящего события. В указанной витрине находим строку, соответствующую значению уникального идентификатора userId:

10001 [variable_from_data_mart_avg_last_10_days=2340051]

[0066] Из вышеуказанной строки извлекаем параметр variable_from_data_mart_avg_last_10_days, характеризующий среднюю сумму трат клиента за последние 10 дней, и его значение. Далее извлеченный параметр и его значение (т.е. обогащенные данные) добавляют к отформатированному входящему событию.

[0067] Обогащенное событие (т.е. входящее событие, преобразованное в заданный формат и дополненное данными (добавленное поле выделено жирным) из по меньшей мере одной витрины данных) представлено ниже в Примере №4:

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

[0069] В предпочтительном варианте воплощения конфигурация обновляется в режиме реального времени, т.е. обеспечивается постоянная загрузка обновленных параметров конфигурации (например, уникальных идентификаторов), что способствует увеличению объема обрабатываемых данных и как следствие увеличение многообразия вариантов обогащения (за счет обновления или добавления новых витрин данных). Возможность осуществлять обогащение данных из множества постоянно обновляемых/добавляемых витрин данных способствует повышению точности обработки событий в системе противодействия мошенничеству.

[0070] Поскольку уникальные идентификаторы могут постоянно обновляться (в режиме реального времени) в рамках обновления конфигурации, то отсутствует необходимость отправки запросов на обновление, что способствует повышению скорости обработки событий в системе противодействия мошенничеству.

[0071] В частном варианте реализации обогащение данных происходит из памяти, которая содержит витрины данных. В качестве памяти может использоваться, но не ограничиваться указанными примерами, оперативная или кэш память. В одном из частных примеров реализации для хранения данных применяется In-memory data grid (IMDG) - распределенное в оперативной памяти объектно-ориентированное хранилище типа «ключ-значение» с поддержкой ACID-транзакций. Использование IMDG позволяет ускорить работу в режиме реального времени со структурами памяти больших объемов.

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

[0073] На этапе (105) анализируют и обрабатывают данные из события и/или витрин данных, необходимые для блока моделей, и добавляют проанализированные и обработанные данные к событию.

[0074] Этап (105) анализа и обработки данных включает проверку входящего события с помощью фильтра модели (см. Пример №1).

[0075] Для представленного ранее входящего события (см. Пример №4) рассмотрим пример анализа и обработки данных, содержащихся в этом событии. Осуществляем проверку условий фильтра моделей:

[0076] Анализ полей обогащенного события (см. Пример №4) показал, что поле event\subchannel содержит значение ecom и поле event\user_id содержит значение 10001, т.е. не является пустым. Далее осуществляется расчет двух переменных:

• avg_sum_last_10_days,

• avg_sum_current_day.

[0077] Переменной avg_sum_last_10_days, характеризующей среднюю сумму трат клиента за последние 10 дней, присваивается значение cf('variable_from_data_mart_avg_last_10days') из ранее обогащенных данных.

[0078] Для расчета avg_sum_current_day=cardsTransactions.byUser().avg() потребуются данные из витрины данных карточных операций cardsTransactions, которая хранит события только за последние сутки. Используем метод byUser(), осуществляющий выборку всех операций по пользователю (user_id="10001") из входящего события.

[0079] Пример данных из витрины данных карточных операций cardsTransactions (Пример №5):

[0080] Все данные относятся к клиенту из входящего события: event\user_id="10001". При помощи метода avg() производится расчет средней суммы операций клиента по двум событиям, извлеченным из витрины данных cardsTransactions. Результат расчета для переменной avg_sum_current_day равен 400000.

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

[0082] В Примере №6 представлено событие после добавления проанализированных и обработанных данных:

[0083] В частном примере реализации дополнительно рассчитывают предикторы, повышающие предиктивную силу модели, на основе проанализированных и обработанных данных из витрин данных, при этом в качестве предикторов выступают по меньшей мере:

• агрегированные переменные (например, средняя/медианная трата клиента за неделю/месяц/квартал/год),

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

• справочная информация (черные/серые списки; списки невалидных документов).

[0084] Предикторы могут рассчитываться заранее и загружаться из витрин данных для последующего использования при анализе и обработке данные из витрин данных или расчете других предикторов (этап 105), либо вычисляться непосредственно на этапе 105.

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

[0086] Рассмотрим использование предикторов на примере конкретных моделей из блока моделей.

[0087] Модель анализа по неплатежным операциям в Интернет банке.

[0088] Из витрин данных загружаются заранее рассчитанные предикторы, например:

• Возраст клиента и как давно он является клиентом банка.

Возраст клиента характерен несколькими параметрами, чем старше человек, тем больше у него:

ο доход,

ο накопленных средств,

ο доступный кредитный лимит,

эти факторы увеличивают вероятность мошенничества.

• Сколько раз устанавливалось приложение Интернет банка.

В обычной ситуации приложение изменяется достаточно редко (например, при покупке нового устройства).

• Соотношение количества устройств и количество приложений:

ο если изменяется устройство, то клиент устанавливает новое приложение - это стандартный сценарий,

ο аномальное поведение - устанавливают приложение и сразу проводят операции по снятию/переводу и т.д.

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

[0089] С помощью данных из витрин данных анализируются операции за последние 24 часа и формируются предикторы за последние сутки.

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

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

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

ο зайти в интернет банк и проверить баланс,

ο зайти в интернет, проверить баланс и пополнить счет.

При мошеннических действиях картина резко изменяется:

ο возрастает сумма операции,

ο частота переводов,

ο однотипные операции по переводу.

[0090] Рассчитанные предикторы и определенные параметры из операции передаются в модель для последующего анализа и вычисления итогового значения результата обработки.

[0091] Модель «операции клиента в отделении банка» (открытие/закрытие счета; платежи; оплата услуг; выдача кредитов и т.д.).

[0092] Из витрин данных загружаются заранее рассчитанные предикторы, например: Индикатор «спящего клиента»:

• Возраст клиента.

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

• Срок связи клиента с отделением банка.

Клиент обычно совершает операции в одном и том же отделении банка. В случае мошенничества клиент обычно посещает новые отделения.

[0093] С помощью данных из витрин данных анализируются операции за последние 24 часа и формируются предикторы за последние сутки.

• Количество заявок на кредит за последние сутки.

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

• Количество уникальных IP адресов (устройств клиента) за последние сутки. Перед посещением отделения, клиент или мошенник, получивший данные, могут зайти в интернет банк и провести ряд операций, например, произвести пополнение счета. Эта активность повышает факт мошенничества.

• Количество мошеннических звонков за сутки.

Этот индикатор повышает вероятность мошенничества.

• Сумма входящих переводов клиенту за сутки

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

• Количество звонков - от банка клиенту или сколько раз звонил банк клиенту за день.

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

[0094] Рассчитанные предикторы и определенные параметры из операции передаются в модель для последующего анализа и вычисления итогового значения результата обработки.

[0095] На этапе (106) отправляют по меньшей мере одно событие на проверку в блок моделей, который возвращает итоговое значение результата обработки. Затем итоговое значение результата обработки добавляется к событию.

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

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

[0098] В качестве примера рассмотрим отправку события (см. Пример №6) в блок моделей, где модель ecom_filter вычисляет итоговое значение результата обработки (score) с учетом всех значений параметров, содержащихся в событии.

[0099] После обработки модель возвращает итоговое значение результата обработки: ecom_filter_model_score_1=740

[0100] Добавляем полученное итоговое значение результата обработки, а также наименование модели, с помощью которой было вычислено это значение, к событию (Пример №7):

[0101] Добавление указанных параметров и их значений к сообщению позволяет сократить время обработки события, поскольку к параметру теперь можно обратиться напрямую без преобразования.

[0102] В частном примере реализации этап (106) дополнительно включает сравнение итогового значения результата обработки с пороговым диапазоном значений, при этом, если итоговое значение результата обработки соответствует пороговому диапазону значений, то осуществляют дополнительное обогащение данных.

[0103] Пороговый диапазон значений содержит значения, свидетельствующие о подозрении на мошенничество (например, значение параметра model_score_1 попадает в диапазон [400-749]), в связи с чем вызвана необходимость дополнительного обогащения данных для подтверждения факта мошенничества.

[0104] Если итоговое значение результата обработки превышает пороговый диапазон значений (например, значение параметра model_score_l попадает в диапазон [750-1000]), то это свидетельствует о высокой (критической) вероятности признания операции мошеннической. Следовательно, дополнительное обогащение данных не требуется, поскольку повторная проверка (путем дополнительного обогащения данных и обработки их моделью) лишь подтвердит сделанный вывод, но увеличит время на обработку события.

[0105] В альтернативном варианте воплощения заявленного решения повторная проверка может быть осуществлена несмотря на превышение пороговый диапазон значений для некоторых случаев, например, для операций VIP клиентов или определенных типов платежей (ипотека, погашение кредита).

[0106] Если итоговое значение результата обработки меньше порогового диапазона значений (например, значение параметра model_score_1 попадает в диапазон [0-399]), то делается вывод об отсутствии мошеннической операции и дополнительное обогащение данных не требуется.

[0107] В одном из частных примеров реализации дополнительное обогащение данных осуществляют с учетом конфигурации и таблицы соответствия параметров. При этом в предпочтительном варианте воплощения таблица соответствия параметров входит в состав конфигурации (т.е. является частью конфигурации).

[0108] Таблица соответствия параметров содержит информацию о:

a. наименование модели,

b. данных из входящего события,

c. уникальных идентификаторах к витринам данных для дополнительного обогащения,

d. коэффициенте веса, характеризующем связь между данными «а» и «b» для модели. Чем больше значения коэффициента веса тем больший приоритет имеют данные для использованиях в моделях и тем точнее рассчитывается итоговое значение результата обработки.

[0109] Пример таблицы соответствия параметров (Пример №8):

[0110] В примере:

[0111] В частном варианте воплощения таблица соответствия параметров может быть создана с помощью модели, которую предварительно обучили на исторических данных, чтобы выявлять взаимосвязи между параметрами, хранящимися в витринах данных. На основе этих взаимосвязей строят таблицу соответствия параметров, при этом таблица хранит информацию о силе взаимосвязи параметров между собой (коэффициент веса). Впоследствии модель имеет возможность дообучаться при появлении новых витрин данных. При необходимости дополнительного обогащения происходит обращение к таблице соответствия параметров и нахождение по таблице параметра, наиболее соответствующего параметру из события на основании самого большого коэффициента веса (т.е. самой сильной связи между параметрами). На основании найденного параметра осуществляем обогащение из витрины данных, соответствующей найденному параметру.

[0112] Фильтр проверки условия использования таблицы соответствия параметров позволяет настроить условие использования таблицы соответствия параметров и повторной проверки входящего события моделью.

[0113] Пример проверки условия использования таблицы соответствия параметров:

[0114] Если итоговое значение результата обработки (ecom_filter_model_score_1), полученный при первичной проверкой модели меньше 750, то требуется использовать соответствия параметров geo_model_table_congruence.

[0115] На предыдущем этапе (см. Пример №7) модель вернула итоговое значение результата обработки ecom_filter_model_score_1=740, что меньше 750.

[0116] Далее происходит проверка таблицы соответствия параметров (см. Пример №8) и определение параметров дополнительного обогащения, которая показала, что модель ecom_filter присутствует в таблице соответствия параметров.

[0117] Затем происходит анализ параметров:

1) Первая запись из таблицы соответствия параметров:

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

2) Далее анализируется следующая запись из таблицы соответствия параметров:

первый параметр user id присутствует во входящем событии, а второй geo_user_id отсутствует.

3) Затем проверяется конфигурация уникального идентификатора geo_user_id:

[0118] Для уникального идентификатора geo_user_id есть данные во входящем сообщении (cf('event.user_id')"=10001). По значению поля уникального идентификатора осуществляется дополнительное обогащение из витрины данных geo_data_last_2_days_table:

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

[0120] По результатам повторной проверки модель возвращает новое рассчитанное итоговое значение результата обработки (ecom_filter_model_score_congruent_1=810), которое добавляется к событию.

[0121] На этапе (107) формируют ответное сообщение на основании данных, сохраненных в событии и/или витринах данных. Кроме того, при формировании ответного сообщения к нему добавляются необходимые данные, такие как:

• обогащенные данные,

• любые данные из события,

• рассчитанные, преобразованные и проанализированные данные (например, предикторы),

• итоговые значения результата обработки моделей.

[0122] В частном варианте воплощения заявленного изобретения в ответное сообщение могут добавляться сведения из витрины данных, хранящей информацию об историческом итоговом значении результата обработки (исторический score), например, 10 последних итоговых значений результата обработки за период времени (день/неделя). На основании указанных данных рассчитывают среднее значение и/или максимальный коэффициент отклонения от среднего значения, для последующего сравнения рассчитанного отклонения с итоговым значением результата обработки от текущей операции. Данные расчета и результаты сравнения также могут быть добавлены к ответному сообщению.

[0123] В одном из частных примеров реализации ответное сообщение дополнительно сохраняется в витрину данных. Сохранение ответного сообщения в витрину данных позволяет:

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

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

[0124] В одном из частных примеров реализации заявленного решения на время обработки события, все данные по этому событию находятся в кэш памяти. После копирования события (отдельно или в составе ответного сообщения) в витрину данных, механизм очистки кэш памяти удаляет неиспользуемые события из кэш памяти. Использование указанного механизма очистки кэш памяти позволяет предотвратить утечку памяти.

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

[0126] На этапе (108) принимают решение о признании операции мошеннической на основании сформированного ответного сообщения, а конкретнее на основании данных, содержащихся в сформированном ответном сообщении.

[0127] Проверка события на предмет признание мошеннической операцией может представлять собой проверку выполнения определенных условий, например:

[0128] С помощью проверки условий принимается решение о наличии или отсутствии мошеннической операции. В вышеуказанном примере:

• если рассчитанные итоговые значения результата обработки моделью ecom_filter_model_score_1 или ecom_filter_model_score_congruent_1 больше 800,

• если время совершения входящего события (event.eventTime) больше 13:00:00,

• если сумма входящего события (event.operation_amount) больше 10000000 (в формате 100000.00, где целая часть характеризует сумму операции в рублях, а дробная часть - копейки),

• если геоданные (event.operation_geo_data) из входящего события не присутствуют в исторической информации о геоданных (userId_geo_data_last_2_days) за последние два дня,

то принимается решение, что операция мошенническая и присваивается код результата проверки rule_1=1,

• если входящее событие не подходит под описанные условия,

то принимается решение о признании операции не мошеннической и присваивается код результата проверки rule_1=0.

[0129] Получаем параметры из ответного сообщения, сформированного на основании данных, сохраненных в событии (см. Пример №7):

• ecom_filter_model_score_1 = 740 не подходит под условие правила,

• ecom_filter_model_score_congruent_1 = 810 подходит под условия правила, поскольку один из двух параметров подходит под условия правила, то условие выполняется,

• cf('event.eventTime') - "2023-08-17 14:16:54" подходит под условие правил, операция осуществлена после 13:00:00,

• cf('event.operation_amount') = 10256700 подходит под условие, т.к. сумма больше 10000000,

• cf('event.operation_geo_data') = "35.456;47.98" и userId_geo_data_last_2days = ["90.00;110.2","98.5;105.3","80.5;90.3"] текущее место положение клиента не совпадает со значениями геоданных за последние два дня - подходит под условие.

[0130] Поскольку все условия выполняются, то операция признается мошеннической и присваивается код результата проверки rule_1=1.

[0131] В альтернативном варианте воплощения заявленного решения после принятия решение о наличии или отсутствии мошеннической операции, код результата проверки добавляется в ответное сообщение. Таким образом, ответное сообщение может иметь следующий вид:

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

[0133] Пример фильтра формирования ответного сообщения:

[0134] В данном примере фильтр проверяет три условия, которые должны выполниться одновременно:

• поле 'event.user_id' из входящего события не должно быть пустым,

• поле 'event.deviceRequest.atm.MerchantId' из входящего события не должно быть пустым,

• поле 'event.deviceRequest.atm.terminal.terminalClass' из входящего события, отвечающее за тип устройства (ecom, банкомат, POS, и т.д.), должно принимать одно из перечисленных значений: 8 или 2.

[0135] Если все три условия выполняются, то в ответном сообщении отправляются поля:

• avg_sum - присваивается рассчитанное значение avg_sum_current_day (средняя сумма трат клиента за текущий день),

• risk_score - присваивается итоговое значение результата обработки, повторно рассчитанное блоком моделей ecom_filter_model_score_congruent_1,

• resolution - присваивается значение о решении мошенническая операция или нет rule_1,

• userId_geo_data - присваивается рассчитанное значение userId_geo_data_last_2 days (информация о геолокации клиента во время совершения операций за последние 2 дня),

• transaction_eventTime - присваивается время проведения операции из входящего события cf('event.eventTime').

[0136] Поскольку все условия фильтра выполнились, ответное сообщение формируется в следующем виде:

[0137] В одном из частных примеров реализации заявленное решение дополнительно содержит этап ограничения доступа пользователя, выполняющего по меньшей мере одну операцию, признанную мошеннической. В качестве ограничения доступа пользователя может выступать, но не ограничиваться указанными примерами: ограничение/запрет доступа пользователя к целевой системе; ограничение конкретных прав доступа; приостановка и/или отмена выполняемых пользователем операций; внесение пользователя в черный список; ограничение/запрет доступа клиента в инет-банка или их комбинация.

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

[0139] На Фиг. 2 представлен общий вид вычислительного устройства (200), на базе которого может быть реализовано устройство для обработки событий в системе противодействия мошенничеству, обеспечивающее реализацию способа обработки событий в системе противодействия мошенничеству.

[0140] В общем случае вычислительное устройство (200) содержит объединенные общей шиной информационного обмена один или несколько процессоров (201), средства памяти, такие как ОЗУ (202) и ПЗУ (203), интерфейсы ввода/вывода (204), устройства ввода/вывода (205), и средство для сетевого взаимодействия (206).

[0141] Процессор (201) (или несколько процессоров, многоядерный процессор) могут выбираться из ассортимента устройств, широко применяемых в текущее время, например, компаний Intel™, AMD™, Apple™, Samsung Exynos™, MediaTEK™, Qualcomm Snapdragon™ и т.п. В качестве процессора (701) может также применяться графический процессор, например, Nvidia, AMD, Graphcore и пр.

[0142] ОЗУ (202) представляет собой оперативную память и предназначено для хранения исполняемых процессором (201) машиночитаемых инструкций для выполнение необходимых операций по логической обработке данных. ОЗУ (202), как правило, содержит исполняемые инструкции операционной системы и соответствующих программных компонент (приложения, программные модули и т.п.).

[0143] ПЗУ (203) представляет собой одно или более устройств постоянного хранения данных, например, жесткий диск (HDD), твердотельный накопитель данных (SSD), флэш-память (EEPROM, NAND и т.п.), оптические носители информации (CD-R/RW, DVD-R/RW, Blu-Ray Disc, MD) и др.

[0144] Для организации работы компонентов устройства (200) и организации работы внешних подключаемых устройств применяются различные виды интерфейсов В/В (204). Выбор соответствующих интерфейсов зависит от конкретного исполнения вычислительного устройства, которые могут представлять собой, не ограничиваясь: PCI, AGP, PS/2, IrDa, FireWire, LPT, COM, SATA, IDE, Lightning, USB (2.0, 3.0, 3.1, micro, mini, type C), TRS/Audio jack (2.5, 3.5, 6.35), HDMI, DVI, VGA, Display Port, RJ45, RS232 и т.п.

[0145] Для обеспечения взаимодействия пользователя с вычислительным устройством (700) применяются различные устройства (205) В/В информации, например, клавиатура, дисплей (монитор), сенсорный дисплей, тач-пад, джойстик, манипулятор мышь, световое перо, стилус, сенсорная панель, трекбол, динамики, микрофон, средства дополненной реальности, оптические сенсоры, планшет, световые индикаторы, проектор, камера, средства биометрической идентификации (сканер сетчатки глаза, сканер отпечатков пальцев, модуль распознавания голоса) и т.п.

[0146] Средство сетевого взаимодействия (206) обеспечивает передачу данных устройством (200) посредством внутренней или внешней вычислительной сети, например, Интранет, Интернет, ЛВС и т.п. В качестве одного или более средств (206) может использоваться, но не ограничиваться: Ethernet карта, GSM модем, GPRS модем, LTE модем, 5G модем, модуль спутниковой связи, NFC модуль, Bluetooth и/или BLE модуль, Wi-Fi модуль и др.

[0147] Дополнительно в составе устройства (200) могут также применяться средства спутниковой навигации, например, GPS, ГЛОНАСС, BeiDou, Galileo.

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

[0149] Источники информации:

[1] Федеральный закон от 27.06.2018 г. №167-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части противодействия хищению денежных средств».

[2] Федеральный закон от 27.06.2011 г. №161-ФЗ «О национальной платежной системе» [3] Федеральный закон от 24.07.2023 г. №369-ФЗ «О внесении изменений в Федеральный закон «О национальной платежной системе».

[4] ГОСТ Р 57580.1-2017. Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер

[5] Создание системы противодействия мошенническим транзакциям, https://crosstech.su/projects/sistemy-protivodeystviya-moshennicheskim-tranzaktsiyam/?ysclid=lo4abk3je652194739.

[6] Система предотвращения мошенничества. https://смартвиста.рф/fraund-management/.

[7] Что такое витрина данных? https://www.oracle.com/cis/autonomous-database/what-is-data-mart/.

[8] Что такое озеро данных? https://www.oracle.com/cis/big-data/data-lake/what-is-data-lake/.

[9] What are Message Brokers? https://www.ibm.com/topics/message-brokers.

Изобретение относится к способу и устройству обработки событий в системе противодействия мошенничеству. Технический результат заключается в повышении точности и скорости обработки событий в системе противодействия мошенничеству. Способ содержит этапы, на которых: a) загружают по меньшей мере одну конфигурацию, представляющую набор параметров для обогащения данных, b) получают по меньшей мере одно входящее событие, c) осуществляют парсинг по меньшей мере одного полученного события и преобразуют его в заданный формат, d) обогащают данные с учетом конфигурации и добавляют обогащенные данные к отформатированному на этапе с) событию, причем конфигурация обновляется в режиме реального времени, e) анализируют и обрабатывают данные из события и/или витрин данных, необходимые для блока моделей, и добавляют проанализированные и обработанные данные к событию, f) отправляют по меньшей мере одно событие на проверку в блок моделей, который возвращает итоговое значение результата обработки, причем итоговое значение добавляется к событию, g) формируют ответное сообщение на основании данных, сохраненных в событии, h) принимают решение о признании операции мошеннической на основании сформированного ответного сообщения. 2 н. и 8 з.п. ф-лы, 2 ил., 2 табл.

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

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

b) получают по меньшей мере одно входящее событие,

c) осуществляют парсинг по меньшей мере одного полученного события и преобразуют его в заданный формат,

d) обогащают данные с учетом конфигурации и добавляют обогащенные данные к отформатированному на этапе с) событию, причем конфигурация обновляется в режиме реального времени,

e) анализируют и обрабатывают данные из события и/или витрин данных, необходимые для блока моделей, и добавляют проанализированные и обработанные данные к событию,

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

g) формируют ответное сообщение на основании данных, сохраненных в событии,

h) принимают решение о признании операции мошеннической на основании сформированного ответного сообщения.

2. Способ по п. 1, характеризующий тем, что входящее событие является сообщением, содержащим данные в виде совокупности пар «ключ-значение».

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

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

5. Способ по п. 1, характеризующий тем, что дополнительно рассчитывают предикторы, повышающие предиктивную силу модели, на основе проанализированных и обработанных данных из витрин данных, при этом в качестве предикторов выступают по меньшей мере:

• агрегированные переменные,

• демографические данные,

• справочная информация.

6. Способ по п. 1, характеризующий тем, что этап f) дополнительно включает сравнение итогового значения результата обработки с пороговым диапазоном значений, при этом если итоговое значение результата обработки соответствует пороговому диапазону значений, то осуществляют дополнительное обогащение данных.

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

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

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

10. Устройство для обработки событий в системе противодействия мошенничеству, содержащее

по меньшей мере один процессор,

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