Good morning and good afternoon. This is John Tolbert from co or cold. Thank you for joining our webinar today, which is sponsored by Ergon airlock. Today. We have Dr. Martin, Berkhart the director of product management from airlock to join us on the webinar about the revised payment service directive. And we're gonna take a little bit deeper, look at the technical requirements to make it a smoother and more secure customer experience.
So a little bit about us Cooper and Cole was founded in 2004. We're an independent Analyst firm offering advice and research to our clients. We support both end user organizations, software vendors, system integrators, lots of different types of companies and organizations with both tactical and strategic advice. We're specialized in information and cybersecurity identity and access management, access governance, GRC, and really anything around the digital transformation, including IOT. Our three major business areas are research. We provide reports on products, product comparisons, subject overviews, comparisons of different markets. The research is vendor neutral. We're always current stay on top of the latest developments. We also have events like this very webinar. We also have conferences. We'll show you a couple of those upcoming ones here in a second, which are really good networking opportunities for professionals in industry. And lastly, we do advisory, which is sort of a high level consulting, helping both software vendors and end user organizations come up with technical roadmaps to meet their customer needs as well as regulatory obligations.
So our next events are consumer identity world. We started this this year in, in Seattle and the next one will be in Paris on November 28th and 29th. It's a good opportunity to come out and learn about consumer identity management systems. And we'll be talking a little bit about that in the webinar today as well, that will be followed by another one in Singapore, December 13th and 14th. And then on this topic around PSD two, we have digital finance world in Frankfurt on February 28th, March 1st. And our flagship event is the European identity and cloud conference, which is in mid-May in mid may, in Munich. So I hope you can join us for some of those events for advisory. One of the services we offer are readiness assessments, and these are comprehensive evaluations of the technical capabilities compared to the requirements in say, in this case for GDPR, the privacy regulation that takes effect next may. This includes things like a, a comprehensive analysis of the technical requirements, the technical infrastructure that an organization has today finding the gaps and then making recommendations to, to solve any problems that arise there. We also do these for PSD two.
So for the webinar itself, everyone is muted. We'll control the mute, unmute features. The webinar is being recorded. It should be available on the website tomorrow. We will have Q and a at the end. There's a, a box on the side here of the go to meeting, where if you have questions anytime during the webinar, you can type those in and we'll address them at the end. So I'll start off giving a little bit of background on how it all started and what the high level technical requirements are. And then I'll turn it over to Dr. Behar from airlock to talk about how airlock can help meet some of those requirements. And then we'll do the Q and a at the end.
So what's the motivation for PSD two, the revised payment service directive. It's an update to the original payment service directive that I think came out around 2005. And it's really about empowering consumers by helping to lower the prices associated with making transfers. And then also protecting consumers in terms of improving the safety and security of making such transfers or interacting with financial service providers. And to do that. PSD two introduces some new concepts and new types of businesses that increase competition in the financial field. And then also this is sort of a follow on to some of the work that's been done in the single Euro payments area.
So payment server, the, our revised payment service directive goes into effect in January, the regulatory technical specifications, those detail, or provide a bit more detail on what needs to happen at the technical level to make PSD two a reality. Those will probably go into effect somewhere in late 2018, early 2019. Some of the work is still ongoing. There are standards efforts that will talk about particularly around APIs that are still being defined at the moment. PSD two defines a new class of business called third party providers of which there are two major ones, account initiation, service providers or AISP and payment initiation, service providers, or PSPS. And they, they do pretty much what they sound like getting account information or initiating payments and thinking about it, you know, banks or other financial institutions have mostly been the ones providing these kinds of services in the past, but in the desire to increase competition to lower payment services fees, new businesses will be getting into this line of work. So it could actually come from totally different kinds of businesses. Maybe merchants themselves will see an incentive for, excuse me, getting into the payment initiation side. So yeah, there'll definitely be more competition arising, but in order to make these things happen, trust frameworks are gonna have to be put in place between banks and all these different third party providers. A bit more on that in a minute.
So at a very high level, the PSD two technical requirements can be broken out into a couple of major areas. There's strong customer authentication and the API requirements. And fortunately they define strong customer authentication in sort of a standard way that we have an information security for years. And that's choosing between two of the, the three factors of it's either something, you know, something you have or something you are.
And then that can be mitigated by performing what they call transactional risk analysis on each transaction. So that as it's currently stands, you need a, at least a strong customer authentication event every 90 days that can be augmented by transactional risk analysis and then popping up additional authentication if needed on the API side, the AISP and PSPS need to be able to get information from banks or other financial institutions, such as, you know, a list of accounts, what the balances are, what kinds of transaction types are supported. And in addition to providing the direct API access, these APIs have to be secured. So there's that need for federated trust for authenticating both the connections from third party providers to the banks, authorizing that, and then doing the same at the client level too. And then there's an additional set of layers around network security that need to be put in place to secure those APIs as well.
So on the strong authentication side, something, you know, again, it could be password or knowledge base authentication, you know, answering certain security questions. Neither one of those two methods are very secure and, and they're not actually all that user friendly on the something you have side, you know, that kind of ranges from at the strong end smart cards, USB tokens to other kinds of tokens and mobile apps. And then there's the something you are partnered biometrics thinking everyone's probably familiar with fingerprint face ID is making the news these days. That's another facial recognition technique, Iris voice recognition, and then behavioral biometrics. They're a little bit different. It's generally based on the use of smartphones. You know, how you hold, use the phone swipe, where you go with it. So those kinds of factors can be taken into account and evaluated to determine whether or not the system believes you're the person you say you are so strong. Customer authentications always required accept in cases where transactions are, are pretty small, like under 30 euros. If it's a, you know, a remote kiosk, maybe at a parking garage or at the train station, or as mentioned before, where you have the ability to do this transactional risk analysis. And here I'm thinking like user behavioral analytics or risk adaptive authentication, we'll dive into some of the details on that in a minute.
So strong authentication options. We have smart cards, you know, at the top end advantages there, you know, there there's supported by many OSS. There's lots of hardware readers out there that can do SSO. And even the newer cards are even contactless. But the reality is unless bank, for some reasons already issued a smart card. They're probably not gonna undertake a smart card project just for PSD too, which I think leads to broader adoption of different kinds of mobile authentication technologies, such as what we might call mobile push apps. And you may be familiar with those today. If you're doing online banking where you, you start a transaction, you know, via your browser on your computer, but then if it's a high dollar transaction, you might get a popup on your phone saying, you know, push to accept or swipe to authorize the payment.
The biometric modalities that I mentioned a minute ago are, are also increasingly available on smartphones. And the phyto Alliance is an organization, which is standardizing the interaction between mobile phone and backend servers. So the, the good news there is there's many different kinds of authentication modules. And thanks to standardization, you can sort of swap out what you want and choose from the modalities that best suit your, your business needs. And I like to think of Fido was sort of like PKI public key infrastructure without the eye. It's still based on private public key cryptography, but doesn't necessarily require a certificate authority. And it allows you to build pair wise, one application to another relying party application connection. And then in some countries, there's the possibility of using your mobile or your electronic national ID on the mobile phone. So it's like getting your smart card on a phone.
And those are generally protected with a higher degree of security using things like secure enclave on iOS or secure elements and trusted execution environment on Android for the transactional risk analysis. I think of this in terms of risk based analytics. This is really, you know, at the time of the, an evaluation of different kinds of factors, both user attributes or environmental or other external risk factors and the policies that govern this need to be both static and then dynamic being able to take into account. Some of those environmental factors, many of the risk engines are fed by three different kinds of intelligence. Cyber threat intelligence is, you know, known bad IP address ranges that are updated by various sources, compromised credential intelligence, many social IDPs share information between each other about if an account or credential's been used or has been compromised. And then also fraud intelligence where people track different types of fraud activities, and then can alert the, the banks in this case to be on the lookout for patterns of potential abuse, by certain accounts, the risk factors start with IP address, for example, and from that you can derive geolocation, geo velocity.
Some people call this impossible journey. If somebody logs in, in Austria, they can't physically log in in Australia an hour later. So you can prevent that. Then things like time of day, day of the week, device ID pretty straightforward devices generally come with an ID, but the fingerprint can be, you know, sort of a look at all the installed software or drivers. And coming up with hash of that. One of the lesser known parts of PSD two is that end user devices need to be free of malware. So being able to provide an indicator like a health assessment saying that you've got antivirus installed and it's up to date would be an indicator that you might wanna evaluate in policy. Then different kinds of user attributes in the history, sophisticated risks engines can evaluate not only what the current request context is, but also compare that to patterns in the past locations, transaction amounts, things like that.
And then again, the compromise credentials or fraud indicator checks to build the policies. Administrators need to be able to select the attributes from the data that they have. You may not want to include every attribute and every policy decision, but there are certain ones that are important for certain kinds of transactions. And for those you wanna be able to set thresholds or required minimums. You need to be able to run that at every transaction request and it may need to trigger additional, you know, step authentication. And then let's say you, don't all the information you need. If you have five attributes and you can only get four bits of information, you can, in a default consumer identity systems can help comply with PSD two as well. They're a little bit different than traditional identity management systems. They start with user self-registration many times they allow the use of social network logins rather than collecting all the information up front.
They do what they call progressive profiling. And then on the GDPR side, they generally allow for pretty extensive consent collection and management and auditing. They can collect user history that can be fed into the risk analysis engine, and they provide lots of different authentication options depending on the vendor or the service provider on the API side banks today have lots of different kinds of it infrastructure all the way from mainframes to, you know, web tier for online banking. But most really don't have the kinds of APIs in place to allow these third party providers to have the direct connection and make the requests about getting account information or whatnot. So banks, if they're not doing that today, really need to begin this as soon as possible because it's, it's probably not gonna be an easy journey from here to there.
So I just wanna give a quick look at some of the work that's going on by the open banking project. You can see these are restful APIs that both the account information, service providers and payment information service providers will use on the payment information service provider side, it's mostly around posting being able to create a transaction request, create a challenge, sign the challenge on the account information side. It's just what you would think, you know, getting the accounts per user per bank, what kinds of transaction types are supported by the bank or, or allowed to the account.
So, you know, there's much more detail here. Open bank is working on it right now as is Berlin group working on standardizing APIs for PS two. But in addition to building the APIs, you really have to think about the security side and it starts from the outside in, you need to protect against distributed denial of service attacks with traditional or NextGen firewalls or using a, a network service provider. There's the web application, firewall, API security, and then looking for known threats and preventing them probably should also have a load balancer. And then you know, more about what the web application firewall needs to do. It needs to validate the trust between the third party provider and the bank, and then also authenticate each connection and authorize the, the content as well as looking through the content to make sure it's not, it doesn't contain, you know, any known web service layer attacks.
So wanted to give a quick graphic showing again, you know, from the outside in everything from the, the user, the payment service user on the left has to have some endpoint security going through the third party provider systems, hitting the bank edge, making sure that the bank's not gonna succumb to a denial of service attack, but also getting information input from the cyber threat intelligence providers to eliminate serious connections at the gateway, going through the, the network balancing to the web application, firewall, cleaning up that traffic, making sure that each connection is authenticated and authorized and trusted before passing it on the application layer. And then the underlying core banking functions in the banking infrastructure.
So to wrap up here, there's a lot of material PSD, two S gonna drive a lot of changes, but I think really it's gonna revolutionize European finance. And, and this will be a very good thing. It's promoting competition. It's going to require banks to modernize their authentication, perhaps modernize other parts of their infrastructure. Scalability will need to be a factor. I'm sure there'll be an increased load. Banks will increasingly have to use consumer identity management to gain a competitive advantage. Considering the fact that TPPs will probably be trying to erode some of the traditional customer base there. And then of course, APIs have to be built and secured. And lastly, because of the changes, you know, there is a high risk of fraud and, and even failure if these aren't implemented correctly, that's why I strongly recommend that banks begin readiness assessment now to prepare for PST two. And with that, I'd like to turn it over to Dr. Burkhart from airlock.
Okay. Hello from my side. Thanks a lot, John, for the introduction into PSC two requirements. So I'd like to first say something about airlock. So Ello is an application security suite developed by Agon informatic. We are located in Switzerland and have roughly 20 years of experience in this field. So together with the software development projects in Agon, we, we started in the nineties when the first online banking systems were actually published and collecting from this evidence. Actually the first, first versions of, of these products that we're talking about now were created. So today we have a, a very strong customer base in the financial industry also because we are partnering with many banking software vendors, such as, or logics fi Nova S.
So my talk will be about three main topics we have already heard about these requirements and, and the first part of the talk. So consumer IM or as I call it customer IM actually both terms are news. We have an entire ebook on the topic together with our partners, promo and Vasco. So you can download it from, from our website, but I will only touch the, the self service topic actually. So there's much more to say about that, but I'd like to refer you to the, to the ebook for a complete overview. So first I'd like to, to outline how traditional IM workflows are are used. So when you think about workforce, I am, then you have users top they're usually your, your employees. So that's kind of internal users and you have help desk and user administrators at the bottom that perform lots of administrative tasks around managing these profiles.
And typically a user experience is just logging in to the system. Maybe the user needs to change the password or not, and then it works. And at some point it's a log again. So if, if anything regarding this account, is it entity or access rights needs to be changed? The he probably issues a ticket, or he, he makes a phone call if he forgets his password, if he moves and has a new address, if the account is locked, if he needs access to a new application, if he wants to have, I don't know his, his mobile phone for authentication, he needs to talk to the guys below to the user admin staff. So that's all nice. But if you want to, to address your entire consumer base, and if you want to actually get them to user services from the internet, then I think you need to do something to scale.
So that's where user self services come into into the play. So we actually offer lots of basic modules where users can manage their data themselves, talking about password reset. For instance, there's studies around that say, typically users forget around 1.8 times in a year, their password. So if you assume certain costs involved for a support call, say, I don't know, 20 euros. If you have 1 million consumers or customers using your service that makes already 36 million euros a year only for handling password resets. So that's the cost side. So you can save quite some money. If you delegate this work to the users. If they have an online form where they can click on a link, maybe they just an email address and they can help themselves as if they're moving. There's no need to have a, a help desk call to change the address. If you have a self service in place, other topic, sign on self registration, if you have some authentication means some token that needs to be activated, or if you have a new type of token needs to be migrated, there's a possibility to automate all these workflows.
And now you may say, okay, but how about usability? If, if users need to work all the time, will they, will. They like them? And actually we have to make the experience that yes, they do like it because they get an instant service delivery. They don't need to, they don't need to keep track on a, on a ticket. They know don't need to answer questions. They don't have to, to call back. So they have a problem. They want access and they can solve, they can solve it instantly. So actually from the usability side, it's, it's even conceived as being positive. And of course, as I said, you can reduce your help desk staff. And, and at the same time you can grow your user base. So that's the kind of the fundamental requirement for being able to scale into the consumer base.
But of course, scalability is not, is not the only requirement that you would have for such a consumer IM system. As I said, usability is very important because you don't have to, you don't get to train these users, right? For user admins in your, in your company, you can, you can gather them for four hours and then teach them how the system works and tell them what to do when something unexpected happens. But for the, the users using using these self services over the internet, you only have a first first chance if they don't get it, they, they will, they will be lost. So usability concerns have to be really wait more. Of course you need support for identity Federation protocols and social logins. So it's, it's not that you can just assume that that all the users have locked into your central windows login and you're active directory infrastructure security is of course a concern because you're exposing very sensitive, very sensitive data here to, to the user in the browser.
So it's not like an internal network that's trusted and you have a secure connection internally. And of course these self services need to be able to present themselves well on, on mobile phones, on, on tablets, on desktop PCs. So responsiveness of, of the interface is very important and not all users are the same. So you need to be very flexible in terms of second factors that they want to use each user. One's a different one, maybe, or just select some of them that you have provisioned. And also in terms of workflows, you need to be more flexible because the user base is just more heterogeneous. And usually you want to integrate these services in, in some Porwal or services that you already have. So it's important to know that they have technical interfaces, for instance, rest APIs that you can use for integrating them.
Okay, let's go to the second topic, strong customer authentication. So we have built in lots of authentication means to do strong authentication. We also have commercial solutions from Vasco and Cobi in token management. So you have really an all in one solution here. And as I said, it's important to be able to assign tokens individually to users. So one may, may want to use S challenges. Another one wants to use this, this two Deb barcodes, or he wants to use some, some USB stick. And of course around these tokens, several registration and management processes are required. Some activation process may even require to send letter to a user. All of this is already included here and regarding identity Federation, we are supporting SAML oof, and open ID connect. Then especially with our commercial partners, we have the mobile app solutions that support push, push notifications, and also transaction signing.
And as I will outline later, we have risk based and step up authentication, possibility options inside. So when we talk about this PSD two, the, the, the central trust framework looks like this. You have a bank on the right side, which actually owns the transactions. And now we have on the left side, the customer that wants to, that wants to be able to include a trusted third party, right? This is the payments or accounts initiation service provider. And, and what happens here is actually well covered by oof, the protocol, which separates the authentication process from a resource access. So the actually the, the, the third party wants to access some resource on banking, API, like an account balance, or it wants to register a payment, but it doesn't have the authorization to do that. So it requests access from the user, which authenticates against the, the bank and gives an access token to the third party and using this access token, the third party can then do what it wants to do in the name of the user. And the nice thing about it is that the authentication credentials are only sent to the bank, and they're not given to third parties. As we have seen in the past where these third parties actually created review for username and password to log it into the banking banking account.
So one downside here is that, that you don't actually have a link to transaction information here. So you would just give the third party access to your account, but then the bank can actually trigger a transaction signing request. So if a payment was registered and the bank
And the bank thinks, okay, I need the validation on this. As we've seen, the requirements are very strong. You actually always need to do strong authentication, but there's some options for, for relaxing these requirements. If you have very transactions under 30 euros, or if you have a thorough risk analysis performed for instance, but there, you can actually make a link between transaction content, for instance, the amount or a beneficiary and a direct content from the user, which is also authenticated, because you can usually display certain information. I would say, I got this transaction, or you it's going 700 euros going to somewhere, is this okay for you? And there you can make the link that requires some kind of push functionality on the user side
Has been talked about risk based adaptive authentication. We also have solution for this. You have plenty of attributes, contextual information from the user session on the web application, firewall from authentication history, or you can even include the fraud score. If you want. You can determine whether the access is from an internal IP range or from external range, whether it's coming from Europe, north America, Africa, wherever you want. And you can, you can feed these information pieces into a risk policy that then says, okay, if the login is from an internal network, you don't need a second step factor, or yeah, you can just, or if you see, or remember me cookie, for instance, the session is considered to be weekly authenticated already. And only if you're navigating to some sensitive area, then you will be confronted with a, with the next second step login. That's also sometimes referred to as a step up authentication. You may have a weak authentication level. And if you want to access something more sensitive than you are asked to give a stronger authentication,
Okay, that's already going to API security. So first and most important only because something is called an API, it does not mean that you have to, it doesn't mean that you're secure, right? So I'm sure you're familiar with the OS top 10 vulnerability list. I've searched for a new version here. The last public versions, actually from 2013. And I found that there's a release candidate out now for 2017. It's not officially published yet, but I mean, the most striking thing is that not much has changed four years have passed and still injection attacks are on top. And you have broken authentication. You have crossed that scripting of all these familiar topics, and there's, there's some, some new elements here, for instance, a seven insufficient attack protection. It actually says you need a way to detect in the first, the first step lock and respond and even block or react to ongoing attacks.
So that's actually a perfect, perfect fit for web application file here. So even though you may say my service is secure because I, I do secure development and I control all the internal processes. This one makes it actually clear that even though you might be secure, you want to be able to detect, to lock, to aggregate information about ongoing attacks and be able to respond. And in case there's something new coming up, you want to be, you want to deploy virtual patches outside your application. And a 10 is a new point here actually mentioning APIs. So is say modern applications are, are typically based on a lot of, lots of JavaScript in a browser and some type of, of API in the backend. And these APIs tend to contain numerous vulnerabilities. So I'm just saying APIs, exposing APIs. That's the same as publishing traditional web application to the internet. You need a solid baseline security,
But then if you go beyond this baseline security and, and that's very interesting for PSG too. Now, they actually require you to publish an API, right? And I've taken an exam request here from the open bank project. It's rest call that allows you to create, create a transaction. And it has a bank ID in here. It has an account number, has a value in the currency and some type of common description. And so when you, when you post this request through our web application, firewall, what you can do is actually extract rules from this call, which are then enforced. So this would, would, would be the list of, of suggested rules that you could enforce. For instance, it detected here the account that to be a UU ID parameter. And if you accept that suggestion, then the F will always for future future requests, it will, it will ensure and enforce that nothing else, nothing other than a valid U ID can be submitted in this account ID field. So there you just with one, with one click, you closed any, any options to, to do injection or, or any other type of attack on this field. And if you're feeling fine, maybe if you have a trusted IP range, that's using the API and internal testing team or something, you can even go and accept all of these suggests and suggestions in, in one, in one click.
Okay? So this is actually nice. If, if you don't know the API, right, you, you can have policy learning and you can detect the API, but really nice would actually be if the API would document itself. So there's actually one API regarding open banking. So it's, it's a UK standard. It provides swagger or open API as it's now called specifications for download. So if you decide to, to deploy this type of API, then the w could actually go there, read this form of specification and without the need for learning, it would know what to do. And it, it would enable a very high security because it has strong and tight wide list rules. As we see here in an example, so it is very nicely detailed. So of course security's only strongest the specification, right? If the spec specification always says, oh, the field is a string and it may be up to 1000 characters long, then it it's not worth much, but this type of specifications that are written now are very, very nice. It's very tied to what is actually required and not more. And it's also interesting from a, from a dev secs point of view, because you then no longer need to manage all these rules on a web. If you update your service specifications, updated, and automatically with that, you will be able to also update enforcement on the web.
So this enforcement, if, if you have a specification or if you're learning rules, that's discovering the static API of, of a, of some of a service, right? But a feature that we have available since about one and a half years, and we call it dynamic value endorsement, it goes even a step further. It says we are observing values in a user transaction that are proposed by the API side. And we are trying to enforce these values back when, when external third parties or users actually file transactions. So to illustrate this here, if you make a call to the banking API to retrieve the, the bad, the accounts of a user, for instance, then using dive it's, it's possible to have like a pool of these endorsed account numbers on the web. It's tied to the user session. And when the user, either through a web interface or through some, I don't know, mobile phone API client, and he meets a transaction involving these account numbers, then the web can actually match the used account numbers against the endorsed account numbers. And that's even stronger, even more tight type of security policy because you can enforce on the web. The, the user is only using accounts that he is entitled to see on the, on the banking API.
Okay. So I'm, I'm wrapping up here summarizing. I think PST two is a very nice example that demonstrate that it's important to have security filtering component and also an identity and access management component in your security stack, because it's because you need to publish APIs and you need to do that securely, and you need to enforce strong authentication. So you, you need both of these components to holistically address PST two. But what we are saying is don't just use it for PST two, because if you externalize these services in your architecture, all applications can actually profit profit from that. And if you, and if you deploy new services, this will reduce time to market and also minimize risk because there's, there's a lot of problems that you have solved a lot of standards that you have set. And yeah, it's just a smaller type of project if you're hooking up to an existing security infrastructure. Okay. So my presentation is finished. So I think now we're gonna have time for the Q and a session, right.
So, yeah, we've got a couple of questions here. We can start with, if payment services are detached from banks, how do banks do fraud detection, Martin, would you like to address that?
Yes. That's a very interesting question. And I mean, even today, trying to think about fraud detection today, what can you do? Right. And I even have a slide on that, but it did make it into the end of presentation. Let me look for that. I think it's yeah. Right. It's here. So we have actually integrated IBM trust here, pinpoint that fraud detection solution. It knows all the bank, Trent and behavioral patterns of these TRO,
Sorry. So what you can do is, is to, to, to include this security pinpoint solution on the web, and it will, it will follow the data on, on the, on the client. So in the we front, and it will run JavaScript logic there and, and score a session record that score in, in, in a cloud service and the web retreats to score. So you can actually rely on this core on the web to trigger actions saying, okay, we see there's aro and detected. So you can either notify the backing application or you can even block requests. And of course you have lots of, of session metadata that you can, that you can include.
And also you have metadata from the authentication channel, right. You know, how things are authenticated and what we have done for some customers in a, in an additional machine learning project is that we integrated all this different type of data in a, in a fraud detection solution, which you see on the, on the lower left bottom here, the strength of this comes from combining the, the technical information that you get from the session from authentication, from trust, your pinpoint information and from banking information, right? You have your traditional fraud detection system, you have money, new lists, and you have, I don't know, risk scores for, for certain accounts or for certain customers. And you can actually combine all of this different dimensional data and, and have a very, very strong next level machine learning based fraud detection solution, which you can also, through the eBanking application, you can feed back into the, the we layer and trigger actions there. If you see that you're above a certain score, you want to terminate the transaction and where even when, so far that we lost the account in, in IM. So you can very nicely integrate and, and have different actions on different levels here. So I think that approach works just as well, if you're publishing an API. And if you know, information about the user authentication that occurs for transactions on this API.
Okay. Very good. PSD two has strong authentication requirements. How do we keep the usability high?
So I think, I mean, one, one very important ingredient is, is to have these user staff services, right? And of course, single sign on in it in general is a very important usability feature. So if all the users have now, I don't know, I don't know how that will work out, but if, if users have lots of accounts in different banks and they work together with different service providers, they want to have the single sign on experience. They don't want to be back on square one and having 20 different credentials for different service providers and banks. Right? So it's important to have kind of a, a Porwal view for the, for the user where, where all the services are, are presented in a nice and consistent way and using single sign on. And of course, depending on transactional risk, you can, you can do you, you can maybe cancel the second authentication step. That's what we saw. And yeah, I think also push notifications are very important. If, if transactions are, are ed on the bank, then users want to know immediately that something is happening.
Yeah. You know, I think that that's probably too where some of the opportunities for the TPPs comes into play. The, you know, companies may wanna build apps that aggregate account information from a variety of banks. So, you know, value add will be, you know, providing that security, providing that single sign on experience between, you know, multiple banks or multiple parties. What I had a follow on question to that, then for you, Martin, what trends are you seeing amongst customers in the financial industry or types of authentication that they accept, or what are their customers asking, or in terms of customer authentication methods,
We, we see lots of mobile app solutions and use. Now, our banks are kind of moving towards mobile app solutions, but we still have customers that use traditional authentication means like matrix cards, for instance. But yes, I mean, SMS challenges are also very popular, but it it's, it's rather something that you want to, you want to replace. Now, if you're, if you're, if you're replying a new type of service, you're usually then not, not having this as an only option and passwords are still widely used. So the dream of having passwordless authentication, I think still has to, has to come.
Yeah, that's very true. I've been hearing people talking about wanting to get rid of passwords for more than a decade, but, you know, we all use them every single day, so there's a lot more work to be done there,
But yeah, you know, I'm kind of hopeful that things like biometrics or mobile authentication becomes more accepted. Obviously there are still, you know, some security issues that need to be worked out. And in fact, that was in the news this week too. But, you know, addressing that usability question, I think, you know, mobile is, is definitely something that people want to use. More of people do see it as a sort of a ubiquitous second factor. So why not use that instead of needing to haves and hundreds of passwords? Well, I had another follow up question. I just wanted to pose there about the risk based policies. So in the financial world, what are examples of some of the attributes that let's say a banking customer might want to evaluate per transaction? I mean, I'm guessing that, you know, the transaction amount is probably something that's really important, but you listed out various factors that you, you can evaluate too. Do you know what the customers are mostly utilizing in those policies today?
What is very popular is to kind of find out whether the, the locking situation is normal, whatever that means. So if you have a history of logging of logging attempts or success login attempts, and you see that the time of the day is the same and you see origining countries the same, or even IP network is the same. And you even know the browser, maybe you recognize the cookie that you have placed, or you see it's the same type of OS and browser combination. So that's a very nice indication that everything's okay. So there's another session that's high checked and accessing from, from a, from an attacker, right. And also of course, on the, on the data side, if the transaction's filed, you know, there's, there's certain white listing rules in place. If you have sent date money to an account before, and you have not complained about that, and it's probably fine to do it in other times. So that's some very high level types of, of risk based policies,
Right? Well, you know, that, that brings up another point then too, you know, in addition to PSD two, which we were talking about today, the customer identity management system can also help with things like, know your customer, both the conceptual version of know your customer, as well as, you know, the, the regulatory know your customer aspect.
Yes. So one topic there it's it's how do you combine the, the know your customer requirements with, with social logins? Right? So we see a bit, we see banks are hesitating to deploy social login functionality because they know if they actually, if they actually have a contract with the, with the user, that's not going, going to be enough, right. If you're, if you're linking your identity to Mickey mouse, then you probably, you're probably not. You're not compliant with no your customer regulations. So at some point there's a, an onboarding process that needs to be triggered that allows you to, to do all you need to do in order to, to know your customer. Really,
Ryan,
Do you have another question that popped up here? It's how clear are the technical requirements for PSD two becoming I heard that batch transactions could not be signed together. Is that true? I, I think there's, there is definitely work ongoing in this area in several fronts. The RTS are still being looked at. Then there are these different, let's say API standardization efforts, like open bank and Berlin group. I, I, I think the reason it's hard to say exactly when RTS will go into effect is because there, there is a bit more work to do. And I don't think everything that has been, or that could be standardized has been standardized. And there's probably going to be things that may never be specified in detail. Martin, would you like to add anything about that?
Yeah. I, I don't know the details of the, the ongoing technical specifications, so it's, I actually don't know.
Okay. What stands
For here? So,
Well, I know that for instance, like open bank, they, I believe about a month from now, they're supposed to have a, a live version out there. So the RTS work, I know there was some pushback let's say on like the, the screen scraping piece. And then of course there was pushback to the pushback on, you know, whether or not to allow that. So I think there, I, I think there's still some debate ongoing and we will keep track of that and, and update the client base as information becomes available. Okay. Once all the questions I have for now, I think thanks for your participation. Glad everyone could attend and any parting comments, Martin.
No. I'd like to thank you all for attending. And if you have questions, don't hesitate contacting us. Of course. So thank you.
And thanks to everyone. The, this should be available tomorrow is recording and thanks for your help, Martin. And this concludes our broadcast.
