Overview of the RPS: The RPS provides insights into the EC's priorities and its vision for payments in the EU. It seeks to create a more digitalised and innovative payments landscape, introduce new pan-European payment solutions, foster an integrated EU market, and enhance customer protection.
Key focus areas: The second pillar of the strategy focuses on two core objectives: strengthening the open banking concept and ensuring high levels of security for payments. To achieve these goals, the EC planned to review the Second Payment Services Directive (PSD2) and subsequently propose a new legislative framework for "open finance" by mid-2022. This new framework would expand the open banking concept and enable broader access to financial data.
Current progress: As of June 28, 2023, the European Commission has released a draft legislation for the third Payment Services Directive (PSD3) and a new Payment Services Regulation (PSR). In parallel, a draft Regulation on a framework for financial data access (FIDA) was released. These developments build upon the advancements made since the implementation of PSD2, reflecting the Commission's ongoing efforts to improve payment services within the EU.
There are three new requirements:
Indeed, under PSD and PSD2 some further clarification was required to define what encompasses a payment account. First, there was a judgement from the European Court of Justice (C‑191/17) clarifying whether a savings account could be considered a payment account or not, and what criteria should apply. And although this judgement referred to PSD (one) in fact, it came out when PSD2 was in force so its guidance could be taken on board. Also, the European Banking Authority (EBA) provided clarification via two Q&As that were answered later (2018-473 and 2019-4856). The definition as now used in PSD3 takes this guidance on board and now reads that a payment account means an account held by a payment service provider in the name of one or more payment service users which is used for the execution of one or more payment transactions and allows for sending and receiving funds to and from third parties. Or, a payment account is now defined as an account that is used for sending and receiving funds to and from third parties. Any account that possesses those characteristics should be considered a payment account and should be accessed for the provision of payment initiation and account information services. Situations where another intermediary account is needed to execute payment transactions from or to third parties should not fall under the definition of a payment account. Savings accounts are not used for sending and receiving funds to or from a third party, excluding them therefore from the definition of a payment account. This may imply that credit card accounts apply as such too.
Whilst PSD3 and the PSR still recognise the Account Information Services Provider (AISP), the proposed Regulation proposed a new provider, notably the Financial Information Services Provider (FISP). The Commission examined the possibility of transferring the legal framework for AISPs from PSD to the future FIDA framework. And although such a transfer would ultimately make sense, given the nature of AISPs' business, there would be a significant risk of disruption and data access rights interruptions for these market operators if such a transfer were carried out prematurely i.e. before the existence of a “scheme”, which will be a pre-requisite for FIDA to take place. There is currently no such scheme in the market. The creation of a private contractual scheme in the payments sector (the SEPA Payment Account Access Scheme – SPAA) is currently being discussed by market participants, which is however outside the FIDA framework. It is therefore deemed preferable to have a staggered approach and provide for such transfer when the FIDA framework will be up and running and when conditions for a smooth transfer are considered appropriate.
A key challenge with respect to fraud is the fact that mitigating measures are usually only taken after a specific type of fraud occurred. And whilst PSD2 indeed mandated strong customer authentication (SCA), which had a significant impact on reducing fraud, new fraud patterns emerged after SCA had been implemented widely. For example, customers are now being tricked into performing a SCA on a fraudulent transaction via impersonation fraud that can happen for example via social media fraud, where the fraudster claims to be a friend or relative, or via calls or messages from spoofed phone numbers, claiming to be the bank, the government or another organisation. The Commission is proposing to introduce a mandatory check to verify whether the IBAN of the beneficiary matches the name of the beneficiary. This confirmation of payee mechanism is already part of the proposed instant payments regulation, and the Commission is now proposing to extend its usage to all credit transfers.
Another improvement is the fact that there now is a legal basis for payment service providers to share fraud-related data between themselves, in full respect of the privacy regulation (GDPR).
Often one payment service provider does not have the full picture of all elements that could lead to timely fraud detection. However, it can be made more effective with a greater amount of information on potentially fraudulent activity stemming from other payment service providers. Therefore, sharing of all relevant information between payment service providers should be possible. To better detect fraudulent payment transactions and protect their customers, payment services providers should, for the purpose of transaction monitoring, make use of payment fraud data shared by other payment services providers on a multilateral basis such as dedicated IT platforms based on information sharing arrangements.
So far so good, but what could raise concerns is the fact that victims of fraud have quite a few rights in the proposed texts; or rather, to put it into the right context, quite a substantial burden and liabilities are being placed onto payment service providers.
For example, where a payment service user denies having authorised an executed payment transaction or claims that the payment transaction was not correctly executed, the burden shall be on the payment service provider to prove that the payment transaction was authorised, accurately recorded, entered in the accounts and not affected by a technical breakdown or some other deficiency of the service provided by the payment service provider.
But there are also scenarios where payment service providers cannot be aware of what happened at all. For example, in the case of spoofing, the proposed text states that where a consumer was manipulated by a third party pretending to be an employee of the consumer’s payment service provider using the name or e-mail address or telephone number of that payment service provider unlawfully and that manipulation gave rise to subsequent fraudulent authorised payment transactions, the payment service provider shall refund the consumer the full amount of the fraudulent authorised payment transaction under the condition that the consumer has, without any delay, reported the fraud to the police and notified its payment service provider. In such a scenario, the payment service provider is possibly not even aware these references are being used; nevertheless, they are on the hook, and the burden is upon the payment services provider to provide a justification for refusing the refund based on reasonable grounds of suspected fraud or gross negligence by the consumer.
We are still in the process of analysing the legal proposals on the topic of fraud and liabilities. Whilst consumer protection is important to keep the trust in payments, we have to be careful not to create an environment where consumers become less vigilant towards possible fraud, as they will be refunded regardless. In our view, consumers should have some skin in this game too.
To that end, it is key to make consumers aware of the risks – something that will require joint efforts. Maybe also worth mentioning whilst on the topic of fraud that in their June 2023 meeting the Euro Retail Payments Board (ERPB) supported launching a workstream on emerging fraud related to retail payments. The outcome of this work would provide the market perspective on fraud that could be channelled to relevant authorities to inform their work – this is expected to start after the summer.
No, this will not be the case. Nevertheless, banks are required to use standards of communication which are issued by European or international standardisation organisations including the European Committee for Standardization (CEN) or the International Organization for Standardization (ISO). But this refers to the communication level – in terms of the content, or at a technical level, there is freedom for banks, but they shall ensure that the technical specifications of any of the APIs are documented specifying a set of routines, protocols and tools needed by third-party providers for allowing their software and applications to interoperate with the systems of the bank. The latter shall make the documentation on technical specifications of their dedicated interfaces available and shall make a summary of that documentation publicly available on their website.
In fact, the considered option to impose a single, harmonised, API standard for TPP access to account data has been rejected by the Commission, despite high potential effectiveness, due to excessively high implementation cost for banks and limited coherence.
Looking at the timing of these changes and the requirements imposed on banks under PDR3 and PSR, we also observe that the transition towards real-time payments across all channels and customer segments has only recently begun. This transition requires substantial innovative developments within banks to ensure that the advantages of real-time payments are accessible to all customers. Will all these demands be overwhelming for banks? Furthermore, what incentives will be provided to encourage banks to persist in developing their services, providing dedicated interfaces (APIs), and embracing new technologies to keep up with all the regulatory changes and requirements?
We still need to assess the specific requirements here in detail, but yet again, it seems significant changes are required that need the banks involvement – permission dashboards are required both under the PSR and FIDA, and schemes need to be created and adhered to under the FIDA, just to name a view aspects.
In fact, the provisions on open banking, as it is being called in the PSR, contain a number of modifications compared with PSD2, and incorporate certain provisions currently contained in the notorious regulatory technical standards for strong customer authentication and common and secure open standards of communication. Key changes include the imposition, except in exceptional circumstances, of having a dedicated interface (or API) for open banking data access and the removal, except in authorised exceptional circumstances, of the requirement on banks to maintain permanently a ‘fallback’ interface. Additional requirements on APIs are introduced as regards performance and functionalities.
TPPs should as a general rule use the API for their access and therefore should not use the customer interface of a bank for the purpose of data access, except in cases of failure or unavailability of the API under specific conditions as mentioned in the PSR. In such cases they should be allowed to request their national competent authority to make use of the interface provided to its users by the bank until the dedicated interface is again available. The competent authority should, upon receiving the request, take its decision without delay. Pending the decision from the authority the requesting TPPs should be allowed to temporarily use the interface provided to its users by the bank. The relevant competent authority should set a deadline to the bank to restore the full functioning of the API, with the possibility of sanctions in case of failure to do so by the deadline. All TPPs, not just those which introduced the request, should be allowed to access the data they need to ensure their business continuity.
Such temporary direct access should have no negative effect on consumers. TPPs should therefore always duly identify themselves and respect all their obligations, such as the limits of the permission which was granted to them, and should in particular access only the data that they need to meet their contractual obligations and provide the regulated service. Access to payments account data without proper identification (so-called ‘screen-scraping’) should, in any circumstances, never be performed. Banks that believe it is disproportionate for the to develop an API can ask their national competent authority for an exemption from having to provide an API, effectively offering access via their customer interface. Detailed criteria for granting such different types of exemption decisions should be laid down in regulatory technical standards developed by the EBA.
So, in summary, under the proposed regulation, the fallback is now being safeguarded via accessing the customer interface under specific conditions.
Both the Council and the European Parliament will start looking at these files. The Council had already a first meeting on these files on 12 July 2023, whilst in the Parliament first the responsible Committee and a Rapporteur need to be assigned – a process that takes some time. Given the fact that there will be elections for the Parliament in the course of next year, it is very likely that the Parliament will reach their position before that, so it would not surprise me if a final text can be agreed between parties only somewhere in 2025 – and the text may have been changed as a result of the trilogue negotiations. To note that we have a Regulation and a Directive – once adopted, the Regulation will be effective immediately upon publication (as per the timelines mentioned in there), whilst the Directive needs to be transposed into national legislation – currently 18 months are foreseen for that. So, it will take some time before we see both pieces of legislation implemented in full.
Diederik Bruggink is Head of Payments, Digital Finance and Innovation at WSBI-ESBG. He holds responsibility at the two savings and retail banking associations for all payments and digital finance topics from a worldwide perspective. Leading a team at WSBI-ESBG, he analyses the multiple dimensions of the payments and digital finance market, proposing and assisting in agreeing member positions with respect to their payments’ and related businesses. He also advocates the associations’ positions on payments with policymakers, regulators, standardisation bodies, industry associations, and is enabling a constant member dialogue on developments, with a particular focus on innovation.
ESBG is an association that represents the locally focused European banking sector, helping savings and retail banks in European countries strengthen their unique approach that focuses on providing service to local communities and boosting SMEs. ESBG members have total assets of EUR 6,38 trillion, provide 313 billion euros in loans to SMEs and serve 163 million Europeans seeking retail banking services. ESBG unites at EU level some 871 savings and retails banks, which together employ 610.000 people driven to innovate at more than 41.000 branches. Its sister association WSBI, founded in 1924, brings together and represents savings and retail banks from around the world. Its aim is to achieve sustainable, inclusive, and balanced growth and job creation. Supporting a diversified range of financial services to meet customer needs, WSBI favors an inclusive form of globalisation that is just and fair. It supports international efforts to advance financial access and financial usage for everyone, therefore- fosters the exchange of experience and best practices among its members and supports their advancement as sound, well-governed, and inclusive financial institutions.
Every day we send out a free e-mail with the most important headlines of the last 24 hours.
Subscribe now