Konsentus Powering Trust in Open Ecosystems

What are Open, Interoperable APIs for PSD2?

Share This Post

This post looks at the PSD2 text and then digs into what I think is meant by the words “API”, “open” and “interoperable” by different parties.

Banks (or ASPSPs) have a lot to gain from providing new services to the customers around data and that much of this may be delivered through APIs, but since the beginning of the year, I have seen many articles published linking the second Payments Service Directive (PSD2) and APIs,  just search LinkedIn. Some articles make the link explicit, other posts just assume that access to the account = API and go on from there. This is despite the fact that, the term “API” is not used within the PSD2 text.

This post looks at the PSD2 text and then digs into what I think is meant by the words “API”, “open” and “interoperable” by different parties. I conclude that the important topic is not one of technology nor terminology, but of cooperation and working together- which is tricky if you don’t have a common understanding.

So what does the regulator want to achieve? Let’s start with the text.

While I am clearly cherry-picking from the 127 pages of PSD2 the following parts are particularly relevant.

Recital 93 states:  In order to ensure secure communication between the relevant actors in the context of those services, EBA should also specify the requirements of common and open standards of communication to be implemented by all account servicing payment service providers that allow for the provision of online payment services. This means that those open standards should ensure the interoperability of different technological communication solutions

The PSD2 article 66 (3 and 4) states: The Payment Initiation PSP (requestor) shall:[..]

(d) every time a payment is initiated, identify itself towards the account servicing payment service provider of the payer and communicate with the account servicing payment service provider, the payer and the payee in a secure way, in accordance with [the regulatory technical standards mentioned in article 98].

The Account Servicing Payment Service Provider (Responder) shall:

(a) communicate securely with payment initiation service providers in accordance with [the regulatory technical standards mentioned in article 98]

(b) immediately after receipt of the payment order from a payment initiation service provider, provide or make available all information on the initiation of the payment transaction and all information accessible to the account servicing payment service provider regarding the execution of the payment transaction to the payment initiation service provider;

Article 98 states that the EBA shall specify

1 (d) the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, as well as for the implementation of security measures, between account servicing payment service providers, payment initiation service providers, account information service providers, payers, payees and other payment service providers.

Beware of what Regulatory Technical Standards might or might not mean.

What is an API, in the context of PSD2 requirements?

Lets try two approaches. Neither are fully correct but try to see it on a spectrum of “APIness”. Firstly, definitions. API stands for “Application Programming Interface”. To quote Wikipedia, “An API expresses a software component in terms of its operations, inputs, outputs, and underlying types, defining functionalities that are independent of their respective implementations, which allows definitions and implementations to vary without compromising the interface.”

So, an API is simply a machine to machine interface where one machine makes a request and the other machine responds to it. In this context, banks have been using APIs machine to machine interfaces for years. Some are in-house. Some reach third party organisations. Here are some examples.

  • The integration of two software components from two vendors within a bank’s back office
    • The SWIFT network, for sending payments: Request: “I’m sending you a payment instruction”. Response: “I got your payment instruction”.
    • The ATM network (via an Acquiring bank) to an issuing bank: Request “Can this cardholder withdraw €50?”. Response: “Yes”.

So far, so unthreatening. Its business as usual. But the experts will criticize this definition as missing the point of a “Real API” a phrase which invokes a world of REST architectures, JSON transport layers, OAuth, sandboxes and developer toolkits. There may be an expectation that Github, is involved and open source licensing regimes. Real APIs may be developed by teenagers while table football in their collaboration pod.

In fact, there are so many elements that can be part of a real API that it is hard (or impossible?) to pin down when a machine to machine interface becomes a “real API”. At least for me.

The problem is that there are two cultures here and both are probably right. APIs bring a tremendous set of tools and ideas that launch us forward into a new way of thinking about data and ways to deliver services implementation, but these ideas scare many when – at some level – we are just talking about another machine to machine interface. It also skips the idea of industry collaboration, that I will come back to.

By the way, I heard the best definition of an API from André Bajorat, CEO of Figo when he said: “It’s basically a mindset that is about making it easy for a developer community to access data”. Very Zen.

Now it gets trickier.

What do we mean by Open, when we talk about Open APIs ?

Assuming that we are OK with the term API, what about “Open API”? There are many aspects where openness might be important. Below are three.

Open Access

A common API classification focusses on who can access the data through the API. Mark Boyd here describes nicely the “Private, Partner, Open” classification – where Open is often changed to “Public” for the purposes of alliteration.

By this designation I am not sure that PSD2 is offering Open APIs. The third parties are not ‘just anybody’ but must be regulated payment service providers, and are therefore in a network regulated by a common set of rules. But this might just be semantics. Still, it is important to remember that by offering an Open API a bank is NOT opening its IT systems to ‘anybody’, but to a closed user group of regulated entities.

Open Data

Is the data that flows over the API “Open” to everybody. No, it is not! PSD2 is clear that data that is sent across the API must not be misused (or even used!) for any other purpose than to make the payment or display the account information. This short sentence does not do justice to the topic, but just be aware that we are working within a tightly controlled data protection environment with privacy high up on the political agenda.

Open Standards

Who owns the standards on which the API is built? Who has the right to change the standards, the functionality? Who has the intellectual property rights (IPR) on the standards? PSD2 does not provide any real standards. The EBA will deliver regulatory technical standards (RTS) which may or may not be “standards” in the sense we mean here. Actually, I don’t believe anybody really cares whether the standards on which a technology are built are open – what the regulators normally care about is that all stakeholders get a say in what can be done with them. Still this is a tricky one even to describe, especially in the abstract.

Clearly PSD2 aims to create an environment that is more open than previously and will the consumers to use their data in new ways, allowing space for innovation from new players in a controlled way. But for the more conservative incumbents who fear that it is unfettered access for “third parties” to come and raid the vaults, I don’t think it is that open.

What is interoperability in an API context?

If API is confusing but harmless when we talk about a single bank, there is more serious confusion when we talk about “open and interoperable” or even “common” across and industry.

The APIs that we casually use in conversation as examples (e.g. Google, Amazon, Facebook…) are almost exclusively used in a one to many setting. There is one data provider and many developers who create applications that in turn offer the data access to many, many consumers (the left hand picture)

An API written to interoperable standards, presumably demands that different (i.e. competing) organisations will have the same API, or the same API standards, so that a developer (a TPP in the PSD2 case) can access all the AS-PSPs without having to do 4,000 integrations. (the right hand picture).

The API in Google Maps is not the same API as Apple Maps. Of course a developer can hide this complexity from me by linking to the two different services, but this will be difficult / impossible when there are thousands of TPPs.

In this context, seeing PSD2 as ‘another’ API implementation is highly misleading. We are talking about something much closer to a scheme. Creating many to many relationships are not exotic nor technically difficult: I know that my ATM card works in any ATM. I can make a SEPA credit transfer to any account holder in the EU. My telephone works with many network providers, globally. This is thanks to good-old fashioned machine to machine interfaces, with standards and governance arrangements, generally in a four corner model.

Two small issues around APIs specific to Payment initiation before I finish and let you get on with your work.

There is a perception that most APIs work without additional security challenges to the user by the holder of the data. For example, when I give an Outlook permission to download my Gmail messages, (through a Gmail API) I set it up with the appropriate security once, and then I do not get challenged every time I refresh my inbox, or send an email. The security is there, but invisible.

This may hold true for PSD2 compliant account information services, but for payment initiation services:

  1. PSD2 requires for all payments (except for micro payments) that there is strong transaction level authentication. Security deserves its own topic but in the end there are various solutions that work, with redirection to the AS-PSP being my preferred one, as the customer always has the same experience.
  2. There is also a fourth party involved (the payee) who will expect to be linked (fairly) seamlessly into the experience.

These factors are not show stoppers – they are not even very difficult (others like iDeal, MyBank, EPS have been achieving this for a number of years), but they do require organisation.

Concluding Thoughts

The idea of Open APIs is great for unleashing the creativity and potential around open banking. Web based APIs may also provide a robust easy to implement technology stack to deploy access to account services.

The terminology may bring some confusion, putting the focus onto technology rather than agreements; and creating expectations about what will actually be delivered.

Payments is a network business, and to avoid fragmentation the way that API’s are built will need to be coordinated. The value to the customers is not just that data is open, but that it is open across many banks in the same way.

Providing Access to the account services that work is not rocket science, but it does require that the industry gets organised and takes some decisions – at least once the first draft of the EBA RTS are published. Just publishing your API will not cut it. 

This article is based on my own opinions after a good few discussions about APIs inside and outside our organisation and in various industry groups.

It’s part of a learning process, so if you want to challenge, correct or add to this anyway, please go ahead and leave a comment. If you agree with bits of what I have written and want to say so, then that is fine too!

Picture of John Broxis

John Broxis

Managing Director, Open Banking Exchange

Subscribe To Our Newsletter

Keep up to date with all our news and publications.

More To Explore

Talk with Our Team Today

Join us on the Journey

Protect your customers transacting in open ecosystems.

Konsentus Rebrand Button - Konsentus Dot-23-23

Find out how our technology can protect your customers within open ecosystems.



On completion of this form you will be sharing your personal data with Konsentus Ltd (company number 1115059) (“Konsentus”/”we”/”us”). We will process such information for the purposes of sending you the requested information. We may also send you marketing communications and information which we consider may be of interest to you from time to time. This may include sending information by email, or us contacting you by telephone, where relevant details are provided. We rely on our legitimate interests as the lawful basis for processing your data in this way. Under certain circumstances, you have rights under data protection laws in relation to your personal data, including the right to receive a copy of the data we hold about you. You also have the right to opt out of marketing communications at any time using the details in an email sent to you or by contacting us at insights@konsentus.com.

This field is for validation purposes and should be left unchanged.

Login to your account