With that. I welcome the next presenter. It's RI Hamman. It's actually my peer tip bank. So he almost has the same responsibilities over there than I have at Deutche. And when we met shortly before that, you mentioned that I took over the theoretical part and now you will become practical. I'm looking forward to
That little bit. Okay. So thanks to Mr. Carl, and thanks to Mr. Mika. I have nothing to say. So all, all the saying so far to, yeah, I am management system or it management system, but I think there are some expects will be interesting because we are also working on a solution and we had a curricular approach and want to cover all our identities and all our access to our applications. I think I must explain a little bit our situation and who provides funk. We are member of the unique credit group. Unique credit group is an Italian banking group, and there are several banks in, we are the major bank in Germany, about 20,000 employees. The whole group has 160,000 employees. They are working in 22 countries and what we've done with this merger, we combine our it. So the it out of our house is going to the combined it of the group. So there's a it service provider of the group it's called Ubers. And this is the only credited information business service. And he is the it provider for all legal entities. So we have not our own special it provider. We have a group it provider and this group, it provider must serve all the countries and all the banks. And therefore for us as a German bank, this is totally external. So this is the situation, our bank, and go back to identity and access management.
I think it's easy. If you look at the technical point of view, if you look at the technical point of view, you have the four things, you have the identity, you have the authentication, you have the access and you have the authorization. That's pretty easy. So if there is a it guy in the room, we say, oh, no, no, it's very complicated. Yes. It's complicated in the systems. And I think it's also complicated on a technical level, but for me as a user of the, it, it's very simple. So I have a identity, I have defined my auto education. I have defined my access and I want the authorization is going right. So this is the point of view, which I have as on the user. Sorry. So this is original slide. It's not make for this presentation. It's the outcome of a session in our department, where we had a brainstorming, what we have to achieve when we are making user management in the bank as a bank function.
So, and there you see, there are some guidelines, basic rules. You have pay attention about users. You have pay attention about technical systems and you have so-called objects. So what does it mean? So you have several users in, in a bank like we are, you have the internal users, you have seconded users from other banks of the group. So they are not legally your users, but they are looking on your applications. And on your user data, you have external parties which are looking on the applications and you have support stuff, which are looking at the applications. So then they have so special things like seconded people. They are halftime working, maybe in the Italian bank, they have their applications and they are halftime working in the German bank and they have access to this applications. So this is especially a problem. When you look in the trading section, so he's able to work in our systems, he's able to make a deal or a train and he trade and he is able to transfer them to the other bank.
And there, he can also do these things. So you see, there is a, there's a totally different situation if you are working in a group and if you are sharing people, so you have to take care about access management, because these are toxic combinations. So guidelines, basic rules. I think the most regulated business today is the financial industry. So we have regulations all over the world and they are not unique. So this is also a problem of the financial industry. So as, as a German bank owned by Italian company, we have two regulators in the house. We have the, in Germany, the so-called B, and we have an Italy bank of Italy and they have different laws behind them and different regulations behind them. And they come into our house and looking on our systems and looking on the Italian perspective and looking on the German perspective, which the laws are not the same.
So, and also you have to respect this laws in our identity and management system. We are on the other side at the technical level, but for us, the technical level was far away. So don't care. Don't take care about the technical level, define what we are doing with the technical orders. This was the message there behind, okay. That leads me to the non it focus. So we are strong on a non it focus. And there are several questions which have to be answered. So the simple question who has access to my application or data, as we mentioned before, as Mr. Miler mentioned before, who did approve this access, is he allowed to approve this with permission? Does she E F and what can be done with this permission in the system? So it's only a read permission. It's a right permission. It's a read, right permission. Can you make trades? And can you give them free on the other side? So these are the questions with the business.
So then this is a big point because this is as Mr. Kurt mentioned in the morning, this is a cultural change. Also in other departments in the bank, all permissions are changed. When people leave the bank or move between departments, you have to rely on HR data. This is new. So the HR data, which you are using for your system has to be reliable, and this is a cultural change. So can I see if someone has rights or ordering and approval, have employees only the rights that needs for your job. This is sod can all see the rights of the implement independent of systems. This is a very good point. So if you have one it provider, then you can have all the it systems, which he is providing to you. So, unfortunately this is not the only one, especially if you look at trading floors. So in trading floors, you have several providers which are outside of bank, outside of company, for example, it's ho dealing, it's FTD, it's Bloomberg, all the, the separate providers. So, and also the traders or the employees have access to their systems. And someone has done the ordering, but you never know it because you have it not in your system. It's done manual, it's done per email, it's done per phone. I don't know it's done. Perfect. So that leads us to the compliance questions.
Am I able to make automatic compliance controls? Is this all compliance? What is in the identity and access management? Can I control my it providers? I give them an order. Am I sure that the order is done in this manner? I want to have it. So am I able to a automat detect reconciliation access rights is, is, was described by Mr. Milika before and re cert recertify periodically in, in Germany, there is a new rule with the fin. They say critical applications in payment transactions or critical rights in applications with payment transactions has to be recertified at least minimum in a six months manner. This is law. You have to do it.
Yeah.
And this entails to what I call access governance. You need the access request management. And I think you need a workflow based access management. So you have look at Amazon or look at the other industries. If you place the order, you get the confirmation of your order. You get an email where your order is, you get an email. If it's in the packing station, it's delivered or something like that. So this was also our wish to give a whole work for process to the ordering people that they see, where their order is in the process, Rowland rights management, you have to map, roll and rights together if they are fitting or not. Ah, access intelligence though. I mentioned before toxic combinations. So you have to detect access rights with reboots, which allow you to detect toxic combinations. So this have you be done in the organization? No, it provider can do this for you. This is a real governance function.
The application of duties. I think it's clear. It's a need to know principle and access history. So especially in training floors, if there are fraudulent actions. So that question is coming out, oh, two years ago, you have make a trading with this person on the other side, who has access to the system who has make the trading, who has the permission to give the confirmation for the order and so on. You need a history because if you're not draining floors and draining floors, the people permanently change. So you need access database where you can go on the history back access reconation review of the responsibilities. Yes, of course we have talk about that. The access warehouse is the outcome of this. You'll need a data warehouse where you have a combined view on all the access rights, which are managed in the systems,
Access, reporting, rights documentation. I think this is clear. You need this for audited functions and you need, of course, a automatic provisioning and deprovisioning system, because if it's run automatically, you have not the problem. He is leaving the company and he has rights there. So this leads and the following, this all defines the so-called access governance layer and the outcome of this access governance layer is provided to the it provider. So the it provider get a confirmed order. It's internally confirmed. It's internally in line with the rules is checked with the rules is checked by compliance, and it's a valid order for the it provider. So he has nothing to check anymore
How to do. Yeah, this was the big question. So, as I mentioned before, though, we, you have the users, you have the approvers, you have audit, you have compliance, you have pre definitions to do so. What is toxic, which excess rights belong to which roles and so on. So this is the governance layer. These are also maybe in the company's new functions. You have to create new functions in your organization, new responsibilities. And for our, our site was clear. We have to implement this central compliance database on the bank side, and to build up the central repository, we, reconciliation process is mandatory and all the design rule based and so on. And the outcome of this access layer is then you see on the left side, the order, this is the confirmed order of us as a customer to the it provider. And what we need back is reconcile order.
So we say to our provider, if we give you an order of an excess, right, we need the reconciliation latest one day later. So this bring us in position to do one day later, reconation this is what we have ordered. This is what is been done in the systems. So this is a technical reconation. So the order we have give to the it provider comes back, we have done this access, right, this role, and this application in this timeframe and so on, and will be automatic recon consulated in this data warehouse. And if they're a fault, you can directly control your it provider.
So with this, we start our access rights program. In 2012, we launched a new system. We called it Mario master access rights information and ordering system. There there's a little story behind one of my employees it's Madoff. And he has much of these great ideas, what we have to implement in the system. And so we manage to use his Preme for, for the system. So it's a T compliance system for us, manages and controls all access rides, all assignments and enables users are having access to our applications and our own data. So we have a central access rides repository. We are can request handling, do on a central way in the workflow, provisioning orders, provisioning, and deprovisioning, and central reporting and controlling functionalities. This is a major part of what banks has to deliver to their auditors. There is no day if there is no auditor in, and it is asking who has permissions to do system, or that system meant what are the real critical rights.
So, and therefore you need also the, the, the HR data. So the approach was to import all access rights once a time. So you have, you have a running system, you have a running it environment. So, and yes, of course there is a documentation. Everybody, you know, the documentation is not a reality. So the approach was to look in the systems which access rights are built in there, and to load them back to our data warehouse. So import the organizational structure. This was in our company quite easy because our HR system is also an organizational system. So in our HR data, there is not only the employee data there is on, on, on which cost side he is working in which organizational unit he is working. And so on all these organizational data, anti hysterical data is in the HR database. So we can import the historical, sorry, the, the organizational structure there. So set up automatic interfaces to import this data. And the next one is implement transparent descriptions.
If you do re-certification of access rights of your team members in the past, there you receive an email of the it guys. And there is in, this is always, he has the access rights. HVB G we three, four, or HVB 2, 1 78. Nobody knows what it's behind. So, and the line manager this ride had since two years, so it's okay. Signed. So, and in the new system, we have also in, in our company, so called it application managers, the it application managers know exactly what the rights do, and they are now forced to, to give a clear description what this mean, this right? That in the reconciliation phase, the line manager can see what you can done with this. So implement efficient compliance reporting functionalities, of course. So since there is a data warehouse and it's SQL based, you can make any ES SQL Ary. There is a pretty user interface there. And with this user interface, the auditors and the external internal auditor are able to screen all the data.
So this was the past, but we want to change this as a corporate function. So we have the business fuel on the left side, we have the technical view on the right side. And the technical guys of you can see that this is held up. This is like F this is ad. This is whatever these are it management systems. And you have a ordering process on the bank side and all work. All it work is done on the other side, and it's not transparent. So, and our approach is to change this completely. So for us, there are only two ways. There is the ordering way to the right side, and there is the ation way to the backside. And all this business function are now in the data warehouse and now part of a workflow. So you have workflow, you have profiling, you have reporting in, you have the pronation in reconciliation, the order management, you have the risk data of the applications in and have all this over web interface.
You have different business user views. So as, as the user, which are ordering access rights, you have the guys which make the business approval. This by the way, can be more than one or more than two or more than three approvals. So as we heard from, from Mr. Milk, you need several approvals. So especially in the trading, there is a trader and a line manager. They together want to make this trade and he will give him access that's for sure. So in this case, we have a third party. This is compliance. So compliance has to look if this is okay, does this trader get this access? Right? So if you look about external companies, so we have several external companies working for us. And for these external companies, there is always an internal guy. If someone of these externals, this is the same process. This is someone in the external company, which needs the rights.
He can go in this interface. So we have it all for, also for the external, it's a web-based application. They, he has a line manager, he or she has a line manager can approve it. And then it got internal the bank. And there has a responsible people for these external provider. And he's the third who is looking on this access rights. And if it's enough, there's a force. This is compliance. So on. These are at reboots on the rolls and on the rights. So the system do this automatically. So it's abutted one time in roll rights. Yeah.
Coming back to the architectural overview, I think I have explained it. And I have not much to say you have, you have the data on, on the one hand side, the user data, the employees data, the organizational data, you have the defined rules, the defined rights. You have a kind of logic in. So which making the workflow, which looking about active boots and involve certain persons and you have on, on the right side, the change and order engine, which placing the orders to the it provider and placing the changes to the it provider. And you see underlined, this is the it providers or several it providers, which are hooked up to the system. So we have done that. It's on the slide. It's no secret with the software resolution from it's the Omar Nel. And you see there that we have the user organizational data and the database. We have the target system database. We have the provisioning engine and underneath this is the data which is delivered from the it provider or from HR. So these are the only technical interfaces you need. You don't need more. So because all of these things, these are organizational processes. This has to be defined by the business and has to be implemented by the business. And that's lead me to the beginning. So identity and access management today is not only it. Yes, you need it. And of course the, it must be reliable. You have to rely on what you are placing at order.
So organization data will be provided by other data sources, and that's it. That's the system
To give you a little guidance, how long it takes. It takes not so long. So our first, we started in, in 2012 and our first scope were the treasury applications, because these are the most risk applications in the bank. So the scope was 240 applications. And we have delivered a lot of them at the end of December, with all the functionalities. And now all the processes are designed. Now, all the business roles are designed. Now, the responsibility in the organization is designed and we are doing this year 2013, we have 1000, approximately 1,200 applications in the bank. And in 2013, we will onboard 600 applications of that. We will start the application onboarding in 14 days, and it will take, I think, two or three months, then we are finished. Why we can do it so quickly. As I said, the, the processes are defined and what we have done in the first quarter of 2013, we have programmed the so-called onboarding automat. This onboarding auto automat is feed from the it. So we, we have built up our generation for our database in this auto automat. So the, it delivers us the data out of the systems. This automate will process this information and place this information in our database. So this is the approach for 2030, and this is the approach for this mass onboarding. So I think
It will be work. Yes, of course. Always, if you do some mass onboarding, there will be some failures, but I think it's, it's not a problem because it's not a technical problem. It's organizational problem to have the people we are looking at the failures and to look if the definitions are the right ones. So 2013, 600 and the other 600, 2014. So it's a three years project for roughly 1,200, 1,400 applications. I think it's not the end. So there are some, a lot of things to do on the organizational side. And, but I think it's a good way to make a new view on identity and access management. Yeah, that's it so far.
Thank you, RI very interesting and very impressive. And I have to say, I like Mario, are there any questions from the audience story? Doesn't seem to be the case. And to be honest, in the interest of time, I would actually prefer to fine to move on, but I'm sure you, you are available for any follow up discussions.
So thank you. Thank you.
