Open banking in Ukraine: AIS/PIS providers and their regulatory status

On 1 August 2025, Ukraine’s open banking legal framework became operational with the entry into force of the open banking provisions of the Law of Ukraine “On Payment Services” (the “Payment Services Law”), together with the Regulation on the Open Banking and other bylaws, adopted by the National Bank of Ukraine (“NBU”). These acts complete the transition to a new model of access to payment accounts and data sharing in the Ukrainian payment services market.

In line with the Open Banking Concept approved by the NBU in 2023, open banking is designed as a structured and secure exchange of data between account-servicing payment service providers and authorised third parties through standardised open application programming interfaces (APIs). In simple terms, open banking creates an ecosystem in which, subject to the customer’s explicit consent, payment service providers may grant licensed third parties access to the customer’s financial data and, in some cases, the ability to initiate payment transactions. This model is largely based on the one established in the EU by the Second Payment Services Directive 2015/2366 (“PSD2”) and is transposed into national law as part of Ukraine’s EU integration.

Two core functionalities required for this model, namely account information services (“AIS”) and payment initiation services (“PIS”), are introduced by the Payment Services Law and further detailed in the bylaws adopted by the NBU. Under the Payment Services Law, AIS and PIS are classified as “non-financial payment services”, which may be provided by banks, payment institutions, e-money institutions and other authorised entities. The following sections focus on the principal regulatory provisions applicable to AIS and PIS providers and on certain practical issues arising in the course of their implementation in Ukraine.

The scope of AIS and PIS

The Payment Services Law provides AIS and PIS as standalone types of non-financial payment services and defines them in functional terms:

• AIS as a service for real-time provision of consolidated information on one or more payment accounts held by a payment service user with one or more account-servicing payment service providers (“ASPSPs”).
• PIS as a service that initiates a payment order at the user’s request with respect to a payment account held with another provider (i.e., ASPSP).

AIS may cover various categories of account data: identification details of the account (such as IBAN, account type and currency), account balance, historical transaction data for a certain period, payee and payer details, as well as information on payment instruments linked to the account. The principal advantage of AIS is that it enables customers to view and manage their financial position in different banks and payment institutions through a single interface (for example, using personal finance management applications). At the same time, AIS’s role is limited to accessing and processing information within the scope of the consent granted.

PIS constitutes a different but complementary function in the open banking ecosystem. It enables customers to initiate payments directly from their bank accounts, without using payment cards, via a PIS provider’s interface or application. For instance, such an interface can be embedded at an online merchant’s checkout page, through which the customer can authorise a credit transfer directly from his/her bank account. The payment order is then communicated by PIS provider to the customer’s bank (ASPSP) via standardised APIs and the funds move directly from the customer’s account to the merchant’s account.

Unlike traditional internet acquiring or payment services based on collection accounts, the PIS provider does not intermediate the funds flow on its own accounts and therefore does not assume the role of a payee or intermediary holder of funds. Thus, a PIS provider merely triggers payment from the payer’s account held with another provider without receiving funds into its own account.

Authorisation process and requirements

The Regulation on the Procedure for Authorising the Activities of Non-financial Payment Service Providers, approved by NBU Board Resolution no. 81 dated 25 July 2025 establishes three authorisation options for providers of non-financial payment services, depending on the applicant’s regulatory status. Specifically, authorisation may be sought by: (i) legal entities that are not yet payment service providers (“PSPs”), (ii) payment institutions, e-money institutions, branches of foreign payment institutions, and (iii) banks. For each category, there is a different authorisation package and a set of ongoing requirements. An applicant must apply to the NBU for authorisation as a provider of non-financial payment services and, upon successful completion of the procedure, is entered into the Register of Payment Infrastructure maintained by the NBU (the “Register”). The term of authorisation is not time-limited and remains in force until it is revoked or the provider is removed from the Register.

While banks and existing PSPs benefit from a significantly lighter authorisation package, new entrants (i.e., applicants that are neither banks nor PSPs) are subject to the most extensive authorisation requirements. In addition to standard corporate documents, ownership structure disclosures and IFRS-based financial statements accompanied by an auditor’s review report, such applicants must comply with a range of more specific authorisation requirements, the most material of which are outlined below.

Business plan

It must be drawn up for at least the current year and for the next three years and set out a detailed description of the applicant’s business model, the target customer segments and delivery channels. The plan should include financial forecasts (covering revenues, operating expenses, funding sources and capital adequacy) under both baseline and adverse scenarios, as well as indicate major cost items (in particular IT infrastructure, staff and any outsourced technological functions). There should also be an explanation of how the applicant will achieve sustainable operations and cover potential losses in the initial phase.

Reputation assessment

The authorisation package must include a full set of documents enabling the NBU to assess the business reputation of qualifying shareholders, key participants, managers and “key persons”. The applicant must submit their identification documents, standard NBU questionnaires (for individuals and legal entities), certificates on criminal record and tax debt status and credit reports from qualified credit bureaus. In addition, for managers and key persons, the package must be supplemented by documents confirming their roles and responsibilities, work experience and education compliant with the NBU requirements.

IT and information security

At the application stage, the applicant must have at least a defined IT architecture supporting AIS/PIS (core systems, interfaces, APIs) and a designed framework of information security, cyber-resilience and business continuity measures (such as access-control concepts, logging and monitoring, backup and recovery arrangements). These items must be sufficiently detailed in the applicant’s information note and the business plan.

Although certain internal policies and procedures may be formally adopted within three months after authorisation but before the first non-financial payment service is provided, the applicant’s draft documentation and model must already be consistent in substance with the Regulation on Requirements for the Risk Management System of Non-financial Payment Service Providers, approved by NBU Board Resolution no. 73 dated 2 July 2025. In addition, as a payment-market participant, the AIS/PIS provider is required, by the time it commences AIS/PIS operations, to implement the information security measures set forth by the Regulation on Information Protection and Cyber Security by Payment Market Participants, approved by NBU Board Resolution no.43 dated 19 May 2021. These include, inter alia, an information security policy, access and network security controls, the use of secure cryptographic tools for data exchange with ASPSPs and processes for monitoring and responding to security and cyber incidents.

Professional liability insurance

Non-bank applicants must hold professional liability insurance (effective from the date of registration in the Register) covering users and ASPSP losses arising from: (i) wrongly executed or unauthorised payment initiation and/or (ii) unlawful access to or misuse of, the customer’s account data. The insurance must meet the requirements set forth by the Regulation on the Procedure for Liability Insurance of Providers of Non-financial Payment Service to Users and Account-servicing Payment Service Providers, approved by NBU Board Resolution no. 71 dated 2 July 2025. This regulation sets out detailed requirements applicable to the insurance policy, including gradually increasing minimum insured amounts during the transitional period until 1 January 2027, after which the minimum insured amount is to be calculated individually for each provider, limitations on deductibles up to 2027 and an extended claims-reporting period of at least six months after policy expiry.

Given that AIS and PIS are new to the Ukrainian market and there is little or no claims history for such services, insurance premiums may be expected to be relatively high, particularly for new entrants and smaller fintech firms.

Authorised capital

On the date of submission of the authorisation package, the applicant’s authorised capital must be fully paid up in an amount not less than the minimum thresholds set forth by the Payment Services Law (except for banks). For entities applying for authorisation to provide PIS, the minimum threshold is UAH 1,000,000. If an applicant also intends to provide other payment services, its capital will be subject to a higher minimum threshold depending on the scope of its services.

No statutory minimum capital is provided for applicants that intend to limit their activities to AIS only. However, even in the absence of a statutory threshold, AIS providers are still expected to maintain capital and own funds that are adequate in light of the scale and risk profile of their business.

Qualified open banking certificate

Following registration into the Register (or the Register of Banks in case of banks) and prior to connection to ASPSP’s APIs, an AIS/PIS provider is required to obtain a qualified open banking certificate, which is either a qualified website authentication certificate or a qualified electronic seal certificate containing specific open banking attributes as specified in the Regulation on the Procedure for Using Electronic Trust Services when Payment Service Providers Obtain Access to Users’ Accounts, approved by NBU Board Resolution no. 82 dated 25 July 2025. In essence, this certificate allows ASPSP to identify and authenticate a third-party provider as an AIS/PIS provider and enables AIS/PIS providers to technically connect to ASPSPs’ specialised interfaces (APIs) and start real-time data exchange. 

A qualified open banking certificate may be issued by: (i) a qualified provider of electronic trust services (“QPETS”) included in the trusted list, provided that such provider supports open banking certificates or (ii) the QPETS “Accredited Key Certification Centre of the NBU”. Although some major bank-affiliated QPETS (for example, those of larger retail banks) generally provide qualified website authentication and qualified e-seal certificates, public information on whether they currently offer an open banking-specific certificate remains limited. Based on the publicly available trusted list, the NBU operates a dedicated certification authority “for OpenBanking”, authorised to issue qualified certificates both for electronic seals and for website authentication. Accordingly, at this stage, the NBU’s QPETS appears to be the main designated issuer of qualified open banking certificates in Ukraine.

Internal rules

Within three months following entry into the Register and before rendering the first non-financial payment service, the provider must develop and adopt the internal documentation package which must include: (1) rules for provision of non-financial payment services, (2) documents governing interaction with AIS/PIS users and ASPSP and procedure for handling requests from such parties, and (3) information security policy and other internal documents on information protection and risk management (as outlined above in “IT and information security”). The internal rules must contain all provisions required by the NBU regulations and must not contradict the conditions and procedures for the provision of non-financial payment services as previously agreed with the NBU in the information note.

Interactions with ASPSPs (banks and other account-servicing PSPs)

The legal status of AIS/PIS providers cannot be fully understood without considering their relationship with the ASPSPs, primarily banks and the key role and obligations of ASPSPs in the context of open banking. The Payment Services Law, further specified by NBU regulations, requires the ASPSPs to support open banking access to user’s payment accounts through specialised interfaces (APIs). The regulations distinguish between two types of such interfaces:

• basic specialised interfaces, to which ASPSPs must ensure real-time and free-of-charge access for duly authorised AIS/PIS providers within five months from 1 August 2025. Basic interfaces cover the exchange of limited set of data required to execute a one-off payment transaction, as well as information on the user’s account balance and account transaction history for a period of up to 31 calendar days prior to the request; and
• commercial specialised interfaces, which may cover a broader range of data or additional functionality as determined by the ASPSP itself and may be offered under a fee-based agreement with the AIS/PIS provider.

Access to a user’s account information is subject to mandatory preconditions with which ASPSPs must comply. Before granting access to a user’s account and for each subsequent request to access the user’s account data, the ASPSP must, on the basis of up-to-date data from the Register and the provider’s qualified open banking certificate, verify that the third party is duly authorised to provide the relevant non-financial payment service. Subject to successful verification and provided that the ASPSP has obtained the user’s consent and a separate permission to disclose information containing banking, commercial or payment-service secrecy, the ASPSP may then grant AIS/PIS providers access to its customer’s account data.

Pursuant to the Payment Services Law and the NBU regulations on open banking, the customer’s consent is the key factor enabling banks and AIS/PIS providers to securely exchange data through APIs. It is the ASPSP that must obtain and/or verify the user’s “active consent” for data access or payment initiation using strong customer authentication (enhanced authentication) in line with the Regulation on Authentication and Enhance Authentication on the Payment Market, approved by NBU Board Resolution no. 58 dated 3 May 2023. The ASPSP must obtain the payer’s consent each time the latter initiates a one-off payment transaction through a PIS provider. As for the consent to the access to account information, it must be provided to the ASPSP upon the user’s first request for account information, submitted through the AIS provider which is receiving access to the account. Such consent may not be given for a period longer than 180 calendar days. 

To make the process transparent and clear for users, when receiving a user’s consent to access account information, the ASPSP must display in its remote banking application: (1) information on the AIS provider that is receiving the access; (2) the number of the relevant user’s account; (3) scope of information to which the AIS provider will have access; (4) the term of validity of the user’s consent and (5) the conditions for revoking the user’s consent or a reference to the document specifying such conditions.

In general, the user’s contractual relationship for the account remains with the ASPSP; the account agreement must provide the terms of access for third-party providers and the allocation of responsibilities. As for the AIS/PIS provider, it must reflect in its customer agreement how the user’s consent to payment initiation or information access is to be given and must clearly set out its own and the user’s liability in that relationship.

The ASPSP remains liable to the user for (i) damage caused by its failure to comply with the open-banking rules, (ii) non-execution or incorrect execution of payment transactions initiated by the user via a PIS provider, unless it can prove correct execution on its side and (iii) disclosure of secret information without the customer’s permission. AIS/PIS providers are liable to both users and ASPSPs for losses caused by their own failures, including unauthorised or incorrect initiation of payments and unlawful access to or misuse of, account data. Non-bank AIS/PIS providers must, in addition, maintain professional liability insurance covering such risks.

Both ASPSPs and AIS/PIS providers are allowed to engage a technology operator which may perform operational, informational and other technological functions in the open banking interaction between the ASPSP and AIS/PIS provider. Such technology operator must itself be duly registered in the Register as a technology operator and must have obtained the right to provide services within open banking framework. Even where a technology operator is involved, both the ASPSP and the AIS/PIS provider remain fully responsible under the Payment Services Law and NBU regulations for the operator’s compliance with the agreed contractual terms and for any breaches in the interaction process.

Current process of the AIS/PIS implementation

Although the regulatory framework for open banking in Ukraine is now formally in place, the technical readiness of market participants remains uneven and the banking sector as a whole is still in a transitional phase. Larger ASPSPs (primarily banks), many of which had already developed APIs and integration solutions before the formal launch of open banking, appear to be better positioned to comply with the new standards and timelines. Under the NBU regulation on open banking, ASPSPs must bring their operations into line with the new requirements (in particular, by ensuring basic API access and publishing technical documentation) within five months from 1 August 2025. During a further 12-month transition period from that date, the NBU will not apply enforcement measures to ASPSPs for the failure to ensure uninterrupted access to their customers’ accounts or to fully configure specialised interfaces. 

On the AIS/PIS providers’ side, as of late 2025, there is no publicly available information on specific authorised AIS/PIS providers or technology operators already operating within the open banking framework. Market players report that several top Ukrainian banks are planning to submit or have already submitted, authorisation packages to get AIS/PIS provider status. There are no public reports about the new entrants – fintech companies which were expected to fill non-financial payment services niche. As outlined above, their authorisation package and ongoing compliance obligations including governance, IT, security, liability insurance and reporting requirements are demanding. In addition, until recently, apparently, no insurers were offering required insurance coverage. Therefore, it is expected that the first entrants will predominantly be the existing payment institutions (most likely banks) that decide to extend their service offering to include AIS and/or PIS, as well as to secure their own clientele.

Against this background and taking into account the time needed for banks to fully set up their APIs and for AIS/PIS providers and technology operators to obtain authorisation and integrate, it is realistic to expect that Ukraine’s open banking model will become fully operational only gradually. Drawing on the EU’s PSD2 model, where it took several years from the formal application of the rules to the deployment of a fully operational open-banking ecosystem, Ukraine is likely to need at least a comparable and possibly even longer period to achieve a similar level of implementation.