Архитектура регуляторной отчётности AML в большом масштабе

Почему отчётность AML — самая сложная задача работы с данными в банке

На первый взгляд регуляторная отчётность AML кажется задачей обработки данных. Регулятор — FINTRAC в Канаде, FinCEN в США — требует сообщать об определённых типах транзакций: электронных переводах средств выше порога (EFTR), операциях с наличными выше порога (CTR), подозрительном поведении (STR) и необычных транзакциях (UTR). Получить данные, привести к нужному формату, отправить.

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

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

Эталонная архитектура от начала до конца

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

• Приём данных из источников. Захват изменений данных из основных банковских систем, Workday HR, клиентских хабов, систем валютных операций и сигналов кибербезопасности. Одни системы публикуют события; устаревшие системы предоставляют пакетные выгрузки, которые мы обрабатываем загрузчиком с проверкой схемы.
• Потоковая магистраль. Потоки событий по модели Kafka передают финансовые транзакции, обновления KYC, совпадения с санкционными списками и события жизненного цикла счетов. Топики разделены по клиентам или счетам, чтобы сохранять порядок событий для каждой сущности.
• Связывание и обогащение. Задачи потоковой обработки связывают событие транзакции с основными данными клиента, иерархиями счетов, этапами валютных операций, профилями KYC и историей поведения. Результат — полностью связанная запись, подлежащая включению в отчётность и соответствующая структуре регулятора.
• Выявление и правила. Actimize содержит сценарии выявления AML для STR/UTR; EFTR/CTR формируются на основе детерминированных пороговых правил и справочных данных. Результат — поток потенциальных отчётов с подтверждающими материалами.
• Подача отчётности и прослеживаемость. Сервис подачи отчётности форматирует данные EFTR/STR/CTR/UTR по схемам FINTRAC, подписывает их и отправляет по защищённому каналу. Каждая запись содержит идентификатор происхождения, позволяющий проследить её до исходных событий.

Платформа построена на Azure — AKS для контейнеризированных сервисов, PostgreSQL для хранения регуляторной отчётности, Azure Storage для исходных событий и Azure Monitor / Sentinel для безопасности и наблюдаемости. При внедрениях в канадских банках «Большой пятёрки» мы расширили Actimize на AKS с помощью PostgreSQL специально для масштабной обработки CTR.

Почему потоковая передача событий, а не ночная пакетная обработка

Исторически отчётность AML формировалась ночной пакетной обработкой. Это работало, когда сроки подачи измерялись днями. Сегодня ожидания FINTRAC — и, откровенно говоря, допустимый для самого банка уровень риска — гораздо ближе к режиму, близкому к реальному времени. Отчёты EFTR должны надёжно формироваться независимо от момента расчёта по исходному переводу. Для STR полезно связывать транзакцию с текущими поведенческими сигналами.

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

С точки зрения затрат AKS предоставляет эластичные вычислительные ресурсы, масштабируемые по объёму: всплески в конце месяца, года и в периоды валютной волатильности не требуют постоянно выделенной мощности.

Моделирование угроз как полноценный архитектурный артефакт

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

Каждая создаваемая нами архитектура в этой области включает явную модель угроз: STRIDE на каждой границе компонентов, классификацию данных в каждом хранилище и идентификацию с минимальными привилегиями для межсервисных вызовов. Секреты хранятся в Azure Key Vault; сервисы используют управляемые удостоверения, а не статические учётные данные. Чувствительные данные — документы KYC, персональные данные клиентов — защищены конвертным шифрованием с ключами, привязанными к направлению бизнеса.

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

KYC и подключение компаний, оказывающих денежные услуги

Отчётность AML опирается на KYC. Если KYC неверен, неверны и отчёты. Одна из наиболее интересных тактических задач, над которыми мы работали, — процесс подключения компаний, оказывающих денежные услуги (MSB) — категории клиентов с обоснованно высоким риском и существенными требованиями к надлежащей проверке KYC.

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

Уроки внедрения в двух крупнейших банках

• Относитесь к схеме регулятора как к контракту. Стройте систему под неё с первого дня. Не допускайте проникновения внутренних форматов данных в слой подачи отчётности.
• Основная работа — связывание данных. Правила EFTR/STR — простая часть. На корректное объединение данных о клиентах, счетах, валютных операциях и кибербезопасности для 30 сценариев приходится 80% инженерной работы.
• Прослеживаемость обязательна. Когда регулятор задаёт вопросы об отчёте, вы должны показать все события, на которых он основан, за минуты, а не дни.
• Одобрение архитектурного совета — не формальность. Используйте его как стимул к тщательной проработке. Проверки, которые мы проходили, выявляли проблемы с размещением данных и управлением ключами, исправление которых впоследствии обошлось бы очень дорого.
• Облачная архитектура ≠ только облако. Некоторые исходные системы ещё годами останутся в локальной инфраструктуре. Архитектура должна честно учитывать гибридную интеграцию.

Нужно такое решение для вашего банка или финтех-компании?

SEYSO проектировала платформы AML и регуляторной отчётности для нескольких крупнейших банков Канады и США — с выполнением требований LCTR, EFTR, STR, UTR, CTR, KYC и CFT. Если вы модернизируете технологии противодействия финансовым преступлениям, переносите Actimize на новую платформу или определяете рамки новой регуляторной программы, будем рады обсудить задачу. С вас — требования регулятора и сложность исходных систем; с нас — архитектура.