Obstacles per se

The closer we come to 14th September 2019, the implementation deadline for the RTS on SCA & CSC, which details much of the PSD2 legislation, the less room we have for unclarity about its stipulations. One of these open points and maybe the most important one is the definition of an “obstacle” in the sense of RTS Art 32(3).

The RTS stipulates a number of API processes and functionalities explicitly, but it cannot define everything in all detail and this “catch-all obstacles article” ensures that nothing can fall through the cracks. It actually lists some examples of obstacles, including the thorny issue of “redirection”, but these became rather unclear since the European Banking Authority (EBA) stated that “redirection is not an obstacle per se”. We heard that many times by now and there is a growing number of problems, which are supposedly not an obstacle per se.

This made me wonder what an “obstacle per se” could be and if such thing exists at all? Let’s illustrate it with an example: say the channel tunnel was closed today. Would that be an obstacle per se? Or an obstacle at all? Well, not for me, as I am not there today, nor for most other people here in Europe, let alone the rest of the world. Some Brits may even celebrate it, but if you asked the poor guys stranded in the Eurostar terminals, they would tell you what a big f* obstacle it is to them.

Obstacles are quite clearly relating to specific people in specific situations. There are no obstacles per se, and what is an obstacle to me, must not be an obstacle to you. So how can we then clarify or define the term “obstacle” in the RTS? A closer look may help: it says that APIs shall “not create obstacles to the provision of payment initiation and account information services.” To judge what could or could not be an obstacle to that, we must realise a couple of things:

Firstly, we must understand what such services are and the key to that lies in the word “service” itself, because we are not talking about a simple payment initiation or account information retrieval for which I could just call the bank myself. How is a Payment Initiation Service (PIS) or Account Information Service (AIS) defined and by whom? Some have existed in the market for over a decade and have matured over time into very complex and sophisticated services. I think it is fair to assume that there cannot be any single definition, but the minimum we can expect is that we are not talking less than the scope of services existing already. For example, one of the main PIS “service elements” is the real-time success message provided to an online retailer, without knowing if and when the payment will actually be executed in the overnight batch process most banks are still using. Customers do not want to wait, but the mitigation of this “non-execution risk” requires a lot of account data to be analysed and this has to happen before the payment is initiated, because a good PIS will not initiate any payments, which risk to fail and leave the merchant without money in the end. Similarly, many AIS are very clever services and not just a simple account balance alert.

Secondly, we must understand why APIs could create obstacles at all and for doing what? Up to now, most PIS and AIS (together called Third-Party Providers, TPPs) have used the bank’s end-customer-facing “user interfaces” to provide their services. Now they shall use the bank’s APIs and for that they have to re-program their software accordingly. But what if the API does not provide the same availability or functionality as the user interfaces? Could these be the obstacles we have been looking for?

Depends. If my AIS is just a light and easy service, even a slim API may provide enough functionality for that. Same for an easy cash management PIS maybe. However, if I have to migrate a real-time e-commerce PIS over to an API, then this will require quite a broad range of functionalities supported by that API, including those for the non-execution risk mitigation explained above.

So, any given API may or may not create obstacles depending on whether it allows a given TPP to migrate their services onto it or not. Hence, APIs must be scoped not just for the least demanding, but the most demanding TPP services around. To tell banks what is needed for that and therefore for their compliance, the European Commission’s API Evaluation Group worked out and recommended the required functionalities. Some of them are explicitly stipulated in the RTS, some others would create obstacles if absent. Important to note that both are legally required and that the EC has warned banks many times that they would ignore the latter ones at their own risk. Unfortunately, most banks have done just that and they may now not be compliant, because whilst their API may not be a problem for some TPPs, it may well create obstacles for others, if they could not migrate their existing services without losing some or much of their purpose and thereby lead to customer detriments.

One may argue that designing APIs for the most sophisticated TPP services would be overkill, but the opposite is true, because the promise of PSD2 is to get more innovation and more competition, and not just reproducing the best services already available today with another technology. But where is the limit then? Can we force all banks to provide the broadest possible APIs for free? No, and that’s not what I am saying. PSD2 forces banks to unlock their customers’ payments data and let them share what is “made available” to them with licensed TPPs. That is what their customers already paid for and cannot be charged again, neither to themselves nor to any TPP accessing it on their behalf. However, anything not made available to their users, e.g. a payment guarantee, and many other things banks do in the background, could be offered as a premium service, and that is where commercial activities beyond PSD2, like the SEPA API Access Scheme, come into play and may lead to much broader APIs still. I reckon most real-time PIS would rather pay a premium for a payment guarantee than operating and maintaining their own non-execution risk mitigation.

My search for a plausible definition of the term “obstacle” in this context comes to the conclusion that there are no “obstacles per se” and what does create an obstacle depends very much on the TPP and their existing or future services. If any given API does not support the functionality needed to migrate such services, then this TPP, and only this one, can claim to face an obstacle in the sense of RTS Art 32(3). If the TPP’s regulator recognises that, they must be allowed access via the bank’s user interfaces until that API is sufficiently improved – even if it was granted an exemption by the bank’s regulator, maybe because no other TPP had problems with it so far. Such obstacles will disappear (by definition), if and when a bank brings their API really at par with its user interfaces and then I am looking forward to even bigger and better premium APIs that go beyond that PSD2-stipulated baseline.