Martin Kuppinger - Findings from a Recent KuppingerCole Study on PSD2 Readiness

I wanna start with showing some of the results of a survey we just published today, I think, or maybe yesterday, which we realized as a survey incorporation with PWC, which was around innovation and disruption, light of the revised European payment services directive. So what we particularly looked at or asked for was at what, what level of preparation are the various layers, which are affected by the PSD two regulation. So goes through some of these numbers. And I think it's interesting to look at some of this.

So what are general information security investment plans in the context of PSD, two strong customer communication, API security, KYC, customer identity management, a little bit about the sample, and then finally some recommendations for them. So when we look ask for the, the investment plans, so I picked four areas here, strong house indication. It looks like by far, most of the organizations plan to invest interest strong education, which is doesn't come to a surprise.

I would say when it comes to other areas such as API security management is to serve the certain number here, it looks quite different. So it's below 60%. If we go back to what we talked about yesterday, it's mandatory to expose interfaces, but obviously it's also mandatory to secure interfaces. So in that area, it looks worse. I think they're full study, which by the way, looks far better than my slide deck is available for download for you. So you might go to the layout survey instead, fraud monitoring, maybe not that high because a lot of organizations already have something in place.

We also ask for five grade access control, which I think becomes more and more important, particularly also the light of GDPR, which is also another regulation coming up. So with the privacy directive, more privacy regulation, we, we are facing things like constant for purpose. So very granular ly news rights also of privacy data and other things become more important. So overall it's in most areas, Cybertron authentication the numbers aren't overly high regarding the current investment land. And so that's something which, which shows up in other areas as well.

So when we ask for authentication technologies that are available to customers or which are land, what is clear, yes, user name, password is something we still find a lot. It's still a very common way to do it, or be another knowledge based approach. So the red color says is lace greens says nets that gray or whatever it is says, nots scope. The adults are more bland.

So some didn't answer various aspects, but overall it shows it's still very much, I would say the standard approach is plus some OTP software out of band, SMS, primarily and other things, and that's space, which we find really hardware and very, very rarely any biometric field. So it's, I should I phrase it, it's very much old school authentication given what we need in future. Yes.

There's, there's some second factor stuff in here, but I think we are all aware that hardware OTPs won't be the solution obviously enough because the cost of logistics, all the problems associated with deploying hardware, OTPs to customers at large scale are far to pick. That's also, I would say very old school at the end of the day. It doesn't make sense in certain areas internally cetera, but at large scale deployment externally. So what we see some interest in biometrics. So there's a number of, we say saying we, we plan it or we wrote it out. So fi is really sort of on the watch list.

So to speak land later. So organizations are looking at at least one six of the organizations, more or less, it's looking at five Alliance standards, but still the numbers are relatively low. We also looked at manufactory risk based that's authentication. And when we, when we discussed this, so I think that's when we did survey, it was before the, the changes in the requirements came last week. So right now it's that you could say, okay, I have risk based indications, last one factor.

But even then when we look at what is in place, some sort of manufac factor indication is in lace, at least according to what the respondent said, FARs was risk based ation. Interestingly. So we also have a split between the various types of the ASPs PIs piece, etcetera, even though we look at only the banks, It's Not that we have a 70 or 80 or a hundred percent ratio here, unfortunately, that really adaptive authentication, which is flexible regarding authentication, which is flexible regarding the risk based aspect Is Still very rarely found.

And So what these numbers show is that we Given That we don't have that much time until PSB two becomes Effective, That we have a Gap Between what is Required and what is Already there. So obviously there's a strong need for organizations to invest in That area because the sort Of, okay, there's some multifactor which might be sufficient in some cases, not at all. So we had this discussion about out of ban ASMs and Whether It's weld or not yesterday. So Even that Number might be So even the ones who claim they have mal factor authentication.

If we Had the numbers, we don't have it in that detail, Having A multifactor, a indication place, which is PSD Two compliant, the numbers probably are Significantly Lower Because yes, we had, we acceptable the charge around, out of bad. That means we have a need to invest.

And simply as that, most organizations are where they should be when it comes to this strong customer authentication requirements of PSD two that's I think Very simple fact, and without Telling too much about an like slides, that's Something which is sort of the, the ongoing or the, The recurring scene of these results. It's I think it's not really surprising. We had the discussion yesterday about The Changes in our organizational change or the reluctance of organizations to change. And I think it's the typical situation.

It's trying to ignore these things until it's more or less late and done moving into or switching into panic mode And then Doing something to be compliant, Usually at Spending too much For that compared to a well planned Rollout and ending up with something which frequently is not the best solution you could have Achieved for that money is spent Standards in place. It's a bit, little bit broader here than view. We have so very unknown Uma, which is important in the context of GDPR.

So that general data protection regulation Uma is a standard which allows user management access it's called Richard allows to control access to for instance, the personal data fiber Alliance standards. I think that's a little bit optimistic, probably tools have some tools have support, but I have to say most of the tool vendors are very ignore regarding fiber. Even the vendors in the adapt authentication space. Many of them don't yet have support for vital land centers.

Vital land standards are interesting because you have a standard way to interact between a device with biometrics or also with other types of strong indication, necessarily biometrics in while this is the main focus and the backend system.

So it makes a lot of sense, because for instance, you could support different biometrics of different types of mobile phones in the standardized way, instead of adapting to Samsung or whatever that one or that one, the one that burns in the others or to Microsoft or whoever else is in the space, you can't do it via or clearly the, the most important since again, it's not where, where you should be providing APIs. 60% says we don't provide 60%, six hours times we don't provide publicly accessible APIs yet even while there are some in which don't need to, to do it.

When we look at the banks, I think so when I, I look at the detailed data for the banks, it's even a little verse, so it's more or less one out of three banks claims that they already provide interfaces. That might be partially to some lack of knowledge, the numbers, what really is provided. But overall, obviously when we come to et, I think there's lines, well, the numbers we had around API security, when we look at it, that part, which is, I think maybe the most complex part.

So occasional, if you're honest, it costs money, but it's not a rocket science to sort of, I would say, okay, yeah, we add some authentication technology. There are sufficient vendors available. When we look at the API part, then it's about how do, how can we do this? We have the core, it, we have to need to build another sort of layer around it, where we have to more agile things. We have to expose APIs. And for the third parties, it's, there's so much architecture, there's so much complex security.

So if you really look at the security challenges, when you want to provide secure and scalable and metal security also run performance, etc issues, when you want to provide secure and scalable access for third parties, which then at the end, go down to your core systems because it's account information, where is the account information found It's found in your core it systems. So At the end of the day, it's, it's really interesting. These systems might run on, on your mainframe still. Sometimes that's, That's the case.

And even if, if it's not a mainframe, it might be Core Banking system, Which is Maybe not the, the most well architected when it comes to APIs and, and, and end to end security in combination with other systems. So It's extremely Challenging.

And, and I did one or two advisories around sort of architecture at that space. And Let's phrase it like this. The intellectually, most challenging Projects Are defining end to end author authorization architecture in a, in this heterogeneous world.

So I, I know no few Areas which are as complex as these, so it's not nothing you can do just, oh, I plug it in and it runs, if you do want to do it well compliant, not only then that you need to. So there's, yes, there's the regulation that you need to expose these interfaces, but there are all the other regulations. If you go back to our standard finance regulations, which are around access governance, You need to Keep these in mind as well.

When that becomes really complex from the entire Architecture Saying, we are not really prepared, it's a problem Because If you're listing it more or less, if you start now, I would say it's probably Already too late To do it well. So What is provided access to some other, so bank account information. Okay.

We, we have to be correct. It's it's not, not all banks, which we had in here. So these numbers are, are, are showing It in general. So transactions around 40% bank account information Look below 30%, but it's, it's aligned. So to speak with, with the number of banks, I would say other customer data, et cetera, but it still shows that there obviously are Yeah, Still some gaps. And I think it's important that that every layer starts to think about the way he wants to deal with APIs.

So one of the other questions I'm rather fast today, How Does the organization currently handle initial Custom Right identification? The simple answer is That's particular banks, or It's also offline, online. So online only are 8.9%. I Remember the second key note of yesterday was the customer expectations, Which was held by.

So I, I would say if, if I look at a customer expectations, probably I could remove the dots. It would be pretty precise in the number. So maybe 89% would expect to do it online and 80 dot 9% Implemented Have it implemented so that that's obvious gap. So I understand the regulations. I understand the challenges around that, but I've Just recently a conversation was one of the players in the video event, Which Hegar conversations with depart, where, where the regulators accept certain forms of let's say more modern, authentication, more convenient at the end of the day.

It's not about being modern or not. At the end of the day, it's about Being user friendly. It's about doing what the customer expect, because at the end, as I've said yesterday, multiple times, the customers who brings the money. So Ideally you do what the customer Wants. And I think that's probably one of the biggest challenges that we don't have, or that many layers don't Sufficiently Take the perspective of their Customers. And we Had an interesting discussion yesterday also about, do we, do we really know Sort Of hard numbers? What The customers expect?

I Think we all have A have a Feeling because we are all customers, Some might be more New school or modern. Some might be more old school Like me, But anyway, so we have some expectations here. And I think it's very clear that even If Their expectations are not that High, they are rarely mad. So yet we have a need, We have a need for change here. And I think what, what becomes very clear if, and if you read through the entire survey, if you look at the numbers, I think it's, it's very clear.

We have a, we are facing a situation and if you would take thousand or 2000 organizations, the numbers might change A little. So we are Close to 100, but I think the, the that's Changed. The tendency is There are gaps with respect To strong customers, indication With respect to APIs and versus respect To KYC. First two aspects are the main aspects Of PSD two at the end of the day, or with other words, Most layers Affected By PSD. Two Are not well prepared yet. Clearly all of you are, but obviously there are many others out there who aren't.

Yeah, no, I've heard that some of you are from the, for bank podcast in Germany. I know at least the folks bank in time as a customer and I Don't have yet, I don't yet have the impression that they are Perfectly well prepared. I might Be accurate, But as, as I've told him, it's very, for me as a customer for of very small folks bank, because I trust mail to My account manager and he does What I Want. So that might be not very compliant, but it works very well. Okay. So lemme look at the people who, who respondent.

So we had, I think, a very good distribution across various levels. So from sea level, which might not know the details perfectly will Mention Directors, directors down to broker and project managers or engineers, Analyst, people working concretely in the activities. So I think it's a very good share or very good distribution across the various top levels truck titles, which is always a little bit hard to, to standardize. And because depending on the organization, same truck title might mean something totally different people.

I have been involved so they could, can be involved in various areas. So clearly many were involved in identity access and information, security information technology, but also model half We're Actively involved in the digital innovation part, Where It come. And this is where, where it's about, how do I react on all these changes are, how do I use the new opportunities or how do I defend myself, better use the opportunities. So I think it overall, the numbers provide a very good Picture of the current state Show that we have to Change some things.

So, so based on that, we, we ended up with four main recommendations. The one that support adapt for authentication. I talked about this yesterday a lot, and I think this is a very important aspect here. So you might need to move to manufacturers authentication. You might try to survive with one factor plus risk based at least for the next, for another 18 months or so. Another 18 months after the, the regulations become effective.

But if you also want to serve a customer, well, then you should retake into account that your customer wants to use the device of choice that he wants to use and approach which, which is convenient to him. And that, that the days where you said, this is the only way to authenticate to my services, but these days are passed. This is really thinking of the history. You shouldn't do it that way anymore. You should accept that for total reasons. One is already custom convinced the, is all these ongoing changes in a way technologies and accept technologies.

So what is considered being secure, not, and taking this into account means you have to move from my perspective to adapt to Alation, which also have to then mitigating risk of fraud. Because if you are flexible enough, you know, you can easily react. If one sort brought up the RSA secured incident six years ago. So if this happens and you haven't adapt to authentication system in place by configuration, you can for instance, say, okay, I need another pin, another pass raise.

Or so as an additional level of security, at least on the fly, more or less instead of saying, okay, I need another six or 12 months to roll out. You say RSA secure ID tokens, or to change to another mechanism. So look up, try to get a flexibility. The other point obviously is share, manage and secure your APIs. So if you, if you're in scope, you need to, so this is the a PS, blah, blah, always hard to keep.

So they, they really did a good job in finding abbreviations. No one can keep in mind with this regulation, but at the end, if you scope to provide APIs to certain parties, you have to do. And I think the one thing is really the call for action to the banking industry to talked about, yes, they are working on standardizing it. And I think it would be very helpful to have standardized APIs.

By the way, if you are consumer of APIs, the other side hasn't standardized yet Until you start consuming, then build your own interface first, which sort of remains stable For where you then Go to proprietary phases of the various banks. So build Also our Architecture here. So what you need at the end of the day is you need an centralized approach where you understand which APIs do we expose, how do we manage them? How can we scale them? How can we all the things around API security management we need To do and how Do we secure them? So what are the very security levels?

I think we will have another presentation by Sean, Where he looks more in detail on the technical element Insecurity That I think it's the one of the afternoon sessions. So Where we look at, what else do we need aside of the specialized API security to, but we need something we need to expose APIs And we need to have to write to you should Revisit your custom identification. So make it easier. There are new technology available.

Yes, that's more a pioneer Thing. But if you really look at it for, from a perspective of a customer, I'll think you definitely should make it easier to do that. You need to align forces. And this is, I think maybe this is The biggest challenge and definitely it's the first thing. At the end of the day, you need to do build a team, build leadership team consisting of the business people, the internal audit and the it experts. So it's not an it challenge. It's Not a digital innovation, blah, blah, blah challenge.

However, you, you framed that Team. It's not an pure business problem. You need to bring different people on the same table in the same room. And we Had a lot of talks yesterday, to which massive Extent, for instance, the PSD Requirements for opening up Interfaces Affect the business models. So From an it perspective, you can able Everything or closed out everything. But the Business model decisions need To be made on a lot of, at another place.

And, and maybe Sometimes the, the, it, people have A pretty good understanding of what is the potential impact Of it. So it It's a conversation You need to have Between the various people.

The, it experts, it, security Experts, your audit people, Your innovation, people, All the others. If You want to meet a deadline, you need to start acting now and you need to work on a work as a team of people that is an isolated initiative in certain areas of your organization. So that's it for my end to give you some numbers. I think there's the results align very well. So they were at that big surprise to me, but they aligned well was I think what we've discussed yesterday and what we first discussed.