PSD2 & Open Banking: The Role of APIM

In this blog, we break down PSD2 and open banking.

Introduction to PSD2 and Open Banking

PSD2 is upon us! Without any doubt, 2018 will be the year in which the implementation of PSD2 will be at the forefront of many financial institutions with an interest in account and payment services.

From a technical point of view, now is the time to ensure the implementation of a dedicated PSD2 interface – for those that have concluded that such is the best way forward. Their focus will most likely be on an API-based approach.

This approach may itself generate a number of highly relevant questions, such as: “What exactly does it mean to create an API-based interface?”, “What are the implications of using APIs?”, and “Does the available PSD2 documentation give me sufficient information on everything that's involved?”

Let’s first have a closer look at PSD2: the revised Payment Services Directive and its current status from a technical perspective.

The revised payments services directive (PSD2) was first proposed by the European Commission in June 2013, adopted by the Parliament in October 2015 and entered into the Official Journal (OJ) of the EU on 23^rd December of that year (making it legally binding in all member states). Its ‘entry into force’ (EU jargon for ‘effective from’) was the 12 January 2016 (20 days after publication in the OJ), giving all member states two years to transpose it into national law.¹

This year is going to be crucially important from a PSD2 perspective as the date on which it officially enters into force across the EU has now passed. This means that all EU member states should now have PSD2 incorporated in their national legislation. Though not all member states have managed to complete this just yet, the expectation is that they will have done so by the end of the first quarter.

Secondly, and more relevant from a technical standpoint, the European Banking Authority (EBA) has finally submitted the final draft of the so-called ‘Regulatory Technical Standards (RTS) on strong customer authentication and common and secure open standards of communication’ to the EU Council and Parliament, which should formally adopt it by March of this year at the latest.

That means we now have all the information necessary to successfully create a compliant, dedicated PSD2 interface, right? So, let’s get to work!

Well – not quite. How come?

A Closer Look at PSD2

The essence of PSD2 is that it allows for highly-secured and consented access by Third Party Providers (TPP) to a bank customer’s account information and/or the bank’s payment services. There is general consensus that these provisions will be best addressed by the bank, or Account Servicing Payment Service Provider (ASPSP) as banks are formally called under PSD2, by offering a dedicated interface based on APIs.

Indeed, such an approach may coincide very well with the bank’s digital transformation programs already underway.

As we know well by now, APIs offer an effective way to quickly and securely expose business capabilities to whichever consumer audience they are intended to be shared with. Hence, it makes great sense to look at APIs as the technology of choice for the dedicated interface.

What’s more, the security standards that have evolved around APIs, in particular those safeguarding restricted access (authentication, authorization), appear to fit very well with the security requirements as they are laid down in the RTS.

Or do they?

The RTS describe the requirements with regard to secure communication at a rather high level only. In order to remain ‘technology neutral’, technical implementation details are left open. Yet, in particular from an interoperability perspective, it is clear that standardization is critical for a successful implementation across the board. Though a number of initiatives that are undertaken in this respect can be identified, it remains to be seen which of those are going to be widely adopted, whether they offer sufficient detail and, ultimately, what effect they will have on interoperability.

At a higher level, there is even debate on some fundamental PSD2 aspects, for example the use of redirection in user authentication scenarios, which some claim may not be in line with the RTS or even illegal.

This leaves us with a situation that is not exactly without risk. Whereas the time for implementation is imminent, we’re still groping in the dark, more or less, as to what to implement exactly. Therefore, it would be wise to allow for significant flexibility in the chosen implementation architecture, ensuring that anticipated modifications can be applied without having a severe impact on the overall work.

The Role of APIs in PSD2

While legislators are still debating the details of some of the specifics laid down in the final Regulatory Technical Standard (RTS), there is a general agreement on the security and communication requirements that a PSD2 implementation will need to be compliant with.

In order to allow TPPs access to a bank customer’s account details or the bank’s payment services, PSD2 encourages the creation of a dedicated interface (next to the existing interface used directly by account holders). Not surprisingly, this dedicated interface is widely expected to be API-based.

In modern integration architectures, APIs are used as a means to effectively expose capabilities from enterprise systems in a consumer-friendly format. Typically, the published API offers an interface based on current open standards and styles. This usually has a positive effect on the development effort required to consume the API–after all, the consumer is shielded from the technical intricacies and complexity that may be associated with the downstream enterprise services (that may have been created using ‘legacy technology’).

For a PSD2 implementation, the dedicated interface will probably be a combination of APIs providing access to the actual business functions (account service, payment service, confirmation of funds service – these APIs are also referred to as the XS2A interface) and APIs that provide essential supporting functions, in particular payment user authentication¹ (including SCA as specified under PSD2).

Steps For PSD2 Implementation

Concentrating on the XS2A APIs, these are steps likely to be part of a PSD2 API implementation:

• Create API design: The design is expected to be based on standards provided through national or pan-European standards organizations, with the API interface descriptions likely to be in Swagger (Open API) format. (Read more >> What Is API Design?)
• Implement security model: Ensure that the published API is compliant with all PSD2 security requirements that apply to the dedicated interface. As with the API design, it is expected that a security profile with technical implementation details will be provided through standards organizations.
• Connect the API: Connect to downstream services that are responsible for processing the incoming requests and generating the response to be sent back to the consumer through the API.
• Ensure publication of the API: Make the API and its details available to prospective consumers as mandated by the RTS.

It's important to note that providing APIs will involve more than ensuring compliance with the PSD2 requirements. Though the RTS already specifies a great deal of security measures, it obviously focuses on aspects that are relevant from the perspective of its mandate, in particular, safeguarding the interests of payment users. Account Servicing Payment Service Providers (ASPSP) will need to go beyond these aspects to ensure operational availability and integrity of their services, which means they’ll have to address concerns regarding performance and scale as well. In addition, they will have to be able to quickly block consumers with malicious intent, or throttle traffic to avoid system overload.

What needs to be taken into consideration is the management of the APIs themselves (operational management, lifecycle management, etc.). This is a subject in its own right, which we will discuss in the fourth article in this series.

How to Leverage Open Banking With PSD2

With regard to API design and the security model, a lot of useful inspiration may be derived from the UK’s Open Banking initiative. 

At first glance, the implementation of a PSD2 dedicated interface certainly looks like a daunting exercise. As we know, the RTS¹ (Regulatory Technical Standards that have been published last week in the Official Journal of the EU, giving banks until September 2019 to finalize implementation of their dedicated interface) are created from a technology-neutral perspective, leaving the implementation details to be specified elsewhere. Fortunately, a number of pan-European initiatives have sprung up to create de facto standards in which the API interface and API security profile are described in detail.

At the same time, we may learn from the standards as they have been laid down by the UK Open Banking Implementation Entity (OBIE) – in particular because these standards provide a great level of detail and because they have actually been implemented, at least by the nine major banks mandated by the Competition and Markets Authority (CMA) under Open Banking (OB). Even though UK Open Banking and PSD2 are quite diverse in terms of functional scope, geographical applicability, and other criteria, from an API implementation perspective, the similarities are more significant than the differences. In fact, the OB Standards proclaim the explicit intention to align with PSD2, allowing for (and introducing) PSD2-specific extensions where required.

The availability of the standards mentioned above certainly helps with the implementation of a dedicated PSD2 interface – yet an implementing party will have to consider items such as:

• Which standard to use, exactly?
• What will be the consequences of this choice in terms of intended interoperability?

It is beyond the scope of this article to compare the various emerging standards in detail. Nevertheless, an initial comparison of the security profiles associated with current OB standards and available PSD2 specifications reveals some interesting differences in overall approach.

Let’s zoom in on a few of those and see whether it helps us decide which route to follow.

TPP Authentication and Authorization

When comparing OB with PSD2, one thing that immediately catches attention is the central role of OAuth2.0 and OpenID Connect (OIDC) in the OB Standards. Whereas OB positions OAuth as the foundation of the security profile associated with its read/write APIs, the use of OAuth is mentioned only as an option in the PSD2 specs as they have been currently drafted by, for example, the Berlin Group (NextGenPSD2). They are arguably the most significant player in the PSD2 standards playing field.

On their part, the PSD2 specifications focus primarily on the use of certificates as a means to support authentication, at the same time allowing more flexibility when it comes to selecting the authorization approach. Though certainly providing a secure foundation for communication between Third Party Provider (TPP) and bank, this still leaves payment service user (PSU) consent to be addressed. In my opinion, this is thoroughly covered in the OB Standards – indeed, using the OAuth2.0 and OIDC standards. Though one may have expected to see this approach with the PSD2 standards as well, it appears this route is not (yet) embraced as such. One wonders why…

Nevertheless, with PSD2, OIDC/OAuth2.0 may be used for authentication/consent/authorization purposes, so implementing parties may certainly opt for that approach. Yet at the same time, the implementation will require client authentication using eIDAS-compliant certificates at both the authorization and the resource server endpoints. The OB standards do not explicitly mention the use of client certificates with the Authorization Server but they do state that the client ID in the OAuth Access Token has to be verified against the client ID contained in the client certificate. A pretty significant difference – it remains to be seen which approach offers most value.

Where authorization also deviates between OB and PSD2 is when it comes to determining the role in which the TPP accesses the Access to the Account (XS2A) interface. With OB, role information is provided through an OAuth scope, whereas PSD2 requires the role to be read from the TPP certificate. The latter approach will certainly have a larger impact; OAuth scoping will be offered through COTS OAuth solutions, whereas reading information from a certificate may require additional work.

Strong Customer Authentication

In the context of payment initiation, a significant functional difference between OB and PSD2 is the latter’s requirement for Strong Customer Authentication (SCA) and the associated need for dynamic linking (i.e., making sure that an ‘authentication code’ that is provided after SCA has been successfully completed is only valid for that specific transaction, for a distinct amount and payee). Interestingly, though SCA is at the heart of the PSD2 RTS, there does not seem to be a lot of unanimity yet as to how SCA should be dealt with in the technical implementation. It may in fact be that the OB Standards offer the most valuable inspiration for SCA implementation – remarkably so since OB itself does not mandate SCA.

The OB Security Profile outlines how SCA can be dealt with in the wider authentication/authorization context associated with payment initiation, leveraging open standards like OIDC and FAPI. It’s pretty remarkable, in my opinion, that neither standard is explicitly mentioned in any of the PSD2 specs mentioned in this article. Still, the debate is going on, and we may well see a convergence of the various standards in the time to come.

How API Management Fits into PSD2 and Open Banking

With the regulatory standards having been adopted by the European Commission, banks within the EU now have until March 2019 to provide a version of their PSD2 interface that will allow Third Party Providers (TPP) to analyze its documentation and execute connection and functional tests.

Exactly what interface a bank will offer is determined by many factors, an important one being their strategic decision regarding PSD2 and open banking in general: What role does the bank envision for itself? While we know of some banks that have taken a firm decision to embrace regulation and seek out new business opportunities, the vast majority seems hesitant, which may have them end up playing a role that is a far removed from their envisaged one.

In addition, and probably influenced by these strategic considerations, the banks have to decide about the actual technical implementation of the PSD2 interface. As was outlined in earlier articles in this series, this interface is widely expected to be API-based, as APIs offer an effective way to quickly and securely expose business capabilities to whichever consumer audience they are intended to be shared with. Moreover, the use of APIs allows for delegation of a significant part of the technical implementation to specialized API management solutions.

What value will an implementing party derive from the use of an API management solution? This obviously depends on the selected solution; not all vendors offer the same depth and breadth in terms of API management capabilities. In the following paragraphs, you’ll find an overview of what you may expect from an enterprise-grade solution – for example, the Akana API Management Platform.

Considerations for API Management in Open Banking

First, whether approaching open banking from a perspective of mere compliance or whether expecting substantial business value from it, an API management solution may be expected to provide great help in terms of ease-of-implementation and interface flexibility. For example, it will allow APIs to be published in a simple and consistent manner, where the solution may even allow for alternative versions based on different OB/PSD2 standards (simultaneously or over time).

Considering the mandatory security requirements that come with OB/PSD2, such as the use of PKI and OAuth 2.0, these are notoriously hard to properly implement. An enterprise-grade API management solution that provides strong security capabilities should support these out-of-the-box.

Next to security, the Regulatory Technical Standards (RTS) place strong emphasis on a bank’s PSD2 interface in terms of its availability and stability – in other words, banks are required to adhere to strict service level agreements (SLA) with their interface consumers. This in turn requires the bank to be able to carefully monitor the performance of its APIs and ensure scalability of its interface while carefully auditing the request messages being processed – the latter also of indispensable value when it comes to fraud monitoring and prevention. Again, these are capabilities that an API management solution (such as the Akana API Gateway, in particular) should offer.

Furthermore, an API management solution may be expected to address security-related and operational aspects that are not explicitly addressed by the RTS or the PSD2 API specifications, but that should be taken into account nevertheless, for example:

• Additional security threats like distributed denial of service (DDoS), compromised message integrity, etc.
• Monitoring and management of consumer ‘behavior’, as a means to protect downstream systems (think of mitigating actions like traffic rate limiting or throttling)

Obviously, implementers should also expect their API management solution to offer a number of additional benefits; in particular, capabilities that will help them to effectively manage the APIs themselves, for example:

• API Lifecycle Management – API development lifecycle, API consumption lifecycle, API versioning
• API Analytics – API intelligence, consumption trends, etc.

From a wider, strategic perspective, an API management solution will also provide indispensable support for non-mandatory APIs - in particular relevant for those banks that approach PSD2 as a business opportunity rather than a regulatory obligation, or more generally as part of an enterprise’s digital transformation process.

As a final thought, delegation of the PSD2 interface implementation to an API management solution can be taken even further, literally delegating this to a distinct interface implementation partner. Where this partner would host and manage the interface for the bank, it would allow the bank itself to concentrate on the underlying business services. We have already seen some promising initiatives by organizations to create a centralized PSD2 interface or hub, for example in Poland.

Conclusion

The emerging PSD2 standards certainly offer a lot of indispensable help for organizations implementing a PSD2 dedicated interface. However, it is also clear that the various approaches are not fully alike, which is bound to introduce interoperability issues. This is particularly true (or concerning) where the standards deviate from existing open standards. It’s interesting to see that UK OB Standards have set out to find solutions within the boundaries of existing standards like OAuth and OIDC, whereas some of the emerging PSD2 standards do not hesitate to introduce extensions, which may prove to be challenging from a technical implementation perspective.

Implementing parties should be aware of this and allow for flexibility in their chosen implementation approach. On the one hand, there may be a need to shift the implementation once standards become more definitive. On the other, in particular when approaching PSD2 from an opportunity perspective rather than a regulatory compliancy one, it may be of strategic value to be able to quickly embrace multiple emerging standards in order to position oneself as a more attractive partner to upcoming Account Information Service Providers (AISP) and Payment Initiation Service Providers (PISP).

PSD2 and open banking bring opportunities as well as challenges. In this series of articles, we have looked at the technical challenges in particular, and how these challenges may best be approached. Creating a OB/PSD2 compliant interface is far from trivial, but fortunately quite a number of essential implementation aspects can be delegated to specialized API management tools like the Akana API Management Platform. Having such an architectural component in place provides the required robustness and reliability in terms of security and availability, at the same time offering the required implementation flexibility. With PSD2 standards still being in flux, this flexibility may well prove to be among the principal benefits.

Try the Akana Solution

Experience the Akana API platform free for 6 months!

Start Trial

👉 Become an Expert

Explore additional resources:

• API Basics
• API Security Best Practices