Sacra Logo Sign In

Fintech investor on how banking-as-a-service platforms build partnerships

Nan Wang


  1. Different BaaS platforms offer different speeds to market. What are the pros and cons with different models?
  2. How do Fintechs think about which BaaS platforms to partner with?
  3. What are some of the popular use cases?
  4. And if we're looking at the product offering from Brex, they have this card processing platform, which includes issuing virtual cards and authorization settlement and fraud charges. Does Ramp also do all of those things or do they differ?
  5. Is there anything that's important and we haven't talked about?


Different BaaS platforms offer different speeds to market. What are the pros and cons with different models?

Guest: The reason why these banks use these middleware providers is because that's essentially their API strategy. For example, Synapse sits on top of Evolve. That's also where there's friction in that relationship. Evolve may want to be a little tighter as far as fraud checks and KYC generally, and Synapse might be a little looser where they want to get more people through the funnel. Synapse wants to get more startups, but Evolve would say, "Wait. We're a regulated entity. And we can't break the law because we're going to get fined. And we would get our license taken away and you Synapse aren't worth it for us for that to happen." So there's this push and pull. So Synapse essentially is the Evolve API strategy. Together, they can provide a developer experience.

FIS, Fiserv and Jack Henry are companies from the '60s and '70s that are centrally an aggregation of acquisitions over the last 40 years. You can imagine from a pure developer perspective that it's impossible to have a good user experience building on top of the FIS.

So Treasury Prime said, "You're totally right. Instead, we're going to do it for you, we're going to plug into the bank's core infrastructure and you just call our APIs." Which is great. Now, the reason why banks would want to do it is because they want deposits.

The problem traditionally that banks had before there was even a middle layer is that they were limited to clients in their vicinity because no one knew about Evolve Bank. The only people who knew about Evolve Bank and Trust are people who lived in Tennessee around the bank. So they knew about the branches, but now how does Evolve Bank and Trust get a client from Seattle? Well, they physically can't, they don't have a mobile app. There are no branches in Seattle. So instead if they partner with Synapse, then if you're a FinTech and you want to build something, you can just build on top of Synapse, but Evolve was going to be the bench sponsor.

In terms of pricing, the middleware’s pricing is not transparent. It’s based on negotiation. It's not obvious from their websites. They only talk about their capabilities. You have to talk to salespeople to start the process.

Synapse charges $5,000 a month plus basis points. And if you're a FinTech startup charging $25,000 a month, and rely on interchange, it means it's impossible for you to build anything. The economics just cannot make sense.

So if we look at Treasury Prime, essentially what Treasury Prime allows a FinTech to do is to embed money movement capability, whether it is ACH, wire card, you need to have a KYC offering. You need to underwrite the customer. If you and I wanted to build a little neobank, we could go to Treasury Prime and do the entire thing on Treasury Prime. And then we're going to offer ACH to our customers, which is going to be coming through Permont or one of the Treasury Prime partner banks.

When we think about Brex, who has their API strategy. They're kind of open sourcing their platform, they're probably starting to compete, but that's not their bread and butter. Brex is still getting startups to use their card and their ecosystem and charging interchange plus something for their expense management, real-time reconciliation etc. That's still probably their bread and butter.

How do Fintechs think about which BaaS platforms to partner with?

Guest: If we're building a commoditized product, we might just go for the one that has the cheapest and less, in the quickest time to market.

Just like ACH, every single banking as a service, middle layer provider is going to provide ACH from Synapse, Bond, Unit. Any of these middleware companies, you can build ACH into your product. And so that's just a commodity, right? The question becomes, well, how good is that ACH product? Because even with the ACH product, there's a lot of nuances that people might have preferences for. And that's why there's a company Moov. Moov today is essentially an open source ACH company, they essentially allow companies to embed ACH products into their platforms.

Moov is a great option for you in a way that Treasury Prime isn't, you can't just call just the Treasury Prime ACH API. You can't do that. No, you have to sign a contract. You got to be a client. You’ve got to onboard with the partner bank. You have to have a relationship with them. Then you can start embedding for your product. With Moov, you don't have to do that.

But if we have a very specific offering, for example, rules-based money movement, you can't embed that experience in. As you start building, you as the FinTech, if you use Synapse for something that is very core to what you're building, but then you want to build an experience on top of that. You might realize that you're having trouble doing that because your apps isn't working well with this other third party that allows you to do X.

So then all of a sudden you're in this position of like, well, I gave him a bunch of controls, feed to market is there, I paid a bunch of money. But I can't customize the experience the way that I want it. This is where we're going into, in my opinion, the future of this, these customized experiences.

The middleware platforms like Unit, Treasury Prime, Bond, no one is doing billions of dollars in volume. Chime, I believe, went to market on Synapse and then quickly came off of Synapse because they wanted to build a customized experience. So that's the problem with middleware products, is that as you get scaled, you get off of it because you don't want to give them economics. So you start building more things in-house.

That's the big problem. That's the same thing with Stripe. Stripe is an awesome go to market strategy, but people leave Stripe because it is too expensive.

Stripe is an awesome go to market strategy, but people leave Stripe because it is too expensive.

What are some of the popular use cases?

Guest: So if you order from DoorDash, the guy picking up the food on your behalf has a virtual card and he pays for the food on your behalf that you paid to DoorDash, right? So DoorDash takes your money, puts it into a virtual card, the courier goes into restaurant, pays with the virtual card for the food and then picks up the food and gives it to you. So that flow of funds is through Marqeta. And for Uber, Uber pays out their drivers same day if they want to, in order for Uber to do that, I believe that they partnered with the Green Dot. And essentially what it allowed to do is that if I'm a driver at the end of the shift, I could say: “okay, give me my money.”

The mechanism that they use here, and this is like a very important distinction, I saw on the Brex website, they use the Visa MasterCard rails to push that money. So they pay return interchanges. So they pay 1% or whatever it is, although I'm sure Uber got a very good deal and insurance less than 1%, but the interchange it's very expensive. It's not like ACH, but the plus side is that it's near instant. The downside is that it's expensive because you can imagine Uber has millions of drivers.

Then there's the issuer processor. This is important because these guys take the majority of the money.

You can imagine that if you need to pay your issuing bank, your sponsor bank some money, and you have to take out a layer of some money and your main business is interchange. It's extraordinarily difficult for you to make money. 

And you need to have a huge scale before you're even contribution margin profitable, right?

And if we're looking at the product offering from Brex, they have this card processing platform, which includes issuing virtual cards and authorization settlement and fraud charges. Does Ramp also do all of those things or do they differ?

Guest: Brex would tell you that, in order for them to scale, all these guys are trying to verticalize as much as possible. That's why you see bank people like Varo buying banks so they could get an extra four basis points. That's why they buy the bank, not because they actually care about the bank.

In this case, Brex building their own issuing processor in-house makes a lot of sense because that means they could save cost. The next step is, I don't know how much they pay Emigrant Bank, but they continue squeezing economics down for Emigrant Bank.

And if they can't do that, Emigrant Bank says, no, they're going to think about going to another bank as a sponsor bank or buying a bank. But Brex doing all these things I can guarantee you that beyond the economics, they could say, "Okay, we tried Galileo for transaction fraud scoring. And we realized that their solution is really not that good and they're misclassifying or their classifications. We don't agree with or they're too fringe and for our partner banks. So there were lots of false positives for fraud. And we don't want to use them." Okay. So what do you use? Well you have I2C. You don't really have more at your scale.

You can't go to first data, Fiserv, et cetera. Then you build your own, right? So you take that flow when you're like, okay, I'll do my own transactions for monitoring. Then there's authorization and clearing. They might say Galileo's API for this is really not that good. Our developers don't like it. We have a very hard time integrating it. And so what, we'll do that ourselves.

The biggest piece of costs for Ramp in the entire life cycle of opening an account for someone is printing the card. Physical card printing. That's 80% of the cost of opening the account after that 20% is just like monthly maintenance costs for that account.

If Brex can acquire a printer, then all of a sudden, they start verticalizing and they rely less and less on other people. Brex is building something very good for authorizations, for payments, for transaction fraud scoring, portfolio reporting. And so they can outsource that and they can charge for it on an API call or whatever else. But that essentially, starts competing with Galileo.

So that's where I think the interesting part about the Brex and the Ramps is how much we could build internally and then minimizing what you rely on third-party infrastructure for, because everything costs.

Is there anything that's important and we haven't talked about?

Guest: It's interesting to think about what happens with middleware providers, what happens with Unit, Synapse, Bond and Moov? This is just a personal opinion, I say they started getting acquired by Fiserv, FIS and Jack Henry, then Fiserv starts going to market as they now have an API strategy. Because today they know that they're already being integrated with these banking service providers. It now is just like verticalizing that solution. That's what I think.

And then there's one more thing that I think you should look at. And some people say that it's not a risk just because so much of FinTech is built on top of Durbin exemption. But there might be challenges or there might be changes to the definition of Durbin. And then if that's the case, you're going to see a lot more business models that are relying on SaaS products rather than interchange.


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.

Read more from

Read more from