Nan Wang
Questions
- What developers are most excited about the i2c platform?
- The banking as a service providers have core capabilities and adjacent capabilities, and there are certain degree of products overlap across different platforms. What do you think fundamentally differentiates the BaaS platform?
- Could you please elaborate on the banking relationship aspect? Does the BaaS provider pick the sponsor banks or the other way around and what determines a strong relationship amongst them?
- If we look at some of the well-known community banks, such as Evolve Bank and Trust, Sutton bank, WebBank, Bancorp, how much difference do their capabilities make for BaaS tech stack?
- Speed to market is something that's come up repeatedly. And one of my learning is that the banks actually determine speed to market rather than the BaaS platform. Could you please elaborate on that? And how should I contextualize who's adding what value?
- Some BaaS platforms provide program management and some don't. What would be the rationale in deciding whether BaaS platforms want to be program managers or not?
- You mentioned how i2c, for example, would select the banking partner based on what program they support, i.e. whether there's a match between what i2c wants to do and what the bank can offer. Could you talk about when Bond builds on top of i2c, what's the process of matchmaking there?
- If we think about two worlds, in the first world, we have a fast-moving FinTech startup; in the second world, we have a Nike or Gap of the world, established retailers or digital brands who have got their own profit-making business model. These two types of companies want to provide financial products. Could you talk about what would be an ideal banking stack for each of them please, and why?
- And from a BaaS player's perspective, what characteristics would be present in their ideal customer?
- Currently, the BaaS platforms mainly monetize through the interchange. Some of them also charge per customer per month type of fixed fee. And some also charge a one-off fee. Could you please talk about how important you think it is for BaaS platforms to be less reliant on interchange and what value-added services they can provide to upsell?
- How scalable do you think BaaS is?
- In terms of use cases, some FinTechs just provide one use case in a big market. Then, there are some other FinTechs, they want to provide multiple use cases. Do you see providing more use cases would be a constraint on how scalable BaaS can be, because if the BaaS only provides debit or prepaid and then the FinTech wants credit or some other things, then this mismatch would either require the BaaS platform to build additional programs or maybe the FinTech needs to look for somewhere else?
- What would be the top three things you look for to determine which BaaS platform would be the most promising in the future?
- Is there anything that you think is very important that we haven't talked about?
Interview
What developers are most excited about the i2c platform?
Guest: I think from a developer perspective, what they like about it is the fact that it is open, it's all API-driven, all of the functionality that the program or the platform offers can be accessed through the API. The other aspect is that it's very configurable. They're able to configure it in many different ways to satisfy different types of financial products, whether they are prepaid debit, credit lending, any flavors of those products as well.
The banking as a service providers have core capabilities and adjacent capabilities, and there are certain degree of products overlap across different platforms. What do you think fundamentally differentiates the BaaS platform?
Guest: I think there's a couple of things that differentiate. One is the different products that they support and whether they're able to make them feel like a single platform. Some of the BaaS players are having to work with different processors to provide different products.
So for instance, Marqeta doesn't have a credit offering. So to offer debit or prepaid and credit, they've got to have multiple platforms behind them. And so they'll have to, their challenge is to make sure that it feels like it's a single platform.
And that's what the banking as a service providers are trying to do. You've got the Galileo, i2c and Marqeta who are typically the engine behind other BaaS players, like Bond and Railsbank. Those guys are, they're BaaS players.
However, they're not an actual processor, whereas with i2c and Galileo and Marqeta, they play in the BaaS world. They're missing some things as well though.
The other BaaS players that I just mentioned, they actually bring the banking relationship, whereas Galileo, Marqeta and i2c, they don't usually bring the bank. So that's a little bit different from those types of players.
Could you please elaborate on the banking relationship aspect? Does the BaaS provider pick the sponsor banks or the other way around and what determines a strong relationship amongst them?
Guest: So it depends on how the FinTech wants to approach it. The FinTech can go to a full-on BaaS provider where they provide everything. They provide the bank, they provide the compliance, they actually provide the network.
And then they provide the processor, again, usually, it's an i2c or a Galileo behind those BaaS providers as the processor. But in that case, it's a one-stop for everything. It makes it very easy.
However, it ends up costing a little bit more to them from the perspective of a revenue share. So they've got to share more of that. Whereas if they go direct with the processor, again, the Galileos and i2c and Marqetas, then they're able to choose their bank. And when they do that, they actually keep more of the revenue.
However, they then have to manage the bank relationship, which may or may not be a problem for them. But that's really the difference there is who manages that bank relationship. And as a result of that, how much of their revenue are they going to give up because of that.
If we look at some of the well-known community banks, such as Evolve Bank and Trust, Sutton bank, WebBank, Bancorp, how much difference do their capabilities make for BaaS tech stack?
Guest: The banks offer direction and approval of which features they'll allow. And so each bank's a little bit different. It depends on their risk level and the types of programs they want to support. So for example, WebBank, they had done some prepaid early on, and then they quit doing prepaid. They didn't want to do any prepaid for a while, and they were just doing lending and credit.
And then my understanding recently here, they're starting to get back into the prepaid, whereas Bancorp primarily did prepaid and debit but didn't do a lot of credit and I'm not sure where they're at on credit today, but each one has a different mix depending on what they want to support from a product offering perspective. They don't actually bring that functionality. They just approve that functionally can be there.
It's really the processor and the BaaS player who provides the actual functionality. And then each of these banks, they have different approaches from a compliance perspective. Some of the banks will completely dictate what needs to happen from a compliance perspective and expect that the FinTech just do it.
In other cases, they're much more cooperative with them where they'll help them out through it. The compliance is a pretty big deal because the banks are on the hook with the regulators, they're going to be audited.
And so the banks have to ensure that any of their programs that are running are following the compliance and the bank directly turns that to the program managers and the BaaS providers.
Again, in the case of the direct processor relationships, typically the processors aren't directly involved in the compliance. They're supporting the program manager or the FinTech in that compliance, but they're not the ones directly responsible for it. So between the banks, it just depends on how they approach compliance and on how cooperative they are with the FinTechs.
Speed to market is something that's come up repeatedly. And one of my learning is that the banks actually determine speed to market rather than the BaaS platform. Could you please elaborate on that? And how should I contextualize who's adding what value?
Guest: So from a speed-to-market perspective, it's definitely the case with i2c, and I know with Galileo, if they just focus on getting a program up and running, they can move very quickly and Marqeta, I assume that they're the same as well. They can move pretty quickly to get a new program up, ranging anything from probably three to six weeks.
However, when you put the bank in the mix, because they've got to check all the boxes from a compliance perspective and make sure that everything's in place, that ends up taking a lot more time. Typically, you're looking at three to four months when the bank gets involved in that.
And a lot of that is really waiting on each other. So, the FinTech is waiting on the bank to identify, Hey, what compliance documentation do I need? And once they get that, then the FinTech has to implement that and document that they've implemented it, pass it back to the bank. So the banks waiting on the FinTech while they're implementing the compliance. And then once they pass it back to the bank, the bank has to review it. And so you have a lot of manual processes there where it just takes people time to read them and review them. And so that's what really ends up taking a lot of time from a value add perspective.
There's value in that because if the bank were to skimp on compliance or not be as thorough as they should, then there are risks to the program in the future, the regulators could come in and say, "Hey, we have to shut this program down until it adheres to all of the compliance regulatory items."
And so sure it seems like the bank is maybe the slow ones in the puzzle here, but in the end, there's actually value there for them to do that. Now, could they be more efficient in their processes? Sure.
They could probably come up with different ways that it may just be a resource question where they need to add more people, but from the process of implementing a new program and getting it up and going, there's from a value add perspective, everyone's got a piece to play in that.
And I would say the processors probably have the most moving parts, just because of the fact that they're getting that program up. They're working with the networks, or working with the banks, or working with the FinTechs to get all that going. And when I say the processors I'll include the BaaS providers in that as well, they’ve got quite a bit to do there.
Some BaaS platforms provide program management and some don't. What would be the rationale in deciding whether BaaS platforms want to be program managers or not?
Guest: The rationale for that would be there ends up being quite a bit of day to day operational management of a program when you take on that program manager role. The other aspect of that is whether they take on the liability because the program manager takes on the liability of that.
And so if there's any fraud or any losses then the program manager's the one who loses that. If there's spend fraud on the cards then any losses go directly to the program manager. And so whoever's taking that role of program manager then really ends up losing out on those potential revenues.
Now, if a BaaS player is choosing to be the program manager, then that typically means they receive the interchange. They receive the interchange, and then they share that revenue with the FinTech, after all their expenses are paid, and losses would be considered one of those expenses.
And so they have to decide whether they want to take on that risk as the program manager and then set that. That's the main component of program management. The second component is really that day-to-day operational, whether they want to have the staff to actually support that and be the program manager.
You mentioned how i2c, for example, would select the banking partner based on what program they support, i.e. whether there's a match between what i2c wants to do and what the bank can offer. Could you talk about when Bond builds on top of i2c, what's the process of matchmaking there?
Guest: With Bond and it would really be the case with any of the BaaS players, their approach can be to have their relationship with i2c, which is really a technology enablement aspect of that. So it's really the technology integration that they've got with i2c.
Bond really has the ability to choose one or more banks to serve as bank partners. So there's nothing stopping Bond from having multiple bank partners that provide credit and multiple bank partners that provide debit or prepaid. They can choose that, they can queue up as many banks as they want. And then when the FinTech comes to Bond, Bond can now decide, Hey, we want to put this FinTech on bank A and the next FinTech, we may put on B for whatever reasons, whether they want to just balance it, or whether there's actually an advantage for putting one FinTech on bank A and another FinTech on bank B.
But they're able to sort of keep that bank selection generic to the FinTech. So the FinTech don't really care who the bank is behind it. They just come to Bond and say, "Here's the product I want to deliver." And Bond behind the scenes then will choose the bank partner. Obviously, the bank partner has to approve of the FinTech and what they're offering, but the FinTech typically wouldn't have to get involved in that decision, or even have to know who the bank is. They have to disclose who that program is issued by bank A or bank B. They've got to disclose that, but Bond is able to mask that and sort of keep the complexities of the bank away from the FinTechs that don't have to worry about it.
If we think about two worlds, in the first world, we have a fast-moving FinTech startup; in the second world, we have a Nike or Gap of the world, established retailers or digital brands who have got their own profit-making business model. These two types of companies want to provide financial products. Could you talk about what would be an ideal banking stack for each of them please, and why?
Guest: When you're talking to a startup versus a well-established company, the main differences are the resources and the money that's available to them. In the case of an established company like Nike or another well-known brand, they're going to have plenty of resources to be able to invest and really build the expertise and bring the resources to do the things that maybe in the long run are going to be better for them. I mean, in the long run, you're a program manager or a company that wants to offer financial products better off managing their own relationships with the banks, with the networks and with the processors, because they have more control over that. And it gives them more flexibility in the future if they want to make changes or do things.
And then from a perspective, the revenue is there. They just have a better opportunity for revenue to go directly with these different partners in the case of a FinTech or a startup, because they don't have as many resources. And they're typically smaller companies, fewer employees, they have less money because they it's all investment money. They have to get going as quick as they can for as little as they can. And the trade off there is to basically share the revenue, have someone else do those things like manage the bank relationship, manage the processor, manage the network as well as they don't have to enter into any sort of long-term commitment from an agreement perspective with the processors or the banks. If they're going with a BaaS player. Now, they have to with the actual BaaS provider, but they're able to negotiate that a little bit better. And there's just fewer moving parts. So it's much easier for the smaller company to work directly with the bank.
And from a BaaS player's perspective, what characteristics would be present in their ideal customer?
Guest: Well, the main things they're going to be looking for are company stability. Making sure that they've got funding that's going to allow them to launch and get their program up and going. The next is the leadership of the company, making sure that the company leadership has experience in doing something like this, right? If it's someone who's been, I don't know, if it's someone who's been fixing bikes forever, and then they want to turn around and offer financial products, they're probably not going to be very successful at that. They might, but someone who's already been involved in financial services is going to be more successful. So they're going to look for that leadership. And then the next thing they're going to look for is how are they going to get their customers? How are they actually going to get customers? What's different that's going to make them successful over somebody else? And so those are probably the main things that they're looking for. There's going to be others. But those from the top of my head, I would think are the ones.
Currently, the BaaS platforms mainly monetize through the interchange. Some of them also charge per customer per month type of fixed fee. And some also charge a one-off fee. Could you please talk about how important you think it is for BaaS platforms to be less reliant on interchange and what value-added services they can provide to upsell?
Guest: They could go with either model to be less reliant on interchange really gives the FinTech or the program manager full access to that interchange. And they would then just charge for their services that they're providing. And they could go either model. It really depends on the risk that they're taking and their approach to pricing some of the BaaS players, they're strictly just going to do program management because they ... I'm sorry, revenue share with the interchange because they know that there's a lot more opportunity for revenue to do it that way, as well as they know that they're going to cover their costs, they're going to get a different kind of clients when they do that. Because some clients are going to say, "No, we want all of the interchange." And they'll be shopping around to try to find that.
So, it's really going to have to, they're going to have to decide what their model is, what their business model is and how they want to differentiate from the others, whether they want to take that approach or not. Again, being able to take the interchange allows them to be more flexible with the clients that they're going to take as far as they can take someone that maybe it's more risky because they know that they're going to immediately get the revenue out of that from the interchange.
Whereas someone who, if they're just doing a fee for service sort of model, then they've got a little bit of risk there because the FinTech or the startup may not be able to pay them because they've spent the interchange somewhere else. And now they're waiting, they've got to submit a bill to them and wait for them to pay. Whereas with interchange, they get the funds directly from the network and then they pay out to the FinTech. So, you've sort of got those two different approaches. And as far as the BaaS player wanting to get out of that, or it really just depends on their business model, if they want to do that or not.
How scalable do you think BaaS is?
Guest: It's got a lot of potential for scalability, especially because they can aggregate banks, right? They can easily have multiple banks in the queue. And from a processor perspective, the processors should be able to scale with the BaaS player. So I would think, knowing Galileo, knowing i2c, I know that both of those platforms can scale to keep up with any of the BaaS players, but from the other side of it then is the bank side. And they can easily start up relationships with additional banks to help scale if they need to do that. And that would be the other aspect of the scalability on that. From a network perspective, it's either MasterCard or Visa, maybe Discover plays in there as well. But from a scalability perspective there, they're going to scale. Onboarding may not scale quite as good, but for the most part, they're a big company. So if they need to get more resources then they can add more resources to help from that perspective.
In terms of use cases, some FinTechs just provide one use case in a big market. Then, there are some other FinTechs, they want to provide multiple use cases. Do you see providing more use cases would be a constraint on how scalable BaaS can be, because if the BaaS only provides debit or prepaid and then the FinTech wants credit or some other things, then this mismatch would either require the BaaS platform to build additional programs or maybe the FinTech needs to look for somewhere else?
Guest: From a use case perspective, and when we say use case, I think you've pointed out that it's prepaid debit and credit, right? Those types of use cases. And I would say the various flavors of those different types of prepaid and credit and debit as well. For the FinTech to support only a limited number of use cases sort of allows them to specialize in that area. And which means that it would be pretty straightforward for a FinTech if they, in fact, want one of those use cases that that BaaS player supports, then it'd be pretty quick that they can get up and going and be pretty standard. It may limit the variability, the different types of features that they could have with that particular use case to do that because the BaaS player is very limited.
My take on that would be, if the BaaS player is only going to support a limited number of use cases, then that's probably a resource constraint on their side. They don't have the resources to be able to support more of them because it's from a BaaS player perspective they could easily with processing partners, provide the abilities for all of those use cases. Now, if they can support all those use cases from a single processor like i2c has all of those use cases covered. Marquetta, they have a partner for their credit, but they support debit and prepaid. Galileo supports debit and prepaid. They're starting to build out for credit and to support that. So, a BaaS player, if they were to go with an i2c, they get all of that from one processor. If they go with Marquetta, then they have to potentially use multiple processors.
And same with Galileo. They would potentially have to use multiple processors, which now adds to kind of their burden to manage those processors, because they're going to have a separate agreement regarding each of the use cases. So a separate agreement for prepaid and debit and potentially another agreement for credits. So that goes back to the resource issue with the BaaS where it may not just be a people resource, but it also may be a agreement or commitment for those other processors. Right? If you've got to have one commitment on prepaid and another commitment on credit, then that then takes away from some of your potential revenue. There's additional costs because you've got minimums, you've got implementation fees, that sort of thing. So, it's being able to provide all of the use cases is really the best scenario, because then you can accept as many types of FinTechs and clients as you want, plus, as they come to you, it's one-stop shopping for all of those use cases.
What would be the top three things you look for to determine which BaaS platform would be the most promising in the future?
Guest: I would say that maybe the top three things to look out for are, there's a lot of things. There's quite a few things, obviously capabilities. What do they offer from a platform perspective? What are their capabilities? Do they meet the different use cases? Do they provide API so the developers can integrate with those? So, from a platform capability is probably the number one. Another important one is availability and scalability, the ability to keep up and to keep the system up, even as programs grow to still be able to keep the system up is a big one. That affected Chime a few years ago, quite, quite, quite badly in that case. The other is how's their leadership? How's the leadership from an investor perspective?
I want to know the leadership to know that that they're very forward-looking, looking to continue to enhance the platform, make it better. What are they doing to reinvest and to continue to expand their capabilities? So those are three, I don't know if that's the right order and there's probably others that might be just as important, but those are some important things from an investor perspective.
Is there anything that you think is very important that we haven't talked about?
Guest: Well, I think it's important to understand that, and we sort of talked about it early on, whether the relationship with a BaaS player or a processor relationship is better. The FinTech gets the same service, whether they're going directly with the processor or with the BaaS player. And as they decide what they want to take on, that'll help them decide which direction they need to go.
Going directly with a processor gives them more flexibility. The BaaS player definitely makes things simpler. And so what is the approach they want to take? There's definitely a place for both types of relationships and it just depends on what the company wants to do.
Disclaimers
This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.
