PSD3 and PSR: Lessons Learned from PSD2
The Payment Services Directive 2 (PSD2) entered into force in 2016, but took European member states three years to implement. Banks quickly discovered that PSD2 did not exist in isolation. It created operational tension with other regulations, most notably the General Data Protection Regulation (GDPR). Banks that implemented PSD2 as a regulatory expense lost out to banks that saw the opportunity to self-disrupt their own payment solutions.
This Insight explores the opportunities, challenges and risks posed by PSD2 and how lessons learned can be applied in preparation for PSD3 and the Payment Services Regulation (PSR).
Prefer to download the full analysis instead?
From regulation to new reality
PSD2 impacted the playing field of institutions and customers alike. It looked to break the monopoly institutions had on customer data and to encourage innovation in the payments domain. PSD2 changed the market by introducing three structural shifts:
- Legal framework for Open Banking
- Enabling third-party access to the financial ecosystem
- Improving security for customers
From a regulatory perspective the mechanism looked straightforward. Institutions that perceived PSD2 as a regulatory exercise limited scope to IT change only. After all, Open Banking solutions and third-party access simply required institutions to make current interfaces available to external parties. During such early PSD2-implementations it became apparent that this was easier said than done. With opening up their payment infrastructure interfaces, institutions were confronted with ownership issues:
- Inconsistent data
Application Programming Interfaces (APIs) were made available externally to enable access to payment infrastructure. Each institution designed its own APIs, resulting in inconsistent data definitions across the value chain. Without clear end-to-end ownership this proved challenging to solve, let alone standardize.
- Fraud risk
Opening APIs to third parties exposed payment infrastructure to new fraud risks, including unauthorized payment orders and unauthorized access. PSD2 responded by demanding strong authentication solutions at a later stage to mitigate these risks.
- Data Privacy Risk
PSD2 conflicted with existing regulation such as GDPR. This added operational and legal complexity for affected institutions on top of the IT-solution. This introduced strategic tension as these two regulations were not designed in harmony.
Some institutions continued to treat PSD2 as a regulatory expense, while others found partnerships with FinTech companies to secure a competitive edge.
The true test of PSD2
PSD2 aimed to stimulate innovation. Doing so required institutions to align Compliance, business and IT. Institutions that treated PSD2 in isolation achieved compliance but little strategic benefit.
In practice, PSD2 became a test of organisational capability: institutions that aligned these disciplines were able to turn regulatory deliverables into strategic advantage. As a result, institutions fell into four strategic response patterns across PSD2 implementations. We captured these patterns in the Regulatory Response Matrix below. It begs the question for institutions preparing for PSD3 and PSR: in which quadrant does your organisation currently operate?
Most institutions started PSD2 in the lower-left quadrant of the Regulatory Response Matrix.
Are you ready for PSD3?
Ensure a proper start for PSD3 and PSR by aiming for strategic alignment:
- Assign ownership
Focus on identifying commercial upside. Use regulatory change as a strategic driver instead of limiting the initiative to mitigating regulatory downside.
- Speak the same language
Close collaboration between Legal, business and IT relies on speaking the same language. Align stakeholders to secure buy-in and constructive contributions from all specialisations involved.
- End-to-end business case
Ensure the business case for PSD3 is not limited in scope to Compliance only. If upside opportunities are in scope, IT and business must be involved already during preparation.
- IT as the driver
Ensure alignment between business and IT in solution architecture. IT needs to support business use cases in order to secure commercial upside for the institution.
Advantage in alignment
Institutions preparing for PSD3 and PSR should treat cross-functional alignment as a structural design choice. This will avoid mistaking PSD3 and PSR for a regulatory expense. It is those institutions that will secure business benefits post-implementation.
Preparing for PSD3 and PSR requires more than regulatory interpretation. Early alignment on regulatory interpretation between Compliance, business and IT will be the decisive factor that separates institutions that secure strategic advantage from those that achieve mere compliance.