О клиенте
Клиент — крупный европейский банк, ежедневно обрабатывающий большие объемы SEPA-платежей. Платежная инфраструктура работала под строгим регуляторным контролем, поэтому каждая транзакция должна была проходить проверку перед тем, как попасть в платежный процесс.
Банку нужна была платформа для проверки SEPA-платежей в реальном времени. Она должна была выдерживать десятки тысяч транзакций в секунду и не замедлять работу банковской платежной инфраструктуры. Система должна была проверять SEPA-сообщения в реальном времени, сохранять полную историю проверок для аудита и выдерживать пиковые нагрузки, например, в периоды массовых зарплатных выплат.
Платформа должна была уметь распределять нагрузку, выдерживать пиковые периоды и продолжать проверку SEPA-платежей при сбоях. Даже короткая остановка в платежном процессе могла привести к финансовым потерям и регуляторным рискам.
Задача
Один SEPA-файл может содержать большое количество транзакций, и каждый из них нужно проверить отдельно. Но для AML/ALR-проверок недостаточно проверить файл целиком: каждую транзакцию нужно разобрать, классифицировать и сохранить в истории обработки.
Основные задачи проекта:
- встроить платформу проверки SEPA-платежей в банковский платежный процесс;
- проверять каждое SEPA-сообщение до передачи в систему обработки платежей;
- разбирать SEPA-файлы с множеством переводов на отдельные транзакции;
- сохранять привязку каждой транзакции к исходному SEPA-файлу;
- классифицировать платежи на подтвержденные, подозрительные или требующие ручной проверки;
- обрабатывать десятки тысяч SEPA-запросов в секунду;
- хранить сообщения и результаты проверок для аудита;
- распределить обработку между несколькими узлами, чтобы сбой одного компонента не останавливал проверку платежей;
- подготовить платформу к установке в облаке и на серверах банка.
Краткий обзор проекта
Мы разработали платформу для проверки SEPA-платежей в реальном времени, рассчитанную на десятки тысяч запросов в секунду. Kafka принимала поток платежных сообщений и передавала их на обработку, а MongoDB хранила SEPA-сообщения и результаты AML/ALR-проверок. MongoDB распределяла данные по сегментам, чтобы платформа могла быстрее записывать SEPA-сообщения и выдерживать рост числа одновременных транзакций
Обработку платежей распределили между несколькими узлами. Поэтому отказ одного сервера или обслуживание части инфраструктуры не останавливали проверку SEPA-платежей.
В банковской инфраструктуре платформа выдерживала нагрузку в десятки тысяч SEPA-запросов в секунду.
Решение
Платформа встраивалась в платежную инфраструктуру банка: принимала SEPA-сообщения, проверяла их по AML/ALR-правилам и передавала дальше только подтвержденные платежи.
SEPA-файл мог содержать сотни или тысячи переводов. Платформа разбирала такой файл на отдельные транзакции, проверяла каждую по AML/ALR-правилам и сохраняла привязку к исходному файлу, а после проверки дальше проходили только подтвержденные платежи.
Каждая транзакция попадала в один из трех кластеров:
- подтвержденные платежи — транзакция прошла проверку и может быть исполнена;
- подозрительные платежи — транзакция блокируется до дополнительной проверки;
- ручная проверка — транзакция передается оператору или внешнему сервису проверки.
Такой подход позволил банку автоматизировать фильтрацию SEPA-транзакций и сократить ручную проверку до действительно спорных случаев.
Архитектура платформы рассчитана на высокую нагрузку: Kafka отвечает за потоковую обработку сообщений, MongoDB — за распределенное хранение данных, а отказоустойчивая схема работы обеспечивает бесперебойную обработку платежей.
Ключевые возможности
- разделение SEPA-файлов с большим количеством переводов на отдельные транзакции;
- проверка каждой транзакции с привязкой к исходному SEPA-файлу;
- AML/ALR-фильтрация в реальном времени;
- классификация транзакций на подтвержденные, подозрительные и требующие ручной проверки;
- потоковая обработка банковских сообщений через Kafka;
- распределенное хранение данных в MongoDB;
- обработка платежей на нескольких узлах с автоматическим переключением при сбое;
- поддержка SEPA и ISO 20022;
- возможность установки в облаке и на серверах банка;
- хранение истории сообщений и результатов проверок для аудита.
Технологический стек
- Бэкенд: Java;
- Очереди и потоковая обработка: Kafka;
- База данных: MongoDB с распределенным хранением данных;
- Архитектура: обработка платежей на нескольких узлах с автоматическим переключением при сбое;
- Протоколы: SEPA / ISO 20022;
- Развертывание: установка в облаке и на серверах банка;
- Модуль проверки соответствия требованиям: AML/ALR-логика, правила проверки и классификация транзакций.
Результаты
Банк получил надежную платформу для предварительной проверки SEPA-платежей. Система обрабатывала большие потоки транзакций, автоматически применяла AML/ALR-правила и сохраняла историю проверок для аудита.
Команда добилась следующих результатов:
- автоматизировали проверку SEPA-сообщений до исполнения платежа;
- снизили регуляторные риски за счет обязательной проверки каждой транзакции;
- сократили ручную обработку: операторы работали только с подозрительными и спорными платежами;
- обеспечили обработку десятков тысяч SEPA-запросов в секунду;
- реализовали распределенное хранение данных в MongoDB для высокой параллельной записи;
- развернули отказоустойчивую инфраструктуру для бесперебойной работы;
- предусмотрели два варианта работы платформы: в облаке и в инфраструктуре банка.
Архитектура также допускает дальнейшую интеграцию с системами выявления мошеннических операций, если в будущем банку потребуется расширить AML-фильтрацию.