Hello. Good morning. Good afternoon. Today's webinar is about preparing for PSD two with strong customer authentication fraud, risk management in the open banking APIs. And I'm joined today by R SAS, Nathan close, and we'll be diving into this topic. So before we begin a little bit about us Cooper and Cole, we were founded in 2004. We're an independent Analyst organization with offices across the globe. We offer neutral advice and expertise and thought leadership. We support different kinds of companies, both end user organizations, corporate users, system integrators, and software vendors with both tactical and strategic objectives. We specialize in information security, cybersecurity, identity management, GRC, and, and really anything around the digital transformation topic.
We have three main business areas. The first is research. We try to stay current on all the topics in those fields that were just mentioned. Identity management cybersecurity, keep up with all the latest developments with the vendors, but we are vendor neutral. We stay current and we are able to offer independent advice, not beholden to any particular vendor. We also do events such as this webinar, but we do conferences and other kinds of special events. And at those events you'll find a lot of thought leaders. We try to provide really good, great networking opportunities for people to meet one another and meet the experts in the field. We also do advisory work and by this, I mean like short term consulting engagements for end user organizations, that might be something like helping with RFP or procurement short listing on the vendor side that usually pertains to doing roadmap validation and, and helping plan out product strategies.
So about our events, we have some events upcoming next week we will have here in Seattle, our third annual now consumer identity world. It's really focused on the special requirements around consumer identity, including some things like PST two, which we're gonna dive into. And then at the end of October, we'll do it in Amsterdam and middle of November, there'll be in Singapore. We also have a cybersecurity leadership summit, which will be November 12th through the 14th in Berlin and running at the same time as the, the cyber access summit. So about the webinar, everyone is muted. You don't have to mute or unmute yourself. We'll take care of that. We are recording the webinar and the recording should be available by tomorrow. We will have Q and a at the end, probably about 10 minutes. There's a questions blank in the control panel for go to webinar here. And you can enter questions that we can address at any time during the webinar.
So I will start off and talk about the background, the technical requirements around these specific topics, and then hand it over to Nathan. And then we will save the Q and a for the end. So thought a really good place to start would be, you know, what is PSD two? Why, why are we doing it? What are the motivations? So PSD two, the two implies there was a PSD one. So that sort of helped set the stage years ago for the single Euro payments area. And it was an attempt to, you know, make the payments market itself more efficient. PSD two will introduce a lot more efficiencies and a lot more consumer protection too. And the idea that it's creating different kinds of financial service entities, new players in the market should increase competition, ultimately lower prices for the consumers. And there are a lot of very interesting security provisions around PSD two that we'll dive into here. So on the whole, it looks to be a pretty good for the consumer of financial services in Europe.
PS, the directive itself went into effect in January, but the regulatory technical specifications or RTS will go into effect about a year from now in September of 2019. But in the meantime, testing has to begin in March of 2019. So that gives banks a third party providers, about six months to, to get things tested out. And there are two major kinds of third party providers, there's account information service providers, which will get information about accounts and then payment initiation service providers, which just like it sounds will be out there trying to initiate payments between different entities.
And in the past, both of these functions have really been performed by banks and clearing houses and, and other financial institutions like that. But the motivation again is to sort of promote competition from even new and nontraditional non-banking types of businesses. And for that to happen, there need to be different trust frameworks put into place so that banks will know which TPPs are, are certified and have the authority to operate within each jurisdiction. So there's lots and lots of different kinds of infrastructure pieces, including a trust framework and certification that will need to have to happen.
So a little bit more on the technical requirements here, strong customer authentication is something that is explicitly defined by PSD to, unfortunately it relies on sort of our common definition of strong authentication with at least two of the things below something, you know, something you have something you are, and, you know, that can be things like passwords, maybe a token or a biometric. And then it also allows for transactional risk analysis to hopefully obviate the need for a strong customer authentication event for each transaction. The other major requirement is that banks provide APIs for third party providers to use. And at a real high level that's about getting account information or information about the banks and supported transaction types, or actually initiating the transactions. So this will require a layer of API security with that federated trust that was hinting at a minute ago, as well as authentication and authorization and even network security between the API security layer at the bank. And third party providers secure strong customer authentication is, will always be required except for low value transactions, or maybe at places like remote payment, kiosks at parking lots, or say Buster train stations, or in cases where this transactional risk analysis has been performed sufficiently. This is where risk adaptive authentication solutions and user behavioral analytics solutions can come into play and help make for a better user experience.
So don't really want to use the term synonymously, but strong authentication, adaptive authentication, risk, adaptive authentication. There are a lot of functional overlaps in that area. And one of the main drivers, I think in getting an adaptive authentication solution is to be able to offer your consumers choices so that they can choose something hopefully better than password, better than knowledge based authentication. You know, there are other choices that are out there, smart cards and USB tokens. They're very strong authentication level of assurance, sorts of options, probably not ideally to the banking industry, but then there are also biometrics fingerprint readers. There's the ability to do social logins, maybe SMS OTP, even though that's been deprecated in some areas due to some security concerns. And there're also mobile apps, mobile push notifications, you know, push or swipe to accept sorts of authentication and authorization methods you've probably seen before.
So besides the offering authenticated choices, adaptive of authentication solutions typically also offer the ability to build and write policies, combining different kinds of scenarios so that you can select amongst a different set of categories of authenticators or authorization types. There's also the ability to integrate, consume and make decisions based upon threat or fraud intelligence from third party sources. This is increasingly important as a way to reduce fraud. Then there's a run time or transaction time risk analysis that actually takes place. These solutions often tie into identity governance or other life cycle management kinds of solutions. And it's really important that they integrate with security analytics or SIM security incident and event monitoring types of tools for more 360 degree view of all the different security events that may be taking place in an organization.
So looking at those strong authentication options, smart cards, you know, like I said, they've been around for a while. They're pretty widely supported. They integrate with most OSS and lots of single sign-on systems. And they're even newer varieties that use contactless cards, you know, that are, make it a more usable solution. But just like with the, the other token based kinds of authentication, it may not be incredibly practical for banks to be offering smart cards or USB tokens for their many thousands or millions of customers. That's why I think the mobile channel is gonna become more and more important. Mobile pushups adds that second channel. It's, you know, something that you have as well as being able to maybe enter a pin or a password, or do a biometric.
The thinking about mobile biometrics, you know, there are built in native capabilities within iOS and Android touch ID, face ID and, you know, Samsung fingerprint, that sort of thing that can be leveraged. They're also third party authenticator vendors that are using the phyto standard, which really it's a great standard for defining the interaction between, let's say the mobile device for authentication and a backend phyto authentication server. There's lots of different choices out there for different kinds of biometrics in that case, including things like Iris scanning and voice recognition. And I think of it as sort of PKI light, you don't necessarily need the, the certificate authority, but it, it, on the pH side, you know, it is an exchange of keys in a decentralized way. So it, that could actually increase privacy as well as security. Then there are also mobile IDs, essentially having a smart card on your smartphone. Those are not nearly as common, but I think that's a very interesting alternative. And we'll probably see more of that in the future too.
There's risk based analytics and try to drive, dive down a little bit on what we mean here on the, the use of the risk engine. That's taking a look at user attributes, environmental or transaction request context and other external risk factors. And in adaptive authentication solutions, administrators should have the ability to define both static and dynamic policies that could respond to changes in any of these kinds of risk factors. There's also a need to integrate, you know, cyber threat intelligence. And generally here, we're looking at things like addresses, URLs, domain, domain, generating algorithms, things that, you know, that might be trying to perpetrate fraud from known addresses, compromise credential intelligence. I think of this as like in API call to something like the, have I been PED service looking for credentials that, you know, have been compromised and are more likely to be used in, in fraudulent attempts and then also fraud intelligence itself, which is a little bit different in that it is an attempt to isolate patterns that may indicate fraudulent behavior, perhaps looking for signs of malware infection, or that maybe the user's device has been taken over by malware or, or as part of a botnet or something like that.
All of these different factors can be evaluated at runtime to determine whether or not a particular transaction should be able to go forward looking at some of the risk factors in more detail there's geolocation, you know, trying to tie that back to a specific IP address from which the request emanates geo velocity. We also think of that as impossible journey, you know, a user shouldn't be able to create a transaction request in Australia, and then an hour later do this, another transaction request from Austria. So we should be able to deny request, you know, just based on the geo velocity attribute time, day or week device ID, device fingerprint. Some vendors have really sophisticated ways of doing device fingerprinting that might take a look at, you know, what operating systems installed. What are the screen resolutions installed fonts, user agent, you know, add up, you know, maybe 20 or 30 different factors and hash it and call that the device fingerprint, then use that information to compare with every subsequent request transaction request that comes in.
There's also a health assessment can be done again, looking for signs of malware, you know, is it could the user's device be part of a bot if so, you know, reject that known compromise IP or network checks, various attributes about the user history of the user. It's really good to be able to build a baseline of what users have done in the past so that you can compare current and future transaction requests, you know, are there requests coming from reasonable locations? Does it fall within the parameters of past transaction amounts, determine whether or not they're on a new device or maybe a jail broken device. Many of the adaptive authentication solution providers will provide SDKs. And you can use that to build mobile applications that, that check whether or not a device is jail broken or rooted. There's that compromise credential check. I mentioned a minute ago and fraud indicator checks that could be factored into every risk score as well.
The policies, you know, you can, many of the solutions can evaluate, you know, a hundred, maybe in some cases, even 200 different factors. I don't think it's necessary to do that. That would be, you know, unnecessarily cumbersome policies, but, you know, you should be able to select the attributes that you are, think are important for your business and then set various thresholds or minimums and assign what the per transaction risk score needs to be above in order for a transaction to be able to go forward. The another really great thing about the adaptive authentication solutions is you can put in different set points. You know, if something's, let's say doesn't quite meet the go forward criteria, but it's pretty high. That's where you can require step up authentication. And, you know, maybe in certain cases, if you determine the risk score, just can't get above in unacceptable level, then you can do a default deny.
And then I use this flow chart as just a way to sort of show what the policies might look like. You know, if you start off with something like a smart card authentication event, you probably don't need to do any upgrade of authentication. But if you start with say user ID and password, and then a user tries to make a high value transaction, then certainly you're probably gonna want to try to step that up and maybe require, you know, one of three different kinds of authentication choices. In this example, I'm showing, you know, maybe use a, a mobile app authenticator as a second channel and step up. So there's lots of different permutations here. Social login, maybe even SMS OTP, even though it's been deprecated in many areas, people do still use it.
The API requirement banks have to create API layers. They have lots of it infrastructure already today. In many cases, it's really not accessible to the outside world through APIs. Some banks do the larger banks are, are definitely getting on board with this already. Many of the smaller regional banks don't have the API to core banking function interface ready today. So just a real quick look at what some of the open banking project APIs. Again, it's just looking at the different kinds of accounts and transactions being able to do this over arrest get or, and the case of starting a transaction, a post.
So to wrap up my part, I think PSD two is gonna have a huge impact on European finance. And I think it will be good. I mean, creating competition in the terms of these third party providers certainly will be very interesting and will really core authentication and authorization modernization across the financial sector, transactional risk analysis. You know, most banks are doing a form of this today, this explicitly calls it out and, and gives banks and other financial institutions real reason to upgrade and, and get the best transactional risk analysis tools that they can. The creation and securing of APIs is a huge task. And by opening up core banking functions through APIs, if banks don't do it right, then this actually increased the risk of fraud and, and failure. So I can't say enough about the importance of getting the piece done correctly and, and secured properly as well. So this point I'd like to turn it over to Nathan close of RSA.
Thanks, John. Okay. So just to quickly introduce myself, Nathan close, I represent the RSA fraud and risk intelligence division. I am responsible for technology, I guess, across the EMEA market segment. So particularly I'm talking to financial institutions daily about the impact of PSD two, what that means for strong customer authentication, transaction risk analysis and so on. But it's also interesting for me because I get different perspectives across different financial institutions in different regions of Europe. And I guess from RSA, we also have our data from our customers and we are looking at what our customers are doing. We are looking at the way financial institutions are migrating to PSD two compliance solutions. So I, I think I can show, share some insights from what I am seeing, but also provide some, some ideas about the way we see PSD two, the way we see customers starting to migrate and implement solutions towards PSD two compliance.
So I'm going start really by looking at what we see from our RSA anti Ford commander center. This is the group that's responsible for detecting and shutting down fishing and malware attacks and gathering intelligence from the underground. They see fishing continuing to grow, and of course it's not slowing down. And social media in particular is taken a, a very sort of recent over the last couple of years, a very sharp uptake in activity forces using social media forums. They're using other systems such as even things like WhatsApp and ways of communicating to each other in more open forums. And this is leading to increasing fraud in channels. In particular, for example, card not present. We seeing that to continually continually to grow and things like account takeover and tripling. We saw last year compared to 2016. And then of course, losses going to exceed 5 billion, new account fraud, 15 times more likely on new accounts.
And very interestingly, the amount of fraud that's coming from the mobile channel. This is, and a very significant part of that actually coming from mobile apps. So this is an interesting trend that's been happening over over the previous years as the web channel moves to the mobile channel for fraud, as users are moving to mobile, more, the forces are moving there as well. And this is, we can see data from our hosted customers, sort of aggregated globally. We can sort of see that the way that the consumers are interacting with the financial systems. And this is telling us a lot about the technology adoption they have and also their behaviors. So if we sort of take this data and other fraud base factors, the distribution we can see between the web, the mobile applications and the mobile browsers can be used as a baseline to understand where the fraud is happening.
As we saw in the first quarter of 2018, the mobile browsers, mobile apps, accounting for 55% of transactions. So the there's more happening in the mobile than it is happening in the web based channel. But if we extend that trend into the future where we're looking at a PSD two environment, we going to expect that the a I S P and PSP third party channels, we're going to take a share of that traffic, like the traditional channels, which we, where we see the mobile taking over from the web. We also expect that these a I S P and PSP channels will also be increasingly mobile. So it's a good perspective to think about that these new channels are going to be, I guess, impacting the amount of traffic that we see in the web and mobile channels that we have today, but that also reflects on the way we look at fraud.
So if we're looking at where the fraud is happening across, across RSA hosted customers globally, we can see that there's more fraud happening in the mobile channels. And it's growing over time in Q1 this year, mobile application, mobile browser transactions made up 65% of overall fraud. So as we think about the PSD two future, we can expect to continue to see the fraud in that mobile channel, but we should also expect to see fraud in the new a I S P and P I S P third party channels. And we should expect be expecting that to keep growing.
If we have a look at another perspective, the impact of PSD two through transaction volumes in the carbon present channel. So we are hearing that we need to expect a three to four times increase of 3d secure traffic as merchants and acquirers in the EU are being forced to authenticate card, not present transactions. So merchants acquires of the EU. They will not be mandated to authenticate transactions, so we can still expect some non authenticated transactions to remain. But from a fraud perspective, 3d secure traffic usually accounts only for a small fraction of the fraud compared to the non authenticated transactions. So as we move more transactions to the authenticated channel, this will help to reduce overall fraud in the card, not present environment.
And I guess to understand the authentication impact of PSD two, if we use some data from the card, not present channel, as an example, we can see what would happen based on the types of transactions. This is like the value of the, the typical values of transactions and the different types of qualified exemption thresholds. What becomes clear though, is the authentication choice is important. More authentications are resulting in more cost and more consumer friction. So for example, we have a, if we have a very high fraud rate, so we can see at the top there, the issuer would be needing to be sending 2 million extra authentications per month. And if, for example, that issuer was using SMS. If the SMSs will cost them 5 cents per SMS, they could actually equate up to a hundred thousand dollars per, per month in SMS fees. So I, I guess the important part here is the authentication choice, understanding how many more authentications that you might be needing to do based on whether you can comply for transactional risk analysis, what your exemption thresholds would be. And this helps us really understand what authentication choices we should be making and working out what the cost of those are going to be, and also understanding what the fridge is going to be for the consumer.
So I'm just going to on the topic of the authenticator choice itself, I thought it's important to mention how the interpretation of the PSD two differs between institutions and competent authorities, I guess, by extension of different countries. And using this example statement from the RTS article 4.1, it states how the successful authentication is based on two factors and should, should generate or shall result in the generation of an authentication code. So if you think maybe as an example of SMS where we're using sending an OTP via SMS, we have to be a little bit careful that the interpretation might be that that SMS OTP is not this code that's resulting in the generation. The OTP for SMS would be what is used to prove possession. So I think it's important to bear this in mind, that it's very important to understand what your institution's interpretation is of the PSD two, what your competent authorities interpretation of the PSD two is before or, and that can influence what the decisions are made about the technologies and the authentication authenticated choices.
So let's have a look at some examples. For example, SMS, SMS, we are hearing different countries in different institutions, having different opinions. In fact, some of them lobbying to be able to retain use of SMS. Now there's different arguments on both sides. For example, the possession one SMS, the way it works, we deliver an OTP code to a mobile subscription number. You can't actually prove that it was actually sent to a particular handset in the hands of that consumer there's particular attacks you might have heard about SS seven, for example, there's different redirects methods, you know, inception methods to copy OTPs malware on devices as well. So arguably there is some question marks about the possession factor, the knowledge and inherit factor. So the SMS on the actual device can be shown on lock screen. So you can't necessarily rely on the pins, the pin codes or the biometrics to unlock the device as a form of element for strong customer authentication. And also we've heard just recently from the EBA, the opinion about card data that cannot be used as a knowledge factor. So card issuers using SMS as a authentication factor have been now been forced to think about, okay, so we can't use SMS with card data as a knowledge factor. How do we do possession and knowledge in our card, not present authentication methods.
And it also from the confidentiality and integrity perspective, the actual data go going across the GSM network has been proven to not be very strong in its encryption methods. So there are definitely institutions who have looked at SMS and said, no, it's not strong enough for us to meet the confidentiality in integrity requirements from a Dyna dynamic linking perspective. Absolutely. We can generate an OTP code, which is unique and for the transaction amount and beneficiary. And we can show that data in the message. So from a dynamic linking perspective, it should be possible to use SMS from a logistics and user experience perspective. Certainly this is something that SMS is okay with, from a cost perspective, arguably sending lots of SMSs can add up, but comparing to other forms of authentication, SMS may be a cheap method to implement.
If we look at examples of the sort of traditional styles of tokens that I guess have been around for many years, very much proof of possession. So it's given that the consumer has a physical token in their hand, or they have a mobile app, which has been enrolled with some sort of seed and they can prove possession with, with that device or application knowledge is usually performed by entering a pin code into the mobile app, or they need to enter a PA a pin to complete a passcode with a sort of physical token. But the problem is that dynamic linking the dynamic linking part needs to be provided. Somehow else, these codes, these tokens are either time based or event based and not unique for individual transactions. And of course these tokens are not necessarily showing transaction data as part of the authentication process. Of course, the cost of these per consumer, when you've got many hundreds of thousands or millions of end users, then the cost of, and logistics of these is gets prohibitive. And from a user experience perspective, certainly if you leave that token at home or something like that, then you can't complete your transaction.
Having a look at another example, for example, a card reader. So this is where we can prove possession again, we've got the card reader, we're asserting the card. So this is something that the consumers definitely got in their hand from a knowledge perspective. Usually there's a pin number or something like that's used to authenticate the transaction from the perspective of dynamic linking. We can see transaction details on the screen, we're generating codes and entering codes on the device and back on the screen. But again, there's a cost to deploy these card readers to the consumers. There's logistics of that. And also the user experience. If they leave their card reader at home, they can't complete transactions on the go.
So this is why I guess a lot of focus has been on the mobile app. It provides that flexibility for the, as PSB or the institution to provide a form of strong customer authentication, which is tailored to their requirements. They can prove possession by requiring the app to have a seed and be specifically enrolled for a particular consumer. The consumers can use the biometrics that they have in available in the device. If, if I'm buying a particular type of device, which is providing me with a fingerprint reader, I want to use that particular device with that fingerprint reader. So you're giving the flexibility to the consumer to use the authenticator that they're bringing themselves. And they want to use from a knowledge perspective, those consumers that may not have the biometric hardware capabilities in their device. They can still use technology such as pins and passcodes to complete the strong customer authentication dynamic. Linking obviously the transaction details can be shown on the screen and after the successful authentication, the application can generate a authentication token and send it back to the banking application. So from a user experience, absolutely, this is something that I hear, the financial institutions are striving to apply for the majority of their consumers.
But of course the, the best experience is what, what, what we call no experience. This is what really, we are saying, the frictionless process of being able to have your activity, your transaction, and then just click submit. And in the background, all of the processes have happened to check. This is you, it looks low risk. Let's just allow this transaction to continue. But of course, we need to be able to qualify for this transaction risk analysis. It's critical for the consumer experience. They, as a user, you don't want to authenticate every time you're paying your rent or your electricity bill. You're paying the same amount each month from the same device, from the same location, same beneficiary, same amount. So this is really the best experience for the consumer to allow them to complete their transactions without the friction of that additional form of authentication.
However, when we are looking at whether we should be building a transaction risk analysis solution or not, I'm hearing different opinions from different organizations about, well, our fraud rates are too high. We don't think we'll comply for transaction risk analysis. So we're not going to build it. I'm in the position where I'm sort of saying, look, we don't really know what your fraud rates are going to be. Once you have implemented a PSD two solution, because there is many things which are subject to change. For example, we are building these new tools for transaction monitoring, according to the articles to 18. So they are providing a, perhaps a higher level of risk assessment of the activities that your consumers are using. We deploying new authenticators, stronger forms of authentications. So the consumers are, are using new methods, moving away from the older bingo cards and passwords.
We are moving to mobile apps ViaMetric and things like that. And in the card not present space, we shifting transactions into 3d secure. So more transactions are going to be authenticated. So many of these factors may actually reduce the fraud rates overall, arguably, there's going to be new transactions coming in these new third party channels, as it is today, we know that the, a PSPS are going to be forced to do their own risk analysis as well. But we also see this is a new channel for fraud. So this could actually also challenge the fraud rates as well.
So from the RSA perspective, I guess we are providing solutions and services across the entire user session from before they even hit the, hit the application as they go through their login, as they do their transactions and as they complete their activities. So from a for action perspective, we're looking at how users are being impacted by phishing and malware with detecting the phishing ML, where we're taking down the, the, those attack vectors. And we're providing our, our customers with intelligence from the dark web about compromise credentials, about card numbers and about details, which could impact the for, for your consumers. And then as we look at the other solutions, as they impact the activities such as the logins and the transactions, we, we have the risk engines technologies to perform the transaction monitoring requirements for the PST two, and also the strong customer authentication requirements for the PST two.
So we'll just have a quick look into a little bit more detail about what these solutions are starting with RSA adaptive authentication. So really this is our solution, which is covering from a PSD two perspective, the requirements for transaction risk analysis, transaction monitoring, and strong customer authentication, providing that frictionless experience to users as they're interacting online, looking at their activities across different channels, using intelligence, which we have from all of our shared customers around the world, and basically providing that ability to balance, provide that balance of risk, providing the tools to decide when and when not to authenticate, when to provide a friction experience and manage different forms of authentication from one forward platform, the risk engine meeting, all the requirements of the article two and article 18, taking in many types of data from different channels, looking at the device, building up the fingerprints, looking at the payment activities and non-payment activities, bringing all that data together to provide the, the risk assessment of user activities online. And it is a complete fraud system. So providing the policy tools, providing the case, case management tools to manage fraud effectively, and what RSA adaptive authentication is well known for is it's very, very high fall prevention with very, very low intervention, providing the frictionless experience as much as possible whilst also stopping a very large amount of fraud.
One of the ways it does this beyond the risk engine is our RS AE fraud network. The world's largest global network of confirmed fraud data. There are thousands of contributors to this E Ford network. And on any given day, there is over 260,000 entries of confirmed fraud information, which our customers are benefiting from. And this data correlates very highly to fraud. And this is what helps our, our, our customers get their fraud rates down low enough to qualify for, for example, the transaction risk analysis exemption and beyond being a fraud risk engine and intelligent system. We also provide strong customer authentication options out the box. So not only do we have the SDK, which is allowing our customers to build mobile banking, mobile apps, authentication mobile apps with technologies, such as the biometrics for authentication cryptographically, signing transactions, showing the transaction data on the screen, and then sign asking for the strong authentication pins and biometrics, and then cryptographically signing that transaction data, sending it back to the banking application as proof of authentication, but also our platform can deliver OTPs via different methods, such as SMS phone calls and via other methods as well.
But I guess very important is that our platform is a framework so we can plug in other forms of authentication. So if you are looking at certificates or you're looking at different tokens or different forms of biometrics then is really just a case of plugging those different authenticators into our single platform and providing that choice to the consumer so that they can use which authenticators that they want to use.
And again, the, this is why our customers are buying our product. This is why they are staying with our product is because we are providing a very high, full prevention rate with a very low intervention rate. So this is where the policy is allowing our customers to choose the amount of risk that they want, the amount of intervention that they're comfortable with for their consumers, but also, I guess, under a PSD two environment, how much fraud do we need to stop to continue doing risk based authentication or transaction risk analysis at the level that we want to do. So giving you that sort of control to slide the intervention rate up or down as, as needed.
So summarizing adaptive authentication, absolutely. From a transaction monitoring perspective, article two and 1818 takes the risk analysis requirements for the risk engine, upper notch requiring behavior analysis, looking at locations, the payment amounts and those sorts of things. So basically, yes, our product is complying to those two requirements and providing that sort of framework for that risk based approach to if the risk is low, allow the transaction to go through transparently, as the risk goes up. Then we start to challenge or decline that transaction the framework for that strong customer authentication and dynamic linking policy manager to allow for exemptions according to articles, 13 to 16, and taking in data for, and, and analyzing and authenticating transactions from different channels. So to the traditional channels, like the web mobile, and for example, the new channels that we are starting to see from the IP and P I S P, where we need to be as an as PSP, we need to be doing the risk analysis of those transactions coming in from those third parties, from a 3d secure perspective where we're looking at card, not present RSA is our product RSA adaptive authentication for eCommerce.
This is what our customers are using to implement transaction risk analysis and strong customer authentication in that card, not present channel. So again, it's a transparent risk based authentication using that shared intelligence from our customers around the world. And of course, 3d secure version. One is what we are doing today. And we in the very advanced stages of testing certification for version two, version two will start to go into production in later this year. And certainly throughout next year, more and more issuers and merchants will start adopting version two.
So from a 3d secure perspective, version one, that was what we've always sort of been used to since 2002, where we've had very limited mobile app support. We've had past codes and things like that, which are not PSD two compliant anymore. There's always been problems with abandonments the merchants didn't like it because the issuer took over the checkout experience. There's been brand issues for the card networks about the actual authentication methods. And of course the, the fraud has been hard to control. The operational costs have been hard to control, and everyone's always worried about whether the transaction's going to be approved or not. So this is why EMVCo 3d or 3d secure version two has really sort of come around is because we needed to provide a more frictionless experience and improve that for detection. So we're getting 10 times more data. So whilst the 3d in version one was providing us simple things like some, you know, device data, IP address, some payment information, and we could build some behavior information around that. As we go to version two, we're getting 10 times more data to make our risk assessment so much better. All of this data going into the risk engine. So we're looking at emerging category codes, we're looking at addresses and phone numbers and matching all this up to see if this does look like the legitimate cardholder. If this does look like the legitimate transactions that they are needing to perform.
So from a transactional perspective, the e-commerce transaction 95% typically are low risk. And this is the transaction risk analysis process are being completed frictionless experience for the consumer, very low chance of a high risk activity happening. So very low chance of a decline happening and balancing the requirement for the strong customer authentication under transaction risk analysis. So typically our products 3d secure version one has always experienced a very, very high success rates for transactions with low abandonment rates and very much so on the fraud detection, very high fraud detection and very low genuine fraud ratio or what some people call false positives. How many genuine customers do you have to annoy or intervene with or authenticate to catch that single fraudster? So whilst you might look at the market and you might look at other technologies who might be doing 80% fraud detection with 20 to one fraud, genuine fraud ratio, RSA is, is well known for very high fraud detection, very low false positives.
So summarizing adaptable authentication from a PSD two perspective, this is the issuer solution for Cardinal present providing that 3d secure version one and version two, as we start rolling that out, transaction monitoring, article two and article 18 that strong customer authentication providing that framework for different forms of authentication and providing the policy tools to allow issuers, to write exemptions according to articles, 13 to 16. And lastly, just a couple of comments, RSA web threat detection. This is our technology, which is providing what we call navigational behavior analysis of the entire click stream as a user goes through their online web session. So we're, we're providing the ability to do that behavioral analytics of way that users are interacting online. And this goes through their entire session from pre log in post log in the transactions and activities they're doing. And we given the, our customers the ability to see the visibility of what their customers are doing, and really drill down into individual web sessions, individual clicks, and understand what those users are doing as they interact online. So this is really providing this navigational layer analysis for web mobile and third party channels, which really sort of fits into where the transaction monitoring requirements are coming for for, and we see this as really as a sort of a, either to be used as an exclusive fraud detection system, which some of our customers do, or as an additional layer of fraud detection, keep those fraud rates down and be able to qualify for his exemption thresholds for transaction MIS analysis. So that's me, I'll then allow this to be passed back to.
Great. Well, thank you. Novin really good and interesting stuff there. So I did wanna show one more slide here. So at Cooper and Cole, we recommend that if you're in the banking business, in the EU worrying about what to do to get ready for PSD two, just a few high level steps here, start by looking at the API calls that you're gonna have to support. And, you know, there are a couple of different groups that are working on standardizing that UK open. Banking's already got stuff out there that's been live. I think since January, you know, from their commercial markets authority, very interesting stuff that's available right now. Then there's the Lin group defining, I think, access to accounts, another twist on the APIs that are required there. So there's a couple of different groups that are publishing standards for inter-operating. And again, you know, as a directive versus regulation, I think there's gonna be some variations between countries between jurisdictions, exactly how this is put into place.
And then that may lead to need for decentralized trust frameworks and, and trust framework operators. And number two here, you know, identify your account, holding and transaction servicing systems. And by this, I mean your current internal IM infrastructure or whatever you're using for maintaining your lists of consumer accounts, you know, as, as Nathan was saying, you know, there's going to be an increase in the number of authentication events. You know, PSD too, I think will in many ways change how consumers interact with their financial service providers. So looking at your backend IM systems, are they, are they going to be able to handle what the projected rates are? If not, this would be a good time to think about upgrading, to meet those API requirements. In, in some cases, banks are going to have to build up, you know, a completely new web tier intermediate tier for providing API services from trusted third party providers into the internal core banking functions. This is, this is a really big area that will probably take a lot of work in, in most cases. So if that hasn't started, that's definitely something that needs to be up and running in, in time for testing in March.
And then lastly, deploy risk adaptive authentication, and transactional risk analysis systems. You know, most banks do some sort of fraud detection today. It's always in their best interest to do that. But, you know, having a solution that can provide the transactional risk analysis with a variety of different kinds of authentication methods, the consumers want is definitely gonna be something that you'll want to have in place by the time the RTS takes effect about a year from now. So that will go to questions. If you have question, remember there's box here in the go panel can type in your questions at time and we address them question. I know we're both kind of talking about the cost associated with doing token based authentication in a financial consumer context, but, you know, I think in some cases there are, you know, high value customers that banks will provide, you know, tokens as a, an extra means of authenticating. Are you still seeing cases like that where maybe some of your banking customers are, you know, absorbing the extra costs so they can pass on that kind of assurance to their customers?
Yeah, I think that's absolutely a case where a bank might have different products or they might have different banking populations and different authentication methods would perhaps be relevant for those different types of end consumers. You can think of a student who might have a, a, a student account, and you can obviously think of a high, high value customer or a private banking style customer who would be wanting to perhaps a, have a higher form or higher level of authentication assurance. And I guess part of that is being able to provide that overall sort of fraud risk assessment for transaction monitoring, transaction risk analysis, being able to have the control to say, okay, for the student, we give them the mobile app and for the high value customer, we asked them to use a token or certificate or whatever they need. And then also having the control to sort of say, okay, transaction risk analysis applies to this group and maybe a hundred percent authentication applies to that other group. So I guess, yes, the answer is yes, we're seeing that. And we're also seeing that the, the financial institution needs that flexibility to be able to manage different types of authenticators, different types of risk levels, different types of policies for different types of transactions.
Yeah. You know, I think that's a really good point. The flexibility is the, the right word to use there. I mean, I, I think we both are seeing that there's an increasing interest in the mobile platform, whether that be mobile biometrics. And I kind of wanted to hit on Fido a little bit too, cause I know RSA is a border level member of Fido, you know, and other kinds of mobile apps, but you know, there, there's still gonna be people without smartphones, you know, who are gonna need other kinds of authentication methods that can provide higher assurance. And then there will be the, you know, the private banking customers that are going to have, you know, secure ID or some other kinds of tokens. So the banks really do have to be able to offer a wide range of authentication choices.
Yep. Even fallback options as well, you know, is all well and good to build a mobile app, but not a hundred percent of the population is going to be able to use a mobile app. And that is a question I'm hearing a lot and the financial institutions are struggling to answer that one is okay, we wanna build the mobile app, but what do we do for that smaller population of consumers who can't use that? What options are we gonna provide them? And then starting to look at alternatives and maybe the tokens is, is coming up as a, an option in some cases.
Yeah. That's a definite possibility. So yeah, on the mobile app side, you know, the use of Fido and, and global platform for things like trusted execution environments, secure element can offer additional security for building mobile apps, something to think about as we go forward on PS two also.
Yep.
Okay. Well, great. Thank you Nathan. We're at the top of the hour and thank you for everyone. Who's dialed in. The recording should be available tomorrow and wish you a good day.
Everyone bye-bye.
