ASPSP веде payment account і надає захищений interface; AISP за згодою користувача отримує account information, але не рухає кошти; PISP передає instruction на ініціювання платежу, не стаючи власником рахунку. В українському Open Banking кожна роль потребує відповідного статусу, а consent і strong customer authentication залишаються у визначеному flow.
Один fintech може мати кілька authorisations, тому brand name не визначає role конкретного screen. Користувач має бачити, чи він дозволяє read-only analytics або створення payment instruction, які accounts і data охоплені та хто виконує authentication. Merchant також повинен відрізняти initiation від final settlement.
Інформацію та офіційні джерела перевірено 2026-08-03. Якщо у матеріалі є майбутня дата набрання чинності, вона не означає, що правило вже діє.
Межі цього матеріалу
| Параметр | Сценарій |
|---|---|
| Хто платить | український account holder, що надає згоду або ініціює payment |
| Кому | beneficiary платежу; AISP/PISP є service provider, а не одержувачем коштів за замовчуванням |
| Мета | визначити роль кожного учасника й межі дозволеної дії |
| Валюта / інструмент | ASPSP API, AISP data access, PISP initiation, consent і SCA |
| Що змінює висновок | authorised role, account type, consent scope, authentication, payment status і provider contract |
Що потрібно знати до платежу
ASPSP обслуговує рахунок
НБУ описує ASPSP як account-servicing payment service provider у моделі відкритого банкінгу. Саме його interface дає authorised third party доступ за правилами. (НБУ — Відкритий банкінг)
AISP і PISP виконують різні функції
Офіційна сторінка НБУ розділяє account-information service та payment-initiation service. AISP authorisation не надає автоматичного права ініціювати переказ. (НБУ — Відкритий банкінг)
Український framework діє з 1 серпня 2025 року
НБУ повідомив про набрання чинності Положенням про відкритий банкінг 1 August 2025. Конкретний provider все одно перевіряється за власним дозволеним scope. (НБУ — Положення про відкритий банкінг)
Покрокова підготовка
- Назвіть account holder і ASPSP. Зафіксуйте, у якому банку/установі ведеться рахунок і який API channel використовується.
- Перевірте TPP role. Знайдіть legal entity та підтвердьте AISP, PISP або обидва дозволи для requested feature.
- Прочитайте consent object. Звірте accounts, data categories, purpose, duration або payment amount/beneficiary до approval.
- Пройдіть bank authentication. Підтверджуйте access у ASPSP-controlled flow; не передавайте password чи one-time code TPP.
- Перевірте результат ролі. Для AISP контролюйте отримані data, для PISP — initiation/status, а credit підтверджуйте окремо.
Які дані та документи зібрати
- provider legal identity та AISP/PISP authorisation evidence
- ASPSP coverage і supported account/API function
- consent receipt із scope, purpose, accounts і validity
- payment initiation/status або data-access audit record
Документи мають пояснювати одну й ту саму операцію: хто платить, кому, за що, скільки, у якій валюті та до якої дати. Якщо назва отримувача, рахунок або призначення не узгоджуються між файлами, спочатку отримайте письмове пояснення й актуальну версію документа.
Практичний сценарій
Бухгалтер підключав dashboard і побачив кнопку «підтвердити доступ до платежів». Legal entity мала AISP permission, а wording означав читання payment-account transactions, не initiation. Компанія звірила role в official data, скоротила consent до одного account і пройшла authentication у bank interface. Для майбутнього Pay by Bank обрала окремого authorised PISP.
Це приклад логіки перевірки, а не обіцянка результату для іншого клієнта. Навіть схожі платежі можуть відрізнятися через країну, банк, суму, валюту, тип отримувача та дату.
Типові помилки
- говорити, що AISP може списувати кошти
- вважати PISP банком, який веде account
- визначати authorisation лише за логотипом застосунку
- плутати accepted initiation з final beneficiary credit
Де проходить межа поради
Роль описує дозволений service type, але не гарантує підтримку кожного account або bank. Exact consent, API та status semantics визначають чинні акти НБУ й provider implementation.
Матеріал має інформаційний характер і не є юридичною, податковою, фінансовою, інвестиційною, імміграційною або санкційною консультацією. Для дії перевірте актуальний первинний документ і, коли потрібно, зверніться до профільного спеціаліста.
Як перейти від статті до конкретної заявки
TradePay може прийняти конкретний платіжний сценарій на індивідуальну перевірку маршруту, реквізитів і доступності; це не є гарантією виконання, строку, курсу або відповідності до завершення перевірки. Після цього чекліста можна передати підготовлений контекст менеджеру TradePay — країни, суму, валюту, призначення, реквізити й дедлайн.
За змінами платіжних маршрутів і практичними розборами можна стежити в Telegram-каналі TradePay Desk.
Важливо
Матеріал має інформаційний характер. Доступність маршруту, строк, курс і підсумкова вартість залежать від країни, валюти, реквізитів та перевірки конкретної заявки менеджером.
Джерела та перевірка
Дата редакційної перевірки: 2026-08-03.
TradePay Desk
Перевірте маршрут до відправлення коштів
Менеджер уточнить реквізити, валюту та доступний спосіб розрахунку для вашої заявки.
Зворотний зв’язок
Наскільки корисним був матеріал?
Оцінка допомагає редакції обирати теми та оновлювати пояснення.
Оберіть оцінку від 1 до 5.