Strong Customer Authentication не зникає після надання Open Banking consent. ASPSP застосовує SCA при initial linking, payment initiation або інших подіях відповідно до чинних local rules і risk/exemption logic; повторна authentication може знадобитися через expiry, scope change чи risk trigger. Універсального інтервалу для України, ЄС і UK немає, а consent lifetime не дорівнює login session.
Користувач може бачити два схожі screens: provider consent і bank authentication. Перший визначає дозволену дію, другий підтверджує identity/authorisation у ASPSP. Надто часті prompts можуть бути incident або policy, але «не питати OTP» не означає weaker security, якщо діє інший SCA method чи exemption.
Інформацію та офіційні джерела перевірено 2026-08-03. Якщо у матеріалі є майбутня дата набрання чинності, вона не означає, що правило вже діє.
Межі цього матеріалу
| Параметр | Сценарій |
|---|---|
| Хто платить | account holder, який підключає AISP або підтверджує PISP payment |
| Кому | ASPSP проводить authentication; TPP отримує лише authorised result/data |
| Мета | правильно пояснити initial і repeat SCA без фішингових ризиків |
| Валюта / інструмент | Open Banking consent, ASPSP authentication, SCA factors і exemption/risk engine |
| Що змінює висновок | jurisdiction, service type, transaction risk, consent age/scope, device, exemption і bank policy |
Що потрібно знати до платежу
PSD2 framework містить SCA requirements
European Commission Payment Services materials описують strong customer authentication як елемент чинного EU payment framework. Proposed PSD3/PSR не скасовує current rules до adoption. (European Commission — Payment services)
Український flow розділяє consent та authorisation
НБУ Open Banking page описує API і authorization interaction AISP/PISP з ASPSP. Third party не повинен збирати customer banking password. (НБУ — Відкритий банкінг)
UK journey має власні FCA rules
FCA Open Banking guidance стосується британських authorised services. Frequency та exemptions не слід копіювати як універсальну норму для України чи ЄС. (FCA — Open banking and the FCA)
Покрокова підготовка
- Розпізнайте дію. Визначте, чи screen надає data consent, ініціює payment, renews access або лише відновлює app session.
- Перевірте redirect origin. Звірте official bank domain/app handoff і provider identity до введення будь-якого authentication factor.
- Прочитайте scope change. Перед repeat SCA порівняйте accounts, amount, beneficiary, permissions і expiry з original consent.
- Не вгадуйте exemption. Запитайте provider/bank reason code або policy, якщо frequency prompts впливає на journey; не bypass security.
- Зафіксуйте anomaly. Для unexpected prompt збережіть time, masked reference та channel, припиніть flow і зверніться official support.
Які дані та документи зібрати
- original consent receipt і scope/version
- ASPSP authentication/session event record
- payment amount, beneficiary та provider reference
- incident evidence для unexpected або repeated SCA
Документи мають пояснювати одну й ту саму операцію: хто платить, кому, за що, скільки, у якій валюті та до якої дати. Якщо назва отримувача, рахунок або призначення не узгоджуються між файлами, спочатку отримайте письмове пояснення й актуальну версію документа.
Практичний сценарій
AISP-користувач повторно побачив bank authentication через кілька тижнів і вирішив, що provider просить новий password. Screen був у official bank app і renew request не розширював accounts, але consent version змінилася. Користувач перевірив legal provider та scope, завершив SCA у ASPSP і зберіг receipt; універсальну «90-day rule» команда в інструкцію не додала.
Це приклад логіки перевірки, а не обіцянка результату для іншого клієнта. Навіть схожі платежі можуть відрізнятися через країну, банк, суму, валюту, тип отримувача та дату.
Типові помилки
- плутати consent validity з authentication session
- вводити OTP у чаті provider support
- називати один repeat interval глобальним правилом
- намагатися обходити SCA через повторні API requests
Де проходить межа поради
Exact SCA triggers, exemptions і renewal cadence визначаються чинним правом та ASPSP risk controls. Без event data неможливо оголосити repeat prompt помилкою.
Матеріал має інформаційний характер і не є юридичною, податковою, фінансовою, інвестиційною, імміграційною або санкційною консультацією. Для дії перевірте актуальний первинний документ і, коли потрібно, зверніться до профільного спеціаліста.
Як перейти від статті до конкретної заявки
TradePay може прийняти конкретний платіжний сценарій на індивідуальну перевірку маршруту, реквізитів і доступності; це не є гарантією виконання, строку, курсу або відповідності до завершення перевірки. Після цього чекліста можна передати підготовлений контекст менеджеру TradePay — країни, суму, валюту, призначення, реквізити й дедлайн.
За змінами платіжних маршрутів і практичними розборами можна стежити в Telegram-каналі TradePay Desk.
Важливо
Матеріал має інформаційний характер. Доступність маршруту, строк, курс і підсумкова вартість залежать від країни, валюти, реквізитів та перевірки конкретної заявки менеджером.
Джерела та перевірка
Дата редакційної перевірки: 2026-08-03.
TradePay Desk
Перевірте маршрут до відправлення коштів
Менеджер уточнить реквізити, валюту та доступний спосіб розрахунку для вашої заявки.
Зворотний зв’язок
Наскільки корисним був матеріал?
Оцінка допомагає редакції обирати теми та оновлювати пояснення.
Оберіть оцінку від 1 до 5.