Обработка банковских выписок и построение единого журнала операций#

Контекст#

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

  • Банкоматы — снятие наличных, баланс-запросы;

  • Интернет- и мобильный банкинг — переводы, оплаты, пополнения;

  • Платежные шлюзы — эквайринг, авторизации;

  • Процессинг — внутренние транзакции, списания;

  • Кассы и POS-терминалы — розничные операции.

Каждая система ведет собственный журнал, в разных форматах (XML, JSON, flat-file, EDIFACT), с разной семантикой полей и асинхронной синхронизацией.

Схема до внедрения Corax:

graph TD A[Банкоматы] -->|CSV / XML| D[(Данные)] B[Интернет-банкинг] -->|JSON| D C[Платежные шлюзы] -->|ISO 8583| D E[Процессинг] -->|Proprietary| D G[POS-терминалы] -->|Binary| D D --> H[Отчетность] D --> I[Мониторинг] D --> J[Аналитика] D --> K[Аудит] style D fill:#f9f9f9,stroke:#ccc,stroke-width:2px style H fill:#e6f7ff,stroke:#1890ff style I fill:#e6f7ff,stroke:#1890ff style J fill:#e6f7ff,stroke:#1890ff style K fill:#e6f7ff,stroke:#1890ff

Проблема#

Банк не может получить единый, достоверный и актуальный журнал всех финансовых операций в реальном времени:

  • Нет единой картины клиента — операции распределены по системам.

  • Задержки в отчетности — данные поступают с задержкой (часы, сутки).

  • Отсутствует корреляции событий в реальном времени.

  • Высокая стоимость интеграции — каждая новая система требует сложной интеграции.

  • Трудоемкая операция аудита и соответствие регуляторными требованиями.

Решение#

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

Пример архитектура решения:

graph LR A[Банкоматы] -->|Producer| K[Corax] B[Интернет-банкинг] -->|Producer| K C[Платежные шлюзы] -->|Producer| K E[Процессинг] -->|Producer| K F[SWIFT] -->|Producer| K G[POS-терминалы] -->|Producer| K K --> N[Kafka Streams / ksqlDB] K --> L[Kafka Connect] N -->|Нормализация, агрегация| T[(Единый журнал операций)] L -->|Sink| D[Data Warehouse] L -->|Sink| E[Elasticsearch] L -->|Sink| F["Мониторинг (Prometheus, Grafana)"] L -->|Sink| G[Система антифрауда] L -->|Sink| H[Отчетность] style K fill:#ffec3d,stroke:#e6b800,stroke-width:2px style T fill:#d9f7be,stroke:#52c41a,stroke-width:2px style N fill:#ffd6e7,stroke:#d46bcb

Apache Kafka — центральная шина событий, все операции в едином формате: timestamp, account_id, amount, type, channel, status.

Описание примера решения:

  1. Системы-источники подключается как Производители (Producer). Каждая система публикует свои события в свой топик Kafka, в своем формате (например, JSON, Avro) с использованием Schema Registry для контроля изменений.

  2. Нормализация и агрегация (Kafka Streams / ksqlDB) в режиме потоковой обработки:

    • Приведение всех событий к единому формату (Unified Transaction Model).

    • Обогащение: добавление client_id, branch, geolocation.

    • Фильтрация: исключение тестовых операций.

    • Агрегация: подсчет ежедневных лимитов.

  3. Формирование единого журнала. Все нормализованные события пишутся в общий топик.

  4. Потребителями (Consumer):

    • Система антифрауда — анализирует поведение в реальном времени.

    • Data Warehouse — для аналитики и отчетности.

    • Elasticsearch — для поиска по операциям и аудита.

    • Grafana / Kibana — дашборды и мониторинг.

    • Регуляторные отчеты — автоматизированная выгрузка.