Банктер үшін RegTech: Data Lakehouse есептілік негізі

1. RegTech деген не және неге қазір

RegTech (Regulatory Technology) — реттеуші талаптарды орындауды автоматтандыру технологиясы. Орталық Азияда бұл термин абстракция болудан қалды: Өзбекстан Орталық банкі (ОБ) SupTech бағдарламасын іске қосты, ол 2027 жылға дейін барлық банктерді гранулярлы деректерді автоматты тасымалдауға міндеттейді.

2025 жылдың қазанында RegTech Forum Uzbekistan II-де негізгі теза айтылды: «Сапалы деректер негізінде болашақ құрамыз». Бұл слоган емес — жаңа операциялық стандарт.

Банктер үшін не өзгереді:

• Мерзімділіктен үздіксіздікке: реттеуші деректерді айына бір рет емес, ағынды режимде күтеді
• Агрегаттардан транзакцияларға: бастапқы деректерді (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 тағайындау.
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 тәуекел мониторингі бойынша сай емес.

Мәселе деректердің болмауында емес, олардың жедел талдау үшін қолжетімсіздігінде. Нарыққа Real-Time Data Warehouse архитектурасы қажет.

4. RegTech инфрақұрылымы ретінде Data Lakehouse

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
• Кейс: ірі банк Apache Doris-те күн сайын ондаған мың күдікті транзакцияны тоқтатады

Сценарий 3: Аудит үшін ELK Stack-ті ауыстыру

Банктер қызметкерлердің кіру логтарын және жүйелік оқиғаларды сақтауға міндетті. ELK Stack күніне ондаған ТБ кезінде қымбатқа түседі.

• ZSTD сығымдау + бағандық сақтау: деректер көлемі Elasticsearch-ке қарағанда 3-5 есе аз
• Tiered Storage: ескі логтар (3 айдан астам) S3/MinIO-ға автоматты ауысады, SQL үшін қолжетімді қалады
• Инвертирленген индекстер: кілт сөздер бойынша іздеу Elasticsearch-ке қарағанда 2-4 есе жылдамдайды

Сценарий 4: ХҚЕС 9 және несиелік шығындарды модельдеу

ХҚЕС 9 стандарты болжамды ақпарат негізінде күтілетін несиелік шығындарды (ECL) есептеуді талап етеді.

• Doris ішкі деректерді (төлем дисциплинасы) және сыртқы макроэкономикалық деректерді бір платформада біріктіреді
• Толық портфельде (миллиондаған несиелер) ECL моделін қайта есептеу — сағаттар емес, минуттар
• BI тәуекел кезеңдері арасындағы портфель миграциясын (Stage 1, 2, 3) риск-менеджерлер үшін визуализациялайды

7. 180 күнге жол картасы