PSD2 has been a tremendous undertaking; with tight deadlines and unclear expectations, an entire industry made up of disparate parts and with entirely different ways of working has had to come together to make this change a reality.
Banks have had to venture into a new technological landscape well outside their wheelhouse, and quickly become experts at providing APIs. Big pan-European third parties like Tink have spent thousands of hours working with banks to integrate with hundreds of APIs that don’t meet the standards we would normally expect.
But behind the big company logos and impersonal pronouns are just people – thousands of them who have spent the better part of a year working to make PSD2 a reality and preparing for a smooth transition to the APIs. We don’t want these momentous efforts to be forgotten in the black and whiteness of compliance.
We’ve been very vocal about the challenges we’ve faced with the web redirect authentication flow and the need for all banks to provide an API safety net. But this is your behind the scenes look at how a PSD2 army inside Tink – made up of over 110 engineering and product experts in three countries – has tackled some of the other challenges.
And how they’re battling through to meet the September deadline.
Challenge #1: Thousands of interpretations = one big mess
To many, the race to the final PSD2 deadline on 14th September has felt a bit like being forced to run a marathon for which you haven’t prepared or trained – and *whoops*, there goes the gun. Off we go.
The European Banking Authority’s interpretation of PSD2 has been vague; they’ve guided the banks with what the API and security elements need to support, but not how to support it.
Essentially, the banks have been told they need to build a bridge – except they’ve never seen one before.
This lack of preparation and clear expectations has been a pervasive and ubiquitous challenge since we began our PSD2 integration work in February.
The list of challenges are a mile long: not having an EBA directory of developer portals, incomplete API documentation that’s also in the local language, and missing or mocked authentication flows that don’t let us test our connections and more.
Without a clear definition of what’s expected, everyone involved – banks and third parties alike – have been trying their best to interpret what to provide. And when you add up thousands of those interpretations, what you get is a big old mess.
Challenge #2: Google, please help
Surprisingly, one of our biggest challenges was actually finding the developer portals so we could start integrating with the APIs. In so many cases, they were not publicly listed or proactively provided by the banks.
So we Googled it.
Yes, when tasked with finding something that’s hidden quite well, Google does what it says on the tin. Without a clear and central directory of open API developer portals, we sourced the info ourselves using keywords like ‘PSD2 developer portal’ or ‘open banking (Bank A)’.
In some cases, we were led to dead ends. Like integrating with an API that had a PSD2 endpoint but in the end wasn’t the actual PSD2 API for that bank. You live and learn.
Through searching (and calling, writing and texting the banks), we found all of the developer portals there are to find. But hat tip to Google for their help in our search.
Challenge #3: Try, try and try some more
The kinds of hurdles our engineers have faced – and the creative ways they’ve found to overcome them – have been the subject of many a lunchtime and coffee-machine chat.
And that story usually goes like this:
"I started integrating with an API and each call gave us a server error. After contacting the bank, I found out we needed to call them to approve every single call. This means that we make a connection, call the bank and wait for their approval – for every single request.”
To offer a bit of perspective, a well-made API takes two-to-four days to integrate with (including testing). But it has taken us around two weeks to get basic flows to start working. Being able to rely on them enough to take the APIs into production has taken months. Many, many months.
So our engineers have gotten creative, trying and testing their way to solutions that aren’t documented. And it has worked for a lot of challenges. But there are some that require help from the banks to solve.
And in the course of tackling these issues together, we’ve gotten pretty cosy with them. They know us by our first names – we talk on the phone, we text on WhatsApp, we email, we have workshops to troubleshoot. We even politely stalk people on LinkedIn to get help (when necessary).
Many banks have been reactive and responsive, offering fixes and collaboratively working with us to solve the challenges. And we’re on track despite the delays.
The PSD2 army keeps on marching
Despite the hurdles, we will integrate with more than 100 APIs that cover about 90% of the European population. There are only a couple of other third parties that get close to offering this kind of coverage. And it’s because of the people behind the scenes.
Within Tink, we’ve built a unique ecosystem to tackle integration. We have dozens of engineers – self-described PSD2 nerds – who have taken the challenges and turned them into knowledge that teammates use to solve issues.
Our engineering teams (with code names like: The Conquerors) have been working like crazy to find ways around the problems and collaborate with the banks to solve the issues. The problems we face have slowed us down to be sure, but we’re making progress.
We will cross that finish line in a month’s time – and keep going. The work to integrate with APIs that might come late will continue, and we’ll keep optimising the connections we already have.
It’s a process that has tested the entire industry. In the end, we’re all just people trying to do our best. It’s not always pretty – and certainly never easy – but the sheer human effort to make this monumental shift will be the reason for open banking’s ultimate success.