Andy Su, co-founder of Pry, on how fintechs choose the right BaaS partners

What do you think about interchange as a revenue stream versus SaaS?

Andy: Interchange pricing is great. The end-user has no idea about pricing, so they feel like it's cheap. But you're making a lot on the backend. A lot of companies are building it and forcing the banks to split some of their revenues. Interchange pricing is obviously just amazing as a business model and investors love it, but you need to get the volume. You need at least a few $100,000 a month of transaction volume to justify a pilot.  Even at that, you'll have the lowest interchange value from all of the providers. So you have to really feel like you can do a concerted effort to get the users on your platform using your interchange.

If we look at the B2B interchange split, let's say 2.5% for the entire value chain. And that's split amongst the FinTech, the BaaS provider, program manager, card networks, and the issuing bank. How much would you be able to pay to the BaaS provider? What are the variables in your head?

Andy: The one thing that I am always looking for is 1.5% for the end-user and then we still make something off of that. The 1.5% is more or less because of Ramp, their whole thing is 1.5% cash back. That's what gets a lot of founders excited about the product. 

Then how much do we make? I'm not sure. I just throw out ten basis points, so 0.1%, and then the rest of the interchange gets 0.9%, which is split between the banking as a service and the banks.

So that would be the ideal that we're looking for. And I think at scale, people will offer that or maybe more because there's some way that Ramp and these other companies must be able to get it to work out. Otherwise, if there's a company out there offering 1.5% to the end-user and you're offering 1%, my customers might ask me where'd that half percent go? Are you taking 0.6 for yourself? We’ll never have a good answer for products like Ramp which kills me as someone who’s looking to build the best product. This is because our service provider is only going to be able to do so much. So if anyone's able to offer this, I would strongly consider and integrate and figure out how to make it work... Move much quicker on it. Basically, the only blocker would be our own roadmap and number of users. And I think that would be the case for a lot of companies looking into this.

We're very early and I’m just testing it out. I just want to know, hey, can we make something? And can we get volume? That was the big part. Can we get our users to use it? And can we get our users to love using it? 

Because what's going to work for us is if there's a mind shift in the end user's perspective on how to spend their money, instead of selecting their card or pulling out one card for all their finances. We want them to start using our platform to issue a different card for each platform. And I think it's better for financial controls for companies.

How would you select a BaaS provider? What's important to you?

Andy: Well, obviously the economics. But even more important for us at this stage, is the speed to launch, which is why Lithic, previously Privacy, is so interesting. Stripe is interesting. I'm just looking to prototype so I'm trying to control costs, and I can control that on the engineering side. If we can ship something in a month, great. In a couple of months, we'll have to prioritize. More than a couple of months, then it's not happening. 

There's the idea that if I spend one month building this, and we don't like our provider, and we can find better rates elsewhere, we can take the time to switch off. We can just redo that effort if it is paying off. Right now, the speed to market is extremely important. And then the economics will make us stay with someone if it does work out.

We need to go fast because startups have a burn rate. Every month a product's not out, we're closer to not making it out of whatever goals that we're trying to do. And then also, it's because what we're doing here is a pilot, we don't have a guaranteed payoff. We don't have a guarantee that all of our customers will convert. We don't even know if it will backfire. If customers will dislike the financial services products that we layer on. So that's why the speed of launch is so important.

One thing I learned from other conversations is that the sponsoring banks determine the speed to market rather than the BaaS platform. Could you please speak about that? How important is having a direct relationship with a sponsoring bank to you?

Andy: I think this is where the scale is a bit off. You probably need a sponsoring bank if you're going for these really high economics right off the bat, and you're going for a lot of volume. We are not, we're just trying to get a prototype up. If it works really well for our 10 customers, then we'll scale it up to 100, and then we'll start talking to a sponsorship bank and all that stuff if it makes sense to do. 

It's not even a factor for me. I don't think it's come up in some of the integrations we're talking to at the moment. What might hold things up is the KYC process. That's the top thing on my mind because we want to be able to create accounts on our end. We don't want to work with a provider with a very strict KYC process. We want to be able to say, here's the EIN, here's the person's name, we know they have $X amount of money in their account, we know they've been in business for so long, just issue them a card.

We don't want to have to ask them all the security questions, call them, have them take a front and back of their social security card. So the KYC process for some companies is something that I look through pretty thoroughly.

What kind of implementation support do you need from the BaaS provider?

Andy: So one of the biggest things I'm looking for that is quite difficult to find is free virtual cards, which is kind of surprising. Our thesis is it is better to issue a card for vendors than to use one card for all your 100s of vendors. In case you lose it, and then you have to go update all those vendors. That's our thesis for why this is going to change. 

If a banking issuer is going to charge us 50 cents or 25 cents or a dollar per virtual card, that's going to be something that doesn't work out for us. We can probably get around it by building a lot of logic around whether we approve the card or not, but it's going to make the integration a lot more effort. So that's probably one of the stranger things that we're looking for that other companies might not care about. Other companies might just want to issue you one card, get you to bank with them, and that's it.

When you look at the margins, it's thin. And if we're paying 50 cents a card, we're actually losing money in the front end. This means that now I have to raise money or something to sponsor this whole endeavor, which probably won't work out.

For all the BaaS providers you have reviewed, what differentiates them?

Andy: So my understanding is that there's Stripe, who has a publicly advertised very bad economics. They're charging you to use their API. But if you talk to them, probably you can work out some sort of deal that's more similar to some of the other companies, and maybe even get that banking sponsorship. There's Lithic, who's one of the more interesting ones that I'm looking at right now because their API docs are good and easy to understand. That's one of the things that make me think, okay, this is going to be easy to integrate. I think Lithic and Stripe are better for virtual cards than physical ones. Physical does require some more work, which is totally fine for us because we're trying to do mostly virtual cards anyway.

There are directive banks like SVB, First Republic, and some other ones that are better for scale. If your whole company is built on the interchange or built on banking, then you'll probably take some more time to work with them. 

I also saw Unit, Bond and a few others. I think some of those companies might be catering more towards larger businesses, not so much startups. Also, the docs are a little bit lengthier. Maybe if they simplified and made it simpler, then that would be more approachable for us.

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.