Standardising PSD2 API: a key for unlocking the PSD2 Trilemma?

The challenges of PSD2

PSD2 offers indisputable opportunities for market integration, increasing competition and technological innovation. However, its introduction also brings along many challenges. For instance, due to the prevailing variety of payment systems and methods in the EU, the regulator pursues technology neutrality and does not mandate PSD2 API technical standard. The lack of PSD2 API standard might intensify payments market complexity and fragmentation, which can be an obstacle for the provision of the PSD2 related services by the new FSI market participants in the banking world. Therefore, market players should decide whether to adopt a PSD2 API standard.

What is the role of API standard?

In the PSD2 context, the purpose of APIs is to technically enable the sharing of payment account information between third party providers (“TPPs”, commonly also referred to as FinTech) and account servicing payment service providers (“ASPSPs”, most commonly banks). The legal framework, consisting of PSD2 and the Regulatory Technical Standards on Strong Customer Authentication and Common and Secure Communication under PSD2 (“RTS on SCA and CSC“), specifies obligations on interfaces instead of informing on how to meet the requirements for the access to account rule. The RTS on SCA and CSC require banks to document and make technical specifications concerning dedicated interfaces publicly available in order to achieve interoperability.¹ The purpose of publishing technical specification is to allow TPPs to develop their own technology solution which should be compatible with the specifications concerning dedicated interfaces published by ASPSPs.

The industry standardisation initiative for PSD2 API

In response to the lack of specific PSD2 API standard in the current legal framework, industry standardisation groups emerged with an objective to create a PSD2 API standard themselves. For instance, the Berlin Group developed the NexGen PSD2 framework that contains interoperable access to account requirements. This framework works on connecting the market demand side (new entrants) with the market supply side (i.e. banks, payment/banking associations, payment schemes, interbank processors operation in SEPA).² As a result, a uniform access to account (“XS2A”) communication can help to reduce the PSD2 access to account complexity and fragmentation.³ Also, it will provide uniform access to the payments market for TPPs.⁴

Standardising PSD2 API: the key to navigating the PSD2 Trilemma?

As mentioned in our introductory blogpost, PSD2 coincides with other legal frameworks applicable to the FSI players. Especially the intersection between PSD2, the General Data Protection Regulation (GDPR) and 5th EU Anti-Money Laundering Directive (AMLD5) occasionally causes friction and/or contains aspects that have not yet been fully crystalized. As a result, the three laws form an intricate framework – “PSD2 Trilemma” – which creates many challenges for the FSI players.⁵ However, could API standardisation help the FSI market players to navigate the PSD2 Trilemma and address the challenges? In this blogpost we will shed light on how can a common API standard enable innovative ways to comply with AMLD5 and the transaction monitoring (TM) obligations as well as help to achieve objectives of GDPR.

Regarding TM obligations, the Dutch financial industry is moving towards a centralised TM structure called ‘Transactie Monitoring Nederland’ (“TMNL”). So far, five Dutch banks have been cooperating to monitor their payment transactions for indications of money laundering and/or the financing of terrorism.⁶ In order to create a TM that supports future FSI business models, and that can combat ever evolving financial crime, it will be necessary to include not only banks, but also TPPs. A joint adoption of a centralized TM, and a holistic overview of the payments market, will result in a more efficient detection of illegal behaviour and help to develop new insights considering financial crime.

API standards can help to achieve a centralized TM model that includes both banks and TPPs. APIs can be used as connectors/facilitators for sharing Know Your Customer (“KYC”) and TM information between banks and TPPs in order to comply with the TM obligations under AMLD5. Therefore, having an accepted PSD2 API standard and breaching current industry barriers would also create a solid foundation for designing API functionalities for sharing KYC and TM data in the future. As a result, both banks and TPPs would be able to efficiently comply with the AMLD5 obligations and prevent as well as uncover illegal behaviour patterns.

API standardisation could also decrease the tension between PSD2 and GDPR. Some of the purposes of PSD2 and GDPR may contradict each other, since PSD2 dictates payment account information sharing requirements and GDPR puts restrictions on personal data processing. One of the main objectives of GDPR is to define standardised data protection requirements. Since a standardised PSD2 API infrastructure creates alignment for data processing activities such as data sharing between ASPSPs and TPPs, PSD2 API standard can facilitate harmonization of data protection rules. Sharing payment account information and possibly KYC and TM data in the future via standardised API infrastructure could provide an optimal and common level of data protection, while facilitating innovation in the FSI.

PSD2 API standard may facilitate navigating the PSD2 trilemma

Can the standardisation of PSD2 API help the FSI players to navigate the PSD2 Trilemma? In short, yes. In the future, creating and adopting PSD2 API standard across the financial services industry could also enable KYC and TM information sharing, which will help to fight money laundering and the financing of terrorism. The FSI players can combine their unique knowledge of the customer and create a holistic overview of the payments market while APIs facilitate this cooperation. Also, PSD2 API standard would help to align data processing activities in financial services and provide a more harmonized data protection field. However, PSD2 API standardisation is not a silver bullet, but rather a clue for navigating the PSD2 Trilemma. Since the PSD2 Trilemma remains multifaceted and complex, various elements must be taken into account for the decision whether or not to adopt PSD2 API standard.

1-Regulatory Technical Standards on Strong Customer Authentication and Common and Secure Communication under PSD2, article 30
2-Berlin Group, ‘NextGen PSD2: A European Standard for PSD2 XS2A’ (2019)
3-The Berlin Group issued a press release in October 2020 stating that they will start working on a full openFinance API Framework, where the NextGen PSD2 API Framework will be leveraged. openFinance allows banks and TPPs to offer enhanced services, products and information that will benefit market participants and will further improve customer experiences. https://www.berlin-group.org/single-post/press-release-berlin-group-starts-new-openfinance-api-framework
4-As of May 2020, the Dutch Payment Association has officially joined the Berlin Group.
https://www.berlin-group.org/single-post/2020/05/29/the-dutch-payments-association-joins-the-berlin-group
5-Navigating a Trilemma: How the introduction of the PSD2, AMLD5 and GDPR shaped a new paradigm for Payment Service Providers: https://www2.deloitte.com/nl/nl/pages/financial-services/articles/navigating-a-trilemma.html
6-Transactie Monitoring Nederland: What is TMNL? https://tmnl.nl/summary-eng/