Red Hat X Podcast Series: Open Banking Challenges and Opportunities

Learn more about how Ivory Service Architect speeds up open banking adoption.

Brian:

Welcome to the Red Hat X Podcast Series. My name is Brian and joining me today is Dr. Alex Heublein, Chief Revenue Officer at GT Software. Today we’ll take a look at GT Software’s Ivory Service Architect, to understand how it can help banks rise to both the challenges and the opportunities of the change taking place in their industry. Alex, welcome to the Red Hat X Podcast Series. Thanks for joining me today.

Dr. Alex Heublein:

Thank you as well.

Brian:

Well, good to have you, hopefully you’re having a good day and ready to have a little fun right now?

Dr. Alex Heublein:

Yeah, absolutely.

Brian:

First of all, tell us about GT Software and how you are positioned in the market.

Dr. Alex Heublein:

Yeah, absolutely. So GT Software, we’re an industry leader in mainframe modernization and integration. So, we have a flagship product, what we call Ivory Service Architect, and that flagship product is really a drag-and-drop, no-code development platform that lets our customers go out and create REST or SOAP APIs to their mainframe environments very, very rapidly with the right level of security, the right level of stability that you would expect from a mainframe environment. So, our customers typically are able to generate APIs into their mainframe applications much, much more quickly, in a matter of days or weeks rather than weeks or months. And they’re also able to maintain those APIs in a much more cost effective way over the long haul.

Brian:

Very nice. Well, we’re talking obviously about the bank industry today. And so I wanted to know how big of a threat is open banking to traditional banking models?

Dr. Alex Heublein:

So I mean, I think it’s both a threat and an opportunity. I think that when people looked at it in the beginning, they sort of looked at it more of a … I think they had more of a “who cares?” attitude. I think as we’ve seen a lot of fintechs come to light and rise over the last few years, I think banks are both seeing it as a threat as well as an opportunity. They see it as a threat in the sense that there is the threat of disintermediation by a lot of the fintechs that are out there. Those fintechs can take multiple accounts that you or I have that have all of our different banking, investment information, pull all of that into a single pane of glass and then add value added services on top of that.

But the challenge with that for a lot of the banks though, is that disintermediates them, that removes some of the customer relationship that they had previously with those customers. So, the banks want to be full service providers, but they’re seeing a potential threat in that regard. But there’s also an opportunity. There’s an opportunity to actually build closer linkages to both corporate customers and consumer customers. So, I think they see it as both.

Brian:

Are open banking standards being mandated by the governments, or is it up to each bank to determine their strategy on this?

Dr. Alex Heublein:

Yeah, it really depends on what country you live in. So for instance, in the UK, the UK mandated a few years back that the top nine largest banks in the UK had to open up their systems. And so those banks very much viewed that as a, “Oh great. The government’s telling us something that we have to do.” Yet another regulation that we have to go deal with.

Brian:

Yeah.

Dr. Alex Heublein:

But what’s interesting is we’ve seen over the last year or two, there’s been a significant change in the way that they perceive open banking and the mandate. They viewed it as a compliance effort. Then they started to view it as. “Well okay. Actually, this makes a lot of sense.” And now they’re starting to see really just in the last year or so they’re looking at it saying, “Wait a minute, we can monetize this. We can actually make more money by doing this” rather than just having to go out, comply with the government mandate.

Brian:

Interesting.

Dr. Alex Heublein:

If you look at what’s happening in the U.S. there’s no government mandate to do it, but it’s more of a voluntary effort, but a lot of banks are realizing, “Hey, this actually makes sense. This makes sense to go do this. There’s a monetization angle to it. And so we should go out and actually do it rather than dragging our feet on it.” So it’s a mixed bag. It depends on where you go. It depends on the country. So there’s both government mandates and there’s also sort of consortium that are being built voluntarily to implement open banking standards.

Brian:

Okay. How much growth are we seeing right now with open banking?

Dr. Alex Heublein:

Yeah, so the growth rate is really high, if you look at it in absolute terms as a percentage of all the financial transactions out there related to banking, still a very small fraction, but the growth rate is tremendous. We’re seeing a very, very large growth rate, 10% a month type of growth rate in the transaction, particularly in Europe. I think it’s really taken off early in Europe because of the government mandate, but seeing very, very high percentage growth rates over the last year or two. And we don’t envision those slowing down. This is a trend that is increasing. More and more banks are seeing it saying, “If we don’t get on board with this, we’re really going to get disintermediated.” Once those types of effects start to occur, then you see kind of a snowball effect where more and more and more banks get involved in open banking.

Brian:

So really you’re seeing that government mandates are creating better growth, which is kind of what you were alluding to in the third question.

Dr. Alex Heublein:

Yeah. I mean, I think so. I think the government mandate sort of kick started the growth and the industry then looked at it and said, “Hey, this actually makes a lot of sense.” There’s a monetization angle to it, and it’s really starting to build upon itself as a result of that.

Brian:

That’s great. What are some of the biggest challenges that they’re facing right now when it comes to implementing open banking standards?

Dr. Alex Heublein:

Yeah, there’s a bunch. I mean, there’s obviously the traditional security challenges that you run into. One of the biggest that we see and that we tend to address is the integration angle. Because essentially open banking you’re providing APIs into your core banking systems to the consumers, to third parties like fintechs, to your corporate partners. So there’s a couple of challenges there, right? One of them is, I’ve got to go build an integration layer. The big challenge there is that I can build it once, but the standards are evolving at such a rapid pace that I have to constantly keep changing. I have to constantly maintain these APIs when I build them. So, the other challenge in doing integration is that the majority of core banking systems are still mainframe-based. And mainframes are not the easiest things in the world to integrate with. So we see a lot of our customers struggling with building that integration layer and then also providing the same level of security, reliability, scalability that they are used to on these mainframes.

Brian:

Okay, well, that’s good. So they can take care of that when the security risks are happening essentially. So they’re moving towards that. Any other challenges you’re seeing?

Dr. Alex Heublein:

You know, another big challenge that we see is really around reliability. When you look at the numbers coming out of Europe in particular, we see very, very wide disparities between the reliability of these APIs that are being deployed for core banking. In some cases you’re seeing three or four nines of availability. In some cases you’re seeing something like 97% availability. And 97% availability sounds great. But until you realize that in a month, that’s almost a day a month, right? So reliability is a challenge. The other challenge we’ve seen in implementing these integrations is latency. I mean, you want to have fast round trip latency times back to the callers. And honestly the banks in Europe were all over the place. I mean, some of them, the best in class ones are at 250 milliseconds, the worst in class were probably at 2,000 milliseconds. So there’s a very wide disparity between both reliability and latency of these interfaces that are being deployed.

Brian:

Sure. Okay. So let’s talk about integrating with legacy mainframe systems. Why is it so difficult? I mean, it seems like it should be pretty straightforward?

Dr. Alex Heublein:

Yeah, you would think, wouldn’t you? No, and it’s interesting because, I mean, there’s a bunch of factors involved.

Brian:

Of course, yeah.

Dr. Alex Heublein:

Probably the biggest factor is that when you look at a lot of industries, but particularly the banking industry, the vast majority of these applications are bespoke applications. They were custom built and they were built originally and architected originally, 30, 40, 50 years ago.

Brian:

Yeah.

Dr. Alex Heublein:

So, integrating with those systems is very challenging. They have very different data structures than we’re typically used to dealing with in sort of modern systems. The applications were never really designed to be integrated with.

Brian:

Okay.

Dr. Alex Heublein:

There’s a huge number of green screen applications. You know, the old green screen terminal applications, you wouldn’t believe the number of organizations that still use those green screen applications. And that’s really the only good way of getting data in and out of those systems is through a human being typing on it.

Brian:

Yeah.

Dr. Alex Heublein:

So there’s a variety of reasons that it’s difficult to integrate with mainframes and we see a lot of companies struggle with this. And it takes them a lot longer to implement these integrations. And they also run into challenges with performance and latency as we talked about. So it’s a big challenge.

Brian:

Yeah. It makes a lot of sense, but you’re helping them with that, which is good. So let’s talk OpenShift and Ivory Service Architect. Why is OpenShift such a natural fit for helping banks utilize your Ivory Service Architect to adapt to open banking?

Dr. Alex Heublein:

Yeah, I mean, I think there’s a couple of key reasons, right? When you look at these applications, these core banking systems are obviously mission critical applications. And pretty much all the applications that are left on mainframes are mission critical. And it’s one of the reasons they’re the ones that are still left on the mainframes. All the low hanging fruit, most of it has been moved off of the mainframes, but a lot of people don’t want to take the risk of moving their core banking system off the mainframe. Because if you fail in doing that, you could probably lose your job if you are a CIO or CTO. So there’s a lot of risk involved in being able to do that. So the fact that these are mission critical applications, one of the things that OpenShift really brings to the table is the security, is the reliability, is the scalability inherent in the platform, right? Because they’re used to this incredibly reliable mainframe system.

They’re used to very, very fast transaction times. They’re used to incredible scalability and performance on these mainframes. And so the challenge is if you go on and implement an integration layer, which is really your communication to the outside world, and that is unreliable. Then there’s no point having super reliable mainframe systems, right? So, they’re really looking for a platform that gives them the ability to have the fault tolerance to achieve the levels of reliability that they want. They want to be able to scale out to provide the performance that they’re looking for. So OpenShift is just a natural fit for us. I mean, it’s an incredible platform, gives us the ability to go out there and implement this without these integration layers, without the customer having to worry about all those details and do it in a way that’s enterprise class, mission critical and can match the performance, the security, the scalability, and the reliability that we see on the mainframe environment.

Brian:

Awesome.

Dr. Alex Heublein:

I think that’s probably the biggest reason that we’ve partnered with Red Hat and it’s a fantastic partnership to be able to do that. Because a lot of customers really, they don’t even know how to implement systems that are that reliable and that scalable. Because you have to do it in the architecture layer.

Brian:

Yeah.

Dr. Alex Heublein:

So it’s a great fit for us as GT Software.

Brian:

Oh, that’s great. And you’re right. You know what I mean? They just want it to work and they don’t want to have to worry, like you said, even worry about all of those logistics and those details. And so making it a very easy process, and also a very safe and effective process. I mean, that’s exactly what you’re doing. So I’m glad.

Dr. Alex Heublein:

Absolutely.

Brian:

Good to hear that.

Dr. Alex Heublein:

Absolutely.

Brian:

So what makes Ivory Service Architect different then from traditional integration methods?

Dr. Alex Heublein:

I mean, a couple of things really. One is that we’ve developed a very, very easy to use, very rapid development platform for these integrations. It’s completely no-code, completely drag and drop, and allows our customers to go out and build these integrations like I said earlier, in a matter of sometimes hours. Now, I’ve got to tell you as a software developer for many years, I’ve heard no-code drag and drop platforms, by the thousands. If I had a dollar for every time I heard about one of these things, we wouldn’t be talking, right?

Brian:

Exactly.

Dr. Alex Heublein:

I would be living on my private island.

Brian:

Yeah.

Dr. Alex Heublein:

So, most of them don’t work, or most of them don’t work outside of a very specific context. And what you find with Ivory Service Architect, it actually does work. One of the reasons I joined the company. And one of the reasons it works is because it is so focused, right?

We are focused on mainframe integration. We’re not trying to integrate with the entire world. We’re trying to make mainframe integration fast, easy, secure, reliable, scalable, et cetera. And so that really helps when you’re designing a drag and drop no-code platform that limiting your scope and, and getting very, very laser focused on one thing and doing one thing extremely well, that really helps. So not having to go out and build a lot of code, may test a lot of code, maintain a lot of code, go in and implement these APIs very, very rapidly. You can modify the APIs and create new APIs very rapidly as these standards are changing, because the industry standards are changing literally overnight throughout the world. So there’s many different standards out there. It’s the great thing about standards, right? There’s so many of them that you want something that’s very flexible, very adaptable, very easy to configure and customize and change things as you go through.

Dr. Alex Heublein:

But you also have to make sure that the level of testing is there. And so anytime you get humans involved writing code, we’ve got to rigorously test that code because we’re dealing with financial transactions here, right? This is real money, right?

Brian:

Exactly.

Dr. Alex Heublein:

So the ability to go out and have code that’s pre-built, pre-tested by a machine, we’ve had this product in play for over a decade. That gives a lot of our customers a certain peace of mind that they know we’ve rigorously tested the software to produce results. It takes a lot of the human error out of these types of transactions and out of building these APIs. And that really gives a lot of our customers a great peace of mind.

Brian:

That’s great.

Dr. Alex Heublein:

The other interesting thing is just the total cost of ownership. When you make all those changes and the standards evolve so rapidly, your total cost of maintaining those APIs goes up dramatically if you’ve got an army of programmers trying to implement them. So, it’s a big difference, right? We see much, much faster, up to 10 times faster implementation of APIs then sort of traditional coding methods. The other nice part is the developers that implement the APIs. You know, A, they don’t have to be mainframe experts to build APIs, believe it or not, we make it that easy to go out and build integrations to mainframes. You don’t have to be a mainframe integration expert to use the tools that we provide, nor do you have to necessarily be an expert in modern integration standards. You don’t have to be a REST or SOAP guru, or read JSON formatting every night before you go to bed. So it’s actually a bridge between the old and the new and allows people that are very close to the business processes to be able to go out and implement those APIs in a way that makes sense for the business.

Brian:

Wow, that’s fantastic. So I mean, really what you’re saying is for the customer it’s faster and more efficient. It is more cost effective and then effective in general. And like you said, even it gives them a significant peace of mind. They’re not having to hire as specialized of programmers really to handle this guy. I mean really, it’s just, it’s a huge win for the businesses.

Dr. Alex Heublein:

Absolutely. And when you couple it with OpenShift and you get the reliability, the scalability, the security, the performance, you combine those two together and you’ve got a really, really neat solution for customers that makes their lives a lot easier.

Brian:

Wow. So now do you have a specific example of some feedback you’ve received from one of your customers that they’ve implemented this and now it’s just like, “Wow, look at what’s changed for them.” Do you have anything like that?

Dr. Alex Heublein:

Absolutely. So, I mean, let’s take a good example from a project that we did last year. There’s a large bank in France that had the goal to be the first bank in France to execute a real-time payment. So they used Ivory Service Architect to go create the integrations out to the Clearpay platform to actually implement the first real-time payment in the country of France. What was neat about it is that not only do we give you in our product the ability to handle inbound requests for APIs and then build APIs that respond to those requests from outside of your organization. We also have the capability of very, very quickly and easily enabling existing mainframe applications to call out to the outside world, without having to know about the new technology standards, REST or SOAP or whatever.

So in this case, that’s exactly what they did. They used our product to take an existing core banking application, call out to a real-time payment provider, process that real-time payment, and then send it back to their customers. And they were able to do this. They went from proof of concept to full production in under two months.

Brian:

Wow.

Dr. Alex Heublein:

And you know, I can’t underscore how amazing that is when you think about it, because you’re actually transferring money and you’re not transferring money in a traditional way. You’re doing a real-time payment, which means that generally speaking, the money’s gone. If you mess it up, whoever you sent the money to has to concur with you to give you the money back, so-

Brian:

Exactly.

Dr. Alex Heublein:

The idea that you can go out and implement something from proof of concept to production in two months, with a level of reliability and testing and everything else… I think that’s a real testament to power of a product like Ivory Service Architect.

Brian:

Yeah, that’s really great. Well, thank you so much for sharing all of this information. Thanks for sharing that example. That’s wonderful. And I really appreciate your time, Alex.

Dr. Alex Heublein:

Thank you so much for your time as well.

Brian:

Dr. Alex Heublein, chief revenue officer at GT Software. My name is Brian and thank you for joining us here on the Red Hat X Podcast Series. If you want more information on today’s discussion and also on GT Software, head over to gtsoftware.com. Have a fantastic day. Thanks for joining us.