Eugene Danilkis, chief executive officer of Mambu, talks about the evolution of banking technology and how the company manages the expectations of the regulators and the customers.
Here is the transcript:
Emmanuel Daniel (ED-TAB): I’m speaking today with Eugene Danilkis, co-founder and CEO of Mambu, an SES Software Service Platform alternative to core banking or maybe the future of core banking. How would you describe what you have?
Eugene Danilkis (ED): Think of it basically as the engine for designing and servicing different loan deposit products. It’s an alternative to core banking in the sense that if you were doing banking services, traditionally a banking platform is what you would get. But nowadays where you’re trying to build the business that’s more agile, using and buying a core banking system and trying to implement that, especially the lending space just doesn’t make sense.
The timelines and the cost of setting that up and the flexibility for the speed to market moments. So, we wanted to take the approach just like Salesforce did with CRM and brought a product that provides you 80% of the functionality you need to manage any lending or deposit project. And then bring it to the sales world and make it easy to integrate through API.
The evolution of banking technology
ED-TAB: Take me through this journey of how core banking has evolved and where you play at the moment. In the old days, core banking was a very monolith, enterprise level type infrastructure, mainframe or closed architecture and all that. And then it became open systems, and you find that the smaller, newer places were able to come in and compete on price. But the model remains more or less the same; it was a monolithic model with a GL. Without your GL, you can’t start building a core banking system kind of thing. So, where are you and where is your proposition in the evolution of bank technology?
ED: Our evolution is very similar I guess to, as I was saying before, the same evolution that you’ve seen in other industries, so for instance, what Salesforce has done with CRM. So, take effectively the same functionality you had or at least 80% of the functionality you need to manage your customers. And reduce it to an order of magnitude of less of complexity and cost, and make it configurable through the application.
So, instead of going into customised code, everyone in the world runs on one Salesforce platform, and they configure it through the application. They can configure their field, their workflows and all of that. It’s the same philosophy with what we do on the banking side. So, if you want to design a new product and you come up with your interest rules, your fee structure, everything else. You just go into Mambu, and you specify that through the user interface and you have your product ready to go.
ED-TAB: So, it is a solution that exists in something like Amazon Web Services?
ED: We do use Amazon Web Services as our infrastructure for most of our customers. So, you get the benefit of course of the Amazon infrastructure underneath.
ED-TAB: You kept referring to Salesforce as a comparison. The big difference being that in Salesforce, the average institutional player has no problems going on a Cloud and driving from there. Banks never wanted to do that, so they always wanted systems to be proprietary to what they do. So, where are you seeing the interest coming from and what type of institutions? And what are they willing to give up to be able to use your model? The excess, your functionalities or your solutions?
ED: The whole application.
ED-TAB: The whole application. And then they can download that to do any form or customisation or are they basically ‒
ED: No. There’s no customisation. All of our 160 sites that Mambu run on are the same application, so there’s no customisation to it. I think what’s changed in the evolution perspective is you’re not building, as you said, a large monolith anymore. They’re using Mambu as one engine, and they’re using the APIs to plug and play different best-of-breed products. For coming up with credit scoring, origination, for instance, they pump data out of Mambu into different BI tools.
So, it’s more of a web based architecture picking and choosing different products as opposed to building a single monolith. So, that’s a completely different approach to the architecture. On the Cloud side of it, I don’t think the story’s very different than what you see when Salesforce came around also in the late ‘90s, early 2000s. Everyone was concerned about moving their customers and sales data to the Cloud, and now it’s a given.
I think we’re seeing the same trend now happening in banking. Even if you look from the regulatory side, there was nothing that was talking about cloud technology in the last five years. And in the last two or three, you’ve seen Singapore, Netherlands, UK and a few other countries where the regulators are encouraging and green-lighting the use of cloud.
Because they realise that the security that data centres like Amazon can provide are far better than anything except for maybe the top one or two tier banks could do themselves. So, why not provide the best technology, the best security, and best services for all the different organisations?
ED-TAB: But a number of these regulators are almost specifying a closed cloud rather than an open cloud. The idea is they haven’t moved to the open cloud role that an average bank in any of these countries is accessing a Mambu, which does not even sit on a server in their country.
ED: It might not sit on a server in their country, but as far as the way that the bank accesses it, there’s a lot of permission and flexibility in how they set up the access rights. So, an organisation that deploys Mambu can deploy it in a way where they only have access to it; they only have access to it from within the walls of the bank business themselves and can access it by logging into it externally.
So, you have a lot of controls of how you access the data, even though the data centres you use, might not be physically in the country, but it’s the internet, even if you access your bank account, your data packet flows from all the world to access it.
Characterising Mambu’s customer base
ED-TAB: So, I’m curious about this 160-client base that you have around the world. What would characterise them in a generic way? What do they tend to be? Do they tend to be smaller institutions? Do they tend to be newer institutions? Do they tend to be institutions in trouble and need to move quickly?
ED: No, it tends to be more institutions ‒ there are three types of projects we primary do. One of them is the organisations that are starting up, and that can be anything from a fintech lending start-up to a new challenger bank in the UK. And a few other markets were working with, they’re building something completely from scratch, and they want to use cloud for an additional approach to their whole business. So, they start obviously with a platform like ours but then everything that they do and build around it is also a cloud for some additional perks.
So, that’s completely the greenfield initiative. The other project that we have, which is fairly common, is the established organisation that wants to move into a new product line. So, we’ve had companies that do consumer lending, and they want to move into SME lending. We’re working on a project right now with a Tier 1 bank that wants to move out and do completely lean automated online SME origination.
We are working with a telco, for instance, that has a 50 million customer base and they want to start doing consumer lending and additional banking products to that. So, they’re not a traditional bank because they’re a telco, but they’re moving into the financial services.
ED-TAB: As a second category.
ED: And the third one is more about the transformational category. That’s where an organisation’s been doing things the same way for the last 10 or 20 years. And it’s not a case of them replacing their old core banking system with Mambu. It’s them relooking at their whole processes, seeing where they can put in automation, where they can put in new customer channels. And they think strategically, “what should our business look like in five, ten years?” And part of that transformation process ends up being putting in a class like ours.
ED-TAB: What the largest client that you’ve seen? What is the true count and customer base?
ED: The largest clients we have, have a million or so active accounts. Which they’re managing with us, a mix of both loans and deposits?
ED-TAB: In which country?
ED: This one is in Africa.
ED-TAB: And in China, what clients are you finding that are talking to you?
ED: In China right now, it’s more about the small business lenders. We’re working with a few customers who are not China-based companies but are expanding an operational footprint into China. So, they want to have an office and footprint; they might have investors who are coming in from outside China. And they want to establish a presence in China usually with a joint entity with someone in China as well. But then usually small business lending.
ED-TAB: So, these small business lenders were not necessarily banks, they look at something you provide and say, “Yep, let’s take and run with it.” But, what is your conversation with the traditional players who have a core banking system on their site with 1,000 programmers still doing line coding? When they look at something you offer, are they skeptical? Are they asking more questions now? Are they using you for pilots at least?
ED: They’re using us for pilots. But I would say their mentality is there are different parts of their business, often the small business lending side of it, maybe a little bit digital banking, little bit consumer lending, which they feel is being attacked by the different fintech companies or perhaps a threat. Or they see a market which is underserved, which often happens in Southeast Asia. It happens in Africa as well, where they feel there’s a market, they could tap. But they need to do it in a much more lean way both from a process, and technology, and cost point of view.
They realise that their current infrastructure is not well suited to it. So, the analogy used is they’re driving a cruise ship, but to go after these markets, they need a speed boat. So, their idea for these is to launch something that’s fairly separate. They wall it off from the rest of the business.
They might own the subsidiary, it reports to their balance sheet back to the core business, but it’s operationally independent and technologically independent. And that gives them a chance to then both test out new technologies but also go after new markets and act in a way that more fintech-like and independent. Because you can imagine of course if you’re running a bank that’s got a multi-billion-dollar balance sheet, and now someone comes and says I want to spend $5 million to launch SME lending.
And I’m going to have a request for the IT team. But this request will go to the very bottom of that stack because obviously the IT team, as you said, have many other projects of keeping the bank alive that they’re already working. That timeline is going to kill the digital initiative so they look for a completely separate operational stack and they use our technology for that.
ED-TAB: Now, where does the data set? Because many countries have regulations that they don’t allow customer information to get out of the county. You need some form of presence in the country.
ED: We use different Amazon data centres, which they have around the world. So, for instance, they have them in Singapore, in Australia, they have them all over the U.S., they have a couple in the UK, and in Germany as well. So, we use whichever the data centres that’s closest to the customer. For a lot of the cases, we have conversations with the regulators, and you explain to them how you do data security and how you manage the customer data.
You’ll quickly find that they’ll appreciate the fact that the service security you can provide if you set up the right cloud infrastructure for the bank is far better than what they can probably do themselves. So, if you talk them through their actual concerns, operational and practical concerns, and you show them how you address that in your usage of the cloud, then it has greenlighted quite a few different projects for that. You can’t put all the Cloud in one same bucket because there are different ways to set up different environments and different ways to set up access to it.
Managing the fear of the regulators
ED-TAB: So, in your conversation with regulators, which regulators do you think are further down the road in terms of understanding the need to deconstruct where they think the Cloud should exist? And are they much more comfortable today talking to a company like yours and also Amazon Web Services? And to think a little bit about the fact that an Amazon Web Services might probably have a lot more security than their traditional bank. In fact, they can go hammering the head of the local bank out of fear of not knowing if something hits, who is responsible or how they’re going to take that.
ED: The best thing is to be direct about it and talk about their fears. So, we go to them, and we say, “What are your concerns about this?” And it’s not usually unfounded; it’s just a matter of not knowing, first of all, how the infrastructure is set up and what operational risk and concerns are. And you just simply talk about it. Are you concerned about the data centre being unavailable? Are you worried about Mambu or Amazon going out of business?
You talk to them about their concerns, and then you explain to them how you have a practical strategy along with the bank with the financial institution to mitigate those risks. And you simply address that one by one. You say if the data centre goes down or if you’re worried about those two countries going to war, here’s how we would address that you still have access to all of your customer data. So, there are practical things you can put in place to address all those concerns, and we simply talk through those.
ED-TAB: So, which regulators are further down the road you think?
ED: We’ve talked to so many. We’ve talked to the ones in South Africa, Argentina, Germany, UK, Guana, and Singapore. Quite frankly, a lot of the conversations are led by the financial institution because regulators ask the institution, “How are you going to deal with this scenario? And, of course, Amazon and we have to be able to support them and answer that question. But at the end of the day, it’s the bank concern.
For instance, if one of their approaches is they take an escrow agreement with us, or they have a local copy of the database, which they back up on a nightly basis. That’s a process which the bank has to set up, and we simply have to build and explain how we support that process and how we make sure the data’s encrypted and secure and so forth. The questions are primary to the financial institution.
And what we see now is that more of them are willing and wanting to have that conversation. In the past, I would say maybe three, four years ago. Initially, the conversation was I’m not sure what the regulator thinks about the cloud, so I’m not ready to look at that because they didn’t even want to broach that subject.
Whereas now they realise the business benefit and they say why don’t you help us to have a conversation with the regulator. Let’s bring Amazon into the room. We see the real business value in it, so we want to have a conversation with them. Whereas before, if they couldn’t find some document that said the cloud is “Okay” in big bold letters, they would simply not even raise that issue. Now they explore it deeper.
ED-TAB: Walk me a little bit through the evolution of your company. There must be thousands literally of fintech companies trying to automate or even bring on a Java-based platform. Any aspect of the core banking system, the GL, the data analytics, and also the core systems of lending and the deposits. But somehow, you seem to have broken through; you seem to be closer to becoming mainstream than any of player of your kind. What is it about what you’ve done right?
ED: I don’t think too many companies have taken a fresh approach at this. In designing and architecting a system in a way that you would from the development point of view, from using the cloud infrastructure and from the way that you set up the software nowadays. I don’t think too many companies have taken a fresh look at that and we did decide to go to the core of the issue.
And we sat down with a blank slate and asked what would a system look like and what functionality should it have? How should it be flexible? Where it more constrained? How should we do our development processes? How should we use cloud technology? So, we sat down a clean slate.
ED-TAB: But when you took your approach, you had to question so many of the concerns that already exist in the minds of the existing customer base?
ED-TAB: You had to challenge conventional thinking. So, where was the breakthrough that came for you where the next client was comfortable talking to you because someone else had bought into the way that you look at it?
ED: Well, it came client-by-client, every individual client. And even nowadays so many of our projects come into references because a lot of our clients speak well of us. And a lot of the opportunities that we have come in through the reference projects. It just builds up by working with them step by step. We like to work closely with our clients to develop the product, but because we only have one product and one code base, we have to take their request and try to generalise it.
So, there might be some ideas that we have from a customer that is doing SME lending in China. Which applies very well to someone who wants to do something in the UK, or a consumer lender that’s doing something in the U.S. So, our approach has been working closely with the clients to develop the product but never to customise it for a client. And I think that’s something that we’ve been quite strict about from product development from the very beginning.
ED-TAB: Always generic.
ED: Always to generalise their needed functionality and come back to ‒ a little bit like an annoying child that asking why the need something? Why they need something? You get back to the root of the issue, and you design the functionality to support the real need. And then you invest additional effort to design it in a way that’s generalisable, such that it doesn’t just solve the problem today, but might solve something they need in a month or might solve something that a client needs the future.
ED-TAB: Where do think a company like Microsoft went wrong because they would have been an intermediary before someone like you came along? Because before them, there was mostly the closed end infrastructure and then they tried to put it up on their platform and even convince the banks that a non-traditional player can scale, can handle the volume, the needs of a typical bank. But you’ve now leap-frog that, you’ve put it on the web and you’re selling what is essentially a generic system.
ED: Well, I think it’s just the focus for them. I don’t know too much about the Microsoft strategy in the financial space. We were obviously looking at the Microsoft Azure Cloud versus Amazon Cloud, and both are terrific products, and we just made the investment in Amazon from the beginning. As far as their product strategy, I think very few companies wanted to tackle the core issue of building out the transactional engine. And the product servicing engine effectively for so many different types of lending and deposit businesses out there.
It’s just not something that too many people wanted to take a fresh approach. But we believe from the very beginning that the SAS model is going to win out, that the cloud is going to become completely normal in financial services; it’s just a matter of time. And also we believed in a very open API integrated architecture where companies would choose best-of-breed products.
So, they would choose us as an engine, and they would choose a different product which they buy or they integrate. So, I think initially from the very beginning, we just believed that’s where the trend was going, and that needed a brand new platform from the beginning.
Strengthening Mambu as an organisation
ED-TAB: Tell me a little bit about how you are configured as an organisation. How many employees do you have? And how many of those spend time tweaking the system so that the generalities productised? So, over time you’ll be selling the same changes that you make to new clients and stuff like that. How much of your employee base spend time with regulators? What comes across as customisation is answering the questions of the different jurisdictions that you sell into
ED: We’re a team just shy of 80 people right now.
ED-TAB: That’s amazing. That’s incredibly amazing.
ED: It’s growing quite quickly so we should be close to about 130-140 by the end of this year, including our office in Singapore and Miami. And about half of that now and probably even by the end of the year is going to be our engineering team, so that includes our developers and our cloud administrators. So, half the team is still technical in some way.
But I think a lot of the work happens before we start building other features, it comes in through both the sales process and also the project process. So, when we work with our customers, we tailor a project for them where we usually put one or two different applications.
ED-TAB: Eighty people? So, do you outsource your line coding at least, any form of line coding at all?
ED: No. Everything’s within our organisation. So, you’re an organisation, and you wanted to come up with something customised outside of Mambu. You came up with some crazy fee structure which we don’t support within the product, and we wouldn’t support because you wanted to base the fees based on sports scores or something. It doesn’t make sense as a core feature within Mambu. Our job was to make sure that you have the functionality within the core product and through the APIs to be able to build that little fee engine outside of it and integrate it through the APIs.
So, there are some organisations of course that build a couple of these little code snippets around Mambu, but we never build that for our customers. We simply provide them the toolkit if they want to do so. But effectively, no, it’s completely our engineering team, and that’s the scope of the company.
ED-TAB: So the most difficult customer you’ve had and the implementation of the customisation aspect of it, what’s the lead time?
ED: So, we don’t customise. If you look at a typical project plan, usually during the sales process we figure out if they are any additional functionality ‒
ED-TAB: You give them the toolset, so they customise it?
ED: We give a toolset, but we identify during the sales process if there’s additional functionality which we might have to develop in Mambu. For instance, if you do compounding interest and Mambu doesn’t support compounding interest, we discover that pretty early in the sales process as a quick example. We just simply then put together a project plan and part of that project plan, one work stream will be the fact that we develop compounding interesting as a new feature in the product.
Of course, it’s not customised for you; it’s part of the core product and available to all of our customers past, and all of our customers in the future as well.
ED-TAB: So, it’s a not a catalogue that you’ve developed, it’s in the system?
ED: That’s right. So, it becomes just core functionality, and then our project team is just working with you as a customer to capture your business requirements and to help set up Mambu in the best way to support them. Because there are literally millions of configuration items, you can have combinations of them. And so our project team is just somebody to talk to you. What do you want to do? How does your product look?
And then work with you to go through the application in real time and go set up the product, and we try out some accounts. We see what happens when you do prepayments, what happens when accounts are late, and we work with our customers in real time to set that up. So, if you have your requirements and you know what you want, there’s no reason why you couldn’t have Mambu set up within a day.
But the reality is, it’s a collaborative process because you are also at the same time starting your marketing campaign for your new product. You’re probably integrating it out to your other systems.
ED-TAB: It’s funny because what you’re describing is the intermission phase of the Indian IT companies which had what you’re saying in adding the customisation back into the core product set. But they never did that, they had large developer pools, whereas you are putting it all back.
ED: Well, we as a company, we have to. And the reason that we have to is that our operational commercial model forces us to. So, the incentive for a company to keep customisations and keep developers is when you charge man days for developing it because you can imagine that it becomes commercially attractive for someone to say you have a new feature request. Let me just see how much that’s going to be. I’ll build that customisation for you. It’s going to be an extra $50,000 plus an extra 20% to maintain, and you keep adding that on.
So, it becomes a little bit commercially addictive to build that out. Well, we don’t do that because our commercial model is completely subscription based, and subscription based is usually tied to key business metrics. It might be a portfolio under management or revenue, whatever it is for the customer, but it’s usually a key business metric on a subscription basis.
So for us, that’s the key driver and the key value of our business. So there’s little incentive for us to try to get professional services days out of you or to maintain a large pool of customisations because that will fundamentally slow our business down over the long term. So, we’re pretty strict about saying “No” to customisations.
ED-TAB: So, what are the kinds of clients that you can see that you’re not going to pick up because that’s not going to fit your model?
ED: It’s probably the clients that want to be replacing systems instead of transforming them. So, even organisations which are ‒ if it’s a greenfield initiative, it’s great because we get to work together with them and we get to design the products for the entire process with them. If it’s someone that’s transforming, that means they’re rethinking about how they’re doing their processes, and they’re also open to coming up with new approaches.
But if someone who’s just simply replacing and saying I have this whole process and I have this old core banking system that I want to switch out that old core banking system product and put in a new core banking system but I want to keep everything else the same. Then that most certainly won’t work with us because that means they’re not changing much of the business and it means they are most likely going to try to force things which they’ve done for legacy reasons.
Some of them we’ve seen are simply fundamentally wrong, but that’s how they’ve just done it and will try to force that into our product, as opposed to trying to come up with a new way of working collaboratively. I think it’s those pure replacements or projects that will unlikely be a good fit for us. It’s organisations that are digitising and thinking about it either from a greenfield or a business transformation perspective. I think we’ll find a way to work together with them.
ED-TAB: It’s amazing because I can only see that you’re learning a lot of things as you go along. And there are areas like cybersecurity, for example, where you’re probably learning a lot of things which is way ahead of just about anyone else because you’re running a platform on a global basis and serving very specific financial institutions in different markets.
ED: We get the benefit of taking knowledge from different customers and applying them. So, it could be working with a telco in Asia, and working with a bank in the UK, and working with another fintech company in the U.S. And when you get to work with all of them and you have one product, also one project team that fundamentally work across all them.
You get to take that learning from all the different companies and apply it back to additional projects with future customers and back to the product as well. And then you find the similarities between them.
ED-TAB: So, this is software as a service?
ED-TAB: But moving to yet another realm which is service. That means without the software component that the bank owns the business itself; the whole thing has moved to a service platform.
ED: So, we’ve seen a few of those projects, and we have a couple that we’re working. Effectively, they’re working probably with another company like a system integrator, or another company that’s providing additional services beyond us. So, they’re still using our platform to drive the engine design of their products, service their accounts, all of those things.
But they may provide additional business services to the customers that we don’t. So, we’ve seen a few of those projects and we kind of fit well because it’s the software’s a service mentality aligned to it.
ED-TAB: So, it’s also the kind of solution that you might sell through some of these service providers, like consulting firms for example?
ED: Potentially, it depends on what the organisation wants to do. The ones that feel like tech and having close ownership of the different pieces of software supported to them. They want to be able to have access to Mambu directly and be able to work with APIs to configure the application. There are others that feel they just want someone to put all the different pieces together for them and they want them to run the service for them.
In which case we’re probably not working directly with the organisation but working with that company that is effectively gluing our projects. Plus a few other SAS products, plus a few other spoke things together, and we’re providing the tool effectively.
ED-TAB: You kept mentioning Salesforce, but you’re much closer to some of these budget airline websites, the budget airline systems where you can start an airline or shut it down tomorrow. But you can do that with a platform that already exists, that serviced all the budget airlines in the country or region.
ED: Speed to market is a big advantage. The fact that you have a platform and they configure it and you can be running with the APIs very quickly is a huge advantage. But it’s not just for the launch of the project; I think it’s also organisations taking into consideration that they don’t know what the tech landscape is going to look like and what the customer base will need. And so they want to keep and maintain that flexibility.
So, you don’t want to build something and say I’ve finally built this amazing architecture and that’s the thing I’m going to run on for five years. Because the reality is you’re going to have to change some products, you’ll have to put in new pieces; you might change your mobile app. There might be new technologies out there, so organisations are trying to design themselves for change and flexibility, and we fit pretty well into that approach.
ED-TAB: Final question, the data that you see flowing through your network or your platform, what’s that telling you? And where is deposit system going in general?
ED: We haven’t done much in the way of data analytics across our customer base. We obviously have all the access to the data, but we haven’t done too much in the way of analytics because of it. Our customers obviously do themselves because they have all of their data, customer’s accounts, transactions, all in one place, which makes it easy for them to do analytics.
And use it for things like credit scoring, or BI. Or perhaps in the very near future AIs, which you’ve probably heard about from the conference. But we have not been using the data for anything.
ED-TAB: Thank you very much, Eugene, for this conversation. I’m very pleased to have met you, and the thinking is what is revolutionary here. And I hope that we will be able to build on this conversation in time to come.
ED: Likewise, well thanks very much.