Thanks for watching Tuum in Action Episode #2: Building a BaaS Infrastructure.
Read the Full Transcript:
Javed: [00:00:00] Hello everyone. Let’s give a minute for all the participants to join. I see we have a sizable number of participants, so I believe we can start.
Hello everyone. I’m Javed Rafi, part of Solution Consulting at Tuum. We have a very interesting topic for today, Building a BaaS Infrastructure. Along with me, I also have Rivo Uibo, who is the Co-founder and the Chief Business Officer. Let’s get started.
When we talk about building a BaaS infrastructure, who would typically require a BaaS infrastructure? That’s how we’re going to begin with, then followed by how a BaaS infrastructure gets set up. It could be various different use cases, different scenarios, how the key concepts of modularity and multi-tenancy are critical when it comes to setting up a BaaS infrastructure. That’s going to be an agenda topic. Then we will discuss our customer LHV success story, where Rivo will walk us through what went behind the scenes in making LHV is a successful BaaS provider. Then we’ll proceed with a product demonstration, where both from a wallet as a service use case, as well as consumer finance as a service use case, I will give you a walkthrough of what Tuum has to offer. All of this we plan to cover in the next 30 minutes, and then we open up for a Q&A which would be the next 10 to 15 minutes. Let’s get started.
Before we talk about building a banking as a service infrastructure, who would typically require a banking as a service provider or banking as a service infrastructure?
It could be a non-financial participant. It could be a non-financial health tech, travel tech, a hypermarket chain, that wants to offer financial products on their own to their client base, without having to go through the complexity of having to build a FinTech architecture. Or it could be a tech company or a use case where they would want to quickly launch a capability – it could be wallets, it could be cards, it could be payments or loans – where they look at the BaaS provider as their ticket to be able to quickly launch a feature in the market. Also it would be relevant for providers or for FinTech ideas where they would like to spend most of their time in solving the business problem rather than handling the technical barriers or the technological barriers that comes behind building an infrastructure.
These are the ideal customers that would typically look to a BaaS provider, where they look for reliability. They look for security and compliance because they know that the BaaS provider is going to be running through a strict scrutinizing process to make sure that the entire tech stack is scalable, is able to satisfy the roadmap requirements, is able to change directions as per the changing market needs. All of this put together makes a BaaS provider quite relevant and quite important in today’s day and age.
How would a BaaS infrastructure come in place? Before looking into BaaS infrastructure, it’s also important to understand, how would a classic infrastructure look like? Typically if we look at a classic co architecture, you have a core platform that caters to various different products. It could be around multi-currency accounts, it could be savings, current accounts, deposits. It could be various flavours of loans, different types of cards, payments. These capabilities in the core would be surrounded by a range of ecosystem players, which would typically offer a digital omnichannel platform, a KYC partner, a partner for payments, could be domestic payments, let’s say FPS backstabs from a UK perspective, from a Saudi perspective it could be SADAD, et cetera. All of this ecosystem components along with the core would typically power a core architecture.
How would this fit into a BaaS scheme of things? If we look at a high-level overview of how a BaaS architecture would look like, the typical type of customers would again depend on the type of BaaS because again, BaaS has different flavours. If we take BaaS from a generic perspective, a typical BaaS customer could be a FinTech that wants to offer wallet. It could be a health tech or a travel tech company, for example, that wants to offer multicurrency FX cards to their customers. It could be a BNPL player. It could be a digital asset player that wants to enable buy/sell of various different stable coins and cryptocurrencies, and wants a wallet to be added as part of the overall ecosystem.
All of these different players would each have their own use case, would have their own use case a requirement where different components of core are required. As a BaaS provider, the primary focus point would be in having the BaaS API gateway, that would enable all of these BaaS customers to be able to perform their onboarding the customer, creation of different types of accounts, servicing the accounts, and performing the day-to-day processes.
Then there BaaS user interface, which would typically manage the day-to-day invoicing. All of these BaaS customers could be subscribed to different products, different subscription models. They would want to understand what is the upcoming invoice, what are the different products that are coming up in the roadmap, so there’s a need for a BaaS user interface.
Behind this BaaS API layer and the user interface lies the entire BaaS tech stack, where typically you would have a dedicated environment with multiple tenants. When I say tenant, a tenant could be a physical tenant or a logical tenant. We’ll come back to that topic in a moment. Apart from the core, there’s also a need for a range of ecosystem components, again, depending on the use case.
If we talk about generic BaaS, a typical BaaS player would want to focus on four use cases: payments, cards, accounts, and loans. That basically means there are a range of ecosystem partners required in order to fulfil these requirements. There would be a card issuer processor, there would be an FX remittance provider that provides up-to-date FX rates, there would be domestic and international payment players that would provide seamless integrations to enable inflow and outflow of payments via different local payment methods, as well as different international payment methods. All of this would enable or power these BaaS customers to be able to run their day-to-day operations.
I did mention tenants. What is the use of having different tenants? When we talk about a typical banking as a service use case, let’s take wallet as a use case. If I’m a FinTech that is looking at a BaaS provider from a wallet perspective, I would typically require a wallet. It could be single currency, multicurrency, again, depending on the use case. I would require a cards management, so that I can issue cards to my customers. I would require fee pricing. I would want my own database so that the data, be it the customer data, the transactional data that relates to my business will in no way get swapped or get copied to my competitor. Here in this case, a wallet provider would typically want an exclusive physical tenant instead of a logical separation off data.
Similarly, when we talk about other different use cases, let’s say if we take the consumer financing use case, a typical consumer financing use case would require a credit decision, loan origination, management, collection, payments. Payments could again be loan disbursals as well as collecting repayments. The entire flow, including the customer data, the ledger, all the different accounting entries, needs to be stored and processed in its own database. This is where a physical multi-tenant setup comes into picture, where every BaaS customer gets a mini core version with the set of features that are relevant for them.
An alternate scenario would be a use case where an entire core gets deployed. That would mean that there’s going to be extensive overhead when it comes to technology. Extensive overhead in terms of cloud cost. All of that could be avoided by having a physical tenant, where only those microservices that are relevant to a particular use case are deployed. This again, is a high-level illustration.
If we take wallets as a single use case, wallet as a service could have multiple flavours. It could be a non FinTech entity, let’s say a travel tech company, or it could be a hypermarket chain, that wants to offer cashback or loyalty reward programs. In this case, they may not require the extensive domestic and FX payment rails. They would instead require a cards management capability so that they would be able to offer closed loop, cobranded cards to their customers. Compare this with a different use case of wallet, where I could be an FX remittance provider where I would like to offer a wallet in multiple currencies that’s backed by a multicurrency card. In this case, the capabilities of functionalities differ. That’s where a multi-tenant as well as a multi-product capability set up would assist you in having physical separation of data and also making sure that every FinTech consumes only those services they are subscribed to and only those services that they need. This again is an example from a wallet as a service perspective.
If I move on to the financing use case, where there could be lending as a service, again there could be multiple different flavours. There could be microfinance, consumer finance, there could be SME financing, where a typical FinTech would want to process or keep track of the inflow of payments that an SME or a merchant receives, using that to do the credit decisioning. Again, there could be different flavours of financing: it could be conventional financing, it could be Islamic financing again. There are multiple flavours.
What it all puts together is that there is a need to have physical tenant from an infrastructure perspective, as well as to offer only those microservices or only those capabilities that are required by a customer, instead of having an entire co banking system deployed for the use of a particular FinTech.
This again is a very high-level overview that highlights the different capabilities that different use cases require. Banking as a service can again be subcategorized into wallet as a service and financing as a service, that you are currently looking at.
What are the different factors that we looked so far? Typically, from a BaaS perspective there are three main factors. One is to have the BaaS API layer that serves as the communication point between the BaaS customers and the BaaS providers. Within the BaaS architecture, for every BaaS customer there’s going to be a physical tenant. This physical tenant will have only those modules that are relevant to their use case.
For example, FinTech A could be interested only in offering wallets without cards, whereas FinTech be may require both wallets and cards. In this case, having the flexibility where you’re able to create physical tenants for each of your BaaS customers with a modular capability, where depending on the checklist off their requirements you’re able to deploy the right modules or right microservices in order to make them work and perform their day-to-day operations.
What remains as common when we compare a BaaS architecture with a classical architecture would still be the range of ecosystem partners, be it get payments, cards, treasury, KYC, AML, et cetera. All of these are commodities that are meant to perform their day-to-day tasks, day in and day out. This would definitely not require a multi-tenant approach. This could be a single installation that is connected to each of these physical tenants. In this example, there’s an assumption made where this BaaS provider is powering four different FinTechs. Each FinTech is focusing on a particular use case, and this use case is helping these BaaS customers to be operating based on their use case requirements.
This was again a high-level overview of how multi-tenancy and modularity gives a BaaS provider the flexibility so that they are able to deploy multiple mini versions or mini cores within their BaaS architecture, and thereby save considerable time when it comes to BaaS support team that has to manage the day-to-day operations, and also the cloud infrastructure cost to be able to efficiently manage without having to deploy resources that are not required by a FinTech. Also from a BaaS customers perspective, they are paying from an economical perspective, because they are only getting the services that they need and not the unnecessary services that may be running in the background.
This is again a high-level overview of how a BaaS architecture could be set up. What I would like to do is I’d like to invite our co founder Rivo to walk us through the LHV success story. Over to you, Rivo.
Rivo: [00:15:48] Thanks, Javed. Let’s speak about the real-life examples, because seeing is believing. Also we have a say here at Tuum, that when jobs are on the line, it is the go-lives that matter. That means that we at Tuum are very much action-oriented.
I would like you to ask you a question. What does an impact look like to you? When we speak about the banking institution, which has dual regulated bodies both in UK and in Europe, it is offering banking infrastructure for more than 200 regulated FinTechs. It’s offering more than 10 million end user transactional accounts and running more than 7% of all the instant Euro payments. Is it impactful? I think it is, because it is a one lean set of operations, having a very large impact on the market.
You might also ask, like, why is a bank like LHV partnering with Tuum? It clearly comes down to the element of strategy, meaning that where do you spend most of your time and resources? You have two options. Either you spend most of your time and resources building the baseline infrastructure, or you spend it on the product management, value added integrations, and working with the distribution channels. LHV has the priorities. After running the global RFP to select the most capable and flexible core banking platform to enable the efficient operations of their BaaS infrastructure, Tuum has been now selected as a partner, and we have gone successfully live and done also very large migration into Tuum platform.
You might also ask, what is it that LHV do differently, that they have such impact on the market? I will highlight four key pillars over there. One thing concerns the capability of systems and technology, because Tuum’s scalable cloud native core banking system with the open architecture, to build out as wide an ecosystem as possible.
The second thing covers the mindset side of things. Because offering the API based products is something completely different than offering, let’s say, fixed banking instrument with certain parameters around it.
The third thing covers the compliance and risk appetite side of the things, that they have made up their mind which customers do they serve and which ones they don’t. You have to be very clear about it.
The fourth key pillar covers the operational side of the thing. Because running the BaaS infrastructure means that you have found a problem worth solving, and you have the extra layer of complexity when it comes to the multi-tenancy and all those additional parameters you need to be able to configure.
How to manage those relations? Those are completely different type of relationship management aspects compared to running your private banking or everyday banking units and the relationship management side of the things.
All in all, as the outcome, LHV has showcased that they are super relevant in the market. They’re considered to be the institution which has the can do and will do type of attitude. They have been able to massively expand their addressable market share. Also, they are able to commercialize now all the infrastructure for additional lines of businesses, meaning also the entry into the retail and SME banking side of the thing.
As a last element, I would highlight that this collaboration also won the IBSI Global Finance Innovation Award for the best core banking implementation. The keyword here is all about impact. Javed, over to you.
Javed: [00:20:05] Thank you. Thank you, Rivo. I would encourage all participants to post your questions to the Q&A, so that we could answer as many questions as possible.
What I would like to do next is to get into a demo, where I would be walking through two use cases, one being wallet as a service and the other one being consumer finance or lending as a service.
What you see here is a dashboard. We did speak about multi-tenancy physical tenant, where every BaaS customer would get a physical tenant. Every physical tenant has a back-office user interface, and this user interface could be configured by the BaaS provider so that they could decide what access rights and rules would a BaaS customer have with this user interface to make sure that they’re able to perform their day-to-day operations, but within the subscription model that a BaaS provider wants to set. Because an administrator access to the tenant would mean that a BaaS customer can configure products on their own.
Certain BaaS providers would prefer that they configure these products in a pre-configured manner that are available out of the box, instead of a BaaS customer doing it on their own. Using the user management capability, a BaaS provider would be able to configure.
Depending on the modules or the capabilities that BaaS customers subscribe to, only those microservices can be selectively deployed within a physical tenant. For example, I would like to run my payments business where I would like to launch FX payments that enables customers to receive money and send money in various different payment methods. In this case, from a BaaS perspective, I would subscribe to the payments module. The payments module will come in handy with various different capabilities.
As a BaaS customer, I have my own AML team, where there is an AML officer who needs to review the payments that failed the AML check. In this case, the responsibility lies on me as a FinTech because I’m the one running the payments business. Therefore I need to provide a user interface. How would that work? Based on the user where it says rules, an AML officer at the side of the BaaS customer would be able to review the details, they would be able to see what actually happened. The AML platform, the transaction monitoring platform, would still be powered by the BaaS provider. Here the AML results is something that is visible, and the AML officer would be able to make a decision.
Similarly, I could be a lending FinTech that has subscribed to the loans module. There are some loans that are pending approval due to some exceptional scenarios. How can I offer a user interface to my loan officer to be able to make this decision? Again, this user interface that’s exclusively available for every physical tenant, therefore for every FinTech, enables BaaS customers to have a seamless user interface to manage their day-to-day operations.
Typically, from a wallet as a service perspective, if I’m a wallet provider and if I approach a BaaS provider, what are the various requirements I would have? I would require a capability where I’m able to create segments amongst my users, because as a wallet provider I would want to group my customers into different categories. That’s something that’s available out of the box. For each of these categories, I may want to set up different pricelists or different fee pricing lists, where similar to that of digital bank I may want to have different subscription models, like basic wallet subscription, premium wallet subscription, etc. As a BaaS customer of wallet as a service, I could configure my own set of fee price lists and associate to a particular group or a segment of customers. Once this is done, and the basic ledger is configured with the various different capabilities, I would then be able to offer wallets to my customers.
How would a wallet typically look? Let’s assume here I’m a wallet FinTech, I’m using the services of a BaaS provider, and the BaaS provider has provided me with all the APIs as well as this back-office user interface. If I’m a back-office person working at this wallet institution, I would be able to see the customer information file of the customer who has been onboarded. I would be able to see the different types of accounts. Again, accounts or wallets, the use case could be single currency or multi- currency. When we say multi- currency, the classic approach is to have one account per currency, not in Tuum. Tuum gives you the flexibility where you can have a modern multi- currency approach where one account is able to hold balances in multiple different currencies. Think about the number of API calls. It’s going to be just one to retrieve all the balances and then show it to the customer on the mobile app.
Along with this, there are again a range of features such as payments, direct debits, fees, setting up various different limits. For example, what if this wallet happens to be that of a family wallet or a group wallet? In this case, we have a client who has different accounts, and one of these accounts happens to be a family account. If I click on the family account and if I go to access rights, I’m able to see different users or different members within this group or the family wallet have different access rights and rules. This would enable a wallet provider to offer a standalone wallet, a business wallet, as well as a family wallet where you could have a separate wallet for the kids in the family and then the parents are able to control it. This is an example from a wallet as a service perspective.
Let’s talk of lending as a service. Typically if we talk about lending as a service, there is a need for different products to be configured. There is a need for loan origination, loan management, loan collection, setting up the different payment integrations. How does the platform offer all of this?
Again, if I go back to the dashboard, if I click on loans, I’m able to see campaigns and products. Here, a BaaS provider can pre-configure all the various different products that comes under a particular subscription model. That would be offered to a lending FinTech. Using these products, a lending FinTech would then be able to offer different loan contracts to its accounts. Again, configuring a product is only going to take a couple of hours, and not weeks or months. It’s a step-by-step approach, where a business analyst or a functional person who has the required knowledge is able to configure.
Again, there are multiple interesting features within the loan product configuration. For example, I can set up an STP rule where the disbursement fee would depend on the channel where a loan contract has been applied. If it’s via mobile app, it has a special promotional value, in comparison to an in-store loan product, for example. This way it’s purely configuration-based approach, where the loan product gets configured. Once a product has been configured, then the loan product is ready for use. What it basically means is a customer can go around and start creating loan contracts. It could be via various different origination channels.
In Tuum, we have the origination layer where a loan could come in from a mobile app or a digital platform. An institution can create a pre approved loan offer and send it as a push notification to the mobile app, so that the customer can make a decision. If he or she accepts, it creates a loan. Then comes the loan management, where the life cycle of an active loan contract is managed. At any point of time, if this loan goes into warriors then you would also require loan collection, and we refer to that as debt management.
The entire setup that is required, the core components from a lending perspective as well as from a wallet perspective, is something that’s readily available.
All the transactions need to be registered in the finance module. Again, there are a chart of accounts that would enable you to configure all the various different assets, liabilities, income, expense, which is again, multi- currency enabled, which will keep track of various different entries that are required, and all the fees associated with that.
This is again a high level overview from a wallet as a service perspective as well as from a lending as a service perspective. I think we are right on time. I’ll pause here and move to questions.
We can get started. The first question, what is the typical implementation timeline for a BaaS architecture? Again, as we discussed, it depends on the scope, because a BaaS could be wallet as a service or it could be lending as a service, or the entire BaaS as a service infrastructure setup. A typical timeline would be, I would say two quarters to do the implementation, one quarter to do the test, go live, friends and family release, do the readiness check and have it ready. This would cover both a wallet use case as well as a lending use case. I hope I answered your question here.
The second question I see, is your BaaS setup applicable to a specific cloud provider? No. Tuum as a platform, we are cloud agnostic. We have live implementations and multiple different public cloud providers. This is something that any fourth-generation core, Tuum being one of the four generation core platforms, should be able to easily handle. This is never an issue.
I see one more question. What is more popular, wallet as a service or lending as a service? Again, it depends on the markets. Typically if we look at Europe, Asia, we see a lot of interest and inquiries coming in from wallet as a service, as well as Middle East, specifically Saudi Arabia. Lending as a service is definitely catching up. I would rank wallet as a service higher in comparison to lending as a service, because WaaS has a wider market range and quick to launch. Because if you have an MVP of WaaS, where you would want to offer wallets to non FinTech institutions who would not require a stringent AML process or stringent domestic international payments, all they would require is a closed loop wallet with a card linked to it. That would not require any regulatory approval. That makes it easy for multiple non FinTech institutions to be able to launch or add more interesting product features to their customers. That’s where we see WaaS being more popular than lending as a service.
How do you collect business requirements? Can you offer ready-to-use templates? Yes, definitely. What we do is, based on the inquiries we have, based on our current customers’ feedback, we could provide you with a set of ready-to-use templates where we pre-configure products, be it wallet, savings accounts, current account deposits, or loans, specific to a particular country or a particular region. That would be readily available so that you wouldn’t have to go through the business requirement analysis and configuration process. This is something we could do.
Any other questions? I see we have also a chat window. Perfect. I believe this session was quite insightful. Please do reach out to us if you have more questions.
What we did today was a very high level overview where we focused on two aspects for any BaaS provider to keep in mind before they consider setting up a BaaS infrastructure. One is modularity – the flexibility to be able to pick and choose which microservices, which module, depending on the customer’s needs. The second is multi-tenancy, where even though logical separation is interesting in certain regions, for example, if a BaaS provider is based out of European Union, a logical separation of data would definitely add value. But if we look at regions where there are stricter data residency requirements, where FinTechs and non FinTechs would not want to risk having their data being shared or stored in the same database as their competition, for example if we talk about Middle East, Saudi Arabia, Central Asia, etc., having a physical tenant would not only make life easy for a BaaS customer, but if a BaaS customer has to go through regulatory requirements depending on the changing business needs, this would also help them quickly achieve their regulatory approvals when it comes to a physical tenant separation.
Thank you. Thank you, everyone. Speak to you soon.
Stay Tuned for More
Want to find out how Tuum’s platform can drive growth, innovation, and efficiency for your SME lending services? Get in touch to find out more.