Aaron Huang, Head of Commercial at Productfy, on choosing the right fintech customers

.

Aaron: Let's take Marqeta as an example. The reason we decided to work with Point72 initially was because the operating partner there who's now on our board is Dave Matter, who's the former head of product at Marqeta. So I call Marqeta 1.0 BaaS. They're vertically integrated with Sutton Bank, and essentially their go-to-market a few years ago was very similar. They were basically building very sophisticated products.

But then they had a company like Square come around, and there was a bit of synchronicity where Square said, "We know exactly what you guys are doing. We know it's actually really hard. But having said that, this is something we're willing to sign on for."

If you look at the level of complexity with Marqeta, the question for Square is: Why haven't they gone into the processor space? They've actually found it somewhat easier to go buy a bank and do a charter than to go into the processor space. To me, this is a precedent for doing things well. The order of complexity for BaaS is essentially to focus on execution and, maybe this is a little bit orthogonal, but not raising a massive round before you have a core product thesis and an architectural framework for how you're actually going to scale this. You don't necessarily want to build and go to market too quickly. You need to flesh out the use case so that if you can get sophisticated enough, you can actually track the Square -- or essentially with the long tail, you don't know where the next Square is, but they're going to rise out of the portfolio of the 100 customers that you have, and you're going to incrementally and accretively focus on those customers as well.

How do you think about the big delineations between BaaS 1.0 and BaaS 2.0?

Aaron: The 1.0 -- I think you can also probably bucket Marqeta and Dwolla in there. There's a bunch of companies that are doing that. There's already starting to be a 3.0 version, but I'll talk about the 2.0 version, which is, in our parlance, fully distributed decentralized financial architecture, which means that one of the factors in terms of scale is the fact that your back office and your backstop is still the bank. I think Marqeta's run into this a few times. LendingClub with WebBank. All of these companies initially partnered with some Durbin Amendment banks that were thirty to fifty people. Now WebBank is eight hundred people, I think. Sutton Bank is a few hundred. But when they first started, their thesis was: We need a charter, we'll get a bank, and we need to scale.

The second iteration of that is essentially our view of the world, which is: In a world where it is hard to get a charter in the US, you have the scarcity value, but you have a constraint. And how you get around that constraint is you have to build an interoperable financial architecture that sits across multiple banks. That alleviates a few things. Not all banks do all things well, and certain banks have both compliance, regulatory and operational risks that need to be mitigated with technology. That's the second piece. There's a 3.0 version popping up and we're keeping an eye on that as well.

Permalink

Is it an area where you can see Productfy expanding?

Aaron: It's a good question. I think if you squint at our architecture, we look similar to a core. I hate the C word, because we don't want to go into the core space. We don't want to be compared to a Fiserv or a Jack Henry. But the core parts that we've built essentially are virtual ledger. The virtual ledger allows us a fair amount of fungibility across banks and cores. We hold the books and records. We're doing the subledger accounting. We're going to do the interest rate calculations. That does give us the optionality later on if we want to enact option two, which is scale across multiple banks, or option three, which is architect the full stack and reverse out to a charter. I'm talking long-term here. We've raised a seed round. But the planning of this is looking at the ecosystem and thinking ahead.

There are a lot of players in the ecosystem, many of which offer similar solutions and products. How do you think about commoditization of BaaS platforms, and how does Productfy escape the competitive dynamic in BaaS?

Aaron: I think it's very similar to a lot of other ecosystems, which is: Tech arguably commodifies products and features, and that's actually a good thing. If you look at it horizontally and look at other incumbent vendors out there like Galileo and Synapse, from a pure product marketing standpoint, everyone says they have the right things.

But if you peel back the layers of the onion, the question is: Who is doing what well? If you talk to folks at Unit, they have a certain thesis. I think their thesis is actually more on the neobank or the gig economy side, which is great -- I think there needs to be a lot of innovation there. I think Galileo was starting to go super point solution heavy on charge cards. Companies like Cardless, who you may not think about as a BaaS vendor but are an iteration of Marqeta, are going super hard on loyalty programs.

So there are two facets when we think about this, which is: Are they innovating on programs, or are they innovating on user experience? The middle layer there is all the features that you need to build the right recipes. The question is: What recipe are they optimizing for, and which recipe are FinTechs optimizing for? I think that's the better question to ask.

Permalink

There are platform solutions and point providers out there. Do all of your customers use you for payments and banking and issuance? Or are they using other providers for one of those buckets?

Aaron: I think everyone wants the full roll-up. If people come to us and use Plaid -- anyone who's done a Plaid integration knows it's really easy to embed, it's a pain to manage. So there is a notion of the platform value being essentially two core components. I would call it ongoing technical debt that a client doesn't have to drain their own resources on -- that's arguably the first piece. And the second piece, as they get more sophisticated in terms of their use cases, is compliance-as-a-service.

All of those pieces are important because the other question would be: Just go to Stripe or to Dwolla and do ACH. But once you get over volume, number one you want the interchange, which comes with core compliance. And number two, you want a more sophisticated platform because you don't want to manage all the integrations yourself. And the third part I would say is you want all of that data commingled in a larger data warehouse where you can create dynamic parameters and features based off of the entire data set.

Those are the three things, I think, clients want. But it's easier for them to start out on a solution versus trying to boil the ocean overnight. If they come to us and say they want to do everything, for us the pushback is: Well, how are you going to do it? What does your roadmap look like? And where do we start?

It seems like most platforms are providing similar products. Many of them have prepaid and debit programs, you mentioned Synapse and Bond also have a credit program. Some FinTech founders we spoke with say that when they pick a BaaS provider, they'd like to think about how the platform will be built out five years from now, not necessarily which programs they can support today, because as you mentioned, you're aligning with their roadmap too, and they're thinking through their own. What would determine the speed of acceleration in the product roadmap and execution working with you guys?

Aaron: I would say four factors. Number one, the FinTech itself has to have a pretty strong technical team. We've worked with teams that have offshore engineers that are not part of the company. They may not necessarily even have a product manager in-house. So there are some core qualifiers we do need in terms of a partnership approach. This is not a sandbox build. You have to understand the APIs deeply, you have to understand how you're going to be using the web hooks. You also have to understand how you're going to power your own experience over time. So that's your roadmap on your side.

On our side, we have to be transparent about the direction we're going in. I think it's probably less of a five-year build out than two facets, which is: Who are you partnering with on the bank side? Where directionally are your programs going in the future? Again, as I mentioned, if you're looking to build out a neobank to compete with Chime, I don't think that that's a value proposition that we're going to partner with. We need to deeply understand the business model of our clients because on the back side we are trying to operationalize the scale with bank partners that can get our clients to market quickly. The determination of speed comes down to: How precise and clear are you, the client, for the prospects in terms you want to accomplish?

Once you and whatever BaaS vendor you're talking to are on the same page, that makes it a lot easier to basically go downstream with the bank. And by the way, the bank has to be aligned as well. So I think a lot of qualifying discussion with BaaS providers is essentially pattern matching around the permutations that are optimized for each technical architecture product team on the FinTech side, and the bank partner in terms of what they're set up to do today and what they're set up to do tomorrow.

The last thing I will say is that the more idiosyncratic the partner program looks like, the longer it's going to take. We've talked with some companies out there that are doing these synthetic, they call it crebit programs, where they want to use a debit card, essentially hack credit scores. That's a great program. We've looked into it. But it's essentially a bespoke program with idiosyncratic parameters. That's probably not something that a BaaS solution is set up for today. In the future, if the market becomes large enough, we might see a point solution BaaS provider go out there and try to steal that program. But that's an example of time to market versus acceleration, which is: What is it you're trying to accomplish?

Hacking credit scores is a good idea. I think we love it. There's a bunch of other credit hacking use cases we've heard from our clients. It's less about the technology rails. You can access card rails. You can access ACH. The question is: Where does a regulatory mandate stand? And it doesn't even matter if it's something that's technically feasible. Somebody, probably an expensive lawyer at Ballard Spahr, has to issue a legal opinion, and that legal opinion then has to be socialized and sold upstream to the bank partner.

So when you talk about time to market, you also have to think about how progressive or conservative your program looks to a bank. If you're pitching an Evolve Bank that might be a little bit more progressive in nature, there might be a semblance of synchronicity there. But in general, there are also risk factors, and that's why compliance-as-a-service is a huge pillar of what we do, because we're trying to set our risk parameters for the marketplace and be very clear about where the boundary conditions are.

When companies are coming to talk to you about these credit hacks, is it a secular trend? Would you describe it as a two-part sale, where they're pitching you on this, and then you're pitching banks and regulators, or are you helping the Fintechs think through that?

Aaron: This is the way I see it, because the financial wellness space is huge. Macroeconomically, a large percentage of the American consumer population -- arguably as COVID has shown -- has meaningful barriers to accessing credit. That's a macro trend. Everyone's seen that. You can build a pitch deck off of this. The question is: What do you do about it? I think when these companies poll their users, a lot of their users say that they want help building credit. Now, that's basically where that liminal space starts and ends for them because they come to us and they say, "Hey, we have an idea."

Now, the question for us is: How big is this idea? I'm using almost a venture capitalist mentality here, which is: What's the addressable market? How big is the idea? Who's the target persona? And if it seems like a good idea that we want to invest in, we will.

But if you are one of the first companies in the space, you'll have to go to a bank partner yourself and convince them because the addressable market will not be large enough for a BaaS provider to invest in. Even earned wage access, which is becoming a huge use case -- probably 10, 20 companies in the space -- I don't see any BaaS platforms really configuring themselves for that because it's still too idiosyncratic in nature.

So, from my perspective, if you have a truly innovative program, go to the bank yourself. Number one, you want to protect the IP -- you don't want a BaaS vendor to essentially parameterize it and then resell it. Second, you're going to have to figure out the compliance and legal framework yourself.

And that's going to take probably half a million dollars of working capital that either you or the BaaS provider is going to have to invest. And the way that the contracts for BaaS providers are written these days, there's not the notion of, "Yeah, great idea. We'll go bring it to the bank." It's instead, "This thing has some hair on it. How are you actually going to go to market?" And so therein lies some of the risk/reward parameters when you're thinking about how you want to launch. Do you actually want to launch with the BaaS provider, or do you want to go to a bank partner yourself?

This is something that we talk to clients about, too. We want the FinTech ecosystem to proliferate and expand. Our goal is to democratize innovation. But if you are literally on the bleeding edge, there are some things that we could do to help facilitate bank partnership discussions, but you need that expertise, and you need to convince the market, and probably the investment community, to pre-fund that idea. It's not just a tech build at that point. It's essentially you building your entire business operations to comport with the use case that you want to get to market. That becomes challenging for a lot of these companies because they have an idea, they have an existing user base, but they don't realize that the overhead to go to market is not just the technology implementation. The program pieces in FinTech, as everyone knows -- you're just going to have to get the lawyers involved.

To switch gears a little bit, let's talk through some of the platform economics. You've identified three revenue models. There's the percentage of the interchange, per user per month, and then one-off fees. Can you talk about interchange as a business model versus the SaaS model?

Aaron: I love interchange for brands, because brands don't look at interchange as a straight P&L. They look at it from a customer retention and loyalty perspective, so it's great for them. If you look at interchange as a straight product vertical that you're trying to get to market, you're going to need to think about the underlying consumer and figure out the spending patterns you're going to try to incentivize, because as everyone knows the interchange unit economics aren't great.

The second piece -- there are program fees. I think if you look at some of the incumbents out there, I don't love the fact that they're so high. They're onerous for the long tail. Their pricing model essentially messages to the market: You better have a good idea, and you better have some venture capital. And if you do, you take the risk, and we'll basically just collect as a SaaS model because we need to show to our investors that there's a payback.

I think there's got to be a little bit of risk sharing, where -- and this goes back to bank partners -- you intimate to them that this is your model for banking as a service. It's not that you don't share risk. It's that the bank has to also have a risk profile where they are saying, "We understand how FinTech works. We are going to have some modicum of flexibility in the way we create program fees. And by the way, if all this works out well, we all share in the success of the ecosystem." That's number one.

When you see high program fees, to me that means that that hasn't been communicated, or the bank simply has no incentive because they're swimming in deposits right now and they don't care. So you have to be mindful of what that program fee signals to you as an innovator.

I think the FinTech in general should get the vast majority of interchange. But I don't think you should optimize for all of the interchange, because the more you take, the more risk you are taking on, because you are not giving some of the fees back to either the bank or the platform to run operations. So the question for the FinTech is: How much do you want to take on yourself, because the more of it you take, if you look at these trilateral agreements, the more of that risk is shifted to you, including things like disputes and charge backs, customer service, audits.

There are certain levers that I think don't exist in SaaS that exist in FinTech. My dilettante experience so far tells me that every time you pull a lever on pricing, something changes in terms of risk. All I know is that if I was a FinTech, I would want less risk but the best pricing, but sometimes those two things are diametrically opposed. It's something to be mindful of, because you don't want to optimize on price if you don't understand where the risk sharing is coming from.

What are the platforms that offer the best economics for developers and what enables them to do that?

Aaron: That's what we're trying to figure out now. I think there are two pieces here. In my mind, commercially, how do I make this look more like a bilateral agreement? How do I make it look simpler, where we abstract away the complexity, where we're able to communicate clearly some of the risks that we're taking on vis a vis some of the risks that the FinTech is taking on. That's number one -- there is a vision to get to some sort of a more bilateral type agreement. I think for developers we do offer the best economics. From a risk-sharing perspective, philosophically we don't recognize most of our revenue until a client launches, and I think it's fair. You don't want us to start collecting program fees. If you look at the way other platforms in this space have their business models, it's like, day one, we're getting charged. "I don't care how long it takes for you to build. That's on you, not on us."

For us, it's like, "Well, okay. Let's assume that everyone is in the second inning of this ecosystem. What's fair?" You don't want to kill innovation from a promising FinTech just because you need to claw back $5,000 or $10,000 for the first three months. That doesn't look like a great long-term business model if you have high upfront cashflow but then your churn is through the roof. And that's the risk that we have to take.

It's not a great risk. But it is a risk that, if we model this the right way -- and again, we have the right folks that invest in our vision, that have been in FinTech before, that have operated in FinTech -- it's the fairest way for us to effectuate the ecosystem and give the highest probability for FinTechs and brands to launch into market. In general, I would say the philosophy has to be: Does a company in this space understand the incentives of all three parties involved and how to make it fair?

You're essentially risk ranking all your clients. And when you risk rank your clients, you have to set a risk premium that you charge. And then over time, there has to be a scale factor tiered up to a certain point where there is some relief, but you obviously can't give infinite relief. It's just something that's fair and balanced for an on-ramp. That has to be reflective of the fact that, over time, if you look at your portfolio long tail, you're going to take the same metrics that a VC looks at and says, "X% of my portfolio is going to churn, but 10% of my portfolio is going to become potential unicorns. And those are the ones we need to nurture and scale." That has to be the model for FinTech.

And lastly, does the platform also understand the economics and incentives of the last (but arguably most important) party, which is the end-user -- either an SMB or a consumer that's going to be signing up for the products and services through the client.

Now, if you look outside of FinTech, which is where this gets more interesting, you can think about a more SaaS-like playbook. That's the flip side of the coin, which we're really bullish on, which is: When you look at FinTech, it is idiosyncratic in some ways. If you look at the fact that FinTechs and non-FinTechs are essentially merging, or looking very similar, then there happens to be an interesting SaaS playbook around bringing products to them that are entirely scalable, because they don't need to competitively differentiate on the financial product itself. They're competing and differentiating on their own brand equity.

What are some potential upsell opportunities for the platform?

Aaron: I think it comes down to how much you expand horizontally across a bank architecture. If you follow the bank's roots, banks make a lot of money on lending. That's why we're moving towards having a credit and lending officer, because you'll start out on basically a debit interchange. As you get more sophisticated, you might launch a secure credit card. That gets higher interchange. And then you want unsecured if you can figure out a way to bring your own balance sheet risk where at some point we are able to underwrite, and we align with where banks make their vast majority of money, which is on that lending side. That's a very well-worn route.

Or you can go verticalized. Let's think about the future of vendor finance. The easier it is to embed, the more opportunities there are for licensing and resale and making it look closer to SaaS. If you go vertically upstream, there are more upsell opportunities.

Any BaaS type of solution, if you look at the competitive ecosystem, you can see which way they're going. That gives you a signal for which ones you might want to make a bet on given whatever program it is you're looking to launch into the market.

Permalink

You mentioned earlier about Plaid being a line of code to install and then pretty hard to churn for various reasons. FinTech companies don't want to be locked in. Can you talk about the long-term option of card-issuing in-house or some of the ways that you could retain customers without making them feel like they're locked in?

Aaron: Well, I think you've got to have some sort of lock-in. Number one, you've got all your accounts, at least your operating account, with the bank. You've got some of your books and records on our ledger. Now if you are a FinTech, or you're launching financial products and services, the biggest question you need to ask yourself is whether you want to build out your own ledger. Otherwise, the virtual ledger that we have does make it more fungible for us to migrate across banking partners. So I think the first piece of flexibility which I have to figure out is: How do we not have us and the client be wedded to a single bank partner that may or may not have risks that we know or don't know?

For example, you don't know in priority of talking to a BaaS provider, whether the underlying bank has had any issues with the OCC. You're not going to the Fed site and doing your own due diligence. You're just assuming that that hasn't happened. Arguably, that's a huge risk, as anyone who's been in FinTech for a while knows. That type of enforcement comes down pretty periodically. But you're not doing that level of due diligence.

So number one is essentially two pieces, which is: How fungible do you want to be with the bank partner? This goes into a vision for architecture. And then how fungible do you want to be with the BaaS provider? And that comes down to whether you want to build out your own ledger.

Arguably it's the same thing as, "Well, why would you build your own ledger if a BaaS provider has one? Why wouldn't you go out there and also build your own Plaid and build your own integrations into all the financial institutions?" It comes down to the build versus buy argument. I think the less friction you have on the bank provider, the more you could possibly look at a flexible BaaS provider as something that's more mission-critical and scales larger, than if you had just a single verticalized solution on a single bank partner. Because to us, I think the constraint's not necessarily on the technology side. It's actually on the bank. That's the core thesis.

So in the future, if a company wants to move and bring their own bank, it makes it easier for us because we can migrate the ledger. If a company wants to build their own ledger, that's definitely something they could do on their side, but it's probably, sequentially, making yourself more fungible for banks, and then thinking about build versus buy for a ledger.

You could look at the Green Dot example. It's not perfect, but Green Dot Bank built their own ledger and is now like an enterprise-level BaaS. It depends on what model you want. There are high ACVs, but their operating costs and their marketing costs are quite high as well. It almost looks and feels more like a professional services shop in some ways than a scalable platform, which is arguably what you want to avoid if you want to go down the Shopify or the Stripe model. So it depends on what model you eventually want to effectuate.

I'm more than happy, if a client becomes very successful, to help them build everything in-house. At some point, they're going to want as much control as possible. So we should make it as easy as possible to migrate our virtual ledger onto the one that they build as well. That should definitely be a data migration question that we can enable. It's more of a strategic discussion around: Do they actually understand the cost basis, the cost of goods sold, for everything that they're doing in-house vis a vis something that we have potentially already optimized much better than they have? And that will be a question I think that you can't really answer until you understand what the revenue side of that business looks like.

Sacra: Sounds like a very complicated relationship that you have to have with these customers. Aaron: It is now, because we're all so transparently in this mindset of trying to learn and pattern-match across a ton of different variables. We enjoy talking about this stuff with our clients too because they have similar questions. So it's consultative in a way, but it also helps us think about our own go-to-market because there are already a lot of incumbents in the market that you can study, and you don't want to do things in a way that just repeats some of those issues or mistakes or challenges. You want to think about the happy path forward.

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.