The EU’s PSD2: API Security and Financial Services

Pierre Coquelle -

In 2015, the European Union adopted the Revised Payment Services Directive (PSD2). This legislative framework aimed to fix the financial services market, which was disrupted by the arrival of new innovative players.

The 2010s gave birth to numerous FinTech startups providing new services in addition to traditional banking institutions. These services range from mobile payment solutions to online financial management, accounting, or crowdfunding platforms. Coined as Third Party Providers (TPP), they are acknowledged in the PSD2 and formally subdivided into Account Information Service Providers (AISP) and Payment Initiation Service Providers (PISP). Meanwhile, banks are described as Account Servicing Payment Service Providers (ASPSP).

To provide their services, TPP and FinTech start-ups had to access the data of ASPSP (traditional banking institutions). Until the adoption of the PSD2, these unregulated information exchanges were jeopardizing the protection of customers’ data. Thus, beyond solid customer authentification, PSD2 aimed at improving data exchanges between banks and FinTech companies.

Screen scraping

Until the PSD2, customers had to provide FinTech companies with their online banking credentials, such as usernames and passwords. FinTechs were then logging in to their customers’ banking accounts on their behalf to access their data. Known as “screen-scraping,” this process has been a matter of deep controversy between banks and FinTech start-ups.

Indeed, banks argued that "screen-scraping" endangered the security of their customers' data. For instance, banks could not:

  • Identify where the FinTech companies were extracting the data, and hence, figure out if they were legitimate users ;
  • Establish if FinTech companies were not extracting additional data that had no link to the financial services they provided.

Furthermore, in case of a data breach, all the banking credentials of TPP’s customers would be accessible to malicious hackers. Pandora’s box would then be opened.

APIs

The European Union PSD2 regulation expressed a general ambition to regulate data exchanges between traditional banks and FinTech newcomers. This broad goal was reinforced by concrete security measures gathered in an additional regulation: the Regulatory Technical Standards for Strong Customer Authentication and Common and Secure Open Standards of Communication (RTS for SCA and CSC).

Article 20 notably states that

“each account servicing payment service provider with payment accounts that are accessible online should offer at least one access interface enabling secure communication with account information service providers, payment initiation service providers and payment service providers issuing card-based payment instruments”

This “access interface” consists of an Application Programming Interface, widely known as an API. It is a technology that enables secure data exchanges and programs to interact.

APIs provide security guarantees lacking in the previous “screen-scraping” model. Indeed, they enable banks :

  • To identify with which TPP they are working ;
  • To share data with FinTech start-ups without requiring these TPPs to use their customers’ banking credentials ;
  • To decide which precise data is allowed to be shared with FinTech start-ups.

Nonetheless, article 24 adds that.

"to ensure that payment service providers who rely on the dedicated interface can continue to provide their services in case of problems of availability or inadequate performance, it is necessary to provide, subject to strict conditions, a fallback mechanism that will allow such providers to use the interface that the account servicing payment service provider maintains for the identification of, and communication with, its own payment service users."

In other words, if the API becomes unavailable, banks must temporarily provide TPP the ability to do screen-scraping. Yet, it's a "new generation" screen-scraping, as TPP now needs to identify themselves to the banks to extract the data.

Outside of the EU

Outside the EU, other states have enacted regulations to foster the use of APIs in financial data-sharing, notably the United Kingdom and Canada, through their Open Banking initiatives.

Data-sharing between banks and FinTech start-ups in the United States also became a concern among market participants and regulators. In May 2019, the Financial Services Committee of the House of Representatives, the lower chamber of the American Congress, established a Task Force on Financial Technology to “examine the current legal framework for fintech, how fintech is used in lending and how consumers engage with fintech.”

On the 21st of September 2021, this Task Force held a hearing on “Preserving the Right of Consumers to Access Personal Financial Data.” The Task Forces underscored that the Consumer Financial Bureau (CFPB), an agency of the United States government, was “currently working on a new regulation to clarify standards around consumer-authorized access to financial data.” Addressing the screen scraping vs. API issue, these new rules are awaited for late 2022 or 2023.

Despite these delays in terms of regulation, American actors started their initiative to adopt APIs to exchange data. For instance, the Financial Data Exchange (FDX) was launched in 2018. It is a non-profit consortium gathering major FinTech companies and traditional banks to create an interoperable API standard for financial services.

API Security

The gradual adoption of APIs, instead of screen scraping, as the process through which data is being exchanged between FinTech companies and traditional banks, is a significant step forward. Nevertheless, APIs do not come secure right off the bat.

As soon as 2019, Gartner, an American technological research and consulting firm, predicted that “by 2022, API abuses will move from an infrequent to the most frequent attack vector, resulting in data breaches for enterprise web applications”.

Like Janus, the Roman god of passages, APIs are two-faced. If they enable data flow, they can become exploits if security is not considered early in their design.

Therefore, we have built, at escape.tech, the first GraphQL API security platform that enables developers to find and detect vulnerabilities in their GraphQL API during the development, staging, and production stages or directly inside their CI/CD pipeline.

Automate the compliance of your GraphQL API

Escape is the GraphQL Security solution that allows you to test your endpoints' performance, reliability, data leaks (personally identifiable information) and security. Especially it allows you to generate automated pentesting reports that m the PSD2 compliance process seamless for your GraphQL API.

Give it a try for free and start complying with PSD2 in 1 minute! 💫

Wanna know more about Security? Check out our blog post "9 GraphQL Security Best Practices" and learn how to build safe GraphQL APIs.