So usually, I deliver this kind of workshop it's used as a workshop that it's easily can go to three or four hours, but today I would like to shrink and make it [INAUDIBLE] within one hour. So that's the reason that it should be a lot more on topics rather than having the whole history what is going on. And I think that the idea of this presentation is to show what is going on, what is the major trend, and what is the strategy that you're seeing, especially in financial services industry. Of course, that it's kind of a sister industry, that it's [INAUDIBLE] is also related, so many of those challenges and also solutions that we are seeing in financial services industry maybe you can find as well in health care.

So just to give an idea, so to put it in the context of what's going on in the financial services industry, there are of course macro trends. And macro trends there are things that happen in the market, it's not technical or technology related, and there is nothing that we as technologists can do about it. We just have to adapt and of course help your business to adapt. So some macro trend is increasing regulatory requirements. When you're talking about regulatory requirements, I'm not only talking about Basel 1 2 3.

Now, we are talking about FFR TB fundamental review trade in books, not only about different regulations about how do you treat data, and how do you treat identity, and now we are seeing this fragmentation in an a different countries, and in different states, even in the United States, states may have their own regulation about how you protect the data, how to use it for example, technology or biometric signature to identify, and how do you protect that data.

For most financial institutions they have a global footprint of course, you can imagine that some measure, especially because their design does have one platform that can't accommodate different needs. And the regulatory and compliance, it's a burden for most of these financial institutions. Another aspect as well with the volatile economic outlook. So nowadays, the way that you map risk or how to adapt it to changes in the market it's just accelerating the speed.

So most financial institutions they need to be able to change the way they approach and measure the risk in a way that it's lot faster than it was a few years ago. And one think that it's in the mindset of the main banks at this moment, it's the increase in competition, it's also because 20 years ago to get into this market you probably had to have a footprint you must be have a point of presence say worldwide or least nationally it's the pin of course of you of your customer. But nowadays, it's all moving to digital.

So the cost of the entry it's lots lower and I also many of those think tanks are desegregating banking services from bank. So what's going on? It's now that those banks they have a portfolio of the products, so now they have to compete with for different segments for loans. They have a lot of competition. That it's also in a digital channel, and sometimes there are companies that are only in digital. [INAUDIBLE] about the big tech as well. For example, you see [INAUDIBLE] come to offer you checking accounts, or European banks in a different part of the [INAUDIBLE] competing with technology companies.

So the landscape changed completely. And another thing that it's also changing dramatically, is the customer's expectation. Nowadays, for example, in many of those surveys that is done with millennials for example, they say well, go to a branch office it's a bad experience, and sometimes even talk with a real person, it's a bad experience. They would like to have the same kind of experience and have for example chatting, go into Whatsapp, your Facebook, or search into Google and have that convenience.

So the [INAUDIBLE] technology landscape, on both sides, channel, be more digital. And a lot of problems happen in getting on board in this channel such as synthetic identities, that's the kind of problem. Any [INAUDIBLE] the regulation, how to use those. So combining of course macro trends and what is the technology drivers, what is the patronage that exists. And they also demand that exist because of those two areas are converging. For example, cybersecurity, it's no doubt it's a major issue for many of those financial inistitutions.

If you're looking for data breaches or issues that they had in the past few years, it's just accelerating. Each year you have more than the previous years. And also regulators are stepping up, and they're getting in and say, well I can let it be so free and the market in the way will deal with its cyber threats For example, in Brazil, the central bank it's came and said, OK, each one of those financial institutions they must have a CSO, and they must provide me in their plan and how you're protecting the data against cyber attacks.

And by the way, if you have any one of those security incidents, you have an number of hours to report that incident. [INAUDIBLE] Data, it's also an opportunity for many of those finance institutions but it's also a responsibility because many of those regulations that have happened in the last five years and looking for example EPR they end at the right to be forgotten. Put in a burden in a financial institution, they must provide data lineage. It means if someone said, I would like to delete my data, the bank must provide, have this if they delete the data, even a tape library.

And also if the financial institution they would like to deposit that data provided most personalizing services because it's also a demand that happened in the market. And has happened in financial institutions, it's the common ground it's there used to have framework we have legacy infrastructure. It's not something that just happened in the last 20 years. Most financial institutions they have 50 years and in some over 100 years. So now how do you deal with the speed of change and dealing with prove it acknowledge or legacy infrastructure.

At the same time the demand it amounts to zero aversion production. Some say, oh, we multiply infrastructure. And the idea is that you can speed up the process to deploy new applications, not have to wait three months to have a new version of the application. Of course, a big reason for in this rollout. The last thing about the technology drivers is do the workplace. Energy workplaces several financial institutions worldwide we express well, I'm not doing benchmarks with finance institutions anymore. I am competing with big techs.

And most of those companies, we are becoming more and more technology companies that deliver financial services. So a major concern is how you can attract the same talent that, for example, Facebook is attracting, Google is attracting? So they are going to also change their workplace to offer something that is more flexible to attract the talented people, and at the same time retain and make and create a productive environment for them.

And the structure transformation is another thing. There is no space anymore for having an infrastructure that you have to wire everything. You must be able to work with infrastructure on the software [INAUDIBLE]. You can have a structure and instructions inside that infrastructure from here.

And what it's translate-- what is the practice plan that gets out of this? The first, it's multi-cloud. Most financial additions, they have a plan to be multi-cloud, in many ways. It's multi-cloud because they have their own private or they're using public cloud, they're using more than a public cloud. They're used in different layers-- function as a service, platform as a service, infrastructure as a service, or for HBC, or for disaster recovery. They are using more than one vendor for reasons that they would elect to optimize for the workload, or they would like to be able to accommodate [INAUDIBLE] different countries.

For example, if you go to Germany, into Germany, not only the data must reside in Germany, but must be also in a German company. So for example, Microsoft Azure, they've hosted their data center inside of Deutsche Telekom.

And different companies, they have different regulations. For example, some regulators say, I would be, or if required, I can get inside your data center. And some cloud SaaS provider do not allow this. So that's reason that many financial institutions, they are creating this kind of a framework. In French geos, we use different cloud SaaS provider. It's optimized to work with that region.

And to be able to work in that environment, to be agile and have the portability that is required-- and there are also some requirements coming from the regulators-- container is a key technology. It's not because it solves a lot of this problem that exists nowadays to develop application. But it's because it's also-- it's allowed them to have that portability that is required.

And APIs, I know that it's not only in the financial institutions, but API is something that they have been talking for the last 20, 25 years. But nowadays, there are regulators driving to force banks to be more API-driven, like for example PIN banking. You must provide, for example, many of those countries that adopted PIN banking, they are-- oops, sorry. They are looking to how you can offer an API to have access to bank services, and data, and to, of course, partner with fintechs or insurance techs or reg techs. So it's something that it's an opportunity also in regulation and, of course, increase the efficiency. And microservice is something that make it viable.

And the DevOps-- the DevOps is something that it's a methodology or a discipline that is put in place, that many financial institutions are looking to how they can develop an application, and they've supported the demand of their customers in a way that it's as good as big techs. And at financial institutions-- I'm going to explain a little bit more-- DevOps is not enough, but it's the way to go. It's principle.

What it's translated to more practical actions, for an FSI strategy at a high level, they would like it with this transformation. It's a accelerated time to market, accelerated experimentation. Many of, for example, the financial institutions where you have data lake in the cloud, because we would like to test it. A lot of hypotheses don't need to be constrained by the infrastructure, so they would like to accelerate experimentation, have the prototyping; develop something that can detect, for example, fraud, and be able to deploy much faster; have a flexible partnering-- fintechs, insurance techs, reg techs. And also, there is a lot more, and the last one, it's a lot more on the insurance companies. It's IoT, internet of services, blockchain, things like that you can plug into this business framework.

And to enable this, you have some technical innovations that the financial institutions are promoting. And tech innovations, a lot more in the process and the discipline and how do you work. It's not infrastructure yet. But the technical innovation, it's polyglot enablement.

As I mentioned, I have been in this market for so long, and I remember when many financial institutions, they said, well, I know how to be very efficient in this market. We are now using only one language, it's Java. JE3-- Java Enterprise Edition. So that's the way that many financial institutions, they said, I'm going to be a lot more efficient.

But nowadays it's not. Nowadays, the idea is to enable different developers, that its use of the language is very efficient to do what they propose to do in a way that you also have the compatibility between-- among those companies. For this, we need also to enable DevOps automation. And many financial institutions, they have been going a step further in infrastructure as a code and work with compliance as a code. [INAUDIBLE] should talk a little bit more about this.

API support-- it's also the way developers, they see it by themselves the components that they are developing. That way, they can be asynchronous, and also you can offer services to other components in a way that you can accelerate the speed of development. Of course, using microservice architecture, allowing this blue-green deployment, this is so critical, especially when you're talking about, for example, in DevOps--

I have heard from many customers that we support worldwide. And they said, well, sometimes you all have been looking for KPIs, and those KPIs that you have is a lot more tied with the infrastructure. We have this Five9's availability on my database, I have this Five9's availability in the web server. And all the system, it's always available.

But the business unit, or at least at the business side of the bank or the financial institution, are as not as happy with the quality of their services that have been delivered. Why? Because many times, the application is not deliver what's expected, even in infrastructure [INAUDIBLE].

And then have the blue-green deployment to allow them to have this granularity. I would like to have the version 1.1 side by side with a 1.0. And if something goes wrong, you can of course turn back. It's not as such as a big shift that you make in infrastructure, and if, for example, that if something goes wrong you have to roll back, and of course, a lot of customers unhappy.

So applications scale elasticity as well, and then moving to platform as a services in a way to speed up the deployment, and also to make more predictable and less prone to errors on security and compliance. And to support this, the infrastructure that allows this transformation is based on containers, language is stack-neutral, lightweight, hybrid cloud, late binding deployment, and a common application design operation. I'm going to go a little bit deeper on those topics.

However, it's very-- [INAUDIBLE] financial institutions, they say, wow, that's beautiful, it's easy. But the problem that I [INAUDIBLE] my run cost. It means that the bank, it's trusted because we're stable, everybody happens as predictable. And that is our differentiation. We cannot afford to have a glitch, for example, in a checking account. So it's super stable.

How I can, for example, move to that ward, if your own ward is a lot more transactional, a lot more batch-oriented? It's not something that you have to destroy the past to move to the future. And of course, with the many years, what's happening, it's what they call the technical debit.

And it is happening now. The development is looking for how they can make the next personal investment application, and at the same time they're too operational. I would like to make it as stable as possible, because I would like to come back to home. So these [INAUDIBLE] different teams which have different objectives, of course, created such a disagreement. And of course, the disagreement is something they would like to solve if you would like to move it faster.

And the DevOps is one thing that has tried to help this. But looking for this specific case, I would like to, because probably you have heard about, for example, bimodal IT from Gartner. Bimodal IT from Gartner, he said, oh, yes you have that problem.

So one solution that you have is, you can split your IT. One side of IT, or type 1 IT, you focus on the legacy. You focus on keeping it stable, and moving forward, these costs are shrinking. And the type 2 IT, you focus on everything that is cloud-native technology, everything that is new. And you're starting from greenfield, you don't have a to care about the past. Of course, you have to create some interface, but have that agreement, but you can move a lot faster.

However, when you start [INAUDIBLE] many financial institutions, we said, wow, our work is lot more complex than this. OK, let's see what is the landscape that most financial institutions are. When they're looking for adoption of new technology, a new platform, they always have this S curve.

And basically, you have a phase that you build something. For example, if you remember the-- I do not know if you remember, but a long time ago, when they were starting putting mainframes, or distributed applications, or even cloud, you have the phase that you build something. Usually, you will focus one problem.

You say, well, I have this problem, I have this opportunity, and I would like to solve with this new, shiny technology. And you build something until you get to point you say, wow, that works, and it's worth to invest in this technology. And you start looking for problems that you can solve the same way.

Just remember, for example, when you start deploying a web technologies or web applications in [INAUDIBLE] institutions, it was like this. Let's do it, for example, in online banking. And then you started, OK, with online bank, we can start doing a lot more things in the banking on the back end, because you can just have in browser. So we're [INAUDIBLE] just scaling this.

Until you reach the point that they cross what they call the service line. It's, you are mature enough in a way that you can expand and offering this technology for different business units can consume. And it's when you, as IT inside the bank or in financial institutions, you have a product. And when you supply the whole demand that we have internally, it moved to a commodity.

It's still growing because, of course, you expected that the bank is still growing. And you still have demand. But they move to a commodity phase. In a commodity phase, we have some platform that is exactly in that [INAUDIBLE]. For example, in financial institution we say, wow, mainframe? That's what they have. They are really good in what they propose to do, and are really reliable.

And in that stage, when you're looking for distributed applications-- yeah, they're [INAUDIBLE] in that phase as well-- not as much for as a mainframe, but it's really stable. We are already across this line of utility. However, there is a lot of room for discussion, because in different geos and in different financial institutions, they have different maturity levels.

But at private [INAUDIBLE] like that. It's in the services line, become product, [INAUDIBLE] some of the financial institution [INAUDIBLE] and scale. But they are dealing with virtualization for the last 15 years. So, of course, they are still involving, still get mature. And what you called cloud 10 years ago, it's different that we're calling today.

So at some point, they are getting more mature. And the public cloud specifically for financial institution, they are in that stage. It's building, scale. One of the reason, it's regulators. Another reason, it's data gravity, especially for financial institutions, because they have the transaction in the on-prems and the mainframe, and then it's really hard to move one application out of on-premise and to move to the public cloud.

So of course, it's a matter of maturity. It's a matter of how to discouple those applications. But it's exactly in that moment. So when you're looking for the multi-cloud strategy, it's cloud. You can have that discussion, what it makes sense to run the private and public, what is the best strategy. But it's in the same package of the multi-cloud.

How do you deal with this/ So what I'm going to [INAUDIBLE] with you, it's, what are most financial institutions, they are taking when they're looking for the governance on each one of those platforms? So, mainframe, their strategy is a lot more mundane. [INAUDIBLE] many financial institutions, they don't want to [INAUDIBLE] and what they try to do is just maintain. If you can take out something of the mainframe, excellent, let's take it out. But I'm not going to shut it down or neither, for example, let them grow.

And distributed application, it's a lot more contained. Because these two can offer a lot, and especially for example in the highly transactional platform that it's dedicated, turnkey solution. For example, many financial institutions, they have a payment. Why should they take in a highly transactional-- a highly ITPA infrastructure that was well-designed, prepared to deal with this peak. You run in a distributed environment. Why should I put in the cloud?

No, I am sticking [INAUDIBLE]. And of course, with the evolution, you can move to the public cloud. But let's try to contain and then not let grow that much.

Private cloud, it's what more financial institutions, they would like to adopt and grow there in the private cloud because of lot of efficiency that exists in the public cloud, because there has a lot of uncertainty and, overall, they are focused more on innovation, doing things that it doesn't make sense to make internally.

I know that you probably have several examples that it's against what I'm saying now, just to give a sense what is the overall, for example. Because this kind of-- it's always in flux, the mindset on how to deal with the cloud. For example, let me give an example with this slide.

About 10 years ago, 8 years ago, many of the discussion that I had at that time with financial institutions who were looking, well, I think that it's for the cost perspective, there is no way to compete with the cloud SaaS provider, because they enjoy the scale. They can be a lot more efficient, because they are sharing infrastructure, and of course, we can optimize the time sharing as well.

And nowadays, in many financial institutions, they realize that it's not true. And financial institutions, they said, well, you know, I can be more efficient than any cloud SaaS provider. We have several banks also in the United States that say, well, I can be 33% cheaper than any cloud SaaS provider. There are situations like this.

However, banks of the equivalent size, for example, in Europe, they say, well, I know that it's when looking for IT itself, I can be cheaper than a public cloud. However, to operate a data center in Paris, operate a data center in Frankfurt, operate a data center in London, it's not that cheap. And my costs go through the sky. And I don't want to be in the data center business.

They [INAUDIBLE] to balance all those costs, [INAUDIBLE] well, looking only for the costs-- but what's happening, it's with the technology that exists nowadays for most of this private cloud-- for example, a lot more focus on container, you have virtualization of a network, you have virtualization of the storage-- the costs go down.

That's the reason that many financial institutions now, they say, well, I can go to the public cloud, but just because they can offer something that I cannot do by myself. Or, I can go to the public cloud because, in my specific situation, they are cheaper. It happens, especially when looking for resilience for smaller banks, or you're looking for the cost of the operation. There are some of the [INAUDIBLE] go in either way.

Another a major shift in this strategy that I haven't seen in also in storage. And for [INAUDIBLE] what storage-- what kinds of storage that you see in organizations, you basically have three. You have object store, that it's pretty new, it's 14 years old. So it was created by-- it was designed to work in a cloud with the cloud-native applications. And you have file-based and the block storage.

In the financial institutions, they have 95% percent of their storage, it's file-based and block storage, because those applications were created a long time ago, and they still rely on these databases, still using block base for many of those applications as well. However, it's not friendly to move applications that rely on those storage to move to the cloud. That's the simple reality of the life.

So, what's going on? In the object store, they have, in my opinion, two elements that make completely and attractive for financial institutions. Another thing, I am talking about financial institutions, because it's, of course, my background. But I think that it's, in the whole, when looking for cloud application. One is the protocols that you use to have access to the storage. It's REST, so over HTTP.

So if you imagine, for example, develop an application, that is the protocol. You don't have to deal, what is the storage of drivers, nothing. You access using HTTP. So unless you are developing in Fortran, COBOL, something like that, any language supports this protocol-- straight and easy, and giving you a lot of freedom on where you are going to execute.

And that the biggest strength is scalability and distributed access. So you can distribute, for example, object store to different data centers, and you'll still be able to access in a way that is pretty efficient. So, we are seeing also the whole market moved to use object store.

For example, in financial institutions, one major user, or at least application, that uses storage, for example, is Splunk. They are now access have a S3 interface, that it's object store. And you are seeing also, for example, many financial institutions adopt a project like SAF, that you have an object store underneath offering file and the block storage.

So think like that. It's what it's changing. And of course, when they're looking for data, how do you store data, how do you consume data, looking for data analytics, machine learning, it's relying on object store. So if you look for object storage, something that is going to grow like-- I don't know. You grow like a rocket. I don't know how-- but it's something that is going to grow a lot. And file and block storage, we are expecting to keep the same or even shrink in a long period of time.

Looking for the quality of this storage, and also, what it's changing in the strategy of many financial institutions-- well, in many financial institutions, they used to have these three-tier architecture, what [INAUDIBLE] three-tier governance on the storage. They look at you have a cold storage or cold tier, warm tier, and hot tier.

When you're looking for the cold tier, you would like to provide the tier that you can provide the most terabytes per dollar that you can get. Because it's kind of storage you it's write once and read multiple times, or maybe it's even something that we store and you hope that you do not access so often, such as a deep library. It's something it's going in deep archive object store. They have different usage, and each financial institution will have different strategy.

And when you're looking for the performance at [INAUDIBLE] TP, payment system, transaction of system, they are in hot tier. This is where we tried to find what is the best I/O per seconds per dollar. And you have something that is in between that we call warm tier.

But what is happening is we have the costs of SSDs that it's almost the same cost of a hard disk. Actually, it's basically, you're getting performance for free. So we're saying that it's squeezing off this one tier. Many of those technologies that was using the cold tier is getting a lot faster, because not only the SSD, but also doing the architecturing, for example, some of those BIOS systems. And you are getting that it's the hot tiers are getting squeezed.

So you are saying that's another reason, that it's many of those technology that is object-based storage, it's taking many of those workloads that is in the warm zone [INAUDIBLE] change that you are seeing. When you're looking for the network side, it's a lot more interesting, in my opinion. Because when you're looking for putting more and more banking application in the cloud, so you start [INAUDIBLE] the financial institution as a whole, especially in retail banking.

It's like, well, why I am using, for example, dedicated circuit, which one of those brains to have access to my data center, if eventually the application's running in the cloud? So it doesn't make any sense. It's decision that mean financial institutions, they took to have dedicated circuits, because they, at that time, their mindset, it was, that's my network and everything that it [INAUDIBLE] trust it, because we put in a firewall, and they have ITS, they have everything to protect the perimeter of the network.

And, you know, if they experience that it's not completely true, and it's not because you are in your private network, that you're secure, many of those attacks happen inside in many of those big networks that exist in many financial institutions. So that is-- and also, the reliability of those links that exists to the internet, it's now much better than 20 years ago.

So what is happening now, it's a software-defined one. It's a major trend that we are seeing in the last few years, and I think that should be in the next few years as well, that instead of relying on dedicated MPLS links that is pretty expensive. You have two or three internet connection links, and you change the whole intelligence to the branch-- instead of, for example, we have for example that it's very common in a branch, you have four to eight boxes in a branch to offering the connectivity for the branch. One is for the modem to connect; another one it's for file sharing, print server; another one, it's for wireless. They have different boxes.

Now you have one server, that everything run as NFVs inside that box. And you have the security on the edge, and they can optimize the link. If it's an application that it's running on your data center, OK, go straight to the data center using a VPN. If not, I'll go through the different VPN, or you [INAUDIBLE] for example, the application, that it's running in a public cloud. Have that flexibility. So that is one of those strategies that many financial institutions, they say, well, that is the kind of application or the way that I'm looking for cloud that I can save [INAUDIBLE] band of my strategy.

So another thing that-- when looking for the public cloud, many financial institutions, they realize they're very late in the game. It's when the regulators ask, for example, for the financial institutions, OK, you move this regulated workload to cloud SaaS provider 1. And do you have a plan if, for example, this cloud SaaS provider get out of the business or are not able to offer you this service anymore?

And it is happening now. Many countries, many regions, they are putting regulations so that financial institutions, they have to provide a plan B or a repatriation plan, or move to the different cloud SaaS provider. So that that capability is something the financial institutions, they have [INAUDIBLE] for. Of course, is not day to night, but at least you have to provide a capability that you can migrate in 180 days, 90 days, depending on the regulators.

And for the application standpoint, it's lot easier to solve-- containers, as I mentioned. But at one hard problem that exists is data. We did a POC a couple of years ago, for example, moving 10 petabytes of data to the cloud. 10 petabytes of data. I know that it's sizable, but it's just to have an idea. 10 bytes of data over a dedicated link, a dedicated 10-gigabit [INAUDIBLE] or 10-gigabit link.

And it doesn't matter how much we slice. Of course, you optimize the transfer of data if you slice an 8 mega, 16 mega, 32 mega. But the problem is, even if you optimize, you're taking about 15 to 30 days going through the wire. And it's not the only problem. This transfer cost only takes about $1 million. So it's pretty expensive.

And if you have to transfer from one cloud SaaS provider to another cloud SaaS provider, there is no quality of services. So you have no guarantee that you are able to transfer that data. And the major solution that it can come out, oh, we can call truck as a service. It means have a Snowball that you can copy the data and move to the cloud.

Now, this doesn't look like this, because many of those application and financial institutions, they're transactional. You have no capability should just freeze, copy the data, restore it in the cloud, and make it sync again. It's not that easy. You can make it, but it's not with the legacy application. You cannot just throw to the cloud.

So in many financial institutions, they know that they have hundreds of thousands of applications, and what they need to build, it's the bridge. They must have dedicated links, or they have a high-speed network with those cloud SaaS provider, if you are-- or at least, it's equivalent to what data that you are putting in the cloud, especially if it's regulated workload.

So I know that it's a lot when they're looking for financial institutions. These, the cloud SaaS providers, some of those issues to move to a cloud SaaS provider, for example data gravity as I mentioned, many of those applications were developed, for example, using middleware, or the communication of databases is synchronous-- things that is simply not easy to move to the cloud.

On the other side of that, it's also cloud SaaS providers that also is a source of concern for financial institutions and also regulators. For example, cloud SaaS provider, they can have access to the data. And some regulators do not allow this. Because if, for example, someone read the data-- I think that it's supposed to be confidential. It's something that's scared to death many of those regulators.

So another thing that it's a lock-in, if you go to something that it's only one cloud SaaS provider can give it to you, and you developed something that is really sophisticated over there, you have to spend so much money or time to move out of the cloud SaaS provider if you need, none of those banks would like to marry for an eternity with this cloud SaaS provider. May try to measure the risk. I can adapt and run [INAUDIBLE] for this cloud SaaS provider, but I don't want to have another mainframe such as to migrate out I need 5, 10 years and that amount of millions of dollars and a huge risk.

And also, there are the ways that cloud SaaS providers handle the data, it's not in line with some regulators. For example, many of those regulators, they said, well, we say if, for example, the customer demands you to delete the data, you have to provide evidence that you deleted data. And when it goes to the cloud SaaS provider, they say, oh, if you happen to delete the data, that's the procedure that we usually follow. But it's not an evidence that data was deleted. So that kind of incompatibility that sometimes is a barrier for many financial institutions to go to the public cloud, it's how to operate in a way, even when you're looking for the shared model, [INAUDIBLE] it's not enough.

So what is the actual status [INAUDIBLE] have seen in many financial institutions? When they're looking for an organization, any financial institutions, we already have this infrastructure. They have been working for several years, 15 years already being a virtual environment to be a lot more stable and mature. And now with it containers, what you call here on the top as a cloud B in financial institutions, where you get, OK, let's start a playing with DevOps, and DevOps and containers. But there is no dedicated infrastructure for this.

And what I am seeing, and based on my pure experience, it's like when the financial institutions, they start is seeing 5% of their workloads run in the containers, they start to look into having a dedicated environment for the containers, because the base of the development cycle with containers, it's a lot faster. So it's not the same as four years ago. Now it's a lot faster.

So they're starting have a dedicated infrastructure for the containers, until you get a point that you probably-- the virtual environments you run on top of containers just to have compatibility. But at that moment, [INAUDIBLE] financial institution, it's moving from phase 3 to phase 4.

When you're looking for cloud-native applications, it's something that we all know, this 12-factor architecture. And we have different layers of abstraction, and of course, they're easy to manage. It's different. For example, when you're looking, OK, I'm going to develop an application from scratch to be a cloud-native application, I have to look for those 12 factors.

And if I go to the platform as a services, so I have a-- I don't have to deal with everything. If I go to function as a service or serverless computing, I have just those, that it's marked by white, blue, that is, for example, code base, dev, and the product parity, and [INAUDIBLE] process.

And I brought this for discussion because, of course in many financial institutions you don't have-- let me jump another slide here. You come back. I think that it's good to explain this. It's in a different other--

This, this slide. Because as much you are close to the infrastructure as a service, it means I have to deal with these 12 factors. It's my concern, or my duty, my responsibility as a developer. When I move to platform as a service, I have less, and function as a service, I have less.

However, the compliance is increased abstraction. The compliance I can also incorporate in the platform. That is a good thing for many financial institutions, because they say, well, for example, I am developing application for credit card. Credit card, they are regulated by PCI DSS. And they dictate how you are going to store the data, manage the data, what is an encryption key, the strength of the encryption key. Everything is defined by the regulation.

So the developer, they do not have to understand about PCI DSS. They can-- for example, you can abstract it, all those requirements, in a function as a service. So when you put in a field to get, for example, a credit card, the platforms already deal with this protection of the data. And of course, platform as a service gives you a lot of more flexibility, and you have some abstraction. In infrastructure as a services, you can have all.

However, if you-- for example, many financial institutions, they cannot afford to go all to a function as a service or all infrastructure as a service. You have to design an infrastructure, or at least the strategies, for adopting cloud. It's a balance of those.

For example, if you're doing, for example, a simulation, Monte Carlo simulation; you are doing, for example, risk checker; or you are doing, for example, the [INAUDIBLE] price, a PT solver, it's something that you can handle in infrastructure as a service much easier, and a lot more flexibility, with better speed.

And if you're doing, for example a personal finance application, function as a service is a lot better. There is no question. It's event-driven. For example, someone opened the app and started, and of course, it initiated the application in the cloud. And platform as a service, in between.

So that's the kind of the structure when we're looking for [INAUDIBLE]. It's not only what I'm going to run my virtual machine? No. You have that spectrum that you have to look for.

So, I'm sorry to jump to that slide. I'm just going back. When you're looking also for data protection, data protection, it's for sure the major concern when you're talk about, for example financial industry, because, of course, it's regulated. And you can see most of the regulations, maybe 70% or 80% of the regulations, rely on privacy [INAUDIBLE] you handle the data.

So this is the list that I collected from many interaction with the financial institutions, and how they deal with cloud SaaS providers, what is-- they create such as a minimum. especially when I was talking, for example, platform as a service, function as a service, that is the minimum how you deal with data.

Of course, different financial institutions or different geos or different regulators, they demand different evidences that you are implementing this. And you have to provide in a different format as well. But when we're looking for the security as a whole, that's the minimum requirement that you have to provide when you design your application or design the infrastructure.

Let me give you an example. For example, GDPR-- General Data Protection Directive. It happened in Europe, and in many of those financial institutions that we have business in Europe, they have to implement this. For example, in GDPR, they have this what are called data lineage. Of course, you have to have a map of what is the data of this specific person or institution. They are inside the institution, because if I have to delete, I have to go to where is the data residing, and I have to delete and provide the proof.

Of course, if in the past a bank can just, oh, get inside data center, that was a disk, and they crash it. They can just pull the disk and then destroy the disk, and have no-- they don't have the obligation to provide any evidence. But nowadays, if you have in the disk and they crash in the data center, and it happened that the data that was required to delete, it wasn't in that disk, they cannot just say, oh, this disk was crashed, and then I destroyed it.

No, no, no, no, no. You have to tell me who got into the data center, who pulled the disk off, and what method that you used, and date and time that destroyed that disk. Because you can provide that kind of evidence. And of course, financial institutions, they don't want to rely-- that's not secret. They don't want to rely on process and people. They prefer to invest a lot more in tooling.

For example, one thing that many financial institutions, they're using now, it's, oh, OK, now I'm using in all those servers that I have, in my infrastructure that I have, PII, or Personal Identification Information, I am using, for example, OPEL compliant drivers, that it's all encrypted. Because even if I do not know what happened with the data because of someone's screw-up, I can prove that the data was encrypted the time that was crashed.

So think like that it's changed the mindset how to deal with financial situations when looking for the cloud. And as you can see here, that is the flow, or CICD pipeline-- Continues Integration Continuous Deployment. You have to go through those steps.

Of course, with CICD pipeline you would like to make it as fluid as possible. But we still have the moment that your developer, you have the quality assurance, staging. Of course, any of those tooling tools that exist for the web, make those steps pretty easy, or at least completely straightforward. But we still have the security review of the compliance.

That's the reason that at the begin of the presentation I said, well, OK, for many financial institutions DevOps is the path to go, but it's not enough, because those two red circles that you can see, because many-- of course, not only financial institutions. I mean, the security is important for everyone. But in the financial institution, they have this kind of-- they bring it to another level, if we can say this. Security is really important for them, because if they have a breach of that security, it's really painful for financial institutions, as we have seen in the previous years.

But what's happening is, after you developed something, you go to security review, you realize, oh, there is a problem. I have to come back. Now I pass for the security. That is another step of that compliance. Are you dealing with the data, and you are providing evidence that you're dealing with the data the way that it's expected? And not only expected in the whole bank, sometimes you'll have to deal with the data in a specific geo, so the compliances become a lot more complex.

So if the-- something, those is not compliant, you have to come back to development, change something, and then probably you have to go through the security review again. And you can imagine what is the nightmare. What many financial institutions, they're trying to-- many of them, they have very good success doing this. But it's a major trend. Everybody is looking to have this, what we call continuous compliance.

And continuous compliance, it means [INAUDIBLE] development they try to incorporate as much of security best practice and compliance from the day zero. It's a lot easier when I am talking about, for example, function as a service or serverless computing. I can incorporate something on a platform as a service, but on infrastructure as a service, I have some templates that can make it easier, and I can develop on top of these. But I don't want to have the security and compliance late in the game, because it can be costly.

And when you're talking about this, I know that it's, you say, wow, of course it makes total sense. But how to deal with this? What is the tools and solutions that is most used, for example, in that space? Well, of course, when you're looking for the cloud, you have what we call this Common Cloud Core. You should have a cloud management platform, that in the cloud management platform you have the tooling that manages the infrastructure that we need it.

For example, in that layer that you can provide, for example, confidential computing using, for example, TEE-- Trusted Execution Element. At Intel we have the Intel SGX, Software Guard Extension. And you can use to protect the keys, you can also protect the content. It's dependent on how you use it. But it's something that manages your infrastructure.

And it's not something that you have overlooked. Because if the infrastructure does not provide you a support for your code, you are being, at the minimum, in a suboptimal environment. And platform as a service, It's where you, of course, can make things reusable. You can also-- of course, in many financial institutions they are taking this in a way that it's, OK, let me create, for example, a specification database that I have a lot of triggers or configurations, that it's good for storing a credit score, and they put it there.

And I am developing an application, I just grab this database that I know that it's compliant. I know that if they have an attack that I can use a stress test on top of this or, say, penetration test or security stress. It changed the name during the years, but you got the point. The idea is that you have this configuration that the security team already provide in a way that it's accelerated the point that you don't have to go to check a lot of things from the start.

And you have the automation frameworks. And in the automation frameworks, it's where things shine when they're looking in financial institutions. Because you have the infrastructure as a code. Infrastructure as a code, you can optimize or automate the location of the resource or deployment of the application. And of course, many of those elements that you're looking at security and compliance, it's infrastructure-related.

So many financial institutions, they are taking these and, OK, extending that capability and integrate what is called compliance as a code. And to give an idea, I put in here two of those probably most popular solutions out there. And one [INAUDIBLE] InSpec.io, that it's from Chef. They can have those compliances, templates. And when they deploy an application, just execute, and it will check.

And you can allocate numbers, for example well, it's not pass or not pass. Or you can say well, that is not ideal. And I can put in a number and, say, try to measure the risk if the application goes live. I'm not expect to have zero in the real ward, but you can at least create [INAUDIBLE] metric that measure the risk if, for example, that application goes live and you have some security concerns with this.

And another one that is also practical, you can look into Google. It's Test Kitchen. And there is a lot of practical tools that also you develop in a container in your environment, if you're on a desktop, and you could transfer all those best practices moving back and forth. And it's something that it's allowing you to create this continual compliance.

Of course, many financial institutions, they're developing their own tools. There is an organization in the United States that called FINEOS. They have this, what they call cloud certification.

And the cloud certification, we have some practices and codes that not only provide you easy-to-go-- it means you develop an application, and we can test using toolings, automation tools, that assure that it's compliant-- but also, when it's deployed in a cloud environment-- doesn't matter if they're on-premise, off-premise-- they can continue checking that they're compliant. Because that is another major issue. It's not they're deploying compliant, but how to make sure that it keeps compliant in the whole life of the application.

So I already presented that slide. I know that it's-- I know that we started a little bit late. So I think that we are on time. And that is my last slide.

I think that it's, when looking for financial institutions, what most financial institutions, we are looking, when they see cloud, is they know that it is unpredictable, future in financial services industry. Things are changing too fast. I think that nobody is going to say, well, in five years you'll be there. No.

Trying to make the decision in architectural and development, that it's flexible enough that you can come back, or at least accelerate and move it faster when you need. So, future-proof architecture. Future-proof architecture, everybody loves to talk about "future-proof" architecture. That's the reason that I put it in quotes. It's just thinking about flexible design.

This is something that, if you're looking for infrastructure and in architectural level looking for the-- it's a framework that you can decouple and couple, things like that. Or at least for components or pipelines, instead of products that deliver something but [INAUDIBLE] in the pipelines, you'll probably be in a better shape to adapt to the future, not to have to destroy everything that you built in the previous year to restart all over again.

And another thing, that it's a mindset that they haven't been seeing change a lot. It's that everything as a service. Because in many financial institutions, what happened, especially when looking also for compliance, it's-- replication of the code. You do something in a code, and you have to develop something that has the same functionality, but it's in a different language, [INAUDIBLE] starting, OK, I'll develop everything on my own, and they keep that code.

It's almost criminal when you're looking for how do you deal with this in a major organization. Have the mindset and [INAUDIBLE] software architect and think everything is a service in a way that you can take advantage of this cloud-native application, microservices, and APIs, to optimize the infrastructure.

And another thing is, build bridges and avoid silos. I know that it's-- I have followed many discussions about financial institutions adopting cloud for the last 10 years at least. And they say, I'm not going to the cloud. When they discover that we need to launch a product and say, wow, I can take advantage of, for example, this capability in the cloud, but I don't have this. And it will take maybe a year to validate and [INAUDIBLE].

Let me give an example. I met, for example, financial institution, they were developing a chat bot. It's like-- for example, Bank of America, they have Erica. Or different banks, they have one chat bot that you can talk with, or at least you go and chat. And for example, this financial institution, they said, well, I have to deal with 16 different languages.

And the problem is how I'm going to train the speech-to-text for 16 languages. I need at least 10,000 hours of content, of course, the audio with translation, that I tag it, that I can train my model. And even if you have this, it's not guaranteed that you have an excellent product.

So why financial institutions, they have to invest in this, we can just consume that services from the cloud SaaS provider, because it makes a lot of sense when I explained the beginning, innovation. So, build bridge. If you are not going to use, look into how those technology works and how you can incorporate, even if you're not using now.

The most successful financial institutions, when they're looking for adoption of the cloud, they are building bridge, they're looking at how to use this technology. Even a small fraction-- oh, I'm looking for the next year using only 1%, 5%, for example, this cloud SaaS provider. If it makes sense, of course I can increase, but I don't need to get in that trap then not be able to develop enough product because I'm not able to consume some services that is needed for the services.

And that's what I have for today. I was planning for one hour. i know that--