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 its current status from a technical perspective. In this article, let’s zoom in on some of its technical challenges/implications – and how we could effectively deal with those.

Series index:

  1. Introduction
  2. Technical implications
  3. Leveraging the UK Open Banking experience
  4. Managing the PSD2 APIs







The role of APIs

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 authentication1 (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.
  • 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.

With regard to API design and the security model, a lot of useful inspiration may be derived from the UK’s Open Banking initiative. We will look at this in more detail in the next article in this series.

To learn more about four common API usage models, mapping to different levels of maturity within an organization, download this free white paper: Enterprise API adoption patterns.

1. Assuming payment user authentication through redirection, or to support an application when choosing a decoupled authentication approach.

Share Button

Add a comment