Urs Zurbuchen - Revised Payment Service Directive: Understanding Its Technical Requirements for a Smooth and Secure Customer Experience

Good morning. I always find it fascinating me as a Swiss. And non-lawyer speaking about the EU directive, PSD two.

Well, there are some technical sides to it. So we speak to that. Don't speak about the, the law stuff.

Cetera, as you all know, the two main aspects of PSC two are access to account given to third parties. And also obviously the strong customer authentication, which is now required when accessing your, your account.

Well, the farmer requires the lab and for the farmer, you have several options. And most of them actually, they focus obviously on the banking side, on the transactions, on how you integrate with your backends, et cetera. There are several options. As I mentioned, for example, the open banking API, which came out of the UK, which is actually required in UK to be implemented, then there's the Berlin group, probably all the, of them better than I do, which also has just published an API.

There is obviously Ts in, in Germany, which will go into that direction, provide the, the functionality of access to account for third parties. But none of them really address the authentication party. So that is led up to, well, at least to the bank, just for, to, for my interest. How many of you represen banks? So just a few, all the rest of you are for FinTech parties, et cetera. Is that right? Mostly. Okay. My presentation is more from the view of the bank right now because the bank has to do the, the strong customer authentication stuff.

They have to implement the gifted possibility for access to account. The most of the challenges are from their side right now, but there obviously are a few challenges for, for the third parties as well.

And we, we get to them historically, a user accessed his bank account through the web interface that the bank provided the evacing application. And now with PST two, there is this new methods, the access to account giving third parties, the ability to access that information and present it to the user.

So the, the third party basically takes over the, the UI and it can aggregate information over several different banks, etcetera, some functionality, which is very good for some customers. But I mean, we already had that before. Think about software.com software. So they all data kind of, they, they initiated payments through their own interface with the banks, but what they did was they used, or app used the web interface using screen scraping. Now with PST two screen scraping is prohibited. They're no longer allowed to do that. The reason for that, I, I don't really know.

And also, sorry, a call with me from Switzerland. So, but what there is already, there is a discussion going on, went on between the European banking authority and the European commission about that screen scraping stuff, because the European commission wanted to retain the possibility of screen skating because that for, for fintechs and providers makes it much easier to access the banks because they already have it in place today. And the European banking authority didn't want that, but in the end, there is kind of a prohibition in the regulation, but there is kind of a fallback.

If the API does not really work, et cetera, then third parties are allowed or the regulators are allowed to open up the possibility of screen strategy. But for the moment, assume screen strategy is no longer allowed. That means we need this kind of dedicated interface. Usually it's an API, obviously there's a lot. It makes a lot sense to have something like that. But if you do that, the user accesses, the third party, the third party in the name of the user of the customer accesses the back, we need some way to involve the user in that transaction.

So the user really can give the permission for the third party to access that account. And that's where the strong authentication comes in into play. And we looked at the few options that we have there, how that can, can be implemented.

First, we have something called embedded strong customer authentication. I have heard that.

Well, maybe you can explain it to me in, in, in the breaks during the breaks. I have heard that several third party providers really prefer that option and I don't get it because there are so many problems involved with it. First off. Yeah.

Grounded, you get the UI. So it's integrated in your own application and it's it's yeah, it's, it's, it's kind of, it looks like one single piece, but I mean, for years, the financial industry has campaigned against users, customers providing their banking, credentials on other websites than their banks. And now what you're asking them is exactly doing that. So that's the first nature hurdle that you have to overcome. If you want to do that, basically what you need to implement is end to end encryption of the credentials or at least the password.

So if the password is then passed through the third party provided through the bank, that the third party provider cannot encrypt. It cannot have a look at it. Doesn't get, because you see in, in, in PST two, the bank has an obligation to protect against man in the middle. And this is exactly man in the middle. So you have to, you have to work against that, by the way, for the third party, there is also a challenge because I mean, we have strong customer authentication and there are several different mechanisms to do that.

And if you control the UI, you have to give the possibility or the ability, or you have to have that UI for all these different mechanisms. Be that flickering, be that any town be that photo to be that whatever different mechanism there is out there, and you have to do that for all the banks you want to integrate. And if the bank changes something, you have to adapt your application to follow that, though.

It's, as I said, I don't really get it. Finally, there is in PSC two, there is the requirement that you have a binding between the strong authentication and the payment data. So if you have to authenticate for, for a payment, that payment data must be visible to the user. And usually if, if you work, we can see that in, in two slides, if you work with tokens, cetera, and that information must be included in the token now here, because I mean, you need to have a channel to the end user to present that data to him.

And again, you need to protect against man in the middle and you don't really have as a bank. You don't really half a direct channel. So the only option you do you have here is that somehow you communicate that data during authentication on an encrypted channel to the user, which then gets decrypted on the customers browser or in the customers, browser and display to the user. The next option is called decoupled.

So there's, it is really, there is nothing time, these kinds of, of, of communications together, except that if the third party accesses the bank, the bank initiates the strong customer authentication. So, but because there is no communication between the bank that you, you know, the browser is communicating with the third party. You have application, there is no interaction with the bank at that moment, but the bank can employ something like a push mechanism, for example, would be, yeah, that would be an example.

But we come to that later, then send the push information, push mechanism to the user to do that. The user requires a smartphone. So this mechanism only works if the customers have smartphones or devices that work like smartphones. Okay. Personally, I, I like that scheme because its too, there is no man in the middle and there is only communication between the customer and the bank directly. So the customer gets that push push mechanism, push commissioner, and then can sorry, can react directly to the bank and say, okay, yes, this is correct.

I try to initiate that payment or allowed a third party to get access to my bank account. There's a third option. Basically.

I, I thought when, when they designed PST two, the RTS, etcetera, they were thinking about this one, it's an internet standard behind it. Some people call it delegated strong customer authentication. The standard behind it is all of two invented some years ago by Facebook now in place and several, several different, big social web applications. What happens is when the third party tries to access the bank, the bank either denies the access because it's not authorized or the third party automatically knows.

Yeah, I don't have authorization and redirects the user to the bank. So the browser then directly communicates to the bank. The problem, obviously here is the UI address because the bank takes over the UI at that moment. It also has a positive aspect in that the user sees, oh, I'm communicating with the bank.

So I'm allowed to enter my usable credentials, etcetera, when, during that authentication where the bank can really employ all that strong authentication that, that it wants to, you have a step called consenting where the user is, the bank provides information about what the third party wants to do, access that account or initiate a payment. And that information can be displayed to the user. And the user really says, okay, I want to do that.

Kind of like some transaction side that has been in place in Germany for years where you get the information on the second channel, okay, you want to initiate a payment to that person, know this amount. And then you say, yes, that's the code I got, I confirm by entry code. So it's very similar to that. And then you integrate that information into the token, send it to the third party. The third party presents the token to the bank and the panel can verify all that. It's a very nice third one. There are some issues with that first, all of really is marked what's the second one.

The standard really doesn't provide for what you're trying to do here, because what happens is you use so called dynamics codes, scope, being the mechanism for all RS to require permission to request the permission they, the standard are defined, has to be prescribed in the configuration. So they're not very dynamic, but if you want payment data that be implemented or you need to be integrated, it has to be dynamic somehow.

So you you're kind of extending it in a nonstandard way and extending security protocols on its own, whereby your own is not always the smart I smartest, I, it can work, but as far as I know, nobody has ever really on a security basis trying to find out if that's what happens. If you do that, what happens if you have dynamic scopes also, usually to, okay. Yeah. Usually if, if you do that, you have a very tight integration with the business side of the bank, the, the banking application and the authentication system have to work very tightly together. That might pose a problem.

When you have a larger strategy of, of implementing a Porwal for example, and you want to, to have that authentication system for all new functionality, not just for PS two, two, or e-banking etcetera foremost, but that implies a little bit also to the other strong authentications mechanism account selection. Usually what you have is you have a user account that user account, a user, I'm a logging name, kind of customer number with credentials. And that gives you access to several different accounts.

Now, if you allow that using all of then the third party presents that token, how would the bank know which account he wants to access? Because that token basic is you access to all accounts. And you want to make sure that you, that you don't do that at least in banks do so you must implement something. Some mechanism in the content stack to select the account that is token really applies by the way, there is an alternative to, to open ID connect, by the way, open banking API to one in the UK, they rely on open ID connect, not on off, okay.

There are some, some additional challenges, user experience, TST two plays much more focus on security and on experience. And that has to be overcome.

Somehow, as Martin mentioned before users, don't like strong authentication. It's it's just cumbersome. So what you can do is you can work with something like risk based authentication, where you apply your risk function and then determine, well, you need strong, authentic, or doesn't. You can have something called adaptive authentication, but you also mentioned L the should choose if can, the ability to select between different strong authentication mechanisms, the one which most, which, which he most like, and for the pop push time, there is issue for the push side.

Most easy would be to use for that, send an SMS with the code. Now, there is a requirement in PSD two, which says that on a smartphone, there is seeking of a push message, has to be completely separated from every other application on that. And because SMS is completely integrated into the system and especially on Android can be received by any app you have on that, on that device, there is no separation. So basically that means anytime is dead. You're not allowed to use it anymore with PST tool. As I said, I'm not a lawyer. So there might be some disagreement of that.

But if you read through, through the PSD two documentation, it can be integrated like that the, that leaves you, or at least depends with a lot of challenges in, in technical side, just to close with an ad, what we do and what we help our customers with is implementing different strategy, different technologies for to, to, to support all, all these communications. You, you see the nuances that these are the banking applications and on the bottom, you have your infrastructure, the servers, the network, et cetera.

And what we kind of supply is a service in the middle, which provides the security services, the strong authentication, the handling of the APIs, the security of the APIs. We don't do the APIs, but the security of all that. So if you are interested in that, my friends are outside. I will be here today. I can answer your questions. And I have, we have customer of our, who be to have presentation board. They also did with this kind of infrastructure. I think it takes place 11 o'clock in the next room.