Open Banking-сервіс бачить лише ті accounts і data categories, які охоплені consent та його authorised role, але scope може включати balances, account identifiers і transaction history. Перед approval звірте purpose, перелік рахунків, типи даних, строк і frequency; не давайте write/payment authority, якщо потрібна лише analytics. Access можна відкликати, а retention уже отриманих даних перевіряють окремо.
Wording «доступ до рахунку» надто широке. Один AISP просить лише current balance, інший — months of transaction history для scoring; PISP може створювати payment request. Privacy risk виникає також через derived data, exports і subcontractors, навіть коли bank password не покидає ASPSP.
Інформацію та офіційні джерела перевірено 2026-08-03. Якщо у матеріалі є майбутня дата набрання чинності, вона не означає, що правило вже діє.
Межі цього матеріалу
| Параметр | Сценарій |
|---|---|
| Хто платить | account holder, який вирішує надати data access Open Banking provider |
| Кому | authorised AISP/PISP як data recipient у межах consent |
| Мета | мінімізувати account-data exposure без втрати потрібної функції |
| Валюта / інструмент | consent screen, ASPSP API, privacy notice, revocation і data-subject request |
| Що змінює висновок | provider role, accounts, fields, history depth, purpose, duration, refresh frequency, processors і retention |
Що потрібно знати до платежу
Роль визначає тип доступу
НБУ розрізняє account-information і payment-initiation services. AISP read scope не слід описувати як універсальний доступ до руху коштів. (НБУ — Відкритий банкінг)
Український framework використовує explicit consent
Положення НБУ встановлює модель відкритого банкінгу, чинну з 1 August 2025. Точний набір fields перевіряють у конкретному consent request. (НБУ — Положення про відкритий банкінг)
UK доступ надається regulated providers
FCA Open Banking guidance пояснює authorised ecosystem і customer control. FCA framework не робить кожний finance app authorised автоматично. (FCA — Open banking and the FCA)
Покрокова підготовка
- Перевірте legal recipient. Зіставте provider name у consent із registered entity, domain, AISP/PISP role і privacy notice.
- Інвентаризуйте requested fields. Випишіть accounts, identifiers, balances, transaction history depth, refresh frequency і payment permissions.
- Скоротіть scope. Виберіть один потрібний account, коротший period і read-only function, якщо product дозволяє granular choice.
- Збережіть consent evidence. Експортуйте purpose, version, granted fields, timestamp, expiry та спосіб revocation без banking credentials.
- Перевірте exit і retention. Після відкликання контролюйте future access та запитайте, які copied/derived data залишаються і на якій підставі.
Які дані та документи зібрати
- provider registry record і privacy notice version
- consent field inventory та minimisation decision
- grant/revoke receipt із timestamps і scope
- data-retention, deletion та processor response
Документи мають пояснювати одну й ту саму операцію: хто платить, кому, за що, скільки, у якій валюті та до якої дати. Якщо назва отримувача, рахунок або призначення не узгоджуються між файлами, спочатку отримайте письмове пояснення й актуальну версію документа.
Практичний сценарій
Freelancer підключав tax app, яка просила balances і 24 months transactions з усіх accounts. Для декларації були потрібні лише business-account entries за рік. Він перевірив authorised AISP, звузив account і period, зберіг consent version та після filing відкликав refresh. Окремим request уточнив retention exported records замість припущення про automatic deletion.
Це приклад логіки перевірки, а не обіцянка результату для іншого клієнта. Навіть схожі платежі можуть відрізнятися через країну, банк, суму, валюту, тип отримувача та дату.
Типові помилки
- припускати однаковий data scope у всіх AISP
- дозволяти всі accounts заради однієї функції
- плутати revocation доступу з миттєвим deletion
- надсилати bank password сервісу для ручного підключення
Де проходить межа поради
Available granularity і privacy rights залежать від jurisdiction та product design. Матеріал не встановлює lawful retention period для конкретного provider.
Матеріал має інформаційний характер і не є юридичною, податковою, фінансовою, інвестиційною, імміграційною або санкційною консультацією. Для дії перевірте актуальний первинний документ і, коли потрібно, зверніться до профільного спеціаліста.
Як перейти від статті до конкретної заявки
TradePay може прийняти конкретний платіжний сценарій на індивідуальну перевірку маршруту, реквізитів і доступності; це не є гарантією виконання, строку, курсу або відповідності до завершення перевірки. Після цього чекліста можна передати підготовлений контекст менеджеру TradePay — країни, суму, валюту, призначення, реквізити й дедлайн.
За змінами платіжних маршрутів і практичними розборами можна стежити в Telegram-каналі TradePay Desk.
Важливо
Матеріал має інформаційний характер. Доступність маршруту, строк, курс і підсумкова вартість залежать від країни, валюти, реквізитів та перевірки конкретної заявки менеджером.
Джерела та перевірка
Дата редакційної перевірки: 2026-08-03.
TradePay Desk
Перевірте маршрут до відправлення коштів
Менеджер уточнить реквізити, валюту та доступний спосіб розрахунку для вашої заявки.
Зворотний зв’язок
Наскільки корисним був матеріал?
Оцінка допомагає редакції обирати теми та оновлювати пояснення.
Оберіть оцінку від 1 до 5.