Fintech lobbyists have shared a variety of views with the European Commission regarding its payments package, pushing for legislators to make changes in areas such as enforcement and contingency.
Fintech trade associations including the Open Finance Association (OFA), the European Third Party Providers Association (ETPPA) and the European Digital Finance Association (EDFA) have submitted feedback to the European Commission regarding the Payment Services Regulation (PSR).
The PSR was alongside the latest Payment Services Directive (PSD3) and other legislative proposals such as the Single Currency Package (which lays the groundwork for a possible digital euro), and shores up as well as building on rules implemented through PSD2.
In many ways, the fintech groups have been pleased with what the EU has now proposed.
They hold the potential to further empower consumers and businesses by enabling them to use more of their financial data and account functions via regulated third parties, the OFA stated in its response.
Meanwhile, the ETPPA commented that it is pleased to see the commissions vision to reaffirm open banking in Europe.
"This is a step forward from the PSD2 in several ways, commented Ralf Ohlhausen, chair of the ETPPA. Moving to regulation is a good thing, as there is now more in the hands of the commission and in Level 1 text. So, the move to the PSR is very, very welcome.
Ohlhausen told 蹤獲鱉鱉 that there are a number of areas that are positive, such as the removal of obstacles and the enforcement requirements for the national competent authorities, and with strong customer authentication.
For example, it clarifies that the two factors must not come from two different categories as long as they are independent, he commented. It has cost the industry a fortune that the current interpretation was different."
Solving the API problem
Application programming interfaces (APIs) have long been a problem for the fintech industry, with sentiment being that account servicing payment service providers (ASPSPs) banks have created obstacles to prevent a frictionless experience.
This ultimately comes back on the third-party provider (TPP), whether an account information service provider (AISP) or a payment initiation service provider (PISP).
The PSR has attempted to iron this out, explicitly listing a set of obstacles that are standing in the way of a frictionless process.
However, the EDFA this does not capture the full scope of potential obstacles. TPPs frequently encounter issues when integrating with bank APIs that are not adequately addressed.
Some of these prevalent challenges include inconsistencies between sandbox testing environments and real-world APIs, demanding production-level eIDAS certification even for sandbox access, as well as the absence of clear service level agreements both for technical support during integration and for the API's overall performance and reliability.
"We are moving backward on some things, such as prescribing technology even more than less, said Ohlhausen. This has been very costly and unhelpful already and the proposed PSR is making that worse by focusing solely on dedicated TPP-interfaces, which makes it even easier for ASPSPs to play bad."
From a TPP perspective, Ohlhausen said that what counts is the functionality of the API and the data it provides, while banks always preferred just looking at technical availability.
To encompass both, PSD2 used the term "performance".
However, the PSR is focusing on "availability" only, Ohlhausen said. That is not enough.
What we need is an API that works well, hence limiting contingency to non-availability is unacceptable.
In the ETPPA response, the trade association said that neither AISPs nor PISPs can put their business continuity into the hands of ASPSPs and must be allowed to use their customer interfaces whenever needed.
We need, like every tech business, contingency at all times, said Ohlhausen. I have never understood why supervisors who would never let a bank get away without full contingency would stipulate the opposite for TPPs by exempting APIs and thereby removing fallback options.
As with other associations, the ETPPA warned that this could lead to discrepancies with other EU regulation. How should TPPs comply with DORA in this case?"
The ETPPA has argued that AISPs and PISPs could end up being forced to rely on the performance and availability of a single dedicated interface provided by ASPSPs, while also required to invest for resilience purposes into the rest of their infrastructure, and when the same ASPSPs provide flawless performance to their customers via separate channels.
"The concept of a dedicated interface is one of the core problems. Giving any interface a monopoly status opens the door very wide for abuse, Ohlhausen said. This is why banks can offer good APIs to their customers and not so good ones to TPPs."
In the PSR, Ohlhausen acknowledged that the European Commission is trying to put its foot down against such abuse.
But, we cannot wait for and cannot rely on everything being policed 100 percent, he said. This will never happen and 99 percent would already not be good enough.
Enforcement cannot be the solution. We have to have contingency unconditionally and it is important to note that this does not require banks to build and maintain any additional fallback-interface, but simply not to block a TPPs fallback to their existing customer APIs, which they run anyway."
Enforcement is a topic also highlighted by the OFA. The trade association recommended that EU regulators should create a specific agency overseeing open banking and open finance.
In the longer term, we believe that the right solution will be creating an EU Authority tasked with supervising the implementation of open banking and open finance rules, the trade association says.
The OFA added that the effectiveness of the open banking provisions will in part depend on enforcement and supervision.
Closely related to this, cross-border obstacles amounting to IBAN discrimination remain widespread, the trade association said. Their removal depends on national competent authorities interpreting and enforcing rules consistently and effectively.
Opening data access
One topic that has sparked disagreement between the fintechs and the banks is the funding model.
PSD3 and the PSR have not stepped away from the principle of free access for TPPs, even if the EUs open finance legislation does.
This has sparked backlash from some banking associations, due to costs of development and maintenance.
The OFA, however, says that attempting to make changes here risks hindering the progress of the files becoming legislation.
Devoting time and energy to this topic detracts from how to ensure that consumers and merchants have access to new and innovative data and payment services, said Nilixa Devlukia, chair of the OFA.
She told 蹤獲鱉鱉 that the OFA believes that maintaining free access for the baseline under the PSR allows the correct balance to progress the commercial discussions for premium APIs via schemes such as the SEPA Payment Account Access scheme.
Banking groups looking to unravel the free access model under PSD2 are ignoring the very clear rationale of the EU Commission on why the current position is maintained under the PSR, warned Devlukia.
Devlukia, who has experience working at EU and UK regulators, warned that introducing changes to the market would have serious practical implications and cripple the open banking market with ASPSPs and TPPs having to negotiate thousands of bilateral contracts.
It would negatively impact TPPs' ongoing service delivery to consumers and merchants and in many cases would mean a stop to the provision of services altogether. There is no guarantee that revenue generated from charging would be used to upgrade APIs, she said.
For example, as pointed out in the OFAs , the EUs impact assessment said that costs incurred by the banks to create these APIs came to 2.2bn.
This is not an exceptionally high cost if divided across the number of EU banks providing payment accounts or if measured against the overall banking sector profit since PSD2 entered into force, the OFA argued.