Источник: http://vunvulearadu.blogspot.com/2019/07/blueprint-of-transaction-monitoring.html

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

Бизнес-сценарий

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

Алгоритм машинного обучения

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

Бизнес-проблема

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

Технические проблемы

Первая задача — собрать все действия с учетными записями в одном месте, подобно потоку данных. Текущее количество действий в минуту, которое необходимо принять, составляет от 40 000 до 150 000. В будущем темпы роста оцениваются в пределах 15–20% в год, в основном за счет онлайн-платформ.

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

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

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

Облачный подход

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

Обзор решения поверх Microsoft Azure

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

Azure Blueprint

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

1 Соберите соответствующие действия

2 Удалить идентификационную информацию клиента

3 Направьте поток данных внутрь Microsoft Azure

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

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

Основной экземпляр Azure Event Hub подключен к Azure Stream Analytics, который становится нашим центральным местом, где происходит настоящее волшебство. Azure Stream Analytics позволяет нам подключить его к решению Машинного обучения Azure и анализировать поток действий с помощью нашего пользовательского алгоритма, размещенного внутри него.

Сочетание Azure ML и Azure Stream Analytics позволяет нам иметь систему, которая может применять наш алгоритм машинного обучения поверх потока данных, не требуя от нас какой-либо пользовательской настройки или разработки. Это наиболее существенное преимущество Microsoft Azure для нашей платформы и отличительный фактор.

Количество действий, помеченных как подозрительные, довольно низкое, менее 0,05%. Мы должны учитывать, что часть из них попадет в репозиторий, где их проверит команда аналитиков безопасности, а другим нужно будет инициировать определенные действия.

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

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

Вторые функции Azure используют содержимое из другой подписки служебной шины Azure, которая отправляет содержимое в репозиторий, такой как Azure Cosmos DB, который используется PowerBI для создания настраиваемых отчетов поверх него и панели мониторинга для мониторинга, используемой аналитиком безопасности. Кроме того, бот, разработанный на основе Azure Bot Service, используется группой аналитиков безопасности для запроса хранилищ и извлечения информации, связанной с различными элементами.

Заключение

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

Источник: http://vunvulearadu.blogspot.com/2019/07/blueprint-of-transaction-monitoring.html