Вимоги НБУ до IT-постачальників банків: що змінила постанова № 70 і як підготуватися до нових договорів

Банки мають до 31 грудня 2026 року перевірити постачальників за чинними договорами на зв’язки з державою-агресором, санкції й списки, пов’язані з тероризмом, а з 1 липня 2027 року вимоги до критичних постачальників застосовуються повністю. Ці вимоги НБУ до постачальників банків запроваджує постанова Правління НБУ від 30 червня 2026 року № 70 про управління ризиком третіх сторін. Адресована вона банкам, але виконувати її банк буде через договори, тож розробники, SaaS-сервіси, хмарні провайдери й аутсорс-команди, що працюють з банками, найімовірніше, отримають анкети, додатки до договорів і вимоги до власної безперервності.

Кого стосується постанова НБУ № 70: чи є ваша компанія TPSP-постачальником

Постанова змінює Положення про організацію системи управління ризиками в банках України та банківських групах (постанова НБУ № 64 від 11 червня 2018 року) і вводить поняття постачальника послуг для банку (у тексті постанови — TPSP, від англ. third-party service provider, «сторонній постачальник послуг»). Так названо юридичну чи фізичну особу, яка як суб’єкт господарювання надає послуги безпосередньо банку або учаснику банківської групи, зокрема й коли сама належить до цієї групи. Відповідний договір може бути про одну чи кілька послуг: у визначенні прямо названо аутсорсинг, послуги з підтримки діяльності банку і технологічного оператора платіжних послуг.

Переліку «розробка, SaaS, хмара» в тексті немає. Наш висновок: IT-послуги, які компанія надає банку за письмовим договором, під таке визначення, як правило, підпадають. Банк має право не враховувати кілька категорій послуг, зокрема глобальну карткову інфраструктуру, міжнародні міжбанківські системи та послуги, що не впливають на його профіль ризику й операційну діяльність (п. 290-11), але ризиками за ними все одно зобов’язаний керувати. Для IT-підрядника, чий продукт працює в процесах банку, цей виняток зазвичай не спрацює. Для постачальників, які самі перебувають під наглядом держоргану (електро-, газо-, водопостачання, телефонний зв’язок і передача даних), банк оцінює ризик за власним судженням, зіставляючи вимоги, які діють щодо таких постачальників, з вимогами постанови № 70 (п. 290-12).

Головне розрізнення: постачальник критичний чи ні. Критичною є послуга, відмова або збій якої може мати суттєвий вплив на бізнес-модель банку, безперервність діяльності, критичні функції чи дотримання законодавства. Якщо кілька некритичних постачальників мають спільного кінцевого бенефіціара або керівника, їхні послуги можуть розглядатися разом як одна критична. Критерії банк затверджує сам, у постанові немає ні порогів, ні переліку. Тому той самий SaaS може бути критичним для одного банку й звичайним для іншого, і запитувати про статус треба кожен банк окремо. Некритичні договори теж не лишаються без уваги: банк оцінює ризик концентрації, коли кілька «дрібних» договорів з одним постачальником разом небезпечніші за один критичний (п. 290-25).

Коли набувають чинності вимоги постанови НБУ № 70 і які строки до 2028 року

Постанову опубліковано на сайті НБУ 30 червня 2026 року, чинною вона стала наступного дня, 1 липня (за п. 7 постанови). Строки розкладаються так:

Строк	Що має зробити банк
до 31.12.2026	проаналізувати чинні договори з постачальниками на заборонені зв’язки, повідомити НБУ про невідповідності й вирішити: припинити договір якнайшвидше чи розробити план поетапного виходу
до 31.03.2027	затвердити план поетапного припинення, якщо банк обрав такий шлях (для критичного постачальника план затверджує рада банку, для некритичного — колегіальний орган)
до 30.06.2027	запровадити внутрішні документи й визначити перелік критичних постачальників
з 01.07.2027	застосовувати вимоги постанови до критичних постачальників
до 01.10.2027	провести перший моніторинг критичних постачальників за договорами, укладеними до 1 липня 2027 року і чинними після цієї дати
з 30.06.2028	застосовувати вимоги до постачальників, не визначених критичними

Для постачальника 2026 рік — це перевірка за «чорними списками», а не за технічними вимогами. Банк перевіряє постачальника і його кінцевих бенефіціарів за чотирма ознаками:

• Держава-агресор. Громадянство чи податкове резидентство держави-агресора або постійне проживання там.
• Санкції. Санкції України, іноземних держав (крім тих, що здійснюють збройну агресію проти України), міждержавних об’єднань чи міжнародних організацій: протягом їхньої дії і ще три роки після скасування.
• Перелік щодо тероризму. Перебування в переліку осіб, пов’язаних із тероризмом або під міжнародними санкціями, і ще десять років після виключення з нього.
• Постанова Кабміну № 187. Належність до осіб, пов’язаних із державою-агресором, яких називають абзаци другий-п’ятий підпункту 1 пункту 1 постанови від 3 березня 2022 року.

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

Що з договорами, укладеними між 1 липня 2026 і 30 червня 2027 року, постанова прямо не каже. Перевірка до 31 грудня стосується договорів, укладених до набрання чинності, а п. 290-15 зобов’язує банк враховувати обмеження й заборони, встановлені законодавством, і під час встановлення відносин, і протягом дії договору. Нові вимоги обов’язкові з 1 липня 2027 року для критичних постачальників і з 30 червня 2028 року для некритичних. Санкції й інші законодавчі заборони діють незалежно від цих строків. Чи застосовуватимуть банки нові договірні умови до угод, підписаних у проміжку, залежить від їхньої політики: норми про це немає. Якщо ви підписуєте договір з банком зараз, готуйтеся, що частину нових умов банк попросить уже в ньому.

Які умови банк внесе в договір з IT-постачальником за вимогами НБУ

П. 290-49 називає вісімнадцять умов, які мають бути в договорі з будь-яким TPSP-постачальником, і дев’ять додаткових для критичного (п. 290-50). Діють вони за тими самими строками, що й решта вимог (див. таблицю). Для IT-компанії найбільш відчутні такі:

• SLA з вимірюваними показниками. Допустимий середній час між збоями, середній час ремонту й відновлення, оперативність вирішення проблем за першим зверненням, час виконання робіт і відповідальність сторін за порушення.
• Дані, API і моделі. Хто володіє даними, застосунками, API, моделями та правами інтелектуальної власності, у який час і в якому форматі їх передадуть банку, зокрема якщо постачальник припиняє діяльність. Для компаній, що працюють на ШІ-моделях, це прямий пункт переговорів.
• Безпека і розділення даних. Відповідальність за інформаційну безпеку й кіберзахист, а також умови, що дозволяють уникнути змішування інформації банку з даними інших клієнтів.
• Країна надання послуг і дата-центр. Договір має вказувати регіон, країну надання послуг і місцезнаходження ЦОД. Для хмарних провайдерів банк керується ще й главою IV положення про хмарні обчислення (постанова НБУ № 99 від 25 серпня 2025 року, п. 290-51).
• Вихід. Умови, за яких постачальник підтримує вихід банку з відносин у разі дострокового розірвання договору.
• Право банку розірвати договір. Якщо постачальник не надав інформації про зв’язки з державою-агресором, санкції та інші обмеження за п. 290-15 або виявлено його невідповідність цим вимогам, банк може розірвати договір в односторонньому порядку.
• Інформація для НБУ. Постачальник дає згоду, щоб банк передавав Нацбанку на його запит інформацію, отриману під час укладення й виконання договору, крім вартості послуг.

Підсудність потребує обережного читання. Договір має містити положення про вибір права та підсудності «за винятком виключної підсудності (з наданням переваги застосуванню права України та підсудності справам судам України)». Формулювання можна прочитати по-різному, а роз’яснення НБУ ми не знайшли. Безпечніше вважати, що банки віддаватимуть перевагу українському праву й судам, а іноземні вендори, які сидять на стандартних умовах, ризикують отримати від банків прохання про зміни.

Для критичного постачальника п. 290-50 додає ще такі умови:

• Ключові n-ні сторони. Постачальник повідомляє банк про субпідрядників і сервіси, на яких тримається послуга, про зміни в них та їхні інциденти. Договори з такими сторонами мають передбачати їхню згоду надавати банку інформацію на запит.
• Перевірки. Банк має право доступу до приміщень постачальника й перевірок, зокрема із залученням незалежних сторін.
• Безперервність. У плані безперервності постачальник визначає мінімальний час безперервної роботи, максимальний час простою, RPO і RTO (допустиму втрату даних і час відновлення), а також бере участь у тестуванні плану безперервності банку.
• Інциденти. Договір має визначати, за який час і що саме постачальник повідомляє банку про інцидент у себе чи в ключової n-ї сторони.

Ризик третіх сторін: як банк оцінює постачальника за досвідом, фінансами й власниками

Перед договором із критичним постачальником банк проводить комплексну перевірку (пп. 290-32, 290-33), а після підписання веде постійний моніторинг заборон, репутації, альтернатив і критичності та не рідше ніж раз на рік перевіряє спроможність постачальника й відповідність договору (п. 290-54). Критерії нижче застосовуються до критичних постачальників.

Операційна спроможність (п. 290-40). Постачальник документально підтверджує досвід виконання подібних договорів чи SLA не менше ніж 12 місяців поспіль перед аналізом, кваліфікований персонал, активи у власності чи довгостроковій оренді, достатні для виконання договору, і відсутність судових спорів щодо невиконання чи неналежного виконання договорів і SLA, які за судженням банку можуть вплинути на виконання договору. Сертифікати ISO та відповідність ДСТУ банк «має право враховувати», обов’язкової вимоги мати їх немає. Для молодого стартапу найбільш відчутний саме критерій 12 місяців.

Фінансова спроможність (п. 290-41). Банк визначає власні показники фінансового стану, а також вимагає, щоб за останній звітний період не було негативного власного капіталу й невиконаних понад 180 днів фінансових зобов’язань на суму понад 50 тисяч гривень «або 10% від сукупної суми зобов’язань за договором». Формулювання допускає два читання, тож не будуйте розрахунків на одному з них: уточніть у банку, як він застосовує поріг. Банк може за своїм судженням вважати, що такий борг не впливає на виконання договору.

Власники й керівники. Репутацію оцінюють у кінцевих бенефіціарів і керівників критичного постачальника: ознаки небездоганної ділової репутації беруться з Положення про ліцензування банків № 149 (пункти 65 і 69), а банк додатково враховує підтверджені злочини проти власності, корупційні й у сфері господарської діяльності. Окремий ризик — непрозора структура власності: коли неможливо встановити всіх кінцевих бенефіціарів через номінальне володіння, трасти чи офшори (п. 290-42). Для невеликої компанії з багатошаровою структурою це прямий ризик відмови.

Ланцюг постачання. Банк аналізує самого постачальника, другу й третю ланки ланцюга, а далі може не аналізувати, якщо обґрунтовано визначить відсутність впливу. Для критичного постачальника ключові n-ні сторони банк визначає обов’язково. Практично це означає, що ваші субпідрядники й хмарні провайдери потрапляють у поле зору банку, навіть якщо договору з ними в банку немає.

План виходу банку з договору: що буде у разі розриву співпраці

Для кожного критичного постачальника банк розробляє два плани виходу й не рідше ніж раз на рік їх оновлює: запланованого припинення співпраці з графіком і поетапним передаванням активів, даних і персоналу та незапланованого, з відповідальними особами й швидким затвердженням бюджету (пп. 290-65 – 290-69). Банк також опрацьовує альтернативних постачальників або власну інфраструктуру і тестує сценарії заміни (п. 302-1). Для IT-компанії висновок прагматичний: чим легше банку забрати дані й перейти до іншого провайдера, тим менш «залежним» ви виглядаєте, і тим спокійніше проходите перевірку. Вигідним аргументом на переговорах стане готова процедура експорту даних із описаним форматом і строками.

Якщо постачальник не відповідає вимогам, наслідки різні. Якщо постачальник не відповідає вимогам п. 290-15 (санкції, зв’язки з державою-агресором), банк ухвалює рішення про припинення співпраці у найкоротший строк (п. 290-58). Якщо критичний постачальник не відповідає вимогам до репутації, спроможності чи договору, банк обирає: продовжити співпрацю або затвердити рішенням ради банку план поетапного скорочення, і до усунення порушення чи припинення відносин ризик за договором вважається високим (пп. 290-59, 290-60). Про ознаки підвищеного ризику в співпраці з критичним постачальником, як-от суттєве погіршення показників, порушення безпеки, втрата даних, інциденти, головний ризик-менеджер або підрозділ з управління ризиками інформує раду і правління не пізніше наступного робочого дня (п. 314), тож серйозний інцидент у вашій компанії може дійти до ради банку вже наступного робочого дня.

Що підготувати IT-компанії, яка працює з банками

Нижче — наш практичний порядок дій, складений за вимогами постанови.

1. Дізнайтеся, критичний ви чи ні. Запитайте у банку-клієнта, чи визначено вас критичним постачальником і за якими критеріями. Банки мають затвердити перелік до 30 червня 2027 року, тож до цього строку відповідь може бути ще неготова.
2. Складіть схему власності. Покажіть усіх кінцевих бенефіціарів і керівників, їхнє громадянство та податкове резидентство. Якщо в структурі є траст чи номінальний власник, готуйте пояснення заздалегідь: структура вважається непрозорою, коли через це неможливо встановити всіх кінцевих бенефіціарів.
3. Зберіть підтвердження 12 місяців досвіду. Цей критерій банк застосовує до критичних постачальників; підійдуть договори, акти виконаних робіт і SLA з іншими клієнтами за останній рік за умови, що ви маєте право розкривати їх без порушення NDA.
4. Опишіть SLA вимірюваними показниками. Середній час між збоями, час відновлення, оперативність вирішення проблем за першим зверненням. Якщо досі працювали на розмитому «найкращих зусиллях», перепишіть.
5. Задокументуйте безперервність. План з мінімальним часом безперервної роботи, максимальним простоєм, RPO та RTO і результатами його тестування: банк, який визнає вас критичним, вимагатиме все це в договорі.
6. Складіть перелік субпідрядників і хмарних сервісів. Особливо тих, без яких послуга не працює: це майбутні ключові n-ні сторони. Продумайте, як повідомляти банк про їх зміни й інциденти. Для критичного постачальника договори з такими сторонами мають передбачати їхню згоду надавати банку інформацію.
7. Підготуйте процедуру експорту даних. Формат, строки, перелік активів, які передаються банку при виході.
8. Перевірте фінансовий стан. Негативний власний капітал і прострочені понад 180 днів борги вище порогу (понад 50 тисяч гривень «або 10%», див. вище) можуть ускладнити шлях до критичних договорів, хоча банк може визнати такий борг несуттєвим для договору.
9. Узгодьте право й підсудність. Якщо ви працюєте на стандартних міжнародних умовах, закладіть час на обговорення цього пункту.

Якщо у вашому продукті є ШІ-компонент, ці вимоги доведеться читати разом з правилами НБУ для ШІ у фінансах, коли регулятор їх ухвалить.

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

Розбір не є індивідуальною юридичною консультацією. Ми працювали з текстом постанови № 70, а положення про хмарні обчислення, Положення № 149 та роз’яснення НБУ щодо критичності й спірних пунктів не перевіряли. Критерії критичності кожен банк визначає сам, тому актуальні вимоги уточнюйте в банку, з яким працюєте.

Часті запитання про постанову НБУ № 70