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.