Akana Platform Free Trial

Get Started Today »

Olaf van Gorp
PSD2 is upon us! From a technical point of view, now is the time to ensure the implementation of a dedicated PSD2 interface. In the previous article in this series, we had a look at PSD2 and some of its main technical challenges and implications. In this article, we’ll have a look at how emerging PSD2 standards help with the implementation of a dedicated interface, and what we can learn from similar exercises like UK Open Banking.

Series index:

  1. Introduction
  2. Technical implications
  3. Leveraging the UK Open Banking experience
  4. The role of API management






At first glance, the implementation of a PSD2 dedicated interface certainly looks like a daunting exercise. As we know, the RTS1 (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 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.


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).

Next time, we will explain how an API management solution offers indispensable value in terms of implementation flexibility and how it effectively addresses aspects of an API-based interface that are not explicitly mentioned in the Open Banking and PSD2 specifications.

1. In full: Regulatory Technical Standards for Strong Customer Authentication and Common and Secure Open Standards of Communication

Share Button

Add a comment