Banklar uchun RegTech: Data Lakehouse hisobot asosi

1. RegTech nima va nega hozir

RegTech (Regulatory Technology) — regulyator talablarini bajarishni avtomatlashtiradigan texnologiya. Markaziy Osiyoda bu atama abstraksiya boʼlishdan toʼxtadi: Oʼzbekiston Markaziy banki (MB) SupTech dasturini ishga tushirdi, u 2027 yilgacha barcha banklarni granular maʼlumotlarni avtomatik uzatishga majburlaydi.

2025 yil oktyabrida RegTech Forum Uzbekistan II da asosiy tezis aytildi: «Sifatli maʼlumotlar asosida kelajak quramiz». Bu shior emas — yangi operatsion standart.

Banklar uchun nima oʼzgaradi:

• Davriylikdan uzluksizlikka: regulyator maʼlumotlarni oyiga bir marta emas, oqim rejimida kutadi
• Agregatlardan tranzaksiyalarga: boshlangʼich maʼlumotlarni (drill-down) ochish kerak, faqat yakuniy formalarni emas
• IT-vazifadan boshqaruv madaniyatiga: maʼlumotlar sifati (Data Quality) top-menejment javobgarligi sohasiga aylanadi

Bank-liderlar — Ipoteka-bank, Asakabank, Xalq banki va Turonbank — MB tomonidan RegTech joriy etishdagi muvaffaqiyatlari uchun taqdirlandi. Ortda qolish nafaqat operatsion, balki toʼgʼridan-toʼgʼri regulyator xavflarini keltirib chiqaradi.

Qozogʼistonda parallel jarayon: Shaxsiy maʼlumotlar toʼgʼrisidagi qonun (No. 94-V) va lokalizatsiya talablari bank infratuzilmasiga oʼxshash bosim oʼtkazadi.

RegTech MB asosiy bosqichlari

2. Banklar nimani joriy etishi shart

No 3697 qaror (2025 oktyabr) Basel III ga moslashtirilgan qatʼiy normativlarni joriy etadi. Bu oddiy hisobot formalari emas — bank IT-tizimlariga arxitektural talablar.

Eng kam talablar toʼplami

1. Maʼlumotlarni avtomatik uzatish: Banklar MB tizimiga maʼlumotlarni avtomatik uzatishga oʼtishi shart. 140 dan ortiq elektron talab ishlab chiqilgan. Excel da qoʼlda tayyorlash — endi variant emas.
2. Data Governance Framework: Maʼlumotlar sifatini ichki nazorat qilishni joriy etish majburiy. MB xatolar topilganda hisobotlarni qayta topshirishni talab qiladi. CDO tayinlash.
3. Yagona maʼlumotlar luʼgʼati: Ichki kodlarni (filiallar, valyutalar, kredit turlari) KPMG ishlab chiqqan MB «Yagona maʼlumotlar modeli» bilan sinxronlash.
4. Xavfsiz integratsiya: «Shaxsiy kabinet» (portal) va API-kanallaridan raqamli imzo bilan maʼlumot almashish uchun foydalanish. Oʼzbekistonda shaxsiy maʼlumotlarni lokalizatsiya qilish.

Tavsiya: banklar KPMG/MB «Yagona maʼlumotlar modelini» oddiy hisobot talabi sifatida emas, oʼz DWH uchun etalon arxitektura sifatida koʼrishi kerak.

3. Legacy-stek nega yetarli emas

Oʼzbekiston bank sektori tarixan monolitik ABT larga tayanadi: Colvir, CBS B2, Oracle Flexcube. Ular OLTP-tranzaksiyalar uchun ishonchli, lekin RegTech vazifalari uchun cheklangan:

• Arxitektural yopiqlik: maʼlumotlar propriyetar BD ichida «qulflangan». Analitika uchun chiqarish produktiv konturga yuklanish yaratadi.
• Nativ analitikaning yoʼqligi: oʼrnatilgan hisobot modullari qatʼiy formalarga cheklangan, anomaliya izlash uchun moslashuvchan ad-hoc tahlil yoʼq.
• Maʼlumotlar fragmentatsiyasi: core banking, protsessing, CRM, mobil ilova — mijoz haqida maʼlumot tizimlar orasida tarqalgan.
• T+1 omborlar: tungi yuklanishli anʼanaviy DWH MB talablariga real-time xavf monitoringi boʼyicha mos kelmaydi.

Muammo maʼlumotlarning yoʼqligida emas, ularning tezkor tahlil uchun mavjud emasligida. Bozorga Real-Time Data Warehouse arxitekturasi kerak.

4. RegTech infratuzilmasi sifatida Data Lakehouse

Apache Doris (VeloDB) asosiy ziddiyatni hal qiladi: banklarga granular maʼlumotlarga real-time analitika kerak, lekin OLTP-tizimlarga yuklanishsiz.

VeloDB: banklar uchun uch darajali saqlash modeli — ODS (xom maʼlumotlar, Duplicate Key, audit trail), DWD (joriy holatlar, Unique Key), ADS (vitrinalar, Aggregate Key, dashboardlar uchun prekalkulyatsiya).

5. Arxitektura: ABT dan MB hisobigacha

6. Toʼrtta foydalanish stsenariysi

Stsenariy 1: Kapital yetarliligi monitoringi (Basel III)

No 3697 qaror real-time da taqsimlanmagan foyda va zararlarni hisobga olishni, shuningdek balansdan tashqari instrumentlar boʼyicha xavflarni baholashni talab qiladi.

• Qlik Replicate / Flink CDC ABT dan bitimlar, xazina pozitsiyalari va kredit portfeli haqida maʼlumotlarni yigʼadi
• Doris aktivlarni xavf guruhlari boʼyicha tasniflaydi. Millionlab kredit shartnomalarini qayta hisoblash — soniyalar, soatlar emas
• Stress-testlash: «Som kursi 10% ga tushsa-chi?» — kapital yetarliligini bir zumda qayta hisoblash
• BI-dashboard normativlarning «svetoforini» koʼrsatadi. Chegaraviy qiymatga yaqinlashganda alert

Stsenariy 2: AML va tranzaksion monitoring

Naqdsiz toʼlovlarning oʼsishi tranzaksiyalarni millisekundlarda tekshirishni talab qiladi. T+1 rejimi firibgarlarga mablagʼni chiqarishga imkon beradi.

• Doris sekundiga gigabaytlar darajasida ingestion qoʼllab-quvvatlaydi — protsessingdan tranzaksiyalar bazaga bir zumda tushadi
• Murakkab detektsiya logikasi: «bir soatda 10+ kishidan oʼtkazma olib, bankomatda naqd pul olgan mijozlar» — bu multi-table JOIN
• Keys: yirik bank Apache Doris da har kuni oʼnlab ming shubhali tranzaksiyani toʼxtatadi

Stsenariy 3: Audit uchun ELK Stack ni almashtirish

Banklar xodimlarning kirish loglari va tizim hodisalarini saqlashga majbur. ELK Stack kuniga oʼnlab TB da qimmatga tushadi.

• ZSTD siqish + ustunli saqlash: maʼlumotlar hajmi Elasticsearch ga nisbatan 3-5 marta kam
• Tiered Storage: eski loglar (3 oydan oshiq) avtomatik S3/MinIO ga koʼchadi, SQL uchun mavjud qoladi
• Invertlangan indekslar: kalit soʼzlar boʼyicha qidiruv Elasticsearch ga nisbatan 2-4 marta tezlashadi

Stsenariy 4: XHHS 9 va kredit yoʼqotishlarini modellashtirish

XHHS 9 standarti prognoz maʼlumoti asosida kutilayotgan kredit yoʼqotishlarini (ECL) hisoblashni talab qiladi.

• Doris ichki maʼlumotlarni (toʼlov intizomi) va tashqi makroiqtisodiy maʼlumotlarni bitta platformada birlashtiradi
• Toʼliq portfelda (millionlab kreditlar) ECL modelini qayta hisoblash — soatlar emas, daqiqalar
• BI xavf bosqichlari orasidagi portfel migratsiyasini (Stage 1, 2, 3) risk-menejerlar uchun vizualizatsiya qiladi

7. 180 kunga yoʼl xaritasi