Згоду Open Banking надавайте лише identified authorised provider і тільки на потрібні accounts, data categories, purpose та строк. Authentication проходьте на bank/ASPSP channel, не передаючи third party login, password або OTP. Для відкликання використайте provider чи bank control, збережіть confirmation і перевірте, що нові data requests припинилися; видалення застосунку саме по собі consent не скасовує.
Consent — це не одна checkbox на всі майбутні дії. Read access і payment initiation мають різний scope, а UI й revocation path залежать від юрисдикції, bank та provider. Після revocation already downloaded data можуть зберігатися за законною purpose/retention policy, тому користувачу потрібні окремі питання про доступ і видалення.
Інформацію та офіційні джерела перевірено 2026-08-03. Якщо у матеріалі є майбутня дата набрання чинності, вона не означає, що правило вже діє.
Межі цього матеріалу
| Параметр | Сценарій |
|---|---|
| Хто платить | account holder в Україні, ЄС або Британії, який керує Open Banking access |
| Кому | authorised AISP/PISP; кошти отримує лише named payment beneficiary |
| Мета | надати мінімально потрібну згоду та відтворювано її відкликати |
| Валюта / інструмент | consent object, ASPSP redirect, SCA, provider dashboard і access log |
| Що змінює висновок | jurisdiction, provider role, accounts, data scope, purpose, duration, revocation channel і retention |
Що потрібно знати до платежу
Український flow базується на authorisation і consent
НБУ описує доступ AISP/PISP через відкриті API, certificates та згоду користувача. Запит credentials на сторонній сторінці не відповідає нормальному redirect model. (НБУ — Відкритий банкінг)
Положення визначає українську правову рамку
Положення НБУ, чинне з 1 серпня 2025 року, регулює взаємодію учасників відкритого банкінгу; exact consent UI може відрізнятися між providers. (НБУ — Положення про відкритий банкінг)
UK користувач має працювати з regulated provider
FCA Open Banking guidance пояснює regulated framework і consumer access. Наявність красивого brand або app-store listing не замінює перевірку legal provider. (FCA — Open banking and the FCA)
Покрокова підготовка
- Ідентифікуйте provider. Звірте legal name, authorised AISP/PISP role, official domain і service, який ви збираєтеся підключити.
- Прочитайте scope. Перевірте accounts, balance/transaction fields, payment beneficiary, purpose та consent duration до approval.
- Контролюйте redirect. Переконайтеся, що authentication відбувається в official bank channel; не диктуйте OTP support agent.
- Відкличте формально. Скасуйте consent у bank або provider dashboard і збережіть timestamp, reference та displayed status.
- Проведіть post-check. Перевірте наступний scheduled refresh, connected-app list і provider retention/deletion response.
Які дані та документи зібрати
- provider authorisation та official-domain verification
- consent receipt із accounts, data categories, purpose і expiry
- revocation confirmation із timestamp та reference
- post-revocation access log і data-retention correspondence
Документи мають пояснювати одну й ту саму операцію: хто платить, кому, за що, скільки, у якій валюті та до якої дати. Якщо назва отримувача, рахунок або призначення не узгоджуються між файлами, спочатку отримайте письмове пояснення й актуальну версію документа.
Практичний сценарій
Власник малого бізнесу підключив budgeting app і випадково дозволив читання трьох accounts на 180 днів. Він перевірив AISP legal entity, скоротив scope до operating account і зберіг consent receipt. Після завершення проєкту відкликав доступ у банку, отримав confirmation та наступного дня перевірив, що scheduled refresh повертає revoked status, а retention питання закрив окремо.
Це приклад логіки перевірки, а не обіцянка результату для іншого клієнта. Навіть схожі платежі можуть відрізнятися через країну, банк, суму, валюту, тип отримувача та дату.
Типові помилки
- передавати TPP пароль або одноразовий bank code
- погоджувати доступ до всіх рахунків без потреби
- вважати uninstall застосунку відкликанням consent
- обіцяти негайне видалення historical data без retention analysis
Де проходить межа поради
Exact consent lifetime, revocation UI і data-retention duties залежать від jurisdiction та provider. Не вводьте credentials поза official ASPSP authentication flow.
Матеріал має інформаційний характер і не є юридичною, податковою, фінансовою, інвестиційною, імміграційною або санкційною консультацією. Для дії перевірте актуальний первинний документ і, коли потрібно, зверніться до профільного спеціаліста.
Як перейти від статті до конкретної заявки
TradePay може прийняти конкретний платіжний сценарій на індивідуальну перевірку маршруту, реквізитів і доступності; це не є гарантією виконання, строку, курсу або відповідності до завершення перевірки. Після цього чекліста можна передати підготовлений контекст менеджеру TradePay — країни, суму, валюту, призначення, реквізити й дедлайн.
За змінами платіжних маршрутів і практичними розборами можна стежити в Telegram-каналі TradePay Desk.
Важливо
Матеріал має інформаційний характер. Доступність маршруту, строк, курс і підсумкова вартість залежать від країни, валюти, реквізитів та перевірки конкретної заявки менеджером.
Джерела та перевірка
Дата редакційної перевірки: 2026-08-03.
TradePay Desk
Перевірте маршрут до відправлення коштів
Менеджер уточнить реквізити, валюту та доступний спосіб розрахунку для вашої заявки.
Зворотний зв’язок
Наскільки корисним був матеріал?
Оцінка допомагає редакції обирати теми та оновлювати пояснення.
Оберіть оцінку від 1 до 5.