Open banking and open finance: outlook for ASPSPs and data holders

September 2023 | SPOTLIGHT | BANKING & FINANCE

Financier Worldwide Magazine

September 2023 Issue

On 28 June 2023, the European Commission (EC) published a package of proposed legislative reforms to the European Union’s (EU’s) core payments laws, which, if enacted, will see the Second Payment Services Directive (PSD2) repealed and replaced with a third Payment Services Directive (PSD3) and the introduction of a new Payment Services Regulation (PSR1).

Certain proposals for PSD3 and PSR1 intend to address shortcomings of the open banking provisions of the current PSD2 framework – provisions which, since PSD2’s implementation, have helped open up access to account data held by banks and other providers of payment accounts (known collectively as account services payment service providers (ASPSPs)) for third party FinTech providers accessing that data on the customer’s behalf.

In addition to PSD3 and PSR1, the EC simultaneously published a draft regulation establishing a framework for financial data access (FIDA), which intends to lay the foundation for access to financial data beyond data relating to payment accounts, giving financial services customers a similar right to grant third party ‘data users’ access to most other types of (non-payment account) financial data held by financial institutions as ‘data holders’.

This article will explore the direction of travel of EU data access requirements as they relate to financial services firms acting as ASPSPs and ‘data holders’ under the PSD3 and PSR1 proposals and the FIDA framework.

Open banking for ASPSPs

PSD2 introduced requirements for ASPSPs to allow access to customer data by account information service providers (AISPs) and payment initiation service providers (PISPs) with the consent of the underlying customer. These requirements were introduced in accordance with the EC’s stated objectives to improve the level playing field between incumbent firms in the payments sector and emerging FinTechs (such as new AISPs and PISPs) and to foster innovation in the payments sector.

PSD2 open banking requirements provided a regulatory framework for the innovation of new customer data-based services, but also introduced some challenges for the ASPSPs that provide the payment accounts to which that data relates.

Under current EU rules, ASPSPs are required to have in place an access interface that is able to facilitate secure access requests by AISPs and PISPs to carry out their services. When receiving requests from AISPs, this means allowing the AISP to request and receive information concerning a customer’s payment account. For PISP requests, the ASPSP must allow the PISP to initiate a payment order from the customer’s payment account and receive all relevant information on the initiation of the payment transaction.

The ASPSP’s access interface can either be a ‘dedicated interface’ (i.e., application programming interface (API)-based), or the ASPSP may modify its existing customer-facing interface. In the case of the former, the ASPSP must also provide a contingency mechanism that enables access via a modified version of the customer-facing interface. Should the dedicated interface become unavailable due to an unplanned outage or breakdown, the ASPSP must inform requesting entities of measures being taken to restore access and the options available in the meantime. The ASPSP also has obligations to report instances of unplanned unavailability to their national regulator without delay.

ASPSPs also have to balance their open banking access obligations with strong customer authentication (SCA) requirements aimed at minimising the risk to customers of fraudulent access to payment accounts and fraudulent payment transactions. As of 25 July 2023, an ASPSP is required to apply SCA when the customer uses an AISP to access certain basic payment account data (i.e., the balance and 90-day payment transaction history) for the first time and on a periodic basis every 180 days thereafter.

For access to other account data, the ASPSP is required to reapply SCA. The ASPSP may also reapply SCA where it has objectively justified and duly evidenced reasons relating to unauthorised or fraudulent access to the payment account. These SCA rules have been introduced to ensure that ASPSPs do not unduly apply SCA as a means of disrupting AISP services and customers’ open banking journey.

Open banking under PSD3 and PSR1

The EC has been keen to underline that it is not proposing radical changes that may destabilise the market and create additional implementation costs. Hence, the EC’s proposals make only targeted amendments.

Notably, PSR1 would mandate that, save for exceptional circumstances, ASPSPs must make available at least one dedicated interface, rather than giving ASPSPs the option of having a dedicated interface or modified customer interface.

Although the EC did not go as far as introducing a single EU API standard for open banking, as previously recommended by the European Banking Authority, the proposals in PSR1 require dedicated interfaces to use standards of communications issued by European or international standardisation organisations and to offer certain minimum functionality.

ASPSPs will no longer be expressly required to maintain a contingency mechanism if their dedicated interface fails, but under new and enhanced requirements they will be expected to offer an ‘effective alternative solution’ to AISPs and PISPs without delay, and failing that, AISPs and PISPs may ask the national regulator to intervene to allow access via the ASPSP’s customer interface. ASPSPs will also be required to publish quarterly statistics on the availablity and performance of their dedicated interface.

To ease friction in the customer’s open banking user journey, ASPSPs must not create certain ‘prohibited obstacles’ in respect of services provided by AISPs and PISPs. Examples of such prohibited obstacles include where the ASPSP requires the customer to manually input their unique customer identifier in the domain of the ASPSP in order to use the services of an AISP or PISP, or where the ASPSP requires authentication that redirects or ‘decouples’ the customer journey in a way that adds unnecessary authentication steps for a customer using AISP or PISP services.

Other reforms include the requirements for ASPSPs to provide customers with data access ‘dashboards’ that allow them to monitor and manage the permissions that the customer has given to AISPs and PISPs in respect of access to their payment account data, covering multiple or recurrent payments.

The definition of ‘payment account’ has also been included in PSR1 to mean customer accounts used for the execution of payment transactions which allow for sending and receiving funds to and from third parties. The inclusion of the revised definition in the PSR1 (a regulation) is intended to address concerns that the scope of payment account-related aspects of PSD2 is not harmonised throughout member states.

The EC has also proposed further changes to SCA requirements for access to payment account data via an AISP. Instead of the 180-day reauthentication requirement applicable to the ASPSP, the PSR1 will require the ASPSP to apply SCA upon the first instance of access to payment account data via an AISP, and thereafter the obligation will be on the AISP to undertake SCA on the customer on a periodic basis every 180 days. At present, the ASPSP will retain the right to reapply SCA should it have reasonable grounds to suspect fraud.

Open finance for ‘data holders’

The scope of data covered by FIDA is broad and includes customer data related to mortgages, loans, savings, investments, insurance-based investment products, cryptoassets, real estate assets, pensions, non-life insurance products and customer creditworthiness assessments. Payment account data will not be in scope of FIDA since the open-banking related aspects of payment accounts will continue to be dealt with under PSD3 and PSR1.

Certain obligations will apply to financial institutions as ‘data holders’ and other obligations will apply to financial institutions as ‘data users’. An FI may be both a data holder and a data user. A data holder is broadly defined as a financial institution that collects, stores and otherwise processes the types of customer data in scope of FIDA, and a data user is broadly defined as a financial institution that has lawful access to that data with the permission of the customer.

Where a data user makes a request to a data holder for access to customer data, with the permission of the customer, the data holder must make that customer data available to the data user without undue delay, continuously and in real-time.

A key difference between data holders under FIDA and ASPSPs under the EU’s payment framework is that, unlike ASPSPs, data holders may ask for reasonable compensation for providing data users with access to customer data under FIDA. The EC is keen to make clear that the compensation is not a payment for the data itself, but rather reflective of the costs associated with maintaining and making the data available to data users. Compensation payable by any data user that is an EU micro, small or medium enterprise should also be limited to costs directly attributable to the data user’s request. These compensation proposals align with compensation requirements applicable to the broader EU data sharing framework set out in the EU Data Act.

Customers, on the other hand, have a right to their data from data holders free of charge.

Much like ASPSPs under the payment services framework, data holders under FIDA are also required to provide customers with a dashboard to monitor and manage the permissions that the customer has granted to data users.

The FIDA framework does not yet specify prescriptive data sharing rules in the same way that PSD2 and the proposed amendments under PSD3 and PSR1 do in respect of payment account data.

FIDA requires that, within 18 months of the regulation coming into effect, in-scope data holders and data users must join a ‘financial data sharing scheme’, whose aim is to develop data and interface standards, coordination mechanisms for the operation of customer dashboards and the framework governing access to certain data, relevant governance rules, transparency requirements, compensation rules, liability and dispute resolution mechanisms. Further similarities and divergences between open banking and open finance requirements may therefore become clear as the standard-setting process under FIDA takes its course.

Ferdisha Snagg is a counsel and George Bumpus is an associate at Cleary Gottlieb Steen & Hamilton LLP. Ms Snagg can be contacted on +44 (0)20 7614 2251 or by email: fsnagg@cgsh.com. Mr Bumpus can be contacted on +44 (0)20 7614 2235 or by email: gbumpus@cgsh.com.

Ferdisha Snagg and George Bumpus

Cleary Gottlieb Steen & Hamilton