Вітрини даних АРРФР: що банкам Казахстану треба встигнути до 1 січня 2027 року

Вітрини даних АРРФР 2027: вимоги до банків Казахстану

З 1 січня 2027 року банки Казахстану мають відкрити регулятору прямий доступ до своїх даних через вітрини. Проєкт правил АРРФР уже опубліковано, а до Нового року лишилися лічені тижні. Розбираємося, що саме вимагається, чому «зробимо в грудні» не спрацює і як перетворити обов’язок на корисний для банку актив.

Що сталося

Новий закон «Про банки і банківську діяльність у Республіці Казахстан» зобов’язав банки другого рівня вести вітрини даних. Запуск уже один раз переносили: замість червня 2026 року норми набирають чинності 1 січня 2027 року. Другого відтермінування ніхто не обіцяв.

16 жовтня 2026 року Агентство з регулювання та розвитку фінансового ринку (АРРФР) опублікувало проєкт постанови з правилами формування, ведення та оновлення вітрин. Публічне обговорення завершилося 3 листопада. На момент виходу цієї статті документ залишається проєктом, і деталі ще можуть змінитися. Але каркас вимог зрозумілий уже зараз, і чекати остаточної редакції, щоб почати роботу, — те саме, що чекати першого снігу, щоб купити зимову гуму.

Що саме вимагається від банку

Вітрина даних — це окрема база систематизованої інформації на інфраструктурі самого банку. Регулятор не забирає дані до себе, а звертається до вітрини через централізовану платформу. Технологічний оператор платформи — Центр цифрового розвитку Національного банку.

Закон називає базові категорії даних: кредитний портфель, великі вкладники, великі платежі, перекази грошей і зняття готівки. Повний перелік полів регулятор визначить у технічних специфікаціях.

Ключові вимоги проєкту:

  • Лише автоматичне завантаження. Дані потрапляють у вітрину з внутрішніх систем банку без участі людини. Ручне завантаження заборонено, тож звичний «подвиг в Excel перед звітною датою» більше не варіант.
  • Робота 24/7. Вітрина має бути доступна цілодобово.
  • Контроль якості. Дані перевіряються і на боці банку, і на платформі оператора на відповідність затвердженим специфікаціям.
  • Незмінний журнал. Фіксується, хто, коли і до яких даних звертався. Журнал не можна редагувати й видаляти, зберігати його треба щонайменше три роки.
  • Жорсткі строки в разі збоїв. Про планові роботи банк попереджає за п’ять робочих днів. Про позаплановий збій повідомляє протягом двох годин після виявлення, усуває його за три робочі дні, а потім звітує про причини протягом одного робочого дня.
  • Захищені канали. Доступ організовується або запитами до бази в режимі читання, або через API. Банківська таємниця при цьому не скасовується.

Вимоги поширюються на банки другого рівня та філії банків-нерезидентів.

Чому це не «ще один звіт»

Звіт можна зібрати вручну, перевірити очима й надіслати до строку. Вітрина так не працює: вона має бути актуальною завжди, а не до п’ятого числа. Це змінює саму природу завдання.

Звіт — це фотографія. Вітрина — пряма трансляція. На фотографії можна поправити світло й прибрати зайве з кадру. У прямому ефірі видно все як є: розбіжності між АБС і кредитним модулем, довідники, які в кожній системі ведуться по-своєму, «тимчасові» ручні коригування, яким пішов п’ятий рік.

Тому проєкт вітрини — це на 20% питання технологій і на 80% питання порядку в даних. Як то кажуть, не дзеркало винне.

У що обходиться запізнення

Конкретних санкцій за неготовність вітрини проєкт правил не описує, і вигадувати суми штрафів ми не будемо. Але ціна запізнення складається не лише зі штрафів:

  • Увага нагляду. Вітрини потрібні регулятору для раннього виявлення ризиків. Банк, у якого вітрина не працює або віддає неякісні дані, сам стає таким ризиком.
  • Аврал замість проєкту. Що пізніший старт, то вищий шанс зустріти 1 січня з тимчасовим рішенням. А тимчасівка — це дорого, нервово і з технічним боргом, який доведеться віддавати весь наступний рік.
  • Робота в режимі «пожежної команди». Дві години на повідомлення про збій і три робочі дні на його усунення — це вимоги до зрілого процесу експлуатації. Зібране нашвидкуруч рішення ламатиметься частіше, а кожен збій тепер бачить регулятор.
  • Втрачена вигода. Банк, який будує вітрину «для галочки», платить повну ціну і не отримує від неї нічого для себе.

Скільки часу це займає насправді

Головна помилка планування — рахувати лише час розробки. До першого рядка коду банк проходить вибір підрядника, погодження договору, оформлення доступів до систем. Кожен із цих кроків легко забирає тижні, а не дні.

Далі йде найбільш трудомістке: інвентаризація джерел, узгодження логіки розрахунку показників, очищення довідників, налаштування завантажень, перевірки якості, навантажувальні тести, вибудовування експлуатації. Сім разів відміряй тут не приказка, а план-графік.

За нашою оцінкою, контур вітрини під ключ займає близько восьми тижнів від підписання договору, причому етапи частково йдуть паралельно. Арифметика проста: договір, підписаний у листопаді, ще залишає шанс на повноцінний запуск до 1 січня. Пізніше до цієї дати реально поставити лише тимчасове рішення і вже потім доводити його до цільового.

Висновок: якщо проєкт іще не розпочато, кожен тиждень без рішення скорочує план. Відкладати на грудень — означає заздалегідь обрати тимчасівку.

Що робити зараз: план на найближчі тижні

  1. Призначити власника. Вітрина — не «проєкт ІТ». Потрібен керівник із повноваженнями над ІТ, ризиками, фінансами та звітністю одночасно.
  2. Провести інвентаризацію джерел. Де сьогодні живуть дані про кредити, вклади, платежі, перекази й готівку? Які системи, які формати, хто відповідає.
  3. Оцінити якість даних. Знайти розбіжності раніше, ніж їх знайде платформа оператора.
  4. Обрати архітектуру. Окрема вітрина поверх наявного сховища або нове сховище даних (DWH) з вітриною як першим споживачем. Другий шлях довший на старті, але окупається. В обох випадках АБС міняти не потрібно: вітрина ставиться окремим контуром поруч.
  5. Спроєктувати експлуатацію. Моніторинг, чергування, регламент повідомлень про збої, резервування. Вимога 24/7 — це про людей і процеси не менше, ніж про сервери.
  6. Закласти зміни. Специфікації уточнюватимуться. Рішення, в якому кожне нове поле потребує місяця доопрацювань, застаріє раніше, ніж запрацює.

На чому ми будуємо сховища та вітрини

Регуляторна вітрина — не привід купувати закриту «коробку» з ліцензією на роки вперед. Ми будуємо корпоративні сховища даних (КСД) і вітрини на відкритих технологіях, на яких працюють світові технологічні компанії. Той рідкісний випадок, коли модне збіглося з практичним.

  • StarRocks + Apache Iceberg: відкритий код і відкритий формат. Iceberg народився в Netflix і працює в Apple, StarRocks використовують Airbnb і Pinterest. Дані банку лежать у відкритому форматі, а не в «чорній скриньці» постачальника.
  • dbt: правила як код. Кожне правило розрахунку — це код з автоматичними тестами, який зберігається в Git-репозиторії банку. Видно, хто, коли і що змінив. Для аудиту це знахідка, для команди — кінець епохи «спитайте в того, хто пам’ятає, як це рахується».
  • Data Vault 2.0: нове джерело без переробки. Регулятор розширив перелік полів, банк змінив АБС або запустив новий продукт — сховище добудовують, а не перебудовують.
  • Перевірка до завантаження, карантин, сповіщення. Дані перевіряються на вході. Сумнівні записи йдуть у карантин, відповідальні одразу отримують сповіщення. Дані звіряються з балансом, а кожне поле вітрини простежується до джерела і правила розрахунку. У вітрину потрапляє лише те, що пройшло контроль.
  • Оболонка і портал керування від RBC Group. Поверх відкритого стека ми даємо власну оболонку і портал із дашбордами, через які банк керує своїм КСД. Завантаження, свіжість даних, результати перевірок і сповіщення видно на одному екрані, а не в десятку консолей.
  • Прозорість замість «чорної скриньки». Правила розрахунку і модель даних зберігаються в Git-репозиторії банку: будь-яку зміну видно, її можна перевірити, і вона залишається у вас.

Що це дає керівникові:

  • Бюджет іде в результат. За відкрите програмне забезпечення не треба платити ліцензії. Гроші йдуть на впровадження та інфраструктуру, а не на право користуватися.
  • Підтримувати просто. В основі — SQL і код у Git. Таких фахівців на ринку значно більше, ніж знавців рідкісної закритої платформи, а новий співробітник читає правила в репозиторії, а не відновлює їх за усними переказами.
  • Готовність до ШІ. Правила, записані як код, зрозумілі не лише інженерам, а й ШІ-асистентам: пояснити розрахунок показника, запропонувати тест, підготувати зміну. А дані у відкритому форматі доступні будь-яким аналітичним і ML-інструментам без вивантажень і конвертацій.

Саме так улаштовані платформи даних у компаній, які молодші за більшість банків і при цьому обробляють на порядки більше даних. Добра новина: банку не потрібно бути Netflix, щоб користуватися тими самими інструментами.

Як отримати від вітрини користь для самого банку

Добра новина: дані, потрібні регулятору, потрібні й правлінню. Кредитний портфель, великі клієнти, грошові потоки — це основа управлінської звітності, ризик-аналітики та бюджетування.

Якщо будувати вітрину на нормальному сховищі даних, той самий фундамент закриває одразу кілька завдань: регуляторну вітрину, управлінські звіти без ручного збирання, план-факт аналіз і сценарне планування в EPM-системі, такій як IBM Planning Analytics. Один раз навели лад у даних — і користуються всі, від ризик-менеджера до фінансового директора.

Будувати вітрину лише для регулятора — як провести в дім воду і користуватися одним краном.

Запитання та відповіді

Що таке вітрина даних АРРФР?

Це база систематизованої інформації на інфраструктурі банку, до якої Агентство з регулювання та розвитку фінансового ринку отримує захищений доступ для нагляду й раннього виявлення ризиків.

З якої дати діє вимога?

Норми закону про вітрини даних набирають чинності 1 січня 2027 року. Правила формування та ведення вітрин на момент публікації статті існують у вигляді проєкту постанови АРРФР.

Кого стосується вимога?

Банків другого рівня Казахстану та філій банків-нерезидентів.

Які дані мають бути у вітрині?

Закон називає кредитний портфель, великих вкладників, великі платежі, перекази грошей і зняття готівки. Точний склад полів визначать технічні специфікації регулятора.

Чи можна завантажувати дані у вітрину вручну?

Ні. Проєкт правил вимагає автоматичного завантаження з внутрішніх систем банку і прямо забороняє ручне.

Чи передаються дані банку на зберігання регулятору?

Ні. Первинні дані залишаються в банку. Платформа оператора звертається до вітрини під час кожного запиту і не зберігає первинні дані постійно.

Чим вітрина даних відрізняється від DWH?

DWH — це сховище, де дані з різних систем банку зібрані та зведені до єдиного вигляду. Вітрина — це підготовлений зріз цих даних під конкретного споживача, у цьому випадку під регулятора. Найнадійніше вітрина працює тоді, коли під нею є сховище.

На яких технологіях RBC Group будує сховища та вітрини?

На відкритому стеку: StarRocks і Apache Iceberg для зберігання та запитів, dbt для правил розрахунку і тестів, методологія Data Vault 2.0 для моделі даних. Керування сховищем іде через оболонку і портал із дашбордами від RBC Group. Правила розрахунку і модель даних зберігаються в Git-репозиторії банку.

Чим може допомогти RBC Group

RBC Group будує сховища даних для банків Казахстану на відкритих технологіях, розробляє рішення для регуляторних вітрин і впроваджує IBM Planning Analytics для бюджетування та управлінської звітності на тих самих даних. Ядро нашої команди будує сховища даних для банків і фінансових організацій із 2002 року. Якщо вам потрібно оцінити готовність банку до вимог 2027 року, почніть із короткого аудиту джерел і якості даних: він покаже реальний обсяг робіт і строки.

Зв’язатися з нами: marketing@rbc-grp.solutions, +7 727 258 1712.

Джерела

Статтю підготовлено за відкритими джерелами станом на 13 листопада 2026 року: публікаціями ділових видань Казахстану про проєкт постанови АРРФР (російською мовою). Вона не є юридичною консультацією; після затвердження постанови вимоги можуть відрізнятися від проєкту.



Залишити відповідь