Новини та зміни

Рік Open Banking в Україні: API, AISP і PISP після серпня 2025 року

Що реально змінилося після старту українського Open Banking 1 серпня 2025 року: ролі учасників, API, consent і ознаки доступності.

Схема TradePay до теми «Рік Open Banking в Україні: API, AISP і PISP після серпня 2025 року»
Зображення: Редакція TradePay TradePay Blog — оригінальна редакційна графіка © TradePay. Усі права захищено

Open Banking в Україні набрав нормативного старту 1 серпня 2025 року, але це не означає однакову готовність усіх банківських застосунків. ASPSP відкриває стандартизований доступ, authorised AISP отримує account information, а PISP ініціює payment лише за consent і authentication користувача. Adoption слід оцінювати за реєстрами, API readiness і фактичними customer journeys, не вигаданою кількістю users.

Перший рік інфраструктури — це не лише launch date. Providers мають пройти authorisation, certificates та API onboarding; bank і TPP повинні коректно обмінюватися consent, account і status data. Навіть нормативно доступна функція може ще не бути увімкнена в конкретному UI або продукті.

Інформацію та офіційні джерела перевірено 2026-08-03. Якщо у матеріалі є майбутня дата набрання чинності, вона не означає, що правило вже діє.

Межі цього матеріалу

Параметр Сценарій
Хто платить український account holder, що дозволяє data access або ініціює payment
Кому merchant чи beneficiary; AISP/PISP обробляє дозволену interaction
Мета оцінити фактичну readiness українського Open Banking після нормативного старту
Валюта / інструмент ASPSP API, qualified certificates, consent, SCA і TPP authorisation
Що змінює висновок provider status, supported bank/API, customer segment, consent scope, endpoint readiness і UI availability

Що потрібно знати до платежу

Положення набрало чинності 1 серпня 2025 року

НБУ датував запуск regulatory framework відкритого банкінгу 1 August 2025. Ця дата є legal/infrastructure milestone, а не статистикою активних користувачів. (НБУ — Положення про відкритий банкінг)

НБУ розділяє AISP, PISP та ASPSP

Офіційна сторінка НБУ описує provider roles, відкриті API, certificates й authorization flow. Роль сервісу визначає, чи він читає дані або ініціює payment. (НБУ — Відкритий банкінг)

Доступ базується на згоді

НБУ framework пов’язує third-party access із explicit consent та authentication account holder. Передача login/password сторонньому застосунку не є нормальною Open Banking flow. (НБУ — Відкритий банкінг)

Покрокова підготовка

  1. Перевірте authorisation provider. Знайдіть legal entity, її дозволену AISP/PISP role і certificate status в офіційних даних.
  2. Підтвердьте bank support. Перевірте потрібний account type, API function і доступність journey для вашого customer segment.
  3. Пройдіть consent flow. Читайте scope, purpose, accounts і duration до redirect у bank-owned authentication channel.
  4. Збережіть status evidence. Для payment запишіть provider reference, bank status, time і beneficiary, не копіюючи secret tokens.
  5. Вимірюйте adoption офіційно. Використовуйте датовані НБУ metrics або provider register, а відсутні числа прямо позначайте як невідомі.

Які дані та документи зібрати

  • provider authorisation/role record і certificate metadata
  • bank API coverage та customer-journey test evidence
  • consent receipt із scope, accounts, purpose і duration
  • payment/data-access log без credentials та secret tokens

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

Практичний сценарій

SME хотіло підключити cash-flow dashboard і вважало, що будь-який fintech уже бачить усі рахунки. Воно перевірило AISP authorisation, coverage двох банків і exact consent fields; один business account ще не підтримував потрібний endpoint. Компанія підключила лише доступний рахунок, не передала пароль і зафіксувала limitation замість твердження, що Open Banking «не працює».

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

Типові помилки

  • називати 1 серпня масовим launch у кожному bank app
  • приписувати AISP право рухати кошти
  • вигадувати user/provider counts без датованої статистики НБУ
  • вводити banking credentials на сторінці third-party service

Де проходить межа поради

Конкретна availability залежить від authorised provider, ASPSP, account type та поточного API deployment. Публічний regulatory start не гарантує feature у кожному застосунку.

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

Як перейти від статті до конкретної заявки

TradePay може прийняти конкретний платіжний сценарій на індивідуальну перевірку маршруту, реквізитів і доступності; це не є гарантією виконання, строку, курсу або відповідності до завершення перевірки. Після цього чекліста можна передати підготовлений контекст менеджеру TradePay — країни, суму, валюту, призначення, реквізити й дедлайн.

За змінами платіжних маршрутів і практичними розборами можна стежити в Telegram-каналі TradePay Desk.

Важливо

Матеріал має інформаційний характер. Доступність маршруту, строк, курс і підсумкова вартість залежать від країни, валюти, реквізитів та перевірки конкретної заявки менеджером.

Джерела та перевірка

  1. НБУ — Відкритий банкінг
  2. НБУ — Положення про відкритий банкінг

Дата редакційної перевірки: 2026-08-03.

TradePay Desk

Перевірте маршрут до відправлення коштів

Менеджер уточнить реквізити, валюту та доступний спосіб розрахунку для вашої заявки.

Уточнити маршрут Читати в Telegram

Зворотний зв’язок

Наскільки корисним був матеріал?

Оцінка допомагає редакції обирати теми та оновлювати пояснення.