PSD2 (the Payment Services Directive 2) entered into force in 2018. Strong authentication (SCA) became mandatory, Open Banking APIs proliferated, hundreds of fintechs positioned themselves on aggregation and payment initiation. Three years after the regulatory deadlines, it is time for an honest review: what kept its promises? What failed? And where are we headed?
What worked
Account aggregation: a market that exists
Account aggregation (AISP, Account Information Service Provider) is probably the Open Banking use case that has found the most real traction.
Personal finance management platforms (Bankin’, Linxo, Fintecture) have built significant user bases. More interestingly: B2B uses have taken off, including alternative credit scoring based on banking flows, income verification for credit applications, cash flow analysis for SMEs.
Some players have managed to turn aggregation into a genuine competitive advantage: credit fintechs that can score a borrower in real time based on their bank statements open markets that traditional banks could not access (self-employed workers, first-time borrowers without credit history, sole traders).
Strong authentication: improved security despite friction
The SCA (Strong Customer Authentication) obligation has mechanically reduced fraud on online payments. The figures are unambiguous: fraud on card payments subject to SCA has decreased significantly.
The price to pay is friction. The obligation to redirect the user to their bank’s application to validate a payment has created non-negligible abandonment rates, particularly on mobile. But this is a cost that the industry has broadly accepted as necessary.
What is still stuck
Payment initiation: a partially kept promise
Payment initiation (PISP, Payment Initiation Service Provider) was supposed to revolutionise online payments by allowing direct payment from a bank account, bypassing card networks. The promise: reduced fees, improved speed, reduced dependence on card schemes.
The reality is more nuanced. The PISP APIs of banks are heterogeneous in quality, availability and performance. The average success rate of a payment initiation varies considerably depending on the payer’s bank. Some institutions maintain APIs that fail regularly or have response times incompatible with an acceptable user experience.
Result: merchants who invested in Open Banking as an alternative to cards have often had to maintain both channels in parallel, which cancels out some of the expected economic gains.
API quality: an unresolved structural problem
PSD2 imposed opening obligations, not implementation standards. The result: massive technical fragmentation. Each bank implemented its APIs differently: varying data structures, heterogeneous error handling, non-standardised authentication.
Aggregators had to build abstraction and normalisation layers whose maintenance represents a significant burden. For smaller players who want to integrate directly without going through an aggregator, the integration work is prohibitive.
The Berlin Group and STET have provided standardisation frameworks, but adoption is incomplete. The promise of a single API to access all European banks remains an aspiration rather than a reality.
The redirect user experience: a persistent obstacle
The SCA authentication flow involves a redirect to the bank’s application or website. On desktop, this is manageable. On mobile, it is often a sequence of redirects that breaks the application context, disorients the user and generates abandonments.
Banks have very variable implementation timelines for “decoupled authentication” (out-of-band authentication, via push notification). This method would allow the user to remain within the third-party interface without a redirect, but it is not yet universally available.
PSD3 and the payments regulation: what changes
The European Commission has published its proposals for PSD3 (revision of PSD2) and a new regulation on payment services. The main developments:
API standardisation
PSD3 imposes more thorough standardisation of access interfaces. The objective is to reduce the fragmentation that has harmed Open Banking since its launch. “Dedicated access interfaces” with mandatory minimum technical specifications.
Open Finance: expanding the scope
The revision expands the scope beyond payment accounts: insurance, investments, credit, savings. This is the move to Open Finance, an ecosystem in which providers can access all of a customer’s financial data with their consent.
Instant payments as default
The instant payments regulation requires payment service providers to offer instant credit transfers (SEPA Instant Credit Transfer) at the same price as standard transfers. This is a major change for payment initiation: if instant transfer becomes the norm, the advantages of Open Banking on settlement times become a daily reality.
What this means for your architecture
If you are already integrated with PSD2
Two priorities:
- Monitor the evolution of your SLAs for connection to banking APIs, as regulatory pressure will force banks to improve their quality of service
- Prepare for migration to the new PSD3 standards when they are finalised (directive publication expected 2025-2026, transposition 2027-2028)
If you are integrating today
Go through an aggregator (Bridge, Powens, Token.io, Tink) rather than integrating banking APIs directly. The cost of the abstraction layer is largely offset by maintenance savings and better coverage.
Design your integration architecture to be independent of the aggregation provider. The interface with your system must abstract the underlying provider so you can change without redesign.
For Open Finance
Anticipate the expansion of scope. The systems that will be well positioned for Open Finance are those with a flexible and traceable user consent model, not those that have hardcoded logic for payment accounts alone.
Conclusion
Open Banking has not kept all its initial promises. API fragmentation and SCA friction have limited the adoption of certain use cases. But it has created real uses, notably in aggregation and alternative scoring, that did not exist before.
PSD3 and the payments regulation will correct the main structural flaws. Players who invested early in Open Banking, despite its imperfections, are better positioned to benefit from the next wave.
Do you have Open Banking integrations to evolve or design? Let’s talk.