It's September 2019, let's go! The world of Open Banking starts today! Every fintech registered as a PSD2 Third-Party Provider (TPP) will be able to consume customers' banking data much more easily .... or ... slightly more easily 😅! In this article, we drive you through what happened in the mind of our developers working on bank connectors over the past 2 years. We acknowledge that the situation has dramatically improved but thought it would be useful to describe with humour the struggles we went through.
The beginning
All right, I want to connect to MetaBank! It is Sept 2019, MetaBank has to provide PSD2 connectivity.
First step: Google! https://letmegooglethat.com/?q=metabank+psd2+developer+portal
- The bank's developer portal is not listed.
- The bank's developer portal is listed 🎉 but the link leads to an "Under construction" page 😭
- There's a developer portal, but let's be clear, it's a pre-packaged documentation product barely filled in
- There's a developer portal and the bank even provided an API for self-onboarding... but it's not working 😢
Ok, we found it! It was tricky, unclear and we had to make some assumptions, but we finally found it! Let's see what it looks like.
Connectivity
Oh hurray! Banks followed basic and modern Internet standards and provided the most common semi-public type of connectivity: JSON APIs.
Thousands of banks in Europe, I'm ready! Let's hire 200 developers to build and maintain 1000 connector apps, each with its own implementation. Go!!!
Not so fast...
API "Standards"
All come with pretty good (or pretty bad) documentation, and OpenAPI definitions for what the bank should do. Cool 🤗
It is up to the bank to choose one of those new "standards" 👍 or to develop a custom interface themselves 👎.
ℹ️ Thank God 🎉, it's now 2021, and most banks did choose one of those standards.
France went with STET (oh yeah, they invented it), and the rest of Western Europe went with Berlin Group (my favorite! Deutsche Qualität_)
Let's onboard!
The bank put "something" live. Let's see how we can onboard... if we have to!
Let's remind everyone that PSD2 RTS specifies that it should be sufficient for a TPP to present a valid PSD2 authentication certificate (QWAC) to connect to a bank. Onboarding is not supposed to be required! But... ok, we understand that some technical setup may be necessary. Let's go!
Uh... did they forget to document it or what??
There's no information on onboarding, no API, no nothing!
Hmm... It won't be that easy.
Let's contact their support! If we can find a way to contact them 😑 Email, webform... That's not the first thing that you find on the portal. This requires a bit of effort. Our first support request takes many weeks to get an answer. Patience...
Oh! Some banks have an API to onboard, and it's even documented. Cool 😀 And it seems to follow the OAuth 2.0 Dynamic Client Registration Protocol. That's nice! Let's try! and fail. HTTP 500 Internal Server Error, HTTP 400 Bad request... Damn. I'm pretty sure that my onboarding code is ok though. Back to support.
Eventually, via API, Developer Portal or automatically, we are onboarded!
Customers authentication approach
The first step to getting access to customer data is to have the customer authorize access to the bank account. As PSD2 is defined to make things "safer", the customer will have to give explicit consent with the help of the bank. Let's go!
But no one wants to be required to store customers bank credentials. The customer would also prefer NOT TO share it with a new market player, and banks don't want their customer authentication credentials shared with a third party...
Best solution: OAuth2 3-legged (or OpenId Connect). That's nice! TPP can delegate the customer's authentication and authorization to the bank itself by redirecting the customers to their portal.
Unfortunately, the user experience provided by the bank's PSD2 Portal is a drama 😱
When there's an issue with authentication or authorization, the bank's feedback to the customer is awful. The bank won't explain that the customer is missing the required mandate or sufficient rights on the account to share the data.
Instead, it just fails with an unhelpful "Something went wrong" message and sends the customer to the TPP, implying that the TPP did something wrong.
Customers are now flocking to our support, even though they encountered an error on their bank's portal 😭.
Our obvious response: send them to their bank's customer help desk. They encountered the issue in the bank portal! Why should (or how could) the TPP take care of a bank issue?
Here's how the conversation goes:
Customer: "Hi, I want to share my account with a TPP"
Bank customer help desk:
- "This TPP not supported"
- "We don't know about this TPP, so it's probably not authorized"
- "Oh yes, tell the TPP that they need to register & consume our PSD2 API" (yeah, nice, we are already passed that stage) 😏
The customer comes back to our support 😭
Come on bank! Could you please get your help desk up to speed to give accurate answers to your own customers?!
Finally, it's "working"
Finally, the customer has authenticated and authorized the account data sharing with the TPP. Let's see what data we receive...
"Working"... Well it's not crashing too often, but the data quality is not great.
Why is that?? Having a look at "API Standard" documentation, it should be well structured!
Ok, Banks have been using IT for decades, since the 1960s and 1970s when they signed gigantic contracts with well-known players like IBM and HP. But that was 50 years ago. Things have evolved since then, but the banks' backends haven't!
They can't get rid of those same old mainframes that store transaction data in a non-structured, flat, unreadable, undocumented format.
But how do you expect a TPP to process this newly available data when it's a big raw block of flat and unstructured text?
How can the TPP decipher that the wire transfer was sent to Mr X, while his name is hidden somewhere in the middle of a bunch of seemingly random information? Banks may have "chosen" for an API standard (Berlin Group, STET etc), but that doesn't mean they followed the attribute specification.
Ok, we must admit that by the end of 2021, the banking interfaces have improved and we have positive interactions with most of their support teams.
We are here to improve the Open Banking world!
When facing a problem with customer authentication or data structure, we've decided to always go back to the bank and ask them improve their system. We do not consider it as our job to account for badly formatted bank data. We don't work around it and implement any "if bankA do this, if bankB do that" clauses in our codebase.
The world of Open Banking means offering
- Well-implemented interfaces, respecting Internet Standards
- Documented interfaces, with a corresponding implementation
- Usable data, which can be handled by machine-to-machine automation
We'll continue to advocate that! We've already helped dozens of banks to fix their implementation, publish improved documentation, or respect Internet Standards, and we will keep on trying!
