Date of publication: 5 September 2025
Source: Liga:Zakon
On 25 July 2025, the Board of the National Bank of Ukraine adopted Resolution No. 80 “On the Approval of the Regulation on Open Banking in Ukraine” (NBU Resolution No. 80), which entered into force on 1 August 2025. Under this Resolution, payment service providers offering account services (banks) must bring their operations into compliance with the requirements of the Regulation within five months from the date the Resolution entered into force, i.e., by 1 January 2026.
The implementation of open banking represents the final stage in the transposition of the provisions of the EU Payment Services Directive 2015/2366 (PSD2). This, in turn, envisages the exchange of data between payment service providers (PSPs) via dedicated interfaces solely on the basis of the user’s explicit consent to transfer such information for the purpose of obtaining data from the user’s account(s) (e.g., balance information, transaction history) and for initiating a payment transaction.
User consent must be explicit and confirmed through Strong Customer Authentication (SCA), which the bank is obliged to accept and record before transmitting any account information to a third-party provider (TPP). The user may withdraw this consent at any time either through the bank’s interface or through the interface of a third-party provider.
Who Initiates the Obtaining of Consent?
The initiator of obtaining the client’s consent may be either the bank where the client holds an account or a third-party provider. In most cases, the initiator will likely be a third-party PSP (AISP or PISP). This would mean that the user, in a third-party application or on a third-party website, would select an option such as “connect account”, “confirm access”, or “pay via…”. After that, the third-party provider will send a request to the bank (via API) to obtain the user’s consent and/or initiate authentication.
Another possible scenario is where the user directly accesses the bank’s application and, through it, grants permission to transfer certain information to a third-party provider (for example, when the user orders integration directly in the bank’s interface or mobile application).
Who Is Responsible for Obtaining and Verifying Consent?
The responsibility for obtaining and verifying (confirming) user consent rests with the banking institution where the user holds an account. The bank is liable to the user for:
- damage caused to the user as a result of the bank’s failure to comply with the requirements of NBU Resolution No. 80;
- non-performance or improper performance of payment transactions initiated by the user through a payment initiation service provider (PISP), unless the bank can demonstrate that the transactions were executed correctly on its side;
- disclosure to a third-party provider of information constituting banking secrecy, commercial secrecy, or PSP secrecy without the user’s authorisation and/or beyond the scope of the authorisation granted by the user.
The bank must conduct SCA of the user and display the necessary information (regarding the third-party provider as well as the scope and duration of access) before accepting the user’s consent.
The third-party provider is responsible for ensuring that the access request is correctly formulated and for verifying the existence of valid consent before obtaining data or initiating a payment. After obtaining consent, the third-party provider must update the consent status by sending requests to the bank (to check whether the consent remains valid or has been withdrawn by the user).
Step-by-Step Procedure for Obtaining Consent to Provide Account Information
- The user initiates the connection in a third-party provider’s service (or in the bank’s interface). For example, in an application the user selects “connect account”, then chooses the bank, after which the service generates an access request (which accounts, what scope of data, and for what duration consent is granted).
- The third-party provider sends a request to the bank through a dedicated API (dedicated interface).
- The request contains technical parameters and details (which third-party provider, which account, scope of information, duration of access, etc.).
- The bank is obliged to ensure the basic capability to receive such requests (basic APIs are mandatory).
- The bank conducts user authentication (SCA is mandatory) and then displays the information for confirmation.
- Before accepting consent, the bank, through its communication channel (mobile application, web banking, or other “remote communication channel”), must display to the user: (1) the name and identifier of the third-party provider (the entity receiving access to the information); (2) the account number to which access is granted; (3) the scope of information to which access is granted (e.g., balance, statements for the last 30 days, etc.); (4) the duration of consent, which must not exceed 180 calendar days; (5) the terms and procedure for withdrawal of consent (or a reference to a document containing such terms).
- The user confirms (provides consent). The consent itself must be confirmed through SCA, i.e., the bank must verify that the account holder is indeed granting authorisation.
- After the information is displayed, the user provides consent in the manner defined by the interface, for example, by clicking “agree/consent/acknowledge and confirm consent” in the bank’s application (web interface). The bank then performs SCA (e.g., PIN + in-app confirmation, OTP/Push, etc.), which constitutes the user’s explicit consent.
- The bank records the consent in its information system and provides the third-party provider with confirmation/access to the information for which the user has granted consent to be shared.
- The bank must record the date and time of granting consent (and of withdrawal, if later withdrawn) in its information system. After successful authentication, the bank returns a code/token or another mechanism enabling the third-party provider to access the authorised data via the API.
- During its operations, the third-party provider verifies with the bank that the user’s consent remains active and requests data within the authorised scope, provided that the consent has not been withdrawn and has not expired.
- Each time the third-party provider displays information to the user, it must update the consent status by sending a request to the bank to reflect the current status (e.g., to display the list of active consents).
A similar algorithm should properly safeguard both users and banking institutions in their interactions concerning the provision of information about the bank customer’s account(s).
Procedure for Obtaining Consent to Execute a Payment (Payment Initiation Service Provider – PISP)
Consent for the execution of a single payment transaction (one-time payment) must be granted by the user each time, i.e., upon the initiation of every individual payment transaction. Accordingly, long-term consent is not applicable for a one-time payment, and a separate confirmed instruction/consent is required for each specific payment. When obtaining consent to execute a payment transaction, the bank is obliged to display to the payer, via the remote communication channel, information about the PSP through which the payer is initiating the payment transaction.
Procedure for Withdrawing Consent
The user may withdraw their consent to transfer information to a third-party provider at any time by using:
- the remote communication channel of the third-party provider (the provider to which consent was granted), or
- the remote communication channel of the bank.
SCA is not required for consent withdrawal (clause 58 of NBU Resolution No. 80). This means that the user may revoke previously granted authorisation through a simple request without undergoing enhanced authentication by the bank. After the withdrawal of consent, the bank must immediately terminate access for the third-party provider.
How consent withdrawal may appear in practice: a third-party provider sends a withdrawal request to the bank (if the user has withdrawn consent via the third-party provider interface), or the bank, upon receiving a withdrawal from the user, updates the status in its system and terminates the third-party provider’s access to the user’s information. All parties are required to update the status of consents in their interfaces and record the duration of consents. If consent has been withdrawn, further exchange of information must be stopped immediately.
Banks and third-party providers, in their respective remote communication channels, are required to display to the user information on the user’s inactive consents to provide account information, with the possibility for the user to obtain detailed information about each such consent. The period for which the list of inactive consents is displayed to the user is determined by the PSP.
Additional Duties/Prohibitions for Banks When Handling Consent
In addition to the requirements mentioned above, the following further obligations apply:
- The bank must refuse to accept consent if the account has been closed. In other words, connection to a closed account (accessing information relating to a closed account) is prohibited (clause 51 of NBU Resolution No. 80).
- The bank and the third-party provider are obliged to display to the user lists of active and inactive consents (with details including: date/time of granting/withdrawal, account concerned, scope of data). The bank and the third-party provider must keep records of the granting/withdrawal of consents: date, time, and party identifiers.
- The bank and the third-party provider must ensure the retention of documents and information relating to payment transactions initiated by the payer through a PSP, as well as all user consents to provide account information, for at least five years from the date of termination of the business relationship with the user.
Practical Requirements for the Consent Interface (What Must Be Displayed/Performed in the Bank’s UI)
When obtaining consent, the bank, in its mobile/web interface, must clearly display and offer the user the following:
- the name and identification of the third-party provider;
- the specific account being connected (account number or a partially masked version, e.g., the last digits of the account number);
- the scope of access – what data may be transferred to the third-party provider (e.g., balance, statements for a defined period, etc.);
- the duration of consent (start/end dates), which must not exceed 180 calendar days;
- how consent can be withdrawn (a button in the application, a link in the web interface, or instructions on the required steps);
- the SCA request (e.g., confirmation in the bank’s application, OTP, signature) – SCA must be carried out before final confirmation.
Who Verifies and How Is It Confirmed That Consent Is Valid?
The third-party provider must verify with the bank (via API) the existence and status of consent before each data retrieval or payment initiation. Such checks are intended to reduce the risk of operating with outdated authorisations.
Short Checklist for Banks (Technical and Procedural Steps to Comply with the Consent Procedure under NBU Resolution No. 80)
- Bring the bank’s website into compliance with the requirements of NBU Resolution No. 80, in particular the provisions of Section IV of the Regulation approved by the Resolution.
- Provide an API to receive consent requests and to provide consent status (active/inactive (withdrawn)).
- Develop or update the bank’s internal regulatory documents in accordance with the requirements of NBU Resolution No. 80.
- Ensure that user consent is obtained via the bank’s payment application, or, if such an application cannot be used, through another remote communication channel.
- Implement in the bank’s channel (application/web) an interface displaying all mandatory elements regarding user consent (AISP/PISP, account, scope, duration, withdrawal method).
- Ensure SCA at the stage of consent confirmation.
- Provide in the user agreement the terms and conditions for granting access to the user’s account to a third-party PSP. Specify in the user agreement the responsibilities of the parties when the bank grants access to the user’s account to a third-party provider.
- Record and retain the date and time of granting and withdrawal of consent, and keep request identifiers.
- Immediately terminate access in case of withdrawn consent, and regularly respond to third-party provider requests regarding the status of consent.
In conclusion, banking institutions should pay attention to the new Regulation on open banking and bring their operations into compliance by 1 January 2026.