an article from the Tink’s blog
Ultimately, everyone involved in this march to September – banks and third parties alike – is in the business of meeting the needs of customers. And yet, they could be forgotten if the majority of banks’ PSD2 APIs continue to offer just one authentication flow – the dreaded web redirect. It’s a method that kills innovation, destroys the customer experience, and could threaten the success of this open banking movement in which we’ve all invested so heavily.
The web redirect issue has everything to do with the ways in which a user experiences a service. In a nutshell, it is the authentication flow the banks choose to support in their APIs and that users have to go through when giving third parties access to their accounts, as well as permission to initiate payments on their behalf.
It’s an important part of the requirements for Strong Customer Authentication (SCA) under PSD2 – or two-factor authentication – a measure that aims to create a safer payment experience for the customer.
There are a few different authentication flows that can be used in a bank’s PSD2 API. In our analysis of bank APIs, we have seen that web redirect is by far the most common – and by far the worst.
It imposes major limitations in terms of the services third parties can build on top of it. And a majority of banks are implementing it in a way that adds a seemingly innumerable amount of non-mobile-friendly screens for the user to click through. The more steps a user has to complete, the more likely they are to drop out of the process.
There are three other flows that can be used – embedded or de-coupled and app-to-app redirect. These flows usually require fewer steps and users encounter less friction. Here’s an example of a typical app-to-app flow for a customer connecting their accounts at one bank to a third-party app.
It’s the flow that users prefer by a landslide. It’s the flow required for UK banks by the Open Banking Implementation Entity (OBIE). It’s a flow that is technically possible for all banks and several bank APIs are already using it.
But the vast majority of banks in Europe are instead using the web redirect flow. Here’s how that translates for a user completing the same action as the image above illustrates.
When the user clicks ‘connect’ so their third-party app can gather their financial data from one bank, the API forces their smartphone to open a web browser (think: Safari or Chrome). The user then has to complete a number of unnecessary steps before manually re-opening the third-party app to get back to where they started.
And they will have to repeat this process for every bank account they connect. Many of the flows we’ve seen look like the one above. And as bad as this flow is, it gets worse.
Below is a real web-redirect flow used by a Tier 1 bank in Sweden that has requested an exemption from providing a safety net for their PSD2 API.
It’s terrible. It has 17 steps. It takes four minutes to complete. There are a number of unnecessary “warning” screens. And we don’t know why.
What’s worse: this is the user journey to connect two accounts at just one bank. And since most users have accounts at more than one bank, they will have to repeat this process for each one. Or choose not to.
Today, we offer our customers the same authentication flows as the mobile banking apps. And PSD2 states that third parties should have a way of accessing financial data – with a customer’s consent – that is equivalent to the mobile banking experience for the user.
Two weeks ago, the EBA doubled down on this part of the directive in a major clarification on the redirect question – and their opinion was quite clear.
They say the authentication flows in the APIs “should not involve additional steps” than when the customer authenticates themselves with the bank directly. In other words, a customer using a third-party service should authenticate themselves using the same credentials and methods they normally use to access their bank accounts. For example, if they use FaceID in the bank’s mobile app, that should be the method with a third-party service too.
But in our effort to evaluate and integrate with the banks’ APIs, we’ve tested out dozens of authentication flows. We’ve counted the clicks and taps in these journeys. And in our assessment of the banks’ sandbox environments, we’ve found that about 65% are offering web redirect as their only authentication flow.
It’s not an authentication method they would use in their own channels. And it’s been challenged by third parties since the day it was invented.
For PSD2 and open banking to succeed, banks need to offer a choice. Otherwise they are creating obstacles that are in direct violation of the regulation – and the spirit of the law.
What’s chilling about the web redirect is how it could erode the customer experience, and limit the ability of third parties to innovate and push the needle of progress to offer vastly better financial services than what is possible today. And banks should not get to limit or restrict third-party innovation.
Third parties like Tink, Klarna, Trustly and more have built successful businesses on improving the customer experience in one way or another. But if we’re forced to suddenly impose this overly complicated and friction-filled flow on our users, it will upend the competitive landscape, eliminate any competitive advantage and remove choice for consumers.
The issue now is that we’re just one month away from the deadline. So the urgency to raise this issue and advocate that we as an industry do something to remedy it has reached a fever pitch.
There are three key reasons why web redirect cannot be the only solution on offer – and they’re all pretty terrifying.
Let’s say you have an Amazon Alexa virtual assistant. And you say “Alexa, please transfer €100 into my kid’s savings account.” She can’t help you. Because Alexa doesn’t have a web browser.
Now imagine that you’re paying for a tank of gas, and you want to directly initiate a payment for it from your bank account. You can’t. Because point of sale systems don’t have web browsers.
There are innumerable examples like these about how web redirect could kill any possibility for third parties to offer a new and exciting generation of financial services – or to innovate and design new types of customer interfaces.
Third parties won’t be able to offer services on any device that isn’t a computer, tablet or smartphone. Forget ‘the internet of things’. Forget smooth checkout. Forget smartwatch payments. In these cases, redirection is not just an obstacle – it kills the innovation by creating a total roadblock.
This reason is the subject of much (tense) back and forth about web redirect. And it’s because it’s subjective. There are no rules that quantify just how many screens or steps are too many – and kill the customer journey. But for us, it’s common sense.
In this day and age, customers are used to smooth and fully native experiences – mostly in apps. Actions can be completed in seconds, they use biometric authentication, and the interface is intuitive.
Web redirect essentially sends users back to the internet stone ages.
It triggers an unnecessary amount of extra steps, slows down the process, and even creates suspicion that the action is a phishing attempt – because no service in 2019 would require this. Users have to manually input credentials like usernames, passwords and pin codes – and they’re largely not willing to put in all of this extra work and time.
The result is an abandonment of the process of asking a third-party app to do something on their behalf. And it puts the user adoption of new services like aggregation and payment initiation in jeopardy.
But more than this, if customers don’t embrace these changes – rather rejecting them by abandoning services because the experience is too time consuming and arduous – then the promise of PSD2 is lost. There will not be increased competition or better services. Because third parties who aim to offer those better experiences will be blocked from doing so.
Third parties have largely succeeded because they offer incredible customer experiences – ones that exceed the high expectations that consumers have. For the banks’ part, they are building world-class mobile experiences with biometric authentication and seamless payments.
We’re both doing the same thing – so why would that change? Especially when PSD2 states that it shouldn’t. The banks’ users and third parties’ users are one in the same. As such, they should have the same experience with any service they choose.
Except they don’t. The consequences for third parties are obvious – they will lose the ability to attract users with convenience, a great experience and innovative services.
It starts with European banks moving in the direction of supporting authentication flows beyond just web redirect. Third parties aren’t against web redirect as such – it works just fine for many. But web redirect can’t be the only option.
There needs to be choice, and through healthy competition we can let users choose which one to use. The ultimate aim is to support users with an experience that is friendly, and mimics what they’re used to in the mobile channel.
The goal of any third party offering financial services is to create a better, more seamless experience for users than what is currently available – and to pioneer new ways for people to manage and interact with their money. Ways even we have yet to imagine.
But in order to do that, we need to be allowed to innovate and design a user journey that’s not dependent on the banks. Otherwise, it doesn’t matter what kind of interface we provide. Because when it comes time for a user to interact with the bank, web redirect will break the journey.
Banking 4.0 – „how was the experience for you”
„So many people are coming here to Bucharest, people that I see and interact on linkedin and now I get the change to meet them in person. It was like being to the Football World Cup but this was the World Cup on linkedin in payments and open banking.”
Many more interesting quotes in the video below:
