The worldwide open banking API ecosystem continues to develop rapidly and is morphing into the all-encompassing and much-lauded open finance. Markets across the world, including Brazil, Canada, and others, are creating and enacting legislation to help promote openness and competition in financial services through the provision of APIs.

In the European Union (EU), the Payment Services Directive 2 (PSD2) legislation was responsible for spurring the initial mass growth. It’s hard to believe that our first post discussing PSD2 was now over eight years ago. The deadline for implementing PSD2 has come and gone, and the majority of banks, albeit with a few exceptions, are complying with their regulatory requirements.

It is generally acknowledged, however, that PSD2 has not brought about an open banking nirvana. Like many EU “maximum harmonization” directives, the legislation drives a change in local law in each member state. Implementation is therefore different in each state and may not go beyond the requirements of the regulation. In this case, the directive also focuses entirely on “payment-capable” accounts and therefore does not apply to a myriad of other banking products.

Given the scope and implementation of PSD2, there is clearly an appetite for continued development in the open banking market. In this context, the next iteration of the legislation — PSD3 — is now being discussed through consultation with the European Commission. The European Banking Authority (EBA), which was responsible for PSD2, was invited to provide feedback on PSD2’s success and potential next steps for refining the legislation in the future.

In this post, we’ll take a look at that feedback and pick three ways in which PSD3 might change open banking in the EU. We’ll also provide our opinions on the logical next steps, regardless of the feedback, for enhancing the standards that have been created under PSD2.

Standardizing the Standards: One Standard to Rule Them All

When we talk about PSD2, open banking, or open finance, we do so in the context of APIs. Say what you like about business models and competition, but at the technical, nuts-and-bolts level, APIs are fundamental to what has been achieved under PSD2. Oddly when PSD2 was first drafted, there was little to suggest APIs would be so fundamental. The focus was on establishing roles and responsibilities and a framework for implementing the Directive in all EU countries. Technology almost did not come into it.

That view, however, appears to have become null and void at the EBA. Early in the response document, they encourage investigating “… the possibility of having a common application programming interface (API) standard across the EU”. The EBA acknowledges the implicit difficulties in doing this, not least due to the vast costs already absorbed by banks and third-party providers (TPPs) in implementing their APIs and clients according to the standards developed or adopted in each country. However, the approach to date “…creates significant challenges for TPPs as they have to invest significant efforts into connecting to different ASPSPs’ [regulatory acronym for banks and other account-providing institutions] APIs and adapting their connections to changes of APIs across time”.

In the context of the EU, a common API standard for open banking – and the final removal of screen-scraping seems entirely sensible. The majority of developers are probably left wondering why this was not implemented in the first place. The EU law-making approach for PSD2 was to set a directive, followed by the implementation in Member State law and then the development of standards. This almost certainly did not help, as the law preceded the standards, and there was little impetus to create unified standards. This is incongruent to the fact that the functions of a bank account, whether retrieving data or executing a service such as making a payment, are relatively straightforward. To the uninitiated or objective observer, designing a ubiquitous API standard based on prior art that fits all markets appears both entirely feasible and, with the right kind of input from stakeholders, achievable.

Under PSD3, the standards-by-market approach should be revised. A common API standard makes sense, especially given the passporting regulations in financial services that allow financial products to be consumed across different EU countries. Having one standard to be implemented by the banks and be consumed by TPPs would massively reduce friction in this context and lend itself to competition within and between markets. It would also help create a clear delineation between regulatory and premium services across the EU, as the APIs a bank is obliged to provide will be clear and unequivocal as a common standard defines them. Anything else the banks can charge for access.

In terms of implementing such a common standard, there is a relatively pragmatic course of action to be taken, namely for all countries to adopt the most common standard as a starting point. The Berlin Group standards are arguably the most widely used and could define the basis of an appropriate model for a unified standard. However, It remains to be seen whether a pragmatic approach is possible in a vast jurisdiction like the EU.

Improving Strong Customer Authentication

One of the areas over which banks have a great deal of control is Strong Customer Authentication (SCA). The account-holding customer of both the bank and TPP have to log in using their internet banking credentials — using multi-factor authentication — to authorize a new service with the TPP, even when they have an existing relationship with that service provider.

The EBA sees that “…​​delegation of SCA to TPPs and TSPs [Technical Service Providers] may have [a] positive effect on the introduction of new authentication solutions facilitating the development of new business models for payment services, as well as customer convenience. This could allow for seamless, efficient and integrated SCA solutions.” This rings true with the fact that one of the major gripes for TPPs is the lack of clarity in SCA exemptions.

The use cases for such exemptions — paying for parking at a kiosk with no UI, for example — are well-known. How to actually apply that at a practical level in the scope of both the current regulations and the required approach to authenticating the account-holding customer is difficult. Some standards can support limited input devices, such as the OAuth Device Flow, but that relies on an appropriate implementation by the service provider. SCA exemptions are intended to allow for scenarios where such provisions are not made, and another trusted party (i.e., a TPP) can prompt an authentication flow and supplied trusted proofs-of-authentication.

The EBA also makes specific recommendations around Account Information Service Providers (AISPs) who can access a bank customer’s account when authorized. They suggest that technical standards for authentication “…require AISPs to apply their own SCA, instead of ASPSPs, after an initial SCA has been performed with the ASPSP the first time the PSU accesses the payment account through the respective ASASP”. This would certainly reduce friction for TPPs required to push their customers to re-authenticate every 90 days, which is a requirement of the technical standards.

The EBA recognizes the issues with SCA as “underlying issues and obstacles” in its summary on the responses. At a practical level, however, there are several ways this could be addressed. For example, using Passkeys as a means of prompting an account-holding customer to authenticate themselves to authorize sharing data or payment could be a bridge between the TPP and the bank, as the TPP can provide strong proofs-of-authentication in their request. This method of presenting an authentication assertion is already manifested in the W3C standard Secure Payment Confirmation, which in turn is supported in latest versions of 3D Secure (although acknowledging that card payments receive some bad press in EBAs comments).

The main bone of contention is really one of trust. The standards bodies need to implement an SCA framework that is not tightly coupled to a customer’s internet banking identity. They must also consider how to create a suitable trust framework backed up by a clear statement of liability between all parties. A means to allow proofs-of-authentication from other identity providers to be trusted at the banks is required, supported by a model that provides programmatic indicators of what authorization is actually required, using a model like Vectors of Trust. A reduction in friction for customers can only be achieved by taking a more feature-rich approach to authentication that works on their behalf rather than against the TPPs.

Supporting Digital Identity

One feature that could support improvements in SCA is establishing a common digital identity. Supporting digital identity is an overt goal in the EU. For example, the creation of the European Digital Identity Wallet has been in flight for several years and intends to provide the basis for creating a digital identity at an EU Member State level. While this will have the same drawbacks as PSD2, as it is a maximum harmonization directive and thus relies on local laws to define what should be implemented, it does offer a glimpse of a means that could accelerate the adoption of open banking/finance. Obviously, some EU Member States already have widely-adopted digital identities. For example, NemID in Denmark and BankID in Sweden are examples we have quoted before. However, tying this in with open banking legislation and standards could significantly uplift the available functionality.

In the EBA response document, there is little to suggest that PSD3 will bring digital identity into scope. We have already discussed how clarifying SCA will reduce friction and increase trust, but there seems to be little in terms of EBA recommendations on this subject. Therefore, the likelihood of PSD3 significantly influencing the development of digital identity in the EU is low. One can hope that during the course of standards development resulting from PSD3, there will be enough interest in providing standards that reference the European Identity Digital Wallet to make a case for integrating them.

In terms of an implementation approach to digital identity, we have already discussed the merits of Passkey and how this can prove strong assertions of authentication. This also provides the basis for an approach to digital identity using technology that will be ubiquitous over the next few years. Now is the perfect time to do some “joined-up thinking” and bring together the regulations and technology to create an important building block for the further development of the ecosystem.

Final Thoughts: Time for a New API Style?

In this analysis, we have concentrated on three key themes that will have substantial implications for the development of PSD3. Yet, we have not touched on open finance themes, which will certainly widen the scope of the regulations.

For us API people, however, there is already plenty that will keep us interested. For example, will any standards bodies — or the body creating the common API standard for the EU — consider other API styles and introduce a GraphQL schema for accounts and payments data? This idea has some grounding in the data. Financial data fits a graph model very well, and using mutations on the graph to initiate payment makes for a clean interface with natural congruence between the payment being created and the transaction that records it. If you think about this from a schematic perspective, the payment and transaction can be represented by an Interface, given the commonality between the attributes.

Of course, PSD3 will probably not dictate API design styles directly. Regardless of the proposed common API standard, it’s very unlikely to deal directly with technical implementation details. The EBA states in the report that a common API standard is best designed by the industry. We also need to consider what impact the possible merger of the Electronic Money Directive (EMD2) may have on the spirit of PSD2 and whether it extends its scope under PSD3, incorporating wallets or other electronic money instruments.

PSD3 will, however, provide the spur for rethinking the way open banking and, consequently, open finance interfaces are designed and implemented. Standards bodies across the EU have a duty of care to get it right for the market, with many TPPs betting the house on the success of open banking. The banks are now universally in the API game and should be interested in shaping their APIs in a way that helps them achieve their goals. With the insights from the first phase and by listening to the community’s needs, there is a chance the next iteration of standards-based open banking APIs — whether they use GraphQL or not — will look very different from what’s gone before.