Dharmesh Mistry: Welcome everybody to the second series of Zafins Core Modernization Podcast, This weeks, special guests are Hans Tesselaar from BIAN, and John Mason from Zafin. Welcome guys. How are you today?
Hans Tesselaar: Good, good. We are fine. At least, I am fine.
DM: Great, great. Hans, would you mind just first taking an introduction of yourself? And just for those people that don’t know BIAN, just a bit of an intro to BIAN as well?
HT: Well, thank you very much, Dharmesh. Good to see you again, John. So my name is Hans Tesselaar, Im, the Executive Director of BIAN and BIAN stands for Banking Industry Architecture Network. So BIAN started in 2008. We are a not for profit association, and our mission statement is to solve the integration issues for the bank. So we started in 2008 with application integration. Then we moved outside the bank. So we do have a very extensive API portal. Two of the 49 pre built APIs, SWAG, and microservices, code. And we launched several years ago in partnership with Zafin, what we call our Callers Bank Initiative. We will move to the Callers Bank a little bit later. So, Zafin, sorry, BIAN, we do have around 100 members from all around the globe. We have financial institutions, software providers, integrators, academics, consultancies, and so on. And so forth. So thats the ecosystem and in the ecosystem, we create the materials that you make available for the industry?
DM: Fantastic. We’re going to delve into a bit more detail behind that because it definitely sounds interesting. John, would you like to introduce yourself and your role within Zafin?
John Mason: Absolutely. Yeah. So John Mason, Ive, been with Zafin now around 11 to 12 years. My current role is Senior Vice President for an area which we refer to as Customer Engineering. Again, the kind of idea behind Customer Engineering is around how do we help? How do we educate Our customers in number one? Adopting Zafin? Yeah, which is a suite of products to support core modernization, But how to do it in a more strategic way using industry, you know, best practice kind of concepts such as buy in. Yeah, and again, well, come on to more of that a little bit later on.
DM: Fantastic. And just so that the audience gets to know you personally a little bit better, Hans, would you mind with a little intro about yourself and your role within BIAN?
HT: Yeah. So in my role in BIAN, I’m the Executive Director, that means I run say on a day to day basis the business. So that is from new member acquisition, PR, interviews, podcasts, you name it just to make sure that we serve our members as they expect out of the membership. So that is my role. Before I stepped in this role, I was with ING Bank. I was Director of IT Innovation and Strategy. It is a long way back into the banking IT environment from an architecture perspective primarily and innovation perspective. So, the BIAN organization is governed by a BIAN Board of Directors. So four times a year, we have a BIAN Board meeting and I then report back to the board, what we achieved, how we spent the budget and so on, and so forth. So, Im, more or less the day to day person to make sure that everybody does what the members expect that we are doing.
DM: Fantastic. And I think you briefly mentioned this word callers, and, you know, my background is, Ive, worked in core banking and I like yourself, Ive, also worked in a bank and they always have a core. So what is it? You mean by callers? Banking?
HT : Yeah. So when we talked about it several years ago, we had the idea that maybe one moment in time, it should be possible to run a bank without a core system as we know it today. And we all know the DXCs and the Fiservs, and Temenos, you name it. There is a lot of in those systems that is not specific to what we would call core. Like you see with for instance, thought machine, the thin ledger type of thing. But we, you know, maybe dreaming a little bit too much. They say maybe one moment in time and when we are… capable of defining and building self-orchestrating microservices. So microservices call a microservice, he knows who calls, then he knows what to do and so on and so forth. Well, okay, keep dreaming but that was the underlying idea. So, but then we came up with the word callers and the word callers, like we do now is frequent speak. They always want to know what it is. And then we explain, okay, it’s a sort of we are almost there but not, so that is so its a good buzzword And we now build four in the approach of building number four, but we have built three iterations of the buying bank based on the caller’s principle. But in essence, today is in best of breed environment where integration is the key topic. So that is where we are, We have three in place. We are working on number four and I think we will touch later on number three and number four. But that is more or less as a proof point as a proof of concept to demonstrate to the industry. This is feasible today. So you don’t have to wait until whatever 20 30 Today. You can start moving in this sort of coreless direction. At least you get less independent of your core vendors.
DM : Yeah. I mean, I like the definition and it does highlight some of the confusion in the marketplace which generally is created. I hate to say it by the vendors themselves but, you know, its based around their product as opposed to a kind of industry standard definition. But I do like this thing that the core is essentially the ledger, but theres so much other software that is required to run the bank, right? That is actually just as important. And So, the buy in kind of remit is to help interoperability of the software to run your bank, in essence, right? Correct?
HT : Yeah. So that’s true. So there are a lot of as you mentioned, additional software besides the ledger that is needed to run a bank. But if you can decouple those from the ledger, then you give the banks the opportunity to go to the best of breed. So, what is my best, KYC solution on the market? How do I link it to my core? What is the best product and pricing? How do I link it to the core? So it gives the bank the opportunity to pick and choose like the legal blocks and create the bank with the state of the art software and not being dependent of only one vendor.
DM: Great. I mean, maybe Ill switch to John now and just ask, John, how does Zafin play a role in coreless banking? Like you’re not a core provider, right?
JM: Correct. Yeah, not yet. Yeah, its a question everybody asks us. Yeah, so were focused on core modernization. So what that really means is like we provide a number of methods and mechanisms and software solutions To externalize, you know, what banks typically would build into a monolithic core platform. So if you look at what theyve done, whether theyve got one, whether theyve got five depending on the line of business and, or product line that theyre supporting, you know, what we try to do is help people understand that you can externalize so much of this. So basically, you unlock the capabilities of the organization. Because when you start building on these monolithic platforms, you get incremental changes, you know, so expensive And obviously the interoperability, the amount of translation of data… and information going around. And yeah, is data really up to date? Is it T plus zero one five. Yeah, even worse in some organizations, when you go from retail towards corporate banking. So, what we do is, you know, we used to have a Zafin language for externalization of these capabilities. So as Hans mentioned, whether its a product, whether its pricing for fees, pricing for rates, if its conditional evaluation of a relationship based pricing structure, we can externalize that from core. But there was, also, you know, well we now have to translate between the bank and Zafin. And if we bring in another solution, whether its channel based solution, KYC solution, we then have to talk to them. So, you know, we started looking at how can we, you know, obviously, theres nothing, yeah… complete and solves everything 100 percent. But how can we find something which would accelerate the conversations and provide a forward looking framework from a banking perspective. Its very important, you know, we need something which is banking specific and not grown from another industry, whether its telco healthcare or whatever, you know, where people go, you can fit stuff into this. So, you know, we started looking at this, you know, quite a few years ago with Hans, you know, and a couple of, you know, complimentary clients that we have, And we started to look at how do we, you know, redesign re, implement, you know, and, or adopt buy in concepts for Zafin. And again, that allows us to now integrate with clients at pace if they’re on the buy in journey. But if theyre not necessarily on the buy in journey already, it gives them a really good starting point in place to start to Modernization start to evolve their infrastructure from a standards based approach. And again, as well come on to a bit later on, we really are looking at real world scenarios now Were moving away from, you know, a lot of people think, you know, on the first look at a buy in its very academic, its very semantic and that’s by design. But now were actually going down through the processes, working with other vendors, other banks, you know, to actually work out how to really implement real world scenarios. And this is one of the, I think the big successes we’ve had in the last two to three years with approved concepts, You know, its really turning this into something tangible that somebody from a bank or somebody from a product company can look at and go, I understand what this means now… As opposed to how do I apply buy in, You know, I’ve never done this before. Nobody’s done this before. So, yeah, that’s what you know, Zafin’s doing. And again, we’ve launched, you know, buy in compliant buy in certified and buy in inspired all various flavors of buy in implementable services over the last two years. And again, its part of our core product roadmap. Now, So again, you know, last year we won, you know, Partner of the Year for, you know, the work that we did with Wells Fargo, for example, Weve accelerated their core modernization journey by leveraging buy in not just from an academic perspective but from an implementation perspective as well. And again, were seeing this, you know, reproduced across each one of our new clients And its a hot topic for every prospect at the moment.
DM: Fantastic. I mean, well, definitely delve more into that case, you know, that example a bit later on. But first I want to switch back to Hans and just ask. So what I understand from John is that youve got this kind of common language, be it for the services or for data across banking. I think that is the first imperative step that, you know, is required to it Enable interoperability. But what else is buy in doing specifically, I guess, or is within the buy in framework that helps banks to Modernization their core or their infrastructure?
HT: Yeah. So what you see is that when we started in 2008, there was no, lets say publicly available bank on the page, There were proprietary models, but it was not something that was open. So we started by identifying all the business functions that should be in a bank, that does everything for everybody. That is our framework. And when we identified those, then the question is how Do they work together? So what is the information dependencies between all those different elemental business functions? So we started by defining sample process definition, how to onboard the customer, how to initiate the loan? And then what are the functions that are involved and what is the information that flows. So that gives the bank an opportunity to look at their own situation and ask themselves the question, which of those functions are we performing? And which are we not? And if you know what it is, you can create your own bank on the page, maybe together with a partner, maybe together with a consultancy partner. So this is what we do nothing less and nothing more. And when you have that in place, then you go and its easy to use the Zafin example. And you said, well, we are in need in a product and pricing solution. You don’t know what it is, but that’s something you think that you want. So, you do an RFI RFP and you send it out to whatever ex offenders. They all have their own definition of product and pricing. You have your own definition of product and pricing By using the buying landscape, you create a common language. This is what product and pricing is. I tick the box and if you have additional functions, why, and can we use them? So its not something if its not in the box, youre out, but it creates a common language. And one of my board members always say its a stone of our setup. You can translate the different worlds into one world. So, and one of the things we did in the call of proof of concept number two is create a tool to combine all those different languages because each vendor has his own, you have your own data schema, your own definitions, and how do you combine this and how do you create one common language? So that was the result of POC II. So creating the common language, creating the bank on the page as a discussion piece within the bank. Is this who we are? Is this what we do? And then you go outside to your potential partners and say, can you provide me this thing and how does it integrate? So that is the strength of the model.
DM: I like it In my head just to kind of almost simplify this for, you know, if I had to explain it to my wife then I can see that buy in is almost like the blueprint of a Lego model and its defined what the connecting bricks could be like. But you don’t provide any of the bricks that comes from the different third parties, but they will fit together if they use the same, you know, standards that you’ve kind of defined. Is that right?
HT: Yeah, that’s correct. Yeah. So that’s why we hope to say, okay, if we have a buy in aligned solution or buy in approved solution, that at the end, when that’s in place, we can help the banks to come to a sort of plug and play environment. So nobody worries when he downloads an app on his iPhone, does it work? No, it works. So that should be the same and it should be, lets say the bank on the phone and they say, okay, I add an additional function And the integration is standardized. So I don’t have to worry about the integration. That is the ultimate goal.
DM: Fantastic. And so both of you have kind of mentioned POCs that you’ve been working on, John. Do you want to kind of expand a bit more on the work that you’ve been doing with Bian?
JM: Yeah. So, you know, we’ve participated in all of the POCs, you know, POC one all the way through to the current in flight proof of concept four which well, talk on very briefly Were not going to spoil too much, ready for when we announce it later in the year. So what we’ve done is, you know, again there’s been a number of things that we’ve been trying to solve with the proof of concept Number one. Yeah, are the Bian kind of concepts and artifacts fit for purpose. So again, we iterate through, you know, and again, Ill use some of the internal language like service domains, service landscapes. We iterate through those to see if theyre fit for purpose for, you know, what we know from a banking perspective. You know, the second thing is that we also work out, you know, how do people use these? How do people actually adopt it? What tooling do we need? Because again, you know, having an… API specification or having a business object model in a data format, you know, is all very well and good, but contextually its really hard to understand what you’re supposed to do with it. So we iterate through. And again, its not just us, you know, there’s quite a few partners and bank participation in this. Now, As Anand said, there’s over 100 and it grows day by day. So we look at that and we, you know, we actually set some of our objectives to be, you know, what can we learn, How do we accelerate the adoption of Bian API? You know, the third part which is typically the shortest part of any proof of concept is we actually implement, you know, a given use case. So after we’ve gone through all the, you know, making sure its fit for purpose, make sure everybody understands it. We know how to use tooling to get API specifications being generated automatically. How do we enhance, you know, business object models. We then typically go through a very fast, you know, four or five week build phase. Will we actually implement end to end solutions? Proof of concept one and two are relatively straightforward because, you know, just due to the use case, Proof of concept three really kind of stepped forward from a standards perspective where, you know, with HSBC being the lead banking partner, we decided to look at open banking. Yeah. Again, one thing that we want to do within binders is leverage other standards, You know, not compete, not kind of try to disrupt. We try to leverage them where possible. So we went through, you know, the arduous task of mapping, You know, the open banking specification typically led by the UK, European kind of one. Its, you know, its the most familiar for us. But we looked at that and modeled it within Bian. So we now have a Bian specific, you know, implementation to show how people can do that. And the use cases. We implemented a number of use cases around that about, you know, consuming external products… product information, which is typically a very difficult task for a bank. But then what can you do with it? Okay. Which kind of set up proof of concept for? So we did, you know, use cases about how do we do product matching? How do we do next? Product recommendations based on, you know, the totality of a banking relationship with a customer? So, yeah, and again, because we have the Bian model, its a composable model, we’ve defined how you can implement these orchestrated processes. Whereas typically somebody would just build it in one application for one use case. Not very reusable, not very, you know, maintainable for the future. And Hans will talk about that a bit later on as one of the key objectives of buying this year. Proof concept. Four unsurprisingly is going down the route of, right? Weve done that. Weve done a kind of, you know, systematic stroke, parametric kind of evaluation of data. How do we, how do we now bring in machine learning and AI? Okay. How do we bring that, into, the buy in kind of concepts? So that has implications across a number of disciplines within buy in. So the traditional is the model, you know, fit for purpose. Its been, you know, its a big focus for our information architecture group. Now, because again, how do you define, you know, sharing of information between machine learning models? Its a very bespoken and yeah, kind of almost, yeah, it is a scientific process, but its also artistic Because again, you dont really know what data you will be looking at. You cant just define a set of columns and say thats what, you know, Bayern refers to as an ML model. We cant do that. So were going through a number of iterations to work out how we can bring in, you know, some kind of dynamic concepts for exchange of information across these capabilities. And then how do we plug in? Yeah, the wonderful. Yeah, AI, generative AI, for example… product recommendations, pricing recommendations, price optimization from a relationship manager perspective stroke, you know, point of communication with the client, But were also bringing in the same set of tools but on top of the Bayern information stack. So at the moment, yeah, its a very, you know, its not that difficult. You can do training within a week. You know, to understand the whole kind of concept and navigate things but were bringing in, the generative AI. So you can start talking to it saying I would like to orchestrate a process to do product recommendations for this. And it will now go through and show you the appropriate service domains and retrieve documentation from proof of concept. For example, you don’t have to navigate, you know, thousands and thousands of pages of information. So again, were bringing it in both sides, How do we assist banks in orchestrating these processes? And how do we actually improve our own lives using BIAN to generate these scenarios out of the box?
DM: And is this actually obviously its not production, but this is actually integrating with a banks real software. They’re like, you know, whether they’re legacy systems or some older third party systems that they bought. Its not just working on your own with a bank but only on your platform, it’s actually working with their platforms, real life showing, you know, the exchange of data, et cetera.
JM: Absolutely. Yeah. So, you know, we exclude a couple of non functional things, you know, just for, you know, expediating the proof of concepts. But, you know, for the last three proof of concepts, we have deployed on a hybrid cloud capability with secure communications using both APIs, file data exchange, and also event based communications. And again, that’s only possible, You know, by defining, you know, the Bayern, you know, object models defining what data is exchanged and people understanding like, okay, you know, this is who I can talk to. This is what I can publish a message but other people need to subscribe to it. So its, really nice. And that’s why I said we spend several months looking at the business problem and then a very short period of time implementing it because its just so good.
DM: Thats fantastic. And Hans, how do you like obviously, Zafin, you know, wants to show that theyve got a great component for Bayern in the product pricing space. But how do you make sure that, you know, the POC ends up with something that is independent, not specific to Zafin. And also, you know, that banks or other members can experience or learn from the POC without having to take part?
HT: Yeah. So first of all, what we do, we are, yeah, lets call it picking the brains of the participants. So Zafin has that expertise on product and pricing modeling and predictive, and so on and so forth. But so we are taking advantage of their knowledge as I say translate that into Bayern and say, okay, this is how you can run it… using the buy in artifacts. I hate the word artifacts. But okay, I have a better word. So it is not that we are implementing and solving solutions. Its not that were implementing an IBM solution of TCS or we did with thought machine. So there were maybe 20 30 over the proof of concept… partners involved all with their knowledge, Some say, okay, lets link to my system just to demonstrate that we can use the proof of concept runs in a mainframe environment, in an Cloud environment, in an Cloud environment. So then we asked the participating partners to make a sandbox environment of their solution available so that we can demonstrate how it works. So it is a buy in solution and using the knowledge of all the different participants. So if we discussing POC three that was run by HSBC, they have the project management and so on and so forth. So there was a lot of HSBC knowledge in it. But the intent is that also Citibank can use it. So its HSBC knowledge and the more or less… making it into a sort of general scope that everybody can. Because what we as buyer need to provide is that we make something available that can be used in every region by every bank despite the size or the location. And because if otherwise, it doesn’t make sense from a standards point. So, and then in the POC three, we used the HSBC sandbox environment. So youre asking, are you now linking to a real bank? Of course, we are not allowed to connect with the real life data from the customer center. Its a no go area. So we have a sandbox environment. So now POC four, Wells Fargo is in the lead. So were using the Wells Fargo. And so we always try to find a real life situation with a real, yeah, real life sandbox, maybe strange word. But thats what we do to demonstrate that it works And that is the underlying And what we did. Because and John went a little bit fast about POC three. But what we did in POC three is that we say, okay, we have to buy a bank and then we have a new customer. And then we ask that new customer. Do you have an account at another bank at an existing bank? And in our case, the answer is yes, And the existing bank is HSBC. So then we ask, okay, can you give? Us consent that we retrieve data from your HSBC account, All within the regulations set up by the open banking authority. So it is in the EU and the UK. So she, when she approved, we retrieved that data, We analyzed that data. And then we say, okay, looking at your data from HSBC, we can make you a better offer. We see that you have a loan for whatever percentage and looking at your history and all the data, we think we can make you a better offer. So that was, lets say the ultimate use of open banking Options available for everybody. But today only used by the aggregators and not yet by the banks. But the bank can do the same as the aggregator does. But we show them how it could be done. So, I think that answers some of your questions. Damir. So yes, we are using an environment of a bank.
30:08 | Phone Caller #3: I mean, what I’ve, learned from that session, that bit there is that, you know, this is not an independent group of people working in theory about to create some standards, but you’re, actually collaborating learning, working together. You know, that’s both banks and vendors to create the standard. Secondly that, you know, you’re using the POCs to prove that the standards actually work in practical terms, environments which, you know, are a mixture of legacy and new software, etc, Right? Its not very specific. Yeah, I mean, its a fantastic way to, I don’t know why all standards aren’t created this way. This is the way it should be.
30:49 | Phone Caller #1: Yeah. Well, I think so When you look at this at the traditional, lets call it traditional standards body. And we were also for a long time a traditional standard body. We are very good in providing PDFs and PowerPoints, And PDFs and PowerPoints always work. Thats the good news. So there is no issue. So when we moved into APIs, and more or less encouraged, lets call it positively by Forrester. So were creating APIs. And first, for the first time ever, we had digital assets. And when we had those digital assets available for the whole industry, all those APIs. We said, what can we do more? And then we said, OK, lets try to use those APIs again inside the bank to solve the integration issues. And that’s how we started with the POCs. So for us, it was also a learning process And moving away from PowerPoint was scary because we were not used to it. We didn’t have the right resources and so on and so forth. So it was a journey And the journey works out very well.
DM: Great. Look, we are kind of running out of time but I have a really important question as well for both of you. And that is, you know, technology is one of those things that evolves all the time, right? How is it that you guys can future proof the bank with what they’re doing today? Because we know that something around the corner Its going to be new and whatever you’ve done in the past is now, you know, even if you implemented something last year, its now old because something new has come along. So how are you future proofing banks with what you’re doing within the standards and, you know, adoption of the standards… Who wants to go first?
HT: I will go first. So first of all, what we do, we try to use as much as possible, open stuff that is available. So we keep away from proprietary stuff. So everything that is open and that we can use an open source tooling. And what you also see that we all know that in any way or form cloud is a future proprietary cloud or public cloud. Whatever Cloud based is also the future… We help the industry to become future proof, to make sure that if they migrate to a plug and play environment, the things that we are not aware of that are maybe around the corner next month can be easily plugged in into your existing environment. Instead, when you have a huge monolithic system, there is no plug and play. So if you start Decomposing your current core into smaller bits and pieces that give you already a germ, start to become future proof.
DM: Fantastic. Anything from you to add, John?
JM: Yeah. So just to reiterate, you know, what Hans has said and the whole kind of concept about buy in, Yeah, to make things future proof, you know, you have to go down a composable, you know, application route. Yeah, composable services, composable implementation. Yeah. As you said earlier on the proof of concepts, we talk to both legacy and new. So again, if you actually talk the right language, you should be able to plug and play, swap in and swap out. Because again, it may not be that the technology is out of date. Its, the implementation may be out of date. Were looking at machine learning and AI. Its not really going to change. Its just what you do with, it is going to be important. So if you implement the appropriate granularity where you can get the benefit of orchestrating these new things Because again, its like, you know, we’ve looked at large language models. Now, everybody’s looking at how do you chain multiple large language models in specific industries? How do you keep human in the loop and all that kind of stuff? Its, only if you actually build these composable frameworks, you’re, using a common language, you can improve them. You can extend them. You can replace them. Because again, its like, you know, one of the key things that were doing with Zafin’s integration and orchestration platform is helping banks bridge to the future. And again, buy in is the way to do that. Yeah, we don’t introduce any proprietary translation kind of between Zafin and Bank, Its like buy in. So some clients were forcing to go down the buy in route, but its, for their benefit, you know, as we move forward. Yeah. So if everybody keeps doing proprietary monolithic, you know, one use case scenario. Yeah, its not going to work.
DM: I’m just going to summarize what I think I’ve, heard and you can agree or not. But what buy in achieves is basically it breaks down the entire bank into a common set of functions and it uses a common language. And one of the things I learned today is that this language is common across whatever geography because I heard that Wells Fargo is part of it and then HSBC were part of it, etc. And in the past, my understanding was that buy in was kind of European centric, but this is good. So it is a common framework. And then by breaking these down into separate small pieces with a common language, we now have the ability to compose or add in or swap out pieces as we wish. And that in effect helps us to future proof the bank as well. So not only are we getting flexibility, the ability to bring in new capabilities, but were also future proofing the bank by doing that. I mean, what a wonderful project to be part of. I thank you very much for explaining that to me. I’ve learned a lot and yeah, it was really insightful. So, thank you.
HT: Okay. Well, thank you. Also pretty much.
