RegTech для банков: Data Lakehouse как основа отчётности

1. Что такое RegTech и почему сейчас

RegTech (Regulatory Technology) — применение технологий для автоматизации выполнения регуляторных требований. В Центральной Азии этот термин перестал быть абстракцией: Центральный банк Узбекистана (ЦБУ) запустил масштабную программу SupTech, которая к 2027 году обяжет все банки перейти на автоматическую передачу гранулярных данных.

В октябре 2025 года на втором RegTech Forum Uzbekistan прозвучал ключевой тезис: «Строим будущее на основе качественных данных». Это не слоган — это новый операционный стандарт.

Что меняется для банков:

• От периодичности к непрерывности: регулятор ожидает поступления данных не раз в месяц, а в потоковом режиме
• От агрегатов к транзакциям: требуется раскрытие первичных данных (drill-down), а не только итоговых форм
• От IT-задачи к управленческой культуре: качество данных (Data Quality) становится зоной ответственности топ-менеджмента

Банки-лидеры — Ипотека-банк, Асакабанк, Халк банк и Туронбанк — уже отмечены ЦБУ за успехи во внедрении RegTech. Отставание несёт не только операционные, но и прямые регуляторные риски.

В Казахстане параллельный процесс: Закон о персональных данных (No. 94-V) и требования к локализации создают аналогичное давление на банковскую инфраструктуру.

Ключевые вехи RegTech ЦБУ

2. Что банки обязаны внедрить

Постановление No 3697 (октябрь 2025) вводит жёсткие нормативы, адаптированные к Basel III. Это не просто отчётные формы — это архитектурные требования к IT-системам банков.

Минимальный набор требований

1. Автоматическая передача данных: Банки обязаны перейти на автоматический трансфер данных в систему ЦБ. Более 140 электронных требований уже разработаны. Ручная подготовка в Excel — больше не вариант.
2. Data Governance Framework: Внедрение внутренних контролей качества данных обязательно. ЦБ уже требует повторной подачи отчётов при обнаружении ошибок. Назначение CDO (Chief Data Officer) или Data Stewards.
3. Единый справочник данных: Синхронизация внутренних кодов (филиалы, валюты, типы кредитов) с «Единой моделью данных» ЦБ, разработанной KPMG.
4. Безопасная интеграция: Использование «Личного кабинета» (портал) и API-каналов для обмена данными с цифровой подписью. Локализация персональных данных в Узбекистане.

Рекомендация: банки должны рассматривать «Единую модель данных» KPMG/ЦБ не просто как требование к отчётности, а как эталонную архитектуру для собственных DWH.

3. Почему legacy-стек не справляется

Банковский сектор Узбекистана исторически опирается на монолитные АБС: Colvir (Туронбанк, Алокабанк), CBS B2 (Капиталбанк), Oracle Flexcube. Они надёжны для OLTP-транзакций, но критически ограничены для задач RegTech:

• Архитектурная закрытость: данные «заперты» внутри проприетарных БД. Извлечение для аналитики нагружает продуктивный контур.
• Отсутствие нативной аналитики: встроенные модули отчётности ограничены жёсткими формами, нет гибкого ad-hoc анализа для поиска аномалий.
• Фрагментация данных: core banking, процессинг, CRM, мобильное приложение — информация о клиенте размазана между системами.
• T+1 хранилища: традиционные DWH с ночной загрузкой не удовлетворяют требованиям ЦБ по мониторингу рисков в реальном времени.

Проблема не в отсутствии данных, а в их недоступности для оперативного анализа. Рынку требуется архитектура Real-Time Data Warehouse.

4. Data Lakehouse как инфраструктура RegTech

Apache Doris (VeloDB) решает ключевое противоречие: банкам нужна real-time аналитика на гранулярных данных, но без нагрузки на OLTP-системы.

VeloDB: трёхуровневая модель хранения для банков — ODS (сырые данные, Duplicate Key, audit trail), DWD (актуальные состояния, Unique Key, дедупликация), ADS (витрины, Aggregate Key, прекалькулированные агрегаты для дашбордов).

5. Архитектура: от АБС до отчёта ЦБ

6. Четыре сценария использования

Сценарий 1: Мониторинг достаточности капитала (Basel III)

Постановление No 3697 требует учёта нераспределённой прибыли и убытков в реальном времени, а также оценки рисков по внебалансовым инструментам.

• Qlik Replicate / Flink CDC собирает данные о сделках, позициях казначейства и кредитном портфеле из АБС
• Doris выполняет классификацию активов по группам риска. Пересчёт миллионов кредитных договоров — секунды, не часы
• Стресс-тестирование: «Что если курс сума упадёт на 10%?» — мгновенный пересчёт достаточности капитала
• BI-дашборд отображает «светофор» нормативов. Алерт при приближении к пороговому значению

Сценарий 2: AML и транзакционный мониторинг

Рост безналичных платежей требует проверки транзакций за миллисекунды. Режим T+1 позволяет мошенникам вывести средства.

• Doris поддерживает ingestion на уровне гигабайтов в секунду — транзакции из процессинга попадают в базу мгновенно
• Сложная логика детекции: «клиенты с более чем 10 переводами от разных лиц за час с обналичиванием» — это multi-table JOIN, не NoSQL
• Кейс: крупный банк на Apache Doris перехватывает десятки тысяч подозрительных транзакций ежедневно

Сценарий 3: Замена ELK Stack для аудита

Банки обязаны хранить логи доступа сотрудников и системные события. ELK Stack при десятках ТБ в день становится дорогим.

• Сжатие ZSTD + колоночное хранение: объём данных в 3-5 раз меньше vs Elasticsearch
• Tiered Storage: старые логи (более 3 месяцев) автоматически перемещаются в S3/MinIO, оставаясь доступными для SQL
• Инвертированные индексы: поиск по ключевым словам ускоряется в 2-4 раза vs Elasticsearch

Сценарий 4: МСФО 9 и моделирование кредитных убытков

Стандарт МСФО 9 требует расчёта ожидаемых кредитных убытков (ECL) на основе прогнозной информации.

• Doris объединяет внутренние данные (платёжная дисциплина) и внешние макроэкономические данные в одной платформе
• Пересчёт модели ECL на полном портфеле (миллионы кредитов) — минуты вместо часов
• BI визуализирует миграцию портфеля между стадиями риска (Stage 1, 2, 3) для риск-менеджеров

7. Дорожная карта на 180 дней