In this episode, I talk with Istvan Molnar, in Budapest, Hungary. Istvan is working on a Zeebe solution with the Mifos Foundation for the future of financial transactions in the emerging market of Africa.
Links to resources mentioned in the episode:
---
Visit our website.
Connect with us on LinkedIn, Facebook, Mastodon, Threads, and Bluesky.
Check out our videos on YouTube.
Tweet with us.
---
Camunda enables organizations to orchestrate processes across people, systems, and devices to continuously overcome complexity and increase efficiency. With Camunda, business users and developers collaborate using BPMN to model end-to-end processes and run sophisticated automation with the speed, scale, and resilience required to stay competitive. Hundreds of enterprises such as Atlassian, ING, and Vodafone design, orchestrate, and improve business-critical processes with Camunda to accelerate digital transformation.
---
Camunda presents this podcast for informational and entertainment purposes only and does not wish or intend to provide any legal, technical, or any other advice or services to the listeners of this podcast. Please see here for the full disclaimer.
In this episode, I talk with Istvan Molnar, in Budapest, Hungary. Istvan is working on a Zeebe solution with the Mifos Foundation for the future of financial transactions in the emerging market of Africa.
Links to resources mentioned in the episode:
---
Visit our website.
Connect with us on LinkedIn, Facebook, Mastodon, Threads, and Bluesky.
Check out our videos on YouTube.
Tweet with us.
---
Camunda enables organizations to orchestrate processes across people, systems, and devices to continuously overcome complexity and increase efficiency. With Camunda, business users and developers collaborate using BPMN to model end-to-end processes and run sophisticated automation with the speed, scale, and resilience required to stay competitive. Hundreds of enterprises such as Atlassian, ING, and Vodafone design, orchestrate, and improve business-critical processes with Camunda to accelerate digital transformation.
---
Camunda presents this podcast for informational and entertainment purposes only and does not wish or intend to provide any legal, technical, or any other advice or services to the listeners of this podcast. Please see here for the full disclaimer.
Josh Wulf: 0:30
What is up Zeebe Nation? It's your boy, Josh Wulf coming to you live from Auckland, New Zealand, over the Internets. And today I have with me all the way from Budapest in Hungary, Istvan Molnar. Welcome Istvan.
Istvan Molnar: 0:46
Hi, Josh. And hi, everyone.
Josh Wulf: 0:50
Thank you so much for making it work to talk it this time of the day for you. It's the evening here, 5:30 in the afternoon. Is it morning where you are?
Istvan Molnar: 1:00
Yeah. 7:30 a.m. In the morning.
Josh Wulf: 1:04
Awesome. You know, thanks for making an early start. And, you know, look, probably people who are listening to this don't know much about what it is that you do. And I don't know much either. I know you're working on a project with Zeebe. I know it's called Mojaloop. I know that it has something to do with real time payments and emerging developing economies, and that's pretty much all that I know. So maybe you could give, like an introduction of yourself and a brief overview of what it is that you're working on, so that I and other people can have an idea of it.
Istvan Molnar: 8:43
So my name is Istvan Molnar, and I'm working at a company or our own company established 20 plus years ago, DPC Consulting. And we are involved in different development projects, of course, in banking and also in real time payments. And this part of this whole journey that we get a partnership with the Mifos Foundation and now recently with the Mojaloop Foundation and what we are working on is a project in this whole ecosystem, of open source financial components, and to provide tools that have adopting banking and banking solution for the emerging countries. And actually, for everyone who wants to use these tools to give some background of "what is this?" So it all started with two different threads. One of them is the Mojaloop Foundation, which was launched just a couple of days ago as an independent foundation, and the sponsors are the Bill and Melinda Gates Foundation, Google, and the Rockefeller Foundation. The way this whole project started was that the Bill and Melinda Gates Foundation has a statement that they believe that everyone benefits from an economy that includes everyone. This was the Level One project and the intention was to provide a platform where real-time payments could take place in emerging countries with a technology which is - as much possible - open source and easy to adopt in these countries. The target is, I believe, in the African countries and also in the Southeast Asian part of the world, to provide things to enable these payments. And if you check out the Mojaloop website, that the foundation establishes their target as - let me read their sentence that opens: "for empowering organizations to create interoperable digital payment systems to increase financial inclusion". So, the idea here is to provide a platform that, first of all, countries could adopt and the Digital Financial Service Providers could connect to, and they can inter-operate. And the inter-operation typically means that they could send fund across. So actually, real money transfers across these institutions already exist. Visa or Osk for money from another partner or do merchant payments that the merchant presents a QR code or other form of information that "what type of, what amount the merchant wants to pay", and then you can click with a single button if you have a smartphone, or if you have just a feature for that, you can still enter just some simple code and get the transaction to go through. And the foundation is working lately to get also bank payments supported on this platform. Also, huge volumes like aid - let's say, because of this virus situation, many governments want to send out different fund. So, that also to be supported by this platform and the Mojaloop Foundation take cares about the central server, which manages the interoperability across the digital financial service providers or the DFSPs and what we are working. Along with the Mifos foundation, and to have a so-called payment hub into this landscape, meaning that at the DFSP, which has its own account management system that the funds of the users or customers are sitting. It could be like a mobile wallet provider. Some of the African countries have different mobile networks that have wallets and can be used for payment - or can be really a bank in some of those countries that the infrastructure is available, and could connect to this real time payment network. And our payment hub that we are working on resides at the bank side and integrates the bank channels with their customers. Instructions are coming in to the bank account management system that the funds are sitting on. Potentially, if someone has a fraud detection mechanism that is part of the ecosystem - and ultimately the Mojaloop system - to execute these payments. And there are multiple phases of these payments - like you need to look up the other party by a phone number or any other proxy for identity - because the concept here is that no one is using account numbers in these emerging countries. But everyone is using, like mobile numbers to do transfers. So the service is available that you just type in the payers mobile number, and there's a look up service first of all. Then secondary, there's a quotation in the system - meaning that you ask the other parties in the chain "how much is this transaction gonna cost for the customer". And you present this information to the the user that "this transaction of transferring - let's say 100 Tanzanian shillings would cost you one or two or 20 Tanzanian shillings". So the customer could pay. You could decide that "I want to execute this transaction", and by approving this transaction, then there's a real-time communication which goes through the Mojaloop central hub, which goes to the other party who has the payer's account and the transaction complete. And we are building this payment of software that any DFSP could use, could introduce to do this inter-operation.
Josh Wulf: 8:44
So... sorry, "DFSP"?
Istvan Molnar: 8:46
Digital Financial Service Provider - because it's not not only banks who are gonna provide or participate in this network, so probably smaller. And it will also do the inter-operations and, in this payment hub, there's the server in the center which orchestrates this process from the FSP or the bank side.
Josh Wulf: 9:16
Okay. Oh, well, this is a big project. Hey,
Istvan Molnar: 9:21
It is actually, because it's running now. I don't know, five-ish, or probably more years since it started - that's the central Mojaloop piece. And there is one more component that I want to mention, but let let me stop, and then let you ask.
Josh Wulf: 9:39
Okay. Well, just incredible. Let me see if I got everything that you've been creating there. So this is an open source system that's being developed for use in Africa, and it's sponsored by the Bill and Melinda Gates Foundation. And what it does is it enables the consumers - like the everyday people working, walking the streets - who have got a cell phone to be able to send and receive payments from any bank to any bank using the system and a phone number. Is that pretty much what this is?
Istvan Molnar: 10:16
Yes, plus in Africa, many of the mobile providers are providing wallets, but they are not interoperable. So if you have the mobile wallet at one network, then you need another phone to have a wallet at the other network, and you cannot send the funds across these networks. And that's gonna be a typical use case, for example, which is already in production in Ivory Coast to enable the two mobile wallet providers to inter-operate with each other. So that's why not only banks, but other financial service providers could use it.
Josh Wulf: 10:53
So they could you use Mojaloop to inter-operate between those two mobile providers wallets?
Istvan Molnar: 10:59
Yeah.
Josh Wulf: 11:01
Okay, so it's like a federation kind of layer of different financial service providers who can store money enabling people to pay each other. OK,
Istvan Molnar: 11:13
Yes, if you can come for this to more and more countries having real time payments. So I'm aware of, for example, Singapore, that the network is called Fast or in Europe. There's a separate instant, for example, to do this like 10 seconds, five seconds, 15 seconds kind of promises for a payment to go through. There is a similar network in Thailand, and they are more and more countries introducing this type of solution and of course platform to enable this for for other part or other countries.
Josh Wulf: 11:57
Yeah, okay. And in a sense, it's also similar to like Stripe or PayPal. I think with PayPal, you can do that. Right now, you can send money to another person, given their email address,
Istvan Molnar: 12:09
and you
Josh Wulf: 12:11
still have to load the money. And I know you can connect a bank. You can connect your bank or your credit card: "PayPal me". This is one that you use a phone number. It runs on everyone's phones. That connects to all of the things, provides a single kind of mesh for making these payments,
Istvan Molnar: 12:26
you
Josh Wulf: 12:27
real-time
Istvan Molnar: 12:28
structural and the next target of the foundation to enable cross country payments. Or from Tanzania, you could transfer funds to the Ivory Coast. They're now too much hassle because usually if you take a SWIFT transaction or other existing case, that becomes quite complicated to
Josh Wulf: 12:49
go. I gotta like, they're gonna, like, write it up by hand and then fax it to another country and yeah, yeah, it's like those kind of transfers. I mean, the United States banking system is incredibly inefficient, you know, because they have each of the States is like a different country over there, So that kind of gave rise to things like Stripe and PayPal. And so this is the same kind of thing for Africa, which is gonna be like turbo-charged to this next chapter for Africa, because, um, yeah, like there's just so much latent talent and potential there, and it looks like it's their time. And you said there was one other component that you wanted to talk about?
Istvan Molnar: 13:31
Yes, because in this whole ecosystem there is one more fundamental component. The account management system that the DFSP could hold the amounts of these customers. So it's purely a core banking platform, I would say, But it's an also an open source platform, which is managed by the Mifos Foundation. Now it's 10 plus years since this platform started. It's used by, I believe, about 100 million and users, um, and let me check the numbers. But I believe, like the latest ones again in multiple countries the original idea was to support micro-loans. Micro-financing, meaning that if there's some money to distribute across the community, that you can set up this open source server easily and manage the loans and manage the calculations off interest and late payments and all the necessary things
Josh Wulf: 14:43
Get out of here! So you can set yourself up as like a micro-capitalist.
Istvan Molnar: 14:49
Ah, we are just the technology providers. But yes, that.
Josh Wulf: 14:58
I know where my next investment is going,
Istvan Molnar: 15:01
And in this whole ecosystem, the Mifos foundation, the project what was created has just become an Apache core project. Ah, I believe two years ago now, you can find it as Apache Fineract, which is the this core banking platform that anyone can download and anyone can tweak and anyone could use. There's a community also growing around this, obviously multiple institutions using this now. And like even for us, that was one of the opportunity that we use this platform in developed countries to provide a really cheaper alternative to commercial products. So ,we also managed to introduce this in Germany for a major bank actually to be a platform to host the loans where they so far used a more complicated system. And also, working with Singapore to get this platform again applied at a major bank to do account management task and loan management operations. So that's the other component that's part of this whole ecosystem and in our laboratory environment, which is supposed to host hackathons, and actually open for anyone to participate. We have this account management system. We have the payment orchestration in the middle. And then we have a Mojaloop instance. And we have six of these installed, and it's like a virtual country. We called it Inclusion to represent the financial inclusion concept. And in this Inclusion, you can actually simulate transactions across these core banking platforms via the payment hub. And then the central module Zeebe. And then you can view these transactions in the UI Operate interface that it goes from the payer to the payee side And what, actually, the steps are involved in this one, and so that's our practice ground where the development is happening. And what we are targeting as Zeebe 0.23.1 is out that to do some kind of performance benchmarking, giving enough resources to the platform, and then really do real-time transactions and test it out. Ah, initial target at least 100 transaction per seconds. But ultimately, we should go up to 1000 financial transactions per seconds to make sure that this platform scales as we wish to have it.
Josh Wulf: 18:16
And so Okay, when you say 1000 per second, let's just go like deep technical for a second. But when you say 100 - let's start with 100 per second. Now, do you mean like, the ability to start 100 per second? And then I guess the next question is like: how fast do they need to complete?
Istvan Molnar: 18:34
Yes, so the idea that let's say that the customers of these, the FSB, let's say sending money to other parties in the network. And that's the number that they want to initiate - 100 financial transaction per second, or even 1000 sooner or later. So, if a bigger entity comes into the board like, really, a mobile wallet provider, then they'll probably be there on the thousands scale. So yes, so that's the number of financial transactions that they want to initiate to the system. Now for completing the transaction: there are multiple steps involved, but ultimately the main step is the send transfer request, which goes through the network. The other party responds and we get this response. All this happens asynchronously actually, because then we put the funds into the account off the customer, or actually, if it's a payer, then remove the funds from the customer's account. So for this one, and the target is a couple of seconds, I'm not sure that there is, like, an ultimate goal. What needs to be achieved. And it all depends on network and and and other factors. But ultimately the customer experience should be in, like less than 10 seconds to complete.
Josh Wulf: 20:04
Yeah, I guess that's like there'll be one source of maybe uncontrollable latency. Your call out to that other DFSP system. Absolutely. Then you have the overhead of your system as well. Yeah, we've done some performance testing on real-time kind of transactions with ZB. One of our consultants, who works a lot with the Camunda engine and also Zeebe proof of concepts, ran it using the event log in a ram disk. So ran the whole thing in Ram He got, I think, like a 10x performance boost out of doing that for end-to-end processing time. Yep. So tell me about how did you find, how did you encounter, How did you discover Zeebe? Like, how did that come about?
Istvan Molnar: 21:02
There are multiple ways. First of all, we are long-term Camunda users. So, we use the Camunda BPMN engine in multiple projects, actually across the globe. So this whole concept that you come up with a solution, that there's orchestration in the middle, it's very close to us, let's say. But obviously the traditional "relational database in the middle" type of workflow engine, or BPMN engine, is not suitable for this type of load. And then we started to think "what do we actually want to achieve in this payment hub", and and I have a list in front of me that what key considerations we were thinking of then. Then, we started to look out that how to implement a modern payment hub. So okay, it's just a couple of things. So, ultimately being in the banking area: running the system on-premises, but also supporting it in the cloud - that was an important requirement or important architectural consideration what we put in place then an as part of this whole payment hub. There's a real-time engine, which is really required to complete the transaction. But we also have like an operations backend, and we could separate these ones that the payment operators of the institution could log in and check "what happened with the transaction"? What was the lifecycle? Why's it got stopped? If any, reasons and how could continue that particular transaction. So there's another part of the payment on which separates, and the idea that these real-time engines are self-contained, highly-available. And so, it's really crucial that we don't lose these engines, and they are also fault tolerant. And that was another important factor that if, let's say, one computer fails, which will happen for sure in a long period of time, that the whole operation is still supposed to continue and the existing in-flight transaction should be able to continue. So, that was also one-off the prerequisites that we put there. And why orchestration? Because there are multiple things happening at the bank side, for example, time-out handling. So, some of the elements in this cool orchestration are asynchronous by design. So, then you call the - let's say - the central system by HTTP, you get a response immediately that the request is accepted, but you get the next information by an issue to be called back. That okay, "this has completed". And now we need time-outs. Because, if I don't get the call back in, let's say 10 seconds, then I need to reinitiate that transaction. So the central system - is it important? So I can retry the same transaction, but I need to do this. Retry. So I need a system that these time-outs can be handled efficiently and I will have potentially 10,000 timers running at the same time at my payment hub because, let's say, ah, this number of transactions are in flight in a peak scenario. So, that was one important factor, the other one that correlating these asynchronous events, meaning that you need some stores somewhere that then call back, coming back. You know, that "where was your process instance" and you could continue that one and potentially, you don't want to keep all that information in-memory but need to be able to retrieve that quite fast. And there was another one that the error-handing in exception scenarios of compensations. So, if something was wrong that you know that you want to give the money back to the customer, to the payer, because you know that the transaction failed for whatever reason, so that part we should not ever lose - because it's really obviously end off. If a customer complains -which they have the right to complain, if you let's say, miss either doing the transfer or completing it. So the other part to get it or we give the funds ah, back to the payer and another aspect that we were looking for: to overview the in-flight transactions to see inside that: "what's going on? Where are these transactions? How many of them stopped, at which point?" So that was, I believe, the key factors that we were looking for. And to tell the truth, we were looking for the CAP theorem what implementations we have and this whole Raft protocol is obviously something that we were looking for too, to implement. The consensus protocol to do local replication kind of things. And also, the other piece that we were looking for that "don't have a relational database in this whole solution, but something which is more adequate for this". Ah, and it's fully replicated across the processing nodes. And RocksDB was one of our ideas also, and it come very handy that looking around that: "hey, is there anything actually that we don't need to start from scratch?" And then it was Zeebe came into the picture simply just by looking for Raft and RocksDB. Because, exactly this is what we targeted that "this is what we need to have a resilient and robust but still stateful engine that is fault tolerant and we cannot lose these financial transactions". So that's how we ended up choosing Zeebe as the core piece of the system because it's what we want. This is the only stateful engine, and all the other connectors who are required connecting to the banks channel connecting to their account management system, connecting to Mojaloop. But right now, we are looking for other countries not not only to the Mojaloop, but for other payment networks to be connected. Those are all stateless and all the status handled inside Zeebe inside the RocksDB, and it's fully replicated across the cluster nodes. So that was that was the whole concept. Then we started off, and it looks very promising that where we are right now - our working prototype. It all looks good, obviously needs some tuning and some more experimentation with the platform and probably also Zeebe needs a bit more maturity along the way. But that's all. We're good. That's how we build the software anyway.
Josh Wulf: 28:24
Right.. and since you've got deep experience with Camunda, you're kind of like: "yeah, these guys know what they're doing. This thing is gonna turn out." And, that basically kind of took a similar approach to what you did like: "hey, what does the future of business process automation at scale look like? From first principles CAP theorem and RocksDB, Raft protocol". It's amazing how you arrived at the same kind of place, just like from first principles. And then just googled a bunch of terms together and "hey: Zeebe!"
Istvan Molnar: 28:56
Exactly. Exactly. And like another key things like all this audit logging which can go directly to Kafka, for example, you know, banking. So you want to log out it at every single step. What happens if something goes wrong? Then at least you know that what went wrong and and what now to compensate? That was another brilliant feature. What we are obviously using or the gRPC protocol that the workers are logged in to Zeebe. So having an efficient binary protocol and not JSON or no ah, Web service SOAP kind off XML things - that's also an important piece that that was driving a lot us in this direction. This is actually a tool that networks perfectly for our use-case.
Josh Wulf: 29:50
If you got, like, experience in Camunda, I'm guessing that you're building in Java?
Istvan Molnar: 29:55
Yeah, I am. So are our native language being ah 0.8 Java guy who started this whole job experience just at that time with James Gosling. So our favorite is obviously Java, and that's how we build this implementation. So it's running...
Josh Wulf: 30:20
Java at 0.8
Istvan Molnar: 30:22
Yeah, yeah, I must during 1994-ish year. That's there. I was in university. Yeah, exactly. So we were presenting in a couple of Java One conferences. So, Yeah, it was before 1.0 at that time, at Sun Microsystems. So, that's where we started off anyway. So we have that history, obviously. So it's a natural choice to go with Java and then being the whole Zeebe in Java - that's also helping because then any type of looking into the code or checking what's going on, that's what comes natural and then, yeah, we use this capability. So, I believe you could see some of the post of the colleagues on the Zeebe Slack that that there's a bit of contribution or at least bug finding that how we can improve in some places in the engine
Josh Wulf: 31:25
Yeah, that's been great.
Istvan Molnar: 31:29
Ah, one more idea that I'm happy to mention about the key features of Zeebe that also came in handy with selection. So, like the BPMN 2.0: it's quite expressive. It's something that anyone could really understand. And I believe we also were already surprised some of the different community members that they're drawing - that I have in my slides. That's the actual flow, which is running in production. So then I was showing that "this is how it is". This is how complex and all the timers and all the exception handling in place. And I told everyone "but this is not a drawing. This is the actual model that we have in the production". And shown them it operating. Then I believe a lot of them were kind of amazed that: "Oh, so this is... you don't just draw and other developers do a lot of work to get it implemented. But that's something that it really runs!" So that - that was another key key thing.
Josh Wulf: 32:34
Huge. "Documentation that never goes out of date."
Istvan Molnar: 32:37
Yep, exactly, exactly and incredible. And another one: that this whole fault tolerance concept that that if you have three nodes and if you are fully replicated then one can fail, and the system still could proceed for those transactions without any interruption. So even the timers fail over to the remaining nodes. So we tested this particular scenario because that's like a key thing. So you wait for, let's say, 15 seconds for the callback to happen. I mean, while your engine fails, then the remaining nodes should take the leadership, and should count the remaining seconds, and then initiate the the re-calling or or initiate the call again to the core system. So that is something that's really powerful, or the other potential configuration for bigger deployments that we have, like five nodes. And with the correct replication settings and even turn off the computers, they could completely fail and the cluster is still fully operational without losing any indicator - so that was another important part of this. And one more - one more thing that I want to mention: that this one is an open source project. This is under the Mifos Foundation called Payment Hub Enterprise Edition. Ah, the documentation is just getting created, and the repositories are already there on the Internet. So sooner or later you will be able to find the necessary documentation. All what I was talking about over there and ultimately the idea that it's not only DPC Consulting or whoever could apply this tool - but others could build and custom it to their requirements. And again, Zeebe is very handy for a couple of reasons because with every DFSP, every financial provider who will apply this technology, they will have some different needs. They have different account management system. The flow needs to be tweaked somehow. Some boxes need to be moved or added, or some changes ultimately are going to be there. So there, Zeebe becomes again, very handy, that we give a template that: "this is guys, how we imagine this real time payment with the model looks. But this is how you have the Zeebe modeler and you can start tweaking your process according to the particular installation and according to the particular requirements of that system or their DFSP". And another super key feature is that we all know that Java is now getting for old guys. And the new guys are coming with GoLang and then JavaScript and all other programming languages. And that's another key feature that they can do it. It should be. So the model remains, and if you replace one connector ah, to be implemented or even workers, or set of workers implemented instead of Java to use, let's say Node JS, then you are free to go and there is no impact. The center piece is still the core tool around persistent engine. And your connectors, which are supposed to be stateless, could be implemented in any programming language quite easily and could deployed into this kubernetes cluster. And: "here you go. You have the complete solution to do and participate in this real time payment flows." So that's, that's, I believe, another key feature. Then we may be recommend, and we use this tool in this open source project.
Josh Wulf: 36:40
Awesome! You're Steve jobs up in here with that: "But wait, there's one more thing!" That's like a greatest hits compilation of "Benefits of Zeebe". I love it! Look - one thing about that is it really kind of validates the idea of Zeebe itself, you know, it's a distributed, replicated, polyglot business process engine, and I can see it maps very well into this use-case. Then the BPMN stuff is, you say it's like documentation that never goes out of date, and then you can build these kind of modular systems where you've got these different DFSPs that you can build adapters for, and people can build them in their own coding language - whatever - it doesn't exclude any community. It's like people who get involved with whatever coding language that they program. And they could even write their own gRPC client for Zeebe. It's pretty easy to do.
Istvan Molnar: 37:40
Yep, exactly. So that's that story: "guys, there's couple of client libraries you can use. But if your favorite language in that particular system integrator- let's say something else, then it's quite easy to connect to the cluster there and get your client running. And take that jobs, take the tasks. What is coming up? Yeah,"
Josh Wulf: 38:03
Totes. I was working at a financial services company in Australia and I did a POC with Zeebe back in the day in Golangt and then, you know, we decided that we're gonna use it. So I go back to the team. Five guys. And I'm like: "Guys. This is it. This is our opportunity to start programming in Go!" And I was in a Node JS team, So I ended up writing a note that Node JS client for Zeebe because they didn't want to go to Go. Yeah, it was pretty straightforward to put together. And Mifos - before I forget - does is stand for "Micro finance. Open source"?
Istvan Molnar: 38:47
Ah, yeah. It does. Yeah.
Josh Wulf: 38:51
Okay, I got it right. I guessed that backronym. Yeah. So you were gonna say something....
Istvan Molnar: 38:58
Um, am I mean related to this one that you can also find that project now under the Apache Fineract project. That is now qualified to become a major or core team Apache project for open source banking platforms. So that's there. And, uh, yeah, I believe that's what I wanted to add. Yep.
Josh Wulf: 39:26
Okay, so there's Apache Fineract. It's an open source software for financial services. Is it like a server, or is it a bunch of components?
Istvan Molnar: 39:36
Um, there are, I would say, two generations. It started 10 plus years ago, that it was Java and modular, but still a single component, which has the customer management, the account management, the loan management, the General ledger management reporting as an integrated Java software, which you could run as a Spring Boot application, for example, or a web archive, but it's not that fancy anymore. So simply as a Spring Boot application, you can scale it horizontally, and there's a relational database behind to store all this information. So that's Generation one of the engine or this core banking platform. So in that sense, it's complete. It has all the pieces to run a bank and manage the accounts of the bank and manage the customers and have the customers multiple accounts and another key feature that its multi tenant by nature meaning that with a single deployment you could have any number of financial institutions supported. They are separated into different databases or database schemas, depending how you want to set it up. And the different tenants can represent Bank One and Bank Two and Bank Three and and a single IT team could manage this. This is especially important if you are in micro financing and the different towns or different groups has their own system, and they are. They don't they want separation, but the single technical team could run this platform for them. So this is a Generation One piece of software, which handles all of these capabilities. And now there's the new generation of Fineract, which is doing all of this in microservices. So, the different components, like managing the users or customers and managing the savings account, managing the loans, managing the general ledgers are separated into different microservices. And that's all CQRS - command query responsibility segregation pattern is used with an asynchronous mechanism to use ActiveMQ to separate these transactions and then execute them later. All of that is introduced in this new generation, and so both of them are available. And obviously there are some places that the previous generation is already in production. But the new deployments are looking for using the microservice based implementation of this platform.
Josh Wulf: 42:38
I see. Okay, so that's Apache Fineract. Yes. So it's basically like a bank customers, transactions, all that kind of jazz . And Okay, so then Mojaloop. So you got, Fineract. It's the bank. The banking software. Okay, then you got this Mojaloop thing - now is Mojaloop the one that you're working on that uses Zeebe. I have that, right?
Istvan Molnar: 43:03
Nope. The Mojaloop sits in the center. It's using less orchestration. It's purely event based. And that is implemented mostly in NodeJS and Kafka to handle these requests and marry with Zeebe. We are using Zeebe in the glue part, meaning that you have your core banking and you want to connect to this real time payment network or actually other networks. So we look for other connectors, and then the DFSP needs to have software which makes this connection. So call next to the banks channels. And I was mean, like, your mobile application that you can instruct, Ah, transaction or you're in Web, their bank application and the account management system being it Apache Fineract. But again, there's a connector there. So if you happen to have a different core banking platform, replace the conical and here you go and it's a different protocol and a different message, and and then then the payment flow still could remain the same. And on the other hand, there's the external averred. There is much a loop there. There you send the transaction, and obviously you could put its payment about the other side. So if let's say in my story, this is the air side, then then the payment hope could be at the pay East Side to the ped fsp, and then they can happily communicate by the module Hope Hub and anyway, the payment up. It should participate in all transactions. Sometimes a player, if I want to send trend money out from my institution, but also as a a year. Then I'm receiving the funds from another institution, and there's obviously a bit of different flow to do this, but that's that's absolutely fine. We gonna have a dozen off different flows that, if more by number, registration with request to pay if merchant payment kind of flows. So that's normal, that we're gonna have multiple roles for a single the FSB in this whole implementation. So that's where we are inside the payment hub inside the DFS PBR using CB toe, orchestrate these processes.
Josh Wulf: 45:24
Okay, so let me see if I got this then. So Apache Fintor Act is an open source banking platform, and it's one of many different banking platforms that you could use. You could have, like, a 19 sixties big iron COBOL system somewhere. Or you could have a pet chief interact Cloud night of running on kubernetes Google Cloud. Yep. Okay, so that's how you run your bank. And then Mogul Loop is this Ah, other system that sits, like, over the top and Federated a number of different banking systems. And it has some kind of a p I that you can use and so it could talk to the different systems and kind of, like, orchestrate them in a sense. And so two people with two different banks that can't talk to each other, they can have emerge allude adapter that can talk to each bank. And then, you know your payment mobile. Ap can now talk to that merger, Lou, and it will our transfer the money between the two banks that have that part right.
Istvan Molnar: 46:26
Almost the my mobile app will connect to my bank because my bank note me. So I need to authenticate, and I need to authorize this particle transaction. So that's that's still there. So, me as a they're being like a customer of ah one off the mobile wallet providers or a banking customer. I'm still going to authenticate to my and thanks to my back, I will bands, drop my bank
Josh Wulf: 46:55
on your
Istvan Molnar: 46:56
please. From my account. One off my accounts. Please initiate a transaction to least more by number. And these The demand initiation request goes to our payment hub. And there's a B with the workflow starts coming into the picture that orchestrate this complete flow. We obviously need to check that. Is there enough fund on the customer's account? To initiate this transaction, you need to put this amount on hold on the customers. Ah, council. He cannot spend it for another purpose. Mean why we busy? If we have doing this whole transaction and what the residents and the whole story goes, then we go out and request and Colback supposed to come back in a couple of seconds if not coming, retry and so on and so on and so on. And finally we put the this transaction on the customer's account. If it was successful or we really is, they hold on the account. If it gay transaction filled.
Josh Wulf: 47:55
This is happening in your payment hub. Yeah, Yes, Where is your payment Hub? Sit in relation to merge A look, then. Is
Istvan Molnar: 48:03
that a nope. The payment hub is at the d FSP. So I'm the bank. I want to control that. What? Transactions going in and going out. I want a complete audit log in my systems. I want an operation or user interface that I could look into these transactions. I can search, I can do reporting. I can dual off this that how was the flu off these transactions? Because in my core banking platform, typically I will see only the successfully completed transactions. So then it failed here and there that you won't have a track record in the core banking platform. It doesn't fit their but it fits exactly into the payment up that we do this process. We do the complete out it. We provide the user interface that the payment operator off the bank off the DFS be would log in and check that what happened? Transactions. And And if some off them fails, there could be obviously many reasons. Ah, then he could take some actions. Cool Someone who were for one that have you received that fund or North or and and do this type of action. So all off this sits at the bank, hopefully in the cloud. But obviously you can imagine that there's gonna hold Premier. Yeah,
Josh Wulf: 49:23
I want to on premises. Right there. Like
Istvan Molnar: 49:25
course. Of course. That and a lot of money. It is maintained, typically by some central authority in a given country like Tanzania. In the in the I believe the government is gonna operate that system, for example, And ivory, who was There's a different entity who operates the central hub. Let's say which which cross the different institutions. We go next to the different institutions with each other. So that's usually and I, like always a different entity who manages the central hub module loop and then on the bank would have this payment hub to let connect settling at each
Josh Wulf: 50:07
country will have its own like, um, national merger loop instance. And yeah, I
Istvan Molnar: 50:15
should local currency trends. Sorry. Go ahead.
Josh Wulf: 50:21
Oh, yeah. What? What is your payment? Hub called because I got a name for Finn. Iraq. I got a name from Roger Loop. And there's your thing. What's your thing? Calls?
Istvan Molnar: 50:30
Probably. You can help us. We've we've naming being bunch of technicals who we simply call it payment Hub Enterprise Edition. Because we had a prototype to test this whole flow without the BPM and without the about the persistence and fail over capability. And now he's simply named it as payment of Enterprise Edition. But we don't have a probably a proper name for it, but might be a good idea to look for something. So if you have an idea and then probably we are welcome to take that,
Josh Wulf: 51:04
Okay, it wouldn't wouldn't. Yeah, I think it would make it easier to conceptualize having like a concrete name for it. So it's kind of like a transaction manager that orchestrates the interaction between Mogul Loop and the bank system. Right? Teoh August. So kind of like motor loop is kind of like striping away. It's like an external AP. I just called her, and then so on one side, I'm calling out to merge, alert, orchestrating the responses and everything, and then I'm also then orchestrating the bank system to to cause this integration with insight, operational insight, compensation, patents, all that kind of goodness. Yes, that's kind of where your thinks it's Yep, exactly OK, and your initial target is Fintor. Act as the banking system because that's like an open source banking system. Is that widely deployed in Africa at the moment?
Istvan Molnar: 51:59
Ah, yes, yes, there are. There are plenty of institutions who are using it in multiple countries in Africa. But as I mentioned to you that we were working with entities in Germany. So major banks are in Singapore to also deploy the same technology, being just simply to lower the cost of ownership for for core banking platform and get some extra flexibility. Because then you can tweak the solution quite easily to your Excel requirements. Who having special products or special capabilities that that others do not have? Yep. And it's also used with major names that that, um, that many off us could be family or if like, like grab, for example, using it to manage the grab wallets, for example. But there are other big names who's who's using this tool set to run there accounts, Let's say,
Josh Wulf: 52:58
And where did this name merger? What? Where does Mo Jialu come from?
Istvan Molnar: 53:02
Now that's a good question, but I don't have the answer for that. So so I'll
Josh Wulf: 53:09
do some research because I kept thinking Mo Joe looked like m o j o. But its M o j a.
Istvan Molnar: 53:16
Look. Yeah, it might have something in, so I really or some off the African languages. And it's probably my fourth that I cannot recall this, but But you should be able to find something on the Internet that where is the name is coming from? And what's the meaning off this name?
Josh Wulf: 53:39
Yeah. Yeah, I'll go looking for that. Okay. And then a name. Then you're gonna find another name. But the working title for your thing right now is payment Hub Enterprise Edition Payment Hub Ian. Yes, it's based. Sing Being uses BPM in Fantastic. And so we didn't Where Where should people go to find your software?
Istvan Molnar: 54:00
At the moment on, it's going to be under the my first foundation websites Let let me look for the Ural. It's supposed to be in our presentation decks, but, you know, tough own implementation software. But we couldn't documenting things. And so eso you should go to my force dot org's and there's a get hobbling called open M f bullpen. Mm movement what it stands for I'm sorry. Names are not my strongest things seems like but But let me and
Josh Wulf: 54:48
also my thoughts got off our J. And
Istvan Molnar: 54:51
that's something that you can find And another one that the my forced initiatives, which I just called you to be to the chat. So it's called Get hub dot com slash open em an f Ah, they're all of the's repositories. What we are working on right now sitting and I'm supposed to create the gate book material to document Ah, hold off that. Ah, what we haven't how to be in this how to download and how to build it for yourself and how to keep the turned run. And
Josh Wulf: 55:27
I say I found it. I found it, Yeah, it's get up dot com four slash open capital M capital F and that's in here Payment hub.
Istvan Molnar: 55:37
Yeah, and there's also the payment of E or a p h e. Because the payment of was the the early incarnation to then not concept. And now the Enterprise edition, which gives for this robustness and and really ready for the primetime. Or I would say going to be ready soon for the prime time. So obviously it's work in progress. We are. We are trying to get it right and then do the necessary performance testing, and I run out the usual things. So the bugs and working obviously with the TV community to to get the software really production ready and me to be usable in a banking environments. All these robustness, all these promises, what Mrs B is making and what we relying on needs to be obviously tested thoroughly, and if anything, then then those needs to be ironed out from the on the solution.
Josh Wulf: 56:39
I'm just looking at this pH ae stuff. There's like about seven repose that I can see like components operations, Web marginal Java connector importer, Adi bms connect the channel like do you need? Is this like a complex, multi repo kind of thing to set up and run?
Istvan Molnar: 56:57
Yes, but we have a ham chart to help me fall off left. So one off the one off the repose contains the environment labs, which contains the BPM and flows and contains the and charts inside. And it could give Ah, I won't say straightforward, but but at least on easier way to get this ah complete system launched and
Josh Wulf: 57:26
hope you don't really know if this
Istvan Molnar: 57:31
Yeah, Look, So I running out means that getting the documentation are right. So I would say that that that come in that is he on the on the road map yet?
Josh Wulf: 57:47
Well, this is a lot of, ah, work that you guys have done. And, um, it's a real kind of, like, complex space to be in and complex technology that it working with So keeping documentation up to date is like a whole thing, man. Yeah, I just did a new release for the node client for ZB. And, um, it's a whole cycle of updating documentation Change log read. May I love most in the whole thing.
Istvan Molnar: 58:14
Yeah, I know when you open your
Josh Wulf: 58:18
I like it. OK, I'm gonna I'm gonna dig into this a lot more like I saw the presentation that you send, But it was so far outside of anything that I can understand cause, you know, like the tick. I understand what the business domain and where the sits and like, this is a whole new thing, right? Like this is like developing the financial system for the future of Africa, which is not something I've ever encountered, you know, before. So I didn't really have anything to map it on. So this conversation has been really valuable for me to understand. You know, the problem that you're solving and where your particular piece of that solution fits into the bigger kind of architecture. It's almost like an economic architecture. Really?
Istvan Molnar: 59:00
Yeah, I agree with you. So if if this all works out before off this open source components and then there's really, like, a complete set that you can build out banking platforms and you can get the non banking billions to use this platform in and and have free Leah really of a toe get involved there. The cost off entry and the cost off account management is really low to get the pedic needs served
Josh Wulf: 59:34
fantastic. Awesome. Well, yeah. Look, thanks for coming on today. Ish von. And, you know, I look forward, Teoh, seeing how this develops in the future really exciting project and great work that you guys doing there. And so, you know, I'd love to circle back around at some point in the future and get an update on how things have been going with it.
Istvan Molnar: 59:55
Yeah, thank you very much. Thank you.