25 липня 2025 року Постановою Правління Національного банку України було прийнято Постанову № 80 «Про затвердження Положення про відкритий банкінг в Україні» (Постанова НБУ № 80), яка набрала чинності 1 серпня 2025 року та відповідно до якої надавачі платіжних послуг з обслуговування рахунків (банки) повинні привести свою діяльність у відповідність до вимог Положення протягом п'яти місяців із дня набрання чинності постановою - до 1 січня 2026 року.
Впровадження відкритого банкінгу є завершальною частиною імплементації норм Директиви ЄС про платіжні послуги 2015/2366 (PSD2), що, в свою чергу, передбачає обмін даними між надавачами платіжних послуг (НПП) через спеціалізовані інтерфейси лише за активною згодою користувача на передачу такої інформації для отримання відомостей з рахунку/рахунків користувача (наприклад, інформації про баланс, історію операцій) та з метою ініціювання платіжної операції.
Згода користувача - це активна згода, підтверджена посиленою автентифікацією, яку банк має прийняти і зафіксувати перед тим, як передавати будь-які відомості про рахунок сторонньому НПП. Користувач може відкликати цю згоду у будь-який момент через інтерфейс банку або через інтерфейс стороннього сервісу.
Хто ініціює отримання згоди?
Ініціатором отримання згоди від клієнта може бути як банк, в якому у клієнта відкрито рахунок, так і сторонній надавач послуг. Ймовірно, що у більшості випадків ініціатором буде виступати сторонній НПП (AISP або PISP) - це буде означати, що користувач у застосунку стороннього сервісу чи на сайті стороннього сервісу буде використовувати опцію, наприклад, «підключити рахунок», «підтвердити доступ» або «оплатити через…», після чого сторонній НПП буде надсилати запит до банку (через API) з проханням отримати згоду користувача/ініціювати автентифікацію.
Також можливий й інший сценарій, за якого користувач напряму заходить у додаток банку і через нього дає дозвіл на передачу певної інформації сторонньому сервісу (наприклад, коли користувач замовив інтеграцію прямо в інтерфейсі або мобільному додатку банку).
На кого покладається відповідальність за отримання та верифікацію згоди?
Відповідальність за отримання та підтвердження (верифікацію) згоди покладена на банківську установу, в якій у користувача відкрито рахунок. Банк несе відповідальність перед користувачем за: шкоду, заподіяну користувачу в разі недотримання банком вимог Постанови НБУ № 80; невиконання або неналежне виконання платіжних операцій, ініційованих користувачем через НПП з ініціювання платіжної операції, якщо не доведе, що платіжні операції виконані банком належним чином; розкриття сторонньому НПП інформації, що містить банківську таємницю, комерційну таємницю, таємницю надавача платіжних послуг без дозволу користувача та/або в обсязі, на який не було отримано дозвіл користувача.
Банк повинен провести посилену автентифікацію користувача та відобразити потрібну інформацію (як про сторонній НПП, так і про обсяг/строк доступу) перед тим, як прийняти згоду від користувача.
Сторонній сервіс відповідає за те, щоб запит на доступ був правильно сформований і те, щоб він перевірив наявність чинної згоди перед отриманням даних/ініціацією платежу. Після отримання згоди сторонній НПП повинен оновлювати статус згоди запитами до банку (чи є згода актуальною, чи не була згода відкликана користувачем).
Вся інформація для твоєї компанії - тепер в єдиному продукті LIGA360. Збільшуй швидкість виявлення бізнес-ризиків: правових, регуляторних, санкційних, репутаційних, судових, фінансових, договірних. Замов презентацію прямо сьогодні.
Покроковий шлях отримання згоди на надання відомостей про рахунок
користувач ініціює підключення у сторонньому сервісі (або в інтерфейсі банку). Наприклад, у додатку користувач обирає «підключити рахунок», далі обирає банк, далі сервіс формує запит доступу (які рахунки, який обсяг даних, на який строк надається згода);
сторонній сервіс надсилає запит до банку через спеціалізований API (спеціалізований інтерфейс);
запит містить технічні параметри і реквізити (який саме сторонній сервіс, який рахунок, обсяг інформації, строк дії тощо). Банк зобов'язаний забезпечити базову спроможність приймати такі запити (базові API - обов'язкові);
банк проводить автентифікацію користувача (це обов'язково має бути посилена автентифікація) і далі відображає інформацію для підтвердження;
перед тим, як прийняти згоду банк у своєму каналі (мобільний застосунок, веб-банкінг тощо, іншими словами «засіб дистанційної комунікації») має відобразити користувачу: (1) назву та ідентифікатор стороннього сервісу (кому надається дозвіл (доступ до інформації)); (2) номер рахунку, до якого надається доступ; (3) обсяг інформації, до якої надається доступ (наприклад, баланс, виписки за 30 днів тощо); (4) строк дії згоди, який не повинен перевищувати 180 календарних днів; (5) умови та порядок відкликання згоди (або посилання на документ з цими умовами);
користувач підтверджує (дає згоду). Сама згода має бути підтверджена посиленою автентифікацією (Strong Customer Authentication (SCA)) - тобто банк повинен перевірити, що власник рахунку справді дає дозвіл;
після відображення інформації користувач надає свою згоду шляхом, визначеним інтерфейсом, наприклад, натискаючи у застосунку (веб-інтерфейсі) «погоджуюсь/згоден/ознайомлений та підтверджую надання згоди» в інтерфейсі банку. Після цього банк проводить SCA (PIN + підтвердження у застосунку, OTP/Push тощо) - це і буде створювати активну згоду користувача;
банк фіксує згоду в інформаційній системі й надає сторонньому сервісу підтвердження/доступ до інформації, згоду на поширення якої надав користувач;
банк має зафіксувати дату і час надання згоди (та відкликання, якщо відкликання буде, пізніше) у своїй інформаційній системі. Після успішної автентифікації банк повертає код/токен або інший механізм, що дозволяє сторонньому НПП отримувати дозволені дані через API;
сторонній сервіс під час здійснення своєї діяльності перевіряє у банка, що згода користувача активна і запитує дані в межах дозволеного обсягу, якщо згоду не було відкликано і не закінчився строк дії згоди;
кожного разу сторонній сервіс при відображенні інформації користувачу має оновлювати статус згоди через запит до банку, щоб показати актуальний статус (наприклад, щоб відобразити список активних згод).
Подібний алгоритм повинен належним чином захистити користувачів та банківські установи у взаємовідносинах з питань надання інформації про рахунок/рахунки клієнтів банку.
Порядок отримання згоди на здійснення платежу (Payment Initiation Service Provider - PISP)
Згода на виконання разової платіжної операції (разовий платіж) має надаватися користувачем кожного разу, тобто під час ініціювання кожної платіжної операції. Таким чином, для разового платежу не підходить довгострокова згода, а тому потрібна окрема підтверджена інструкція/згода на конкретний платіж. Банк під час отримання згоди на виконання платіжної операції зобов'язаний відобразити платнику в засобі дистанційної комунікації інформацію про НПП з ініціювання платіжної операції, через якого платник ініціює платіжну операцію.
Порядок відкликання згоди
Користувач може відкликати свою згоду на передачу інформації сторонньому сервісу будь-коли з використанням:
засобу дистанційної комунікації стороннього сервісу (того сервісу, якому було надано згоду) або
засобу дистанційної комунікації банку.
Для відкликання згоди SCA не є обов'язкова (п. 58 Постанови НБУ № 80), тобто користувач відкликає раніше наданий дозвіл простим запитом без потреби проходити посилену автентифікацію з боку банку. Після відкликання банк має негайно припинити надання доступу сторонньому сервісу.
Як відкликання згоди може виглядати на практиці: сторонній сервіс надсилає банку запит про відкликання (якщо користувач відкликав згоду через інтерфейс стороннього сервісу) або банк при отриманні відкликання від користувача оновлює статус у своїй системі і припиняє доступ стороннього сервісу до інформації користувача. Усі сторони зобов'язані оновлювати статус згод у своїх інтерфейсах і фіксувати час дії згод. Якщо згода була відкликана - подальший обмін інформацією повинен бути припинений одразу.
Банки та сторонні сервіси у власних засобах дистанційної комунікації зобов'язані відображати користувачу інформацію про неактивні згоди користувача на надання відомостей з рахунків із можливістю отримання користувачем деталізованої інформації про кожну таку згоду. Період, за який відображається перелік неактивних згод користувача на надання відомостей з рахунків, визначається НПП.
Додаткові обов'язки/заборони для банку при роботі зі згодою
Окрім вищеозначених вимог існують також додаткові вимоги, які передбачають, що:
банк повинен відмовити у прийнятті згоди, якщо рахунок було закрито. Тобто підключення до закритого рахунку (отримання інформації стосовно закритого рахунку) - заборонено (п. 51 Постанови НБУ № 80);
банк і сторонній сервіс зобов'язані відображати користувачу переліки активних і неактивних згод (із деталізацією: коли надано/відкликано, який рахунок, обсяг даних). Банк та сторонній сервіс мають зберігати записи про надання/відкликання згод: дата, час, ідентифікатори сторін;
банк та сторонній сервіс мають забезпечувати зберігання документів та інформації щодо виконаних платіжних операцій, ініційованих платником через НПП з ініціювання платіжної операції, та щодо всіх згод користувача на надання відомостей з рахунків не менше п'яти років із дня припинення ділових відносин із користувачем.
Практичні вимоги до реалізації інтерфейсу згоди (що саме повинно відображатися/виконуватися у UI банку)
При прийнятті згоди банк у своєму мобільному/веб-інтерфейсі повинен чітко показати й запропонувати користувачу:
назву та ідентифікацію стороннього сервісу;
який конкретно рахунок підключається (номер або його частково-маскований вигляд, наприклад, останні цифри номера рахунку);
обсяг доступу - які дані можуть передаватися сторонньому сервісу (баланс, виписки за певний період тощо);
строк дії згоди (дати початку/завершення), який не може перевищувати 180 календарних днів;
як відкликати згоду (клавіша у застосунку, посилання у веб-інтерфейсі, інструкція з необхідних дій);
запит на SCA (наприклад, підтвердження у застосунку банку, OTP, підпис) - SCA має бути виконана перед остаточним підтвердженням.
Хочете аналізувати законодавство глибше? Побачте повний контекст до кожного НПА - з новою LIGA360! До кожного документи знайдуться пов'язані закони, судова практика та аналітика. Залиште заявку на презентацію.
Хто перевіряє і як підтверджується, що згода дійсно активна?
Сторонній сервіс повинен перевіряти у банку (через API) наявність і статус згоди перед кожним отриманням даних або перед ініціацією платежу. Подібні перевірки повинні зменшити ризик роботи з неактуальними дозволами.
Короткий чек-лист для банку (що зробити технічно/процедурно, щоб дотримуватись порядку отримання згоди за Постановою НБУ № 80):
привести веб-сайт банку у відповідність до вимог Постанови НБУ № 80, зокрема положень Розділу IV Положення, затвердженого постановою;
забезпечити API для прийому запитів на отримання згоди та надання статусу (активна/неактивна (відкликана));
розробити/доповнити внутрішні нормативно-правові акти банку з урахуванням вимог Постанови НБУ № 80;
забезпечити отримання згоди користувача - фізичної особи за допомогою платіжного застосунку банку, а в разі неможливості використання такого платіжного застосунку - іншого засобу дистанційної комунікації;
реалізувати у своєму каналі (application/web) інтерфейс для відображення для користувача усіх обов'язкових пунктів стосовно згод користувача (AISP/PISP, рахунок, обсяг, строк, спосіб відкликання);
забезпечити посилену автентифікацію (SCA) на етапі підтвердження згоди;
передбачити в договорі з користувачем умови надання доступу до рахунку такого користувача сторонньому НПП. Зазначити в договорі з користувачем відповідальність сторін під час надання банком доступу до рахунку користувача сторонньому сервісу;
фіксувати та зберігати час/дату надання та відкликання згоди, зберігати ідентифікатори запитів;
негайно припиняти доступ за відкликаною згодою, регулярно відповідати на запити про статус згоди від сторонніх сервісів.
Отже, банківським установам варто приділити увагу новому Положенню стосовно відкритого банкінгу та привести свою діяльність у відповідність до 1 січня 2026 року.