Architecting a Digital Strategy for PSD2 and Open Banking

Good afternoon, ladies and gentlemen, welcome to our Al webinar architecting, a digital strategy for PST two and open banking lessons learned for the new regulatory mandates. This webinar is supported by P the speakers today are panel Dingle, who is senior technical architect at ping identity Ross Brecks. I am architected open banking and me Martin Kuppinger I'm the CEO, founder, and principal Analyst at Ko a Cole. Before we started some quick information about Ko, a coal we're.

An Analyst company have been founded back in 2004, acting as a source for neutral wise expertise on leadership and practical relevance was a focus on information security related topics, but also things which are connected to the digital transformation. We started in identity and access management. But right now cover a far broader range of topics. Our business areas are research where we provide various types of research, including our leadership compasses, which provide an overview of vendors in the particular market segment events and advisory services for events.

We just last week did our main event, which is European identity and cloud conference, which will be held again next year in may, aside of that, we will do a serious of consumer identity management related events, which will be in Seattle and Paris and Singapore between September and December. This year, some guidelines for the webinar, you are muted centrally, so you don't have to mute or mute yourself via controlling. These features we will record or are recording the webinar in the podcast. Recording will be available usually latest by tomorrow. And then there will be a Q and a session.

At the end. You can end the questions at any time using the questions feature and the good webinar control panel, which you will find at the right side of your screen. The more questions, the more lively is the Q and a session. So if you have any questions don't hesitate to enter these, the agenda for today is split three parts. In the first part I will talk about or give an overview of PST two and the upcoming changes, especially for banks. And the second part then, which is a joint presentation of paneling and Roth brag.

They will talk about best practice and the opportunities PST two and open banking brings to banks in the EU and the third part, then it'll be a Q and a session. So let's directly start. I think what we have seen over the past couple of years is a massive increase in cost of compliance. So back right after the financial crisis, we saw a lot of new regulations in Germany, for instance, Thema risk. So the finance market regulations, which has been first extended and pays three, came with Germany.

It security law, basically it's the same in most countries, PSDT two became effective or becomes effective early next year. And also GDPR, which also has an impact on the finance industry becomes effective next year.

So within January may next year, there's a lot of new regulatory pressure, which leads to an ever increasing cost of compliance while where most organizations still follow what I call the, the regular later auditor approach that they do, just exactly what the regulators and auditors are expecting, but clearly cost of compliance, reference to competitiveness without an immediate benefit. However, I think they are and that's will be my final slide.

Then after a couple of other slides in between, I think there are also opportunities in the PSD two regulation, in many other regulations, there are opportunities. And I think we need to move away a little bit from this negative perspective, towards a more positive view on saying, okay, what is in for us? What are the things we can do based on that? So what does the EU want to achieve with PSD two?

So the revised payment services directive, which is the formal and full term of it, the one thing is it'll, it should drive Europe's finance industry to an integrated in a more efficient payments market. So opening up things, providing more integration, it should provide protect consumers by making payments safer and more secure. Another important area, obviously with all the attacks going on. And the plan also is to create a blade ground for new payment service providers and for increasing competition. So there are a lot of terms.

I don't use all the abbreviations, which we could use here, but look at just some of these. So when looking at this situation, there's one important group which comes into believe, which are the so-called third party providers or TPP, which can be ISPs account information, service providers, which can access account information.

And thus, for instance, provide an overview in a single interface, across the accounts at various banks and the PSPS, which can initiate payments. They also could potentially be both banks must provide interfaces for these third parties. That's a very important thing. And this is also where the later on the open banking I API comes into play because in fact regulation would allow the, every bank to have sort of its own layer of APIs. So even while they clearly would be somewhat similar, because at the end of the day, it's about the same types of services. That would be a challenge.

And so having a standardized API clearly helps, but that's part of the second part of our webinar today, target of the U EU is to foster competition. And clearly this, this bringing into the bla third party providers, which must have access to the banks that will change competition. These new providers have less burden regulatory compliance, but it's not that they don't have any burden.

They have, they must register. They must run through a process. So it's not that easy, but yeah, obviously anyway, this there's an impact on the business model because TPP can from the interface to the customer. And so if you lose your sort of direct contact to the customer, then it's a massive challenge for the business. And many of these ISPs and PSPS will be young at trial, innovative organizations, which is not what all the established banks stand for. So some are some are moving the direction, but clearly it's a challenge.

And so there's potentially a situation where they will take an ever growing part of the business. So what are the options probably making it blunt sometimes helps to make it clear sort of one option ignore or die. So the customers, so if you trust say, okay, I have to do it. I do my business as usual. Then at some point more and more customers won't be the customers of the banks anymore.

The TPVs, to some extent, there are a lot of regulations around fees, but at the end more and more, they will come into a position to hate the business model. It's a pretty bad situation. And at the end, this is what sort of is behind all this transformation thing. Probably the most important thing in the entire digital transformation is that it's about getting closer to your customers and consumers. And if you don't go that path and use the opportunities, then it's sort of the counterparts to what organization should do in the digital transformation. So what's the other option.

The other options use the opportunities and be agile or become ad agile because there's nothing in which sales a bank or can't take. The traditional is P and PS P. So interface with others. We do one who interfaces with the customer, your customer, try to build on that momentum. And I had a very interesting conversation last week was somewhere inform German mutual bank, which in fact has 25 million customers. And if you have 25 million customers, then it's a starting point.

And then there's, it's so obvious that you have to say, okay, I'll try everything to become their primarily interfaced all financial services they use, regardless of whom. So just turn it around. And by the way, I think there's also point benefit from your knowledge about how to be compliant. Despite the bigger burden bank has to carry at the end of the day, a bank knows how to deal with it. New players will be challenged by that. So the interface to the customer, it can be a TPP. So the customer comes in through the TPP storage bank, but it also can be a bank.

The bank can so to speak, become the TPP for other banks and extend their model. And I think this is something which is very important to understand when looking at PSD two, the other challenge or related to that is the entire interfacing, because it also means you have to think about how can you work in your organization. You still have to serve your traditional customers using the traditional services, and you have your core banking business, which has to operate at standard speed, stable and reliable. On the other hand, there will be the new banking services.

There will be the need to expose APIs for existing new customers. This needs to be agile competitive. So that needs to be to some extent separate, but on the other hand, well integrated.

So we, you will, if you're a bank you will Marily and innovatively end up with a sort of a layered it architecture where you have a core it where you have maybe the somewhat more actual it, which you use internally where you expose them APIs to others, because you have to do in the context of PSQ. And it's very important to understand it and to look at it also for various aspects, it's a challenge for your business models. So you need to have it. What do you need from your business models?

What the perspective here, it's a challenge for enterprise architecture and as part of enterprise architecture, it's a part challenge for enterprise security architecture help, can you ensure, and to end authentication and to end authorization and to end auditing across all the various layers, which be, might be more three or even more when the people come in with their app and end up in some scenarios at the mainframe who doesn't have the ability to manage these individuals. So, but might use them functional accounts.

So there are a lot of very interesting areas in here, and it's absolutely worse, not only worse, but time to move, to look at this right now from not only the business model perspective and not only the regulatory perspective, but also from the enterprise architectural perspective and from the enterprise security architecture perspective. So APIs are one of the big things in PSD.

Two, the other big thing is strong authentication, which isn't overly well defined in the regulation. But I think we all know what strong authentication at the end is. It's using at least two factors. So something, you know, plus something you have or something, you know, plus something you are or whatever combination. So it's really two different factors. The question clearly will be, and there are some, some documents around what is considered being strong enough. There are various ways to do it, but strong indication becomes a challenge.

And in the context of PSD too, there's a lot of talk about strong customer, a indication. There were some changes. So there was a, an RTS, so a revised technical specification, and there were couple of changes around the, a indication. So in fact, basically it says for most scenarios now touches on my next slide. Two factor authentication it's required.

So, or two or more factors. And then there was a discussion around risk based altercation. So in fact, what the regulation says is that if you only use one factor, you can't simply say, okay, I use some risk based authentication where I understand context risk, oh, this person trust moved within two minutes from whatever Germany to Russia or wherever else. And so the risk is increased.

They said, it's not fully sufficient. So there are some exceptions right now, but basically it says, this is not sufficient, but that's not mean that banks shouldn't use or other any other provider because the authentication's also done at the TPP. So it doesn't say, oh, we don't need, or should not use risk based authentication anymore. I think there's a different angle. So you need two factors. But if you look at it from a broader perspective of risk mitigation, then you definitely must have risk based authentication in addition.

So you end up with an adapt authentication anyway, and that should be your strategy or big target to say, I'm very flexible regarding the authenticators I can use. I have the risk based approach in place, and this is what really makes up the adaptive authentication. So you don't need to be flexible regarding your accuracy. Trust can say, okay, these two are the ones I always will use because day together make a good enough MFA two FFA, in fact, two factor indication to be compliant.

But if you do it right, then you move to an approach for subparts really multifactor plus risk based authentication, moving to a real adaptive authentication. So SCA strong customer authentication. This two factor thing is required always for PSD to accept. And it's a little bit more complex, but these are the most important exceptions transactions under 30 Euro, former leader under 10 Euro. And then it was moved up to 30 Euro right now. It's not required for certain types of remote unattended payment.

KSKS such as per meters of transport stations where it would be very difficult to implement such a means. And for certain types of businesses where transactional risk licenses has been performed sufficiently. So where one factor plus risk based application is in place and proven it's allowed for an 18 months supervisory period until final decision. So it might be that the one factor plus risk based, even in the rare cases or in the specific cases where it's allowed today will be forbidden after 18 months, 18 months after the regulation becomes effective.

So when looking at authentication very quickly, what you also should keep in mind always is it's not about syncing authentication from your end. It's about syncing from the customer. So most banks currently just say, okay, I have this way you can use to access your account. Maybe they are two or so, but it's not really flexible because they always look at it. So what do I have to do? And what's the best way for me to do it, but at the end, if you want a better customer relation, look at it from the perspective of the customer.

And that means ease of use device of choice and simple change of the device immediately available. Nothing you have to send first by postal mail and it should work everywhere. This is what you should keep in mind. So with all that, having said, all that stuff around PhD two, who might act how, when comes to authentication that authentication for banks is the obvious choice. Get rid of the single choice eCommerce, which can potentially become payment. Initiations service provider get rid of the password. Passwords are so outdated. There are better ways to do it, which really work these days.

FinTech be innovative, not only in your business model, but also regarding authentication credit card. Companies might face some interesting challenges because having the C B on the backside of the credit card and the credit card on the front side, doesn't make it two-factor authentication. And there are a couple of countries terminated for instance, where most people don't use the pin of their credit cards.

So this, this obviously a C share. So a lot of things in PS, two, what you should do is look at it. Not only from a negative perspective, yes, there's an increased pressure, but there are also opportunities opportunities you can use by consuming your own APIs and the one of others you can become, play a bigger play, so to bigger game. So to speak, look at it.

The opportunities, not only the threats provide a better customer service, more adaptive, more convenient, and start now because banks have it easier because they don't have to undertake and learn the regulatory processes, the licensing process, etcetera. So there's an opportunity as well with that. And my overview about the PS PhD regulation, I hand over to Pamela and Ralph. Hello everyone. Thanks very much. Thanks very much. And Martin for the introduction.

So keeping a brief, this is a joint deck that both Pamela from ping identity and myself from radium will be presenting and hope to instill some, some thoughts amongst you. And I'm looking forward to your questions at the end, skipping through labor on who we are. So Martin's given a brief overview of PSD two to call it out in a little bit more detail. We've got 28 member states, a huge number of official languages and massive population base of 500 million inhabitants.

Some of the challenges that have been raised by having essentially a technology, non technology neutral and non-prescriptive approach to how banks are supposed to comply with the new regulations has resulted in some interesting debates. I'm sure everyone's aware of the com or the constant touring and throwing of the various different stakeholder groups within the European community.

But as it's heart, everyone has to try and respect the spirit of the directory, provide a technology and framework in which to service APIs and to a large degree interpret the regulations both individually, but also at a national level. And this lack of clarity in this lack of prescriptive technical standards may result in a high barrier of entry for TPP as Martin alluded to, if I'm a TPP or a small startup in France.

And I wish to consume financial services across all of Europe, if every single European entity, every single European PSP has a different API secured in a different manner, different authentication mechanisms, cetera, cetera, cetera. It actually may or runs the risk of not achieving the objectives laid out for, or by the EBA, which is to foster competition. And all of the other points that Martin touched on in these introduction, focusing on what we're doing in Europe, the competition and markets authority, which is essentially the UK's competition.

Regulator has looked at PST two and seeing the opportunity that has to really shake up competition amongst the UK financial services industry. Because as we all know, banks are fairly static. 60% of retail customers in the UK have stayed with their primary bank or ass P S P. I certainly know that I've never changed. And so I've been in the UK for the last 12 years and as a business owner, now my default pattern of behavior will be to bank with the same bank that I do retail.

So I surprising that 90% of SME customers will bank with their retail bank provider, PSD one and other competition regulations were adopted. And there's a whole raft of different processes that, and competition mandates that the banks put, sorry, that the regulators put in place in the UK to drive and drive through innovation inside the UK. Things like fast account switching, which would theoretically allow you to switch banks within 48 hours. That's new credit cards, online banking, credentials, everything standing orders migrated, et cetera, cetera.

But again, the adoption of foster account switching hasn't been particularly high. So with PSD two and the, the requirement to force banks to provide a, an API, the competition markets authority has beefed up the legislation and has ordered the banks to standardize on a common technical and functional API specification, and to create an entity that will ensure compliance with the goal of trying to harmonize and lower the barrier of entry for TPPs to consume APIs, both payments, initiation, and account information services by delivering a single functional specification.

So the data payloads for how an account record is modeled a as well as the messages that will initiate an immediate account or sorry, payment, as well as to drive, try and drive through the common technical specifications and a common trust framework that the TPP and all actors can safely operate in to drive down that barrier of entry. So that TPP, once they have conformed or delivered against one API or one bank, they should be capable of interacting and consuming the same API as, and accessing the same data for any bank.

So a TPP only has to deliver against the open banking standard in order to be able to interact with the APIs provided by any UK financial institution. Just a point of clarity there, the banks in the UK that are required to adopt these standards are known as the CMA nine. So that's the competition of market authority, nine banks or building societies, which includes the vast majority of UK banking accounts. It's a very, very, very high percentage, but the competition of markets authority also didn't wish to stifle innovation for, or burden with undue regulatory requirements, smaller players.

So smaller players or smaller ASPs SSPs are not obliged to adopt this standard, however they are free to do so. So this is an open we're trying to drive through an open set of standards and an open ecosystem that all actors and all participants can safely plan. So open making in the UK as Martin has already touched on. We've got a huge number of stakeholders trying to feed into this open banking framework. We've got European regulators, UK regulators, UK banks, both existing and challenging challenges, and third parties, both established and new entrance.

And it's been a very interesting and very challenging exercise to try and drive through a common specification that everyone can agree is the best possible starting point for adhering to both the PSD two objectives, as well as the CMA objectives. Some of the major contributors that we've had from outdoor from the industry have also included the open ID foundation as well as established players within the identity access and management space of which hangs one.

But this has been very much a open collaborative effort to try and come up with a standard set of frameworks that everybody can utilize and leverage. And the banks can adopt with the aid of industry partners with the aid of their identity and access management vendors. Because one of the biggest challenges is to, is to secure and safely expose these APIs. And there are specialist vendors and specialist protocols out there that banks currently rely on.

And essentially we're looking to the industry, both the technology and the financial to help drive these standards and these processes, we bring 'em all together specifically on the open banking directory services, the, the open banking ecosystem is going to be, will consist essentially of two parts.

It's a, we're trying to drive through a common functional set of specifications, but we will also be providing essentially a identity and access management and identity provider service, such that all members in the ecosystem have a common IDP, a common set of unique references and a common way of safely identifying that each act of inside this ecosystem has been accredited, is appropriately regulated, and that all participants are safe to do business with those, with those participants, the open banking directory is not to be seen as a, a barrier to entry, but really as the gate, as a gatekeeper, that we will provide services that will do due diligence on trusted third parties, mainly making sure that they are, that do exist on the national competent authority registers.

And we'll provide a, a common set of credentials if you will. That identifies that TPP into the, the UK ecosystem. Our security target state consists of four very common building blocks. And for the technical people on the, on the call, there should be a four building blocks that are very, very familiar. We're leveraging basic PKI. So TLS 1.2 to provide transport layer, encryption and transport layer identification of part parties exchanging data we've selected and adopted the O two as the industry authorization based protocol. Layered on top of that, it's actually 0.4.

We've recently announced that we have adopted the open ID connect protocol that is based heavily on the financial API working group of the open ID foundation. That's significantly enhances and strengthens the payloads and the processes and the messages that are being sent around. And all of this is made available by the Jason web token security suite, which is a way of communicating data, either in a method or in a format that is either signed.

So it can be non reputable non-repudiation can take place, and each message can be checked and validated that appropriate TPP or as PSP, but it can also optionally be used for encryption to ensure that messages stay secure between participants when communicating over a, an untrusted network as, or an untrusted clinic as there still is within our ecosystem. I'll turn it over to Pam. Perfect. And I expect you to jump in here too, as we go through some of the technical pieces.

I know, I know, I mean, you're much, very much a wallflower Ralph, so I'm sure that's gonna be a tough problem. Hi everybody. My name is Pam Dingle. And just so you know, Ralph and I have been working together with other vendors in the space, as Ralph said, in sort of a collaborative environment to try to get us to a security state that is acceptable for financial grade API interactions. So there's been a ton of comment, a ton of iterative revisement of what open banking UK is trying to do.

And I will say that they have come up with the most prescriptive set of recommendations out there, or at least that I'm aware of on how API security like those mandated inside of PST two could be implemented. So I'm gonna go through very quickly and just talk about some of the technical reasons why OWA two and open ID connect have been chosen. So the number one reason why O 2.0 and open ID connect are important are because it safeguards people's credentials.

So if you think of how powerful a user's passwords are, it allows you to impersonate that person, not only at their bank, but possibly at many other places where they might reuse their password. So OAuth two is what's called a delegated authorization protocol. And what that means is that a banking user can choose to allow a given third party provider access to only a piece of their banking information, not everything.

If you think about the current screen scraping initiatives that are out there today, you are passing your primary credentials to an application that may or may not respect those credentials, perhaps they do, perhaps they don't. But if all you're looking to do is mitigate risk, then plausible deniability is your best defense. If the TPP never sees your credentials and only ever receives a small token that allows them to get to a single piece of functionality consented to by a user, then everyone's MIS risk is less. Do you wanna go forward?

Ralph, Ralph's playing my, the presentation guy. So what does that really look like if you've got an application or a service in this case that is trying to take advantage of banking accounts, then what we're talking about is a series of web redirects and restful data fetches that are going to minimize the entities that see your passwords and maximize the API access that the application can get to.

So what you're seeing here is the management of money app playing the part of a third party provider is going to redirect to a financial institution and allow that financial institution to securely auth authenticate the user and collect consent for what the money the management of money app wants to do once that consent and authentication has occurred. There will be a redirection back to the server at which point in an access token can be fetched via a rest rest call.

Now, the important thing about that is that the token doesn't actually get sent over the browser, redirect it's sent in a private fetch that occurs over mutually authenticated TLS in a, you know, very secure, very well watched way. These are the details that we're working on right now in trying to tune OAuth 2.0 and open ID connect for financial purposes. Go ahead and stick us forward here. Now what Martin and Ralph have been talking about is the trust model, this idea of an authority.

So while I do respect the idea that it, there should be a low barrier of adoption for third party providers, I think we can all agree that there is a, a barrier that's too low, and we do actually want people's finances to be safe. So the question is what's the right balance. And I believe we will tune that over time.

However, the way that it works today is that the authority right and open banking UK's is an excellent example of this. The authority decides which trust relationships exist between which third party providers and which account servicing payment services providers. So instead of the management of money app, having to establish a trust relationship and a contract with every single finance financial institution out there, it can sign up one time, be vetted one time by an authority. And now it can start to interact on behalf of customers.

The important thing to note about this trust model absolutely critical is that the gate for whether this money management and money application can access accounts on behalf of the customer or not the gate is the customer it's consent that allows a user to choose which applications can interact on their behalf. And so the consent user interface becomes the most critical part of this picture.

Okay, go ahead, Ralph. Right. So secure customer authentication and consent. I think that Martin covered it very well. The important thing about this is that it's not standardized.

It is the, the domain of the financial institution. They get to choose what you see. They get to choose what you interact with and how you decide whether a given request for interaction should be permitted. So I believe that this is going to be a huge area of innovation in the next three years. I also think that PSD two, the mandate is something that will have to be worked around in some cases for the benefit of the customer. And I think the gamification of that, that consent is going to be very fun to watch. We have to make it explicable to the user.

And some of the, you know, when you look at the interaction between GDPR and PSD, two on what's being mandated, those may not actually be the best rules to live by when it comes to actually communicating to customers. What consequences are of agreeing to a given request, Ralph, is that, would You agree with that?

Yeah, it does. I, I just was gonna gonna jump in. So the consent model defining essentially a human readable and a human understandable authorization model is one of the challenges that each of the, as PSPS are going to have, especially when you do factor in things like GDPR. So the consent in a payments use case I'm gonna speak for the UK consent for a payment actually happens between a TPP and a it's customer. So if you take an example of, I wish to make a payment from I'm using Amazon, which is a trusted a TPP and Amazon, I wish to buy something from Amazon.

Amazon is under no obligation and nor should they be to convey to the, as PSP exactly what the customer is buying that's entirely within the purview of the ASPs, sorry, the TPP, it is provides information about their business model, what it is that they're selling and is not relevant to the consent or the authorization that needs to take place between a, a PSU, let's say a bank's customer and a bank, all a bank needs to know is what, how much you're trying to pay and to, and to, and to who.

So trying to come up with a consent model that adheres to the spirits and the legal frameworks of GDPR and PST two was one of the challenges that we faced with open banking. And it's, again, one of the, one of the key drivers for adopting a segregated approach for consent management, because consent takes place in two places under the OWA model, we only, or the ass P S P only needs to know about the elements that is relevant.

And, but it has to ensure that those elements are played back to the customer. So the customer is very, very clear of, of what it is they're consenting to and the potential consequences of, of this action. Yeah.

Well, it's interesting too, that, you know, there was, there was just a phishing attack that it went on with Google, where Google allows any client to set the name of their application to anything. And so there's a, there's very clearly something that you don't wanna see happen in a banking context, right? You shouldn't be able to, you know, create a client and name it, anything you want, and have it accidentally be similar to a bank where people may have accounts where they might accidentally grant consent to the wrong entity. That is the job of the authority, right?

And the authority is taking on that responsibility to make sure that these clients are vetted. And, you know, for me, I really strongly believe that we can do very well with the technical side. We can lock things down. We can force clients to have certificates and we can check those certificates and we can revoke their access if something goes wrong. But the people side is really the, the green field, right. For someone to try to possibly commit fraud.

So we, we will watch it and we will improve. Yes. And it's just gonna be an iterative. It's certainly gonna be an iterative process. The people side is absolutely critical in the PST two, there are multiple national competent authorities. So there is nothing stopping a TPP, registered in Germany from gaining access to all of the UK.

We, the model was being put in place is to do that a very, very low barrier of entry. But behind all of this is a very large number of competent authorities or competent registers that will be feeding into, or essentially acting as the primary gatekeeper for TPP and as PSPS to conduct business under a PSD two context. And obviously behind all of those authorities are people.

So the people and processes and the education that needs to take place to make this a safe ecosystem operates on many, many levels, but it is, as you say, the, the lynchpin of success, and one of the key barriers to preventing fraud from taking place, especially if you consider what is now going to be made available. So with these redirect flows or with any sort of flows, TBPS at some to a large degree, gonna start being encouraged to use third party applications. That's the aim of this to embrace new organizations and new businesses and new applications.

And at some point in the journey start typing in their banking credentials.

So it's a delicate balance between trying to build an ecosystem and also try and educate all participants, including banks, customers, to be mindful of ensuring that when they are, when they're surrendering credentials, that they have gone through just some basic checks to make sure that they are actually talking to the bank, that the banks presenting a nice certificate, that CPP is reputable, or that they think it's reputable, but it is gonna encourage a large number of a large number of customers to start being educated, or I suppose, required to surrender their banking credentials whilst using a third party application.

And that's a, a big change from what or how customers deal with their banks today. And it is one of the areas that is everybody in the ecosystem needs to be mindful of.

All right, let's go to the next slide here. Right?

So just, just a couple of key key takeaways for, for everybody here, that's looking to finalize or come up with a, a PSD two approach, and it's just sharing some of the experience and some of the analysis that we've done with Pam and other vendors and the wider ecosystem. So there is a large number of security standards out there based on or two. And the more strict that you become and the more of the later security standards that you adopt, the higher your customer and ecosystem security can be, but likewise, there is also risk to a delivery.

So some of the later security standards haven't been adopted by, by all vendors and may not be available in times for banks to deliver and upgrade the security infrastructure in time for the January 1st deadline. So with open banking in the UK, we had to adopt a pragmatic approach to try and find what we felt was the most relevant set of security standards that would have appropriate protection for all participants. And as you can see, I've tried to model that on the diagram on the right hand side. And essentially, as we said earlier, everything's gonna be based on OWA two.

And if we said, okay, O two was good enough, there's very, very high vendor support, but just using vanilla, O two also comes with very, very high participant risk. And as we move through a more prescriptive and a more specified technical set of security standards, we get to a higher ecosystem security and much safer levels of security for each of the participants, but a, it does come with risks to delivery. Cause these are brand new sets of standards being worked on by the financial API working group. And they do not yet have wide adoption.

So for all the banks present on this call, trying to find the pragmatic approach to delivery of PST two will be key inside the, the timelines. And there's other ways that you can mitigate some of the underlying risks that maybe left left. If you use some of the, or less prescriptive security framework, such as improving your strong customer authentication capabilities to more, have stronger, stronger assurances, stronger satisfaction that your customer is really the customer that you're dealing with in all points that Martin talked on earlier.

But at the end of the day, you have to acknowledge that PST two is a thing. It is going to radically shake up how well the way customers potentially do business. And the most important thing is to remember that all of these pieces of legislation are all being done with the customer in mind. And the customer experience is key to making a success of not just your own services, but also successful API channel. And as functionality moves out to TPPs and away from banks, the way customers interact with their bank will become more and more focused on API led products.

And when you are delivering an API led product, the security experience, and a security trust that you offer to your customers using these APIs is absolutely key by putting your customer first and making your customer central to the entire journey and the entire process and empowering your customer to share and use data, but doing so in a safe, trusted way will be key to retaining your customers and growing and deepening that trust relationship that banks already enjoy with their customers today. Right?

And so, from my perspective, of course, you know, I, I am an identity geek. So what I see out of what the Oakland banking UK group is doing is an attempt to push the envelope. So they have really done the work to create a prescriptive set, a recommendations. I believe that's likely to be picked up by others in the PSD two world, simply because nature pours a vacuum. If you can piggy piggyback on this kind of work, you know, to start ahead of the game in looking at how, how you know you as a non UK bank might secure APIs. This makes a ton of sense.

The, there is in fact, so the, the financial API working group in the open ID foundation, you can see the link here is a place where exactly that globalized approach is being taken. So the folks from open banking UK are in there, there are folks from Japan, from America, from Germany, everywhere. You can think they are coming together in this group and trying to create technical specifications.

Of course, the technical specifications are only a small part of what you all will have to do in order to comply to the mandates. But I'd like to think that we can at least lock down the plumbing and then turn and, and focus on some of these more difficult, semantic problems that you might see. So I would strongly recommend you look at that group and look at participating in that group, if you are the person who is in charge on of that planning stuff. And I think with that, I think we can open it up for some questions. If I just, just wanted, I just wanted to say just a quick follow up.

So the specifications that have been developed by, for open banking, they are open to anybody to join and access, provide comments. And particularly on the plumbing point that PR raised the open banking implementation entity is really designed as a vehicle for the banks to meet their immediate competition mandate requirements from the CMA we are looking to deliver, or have the open ID foundations, FY working group maintain the plumbing specifications as you were.

And in the medium term, we are looking to use the later set of the financial API working groups for read right specification as our definitive guide and definitive specification for how UK banks will be providing the plumbing for access to APIs. So everything we're doing is open. Everything we are doing is available and as references. And as Pam said, I highly encourage everybody to partake in the open ID F working group.

Okay, Pamela, Ralph, thank you very much. And as you've said, I think then we can move over to the Q and a session. So it's to speak latest time for the attendees to enter the questions they have. We already have a couple of questions here. So I wanna start with a process technical question, maybe for you, you Pam, how does a long lived OWA access token match a single payment? I don't know that it will be a long lived access token. It may be a very short lived access token.

There are various mechanisms for refreshing that token that might be preferred over issuing one token that lasts a long, long time. Ralph, have you guys actually locked down that from an open banking perspective?

Yeah, absolutely. So the it's a great question.

So the, as Pam said, so for any of the actions that we deliver can be used to provide both an access token and a refresh token to allow a, a consented, consented access to be played in at any time, there is a clear separation of concerns from an identity access management layer, IE, and a functional app. So functionally the specifications are item potent. So you'll be able to play in an access token to say, make a single immediate payment.

You'll get an immediate response as to whether in the UK as to whether or not that payment was performed, or the bank is immediately going to try and make that payment. If you play in that access token, again, the response you'll get will be, we've already seen this payment. This payment has already been executed for a period of, so for a period of time. And it's important to note that this is a little bit of a leading question, because with O two, it is possible to obtain both an access token for individuals, but also access tokens where the TPP wishes to act on its own behalf.

So in order to address this scenario where a payment has taken place and has been executed, but a TPP wishes to, for whatever reason check, you know, a period of time later, what the status of that was, was it actually executed, et cetera, etcetera, there will be APIs that will be accessible at a functional level with just a TPP credential. Okay.

Ross, thank you. And we have a couple of other questions. So maybe we, we try to answer a little bit focused to the next ones because otherwise we will not be able to cover all of them. So I think there's a, in fact, two questions and I'll start with the first one, what security systems are required for January, 2018 with open, when open access clicks in EA the interim period before the S EA RTS applies 18 months.

He, so what, what do you need to do in the, the starting so to speak from January, 2018 on more from PSD perspective, probably regarding the security systems you have to have in place. You wanna take that route, or you want me to, I'm more you after you can.

So, as I understand it, the while the mandate is not in effect, the spirit of what has to be complicated, accomplished is in effect. And so I would expect that very first period to be all about tuning, what happens, we, you know, there's no point in dodging the SA SCA requirements until the day it goes into effect. So I would expect people taking to be taking a best attempted SCA knowing that, that they have a little bit of wiggle room. Yeah. So just a quick follow up.

So the API, I believe you have to have made available your ASPs have to have made available via APIs, the actual information. So the ability to execute payments there is risk obviously associated with providing API access with non SCA. So that is something to be mindful of. And I think there's side of Thea part, I think for the API part, the one thing you definitely have to have is an API security and management solution, which allows you to manage to monetize and all that stuff. And to secure your APIs.

Another question I have here is any observations on the state of readiness of banks for open access and securities in January, 2018. Maybe I can jump in here first. So we just recently published a survey. We run around the PSD two readiness, which was more, I would say, concerning in the sense of many banks are not where they should be right now. There's a significant risk that a lot of flavors in this market will not be ready by really ready by January, 2018.

So there will be something probably because there, there has to be something, but it looks like there's many new regulations, many layers have waited too long. And then right now they have to hurry to catch up.

I, I would, I would add to that only to say that there was not a lot of time given, you know, knowing, you know, the experience that I've had now with how banks work and seeing the time when a bank learned what they had to do in the time when they legally had to do it. This is a very short period of time for any business to roll out this kind of infrastructure. So I do have a bit of sympathy for the folks who, who are looking at what has to be done and feeling concerned.

Yes, I would say partially true, but, but anyway, as many other regulations, there's still usually that period, which first is taken to look at it. And then until you start, you have already lost a couple of months.

Anyway, I think yes, there is a challenge and all the effective organizations have to face that challenge. So another question I have here is with these standards, can I build an Eubank account that has traditional banks in every country? It gives me an overview overall, an overview overall, my financial data from one Porwal. So probably the point is can IP do that or individual do that A hundred percent? So it's the logical, as you said earlier, some logical choice for each of the, as PSPS to become AISP. So it's perfectly reasonable. Indeed.

It's a, it would be a quick win for as PSPS in the UK to offer a consolidated dashboard of all account information or, or account balances from any other bank. Even while that means leaving their comfort zone so far, it was, they were always relaxed and saying, okay, I will not provide access to others, even if I could. So this let's say the willingness to cooperate or to interface has been, I would say RA low so far. And that's probably my change because it must change A hundred percent. It's competitive advantage.

If one bank does it, then you may see a mad rush for all of them to offer the same functionality. Okay. I think we gone through the most of the questions right now. We are close to the top of the hour. So I would like to thank all the participants and I would like to thank you, Pamela and Ralph, for your presentations in this, a call webinar up to you soon and other webinars as well. Thank you.