The BaaS trap most fintechs don't see until they're in it
BaaS works. At launch, at $5M in monthly volume, and often through the first few rounds of growth, BaaS is a reasonable choice. The infrastructure is fast to stand up. The compliance burden is manageable. The economics look acceptable.
Then volume grows. And the economics stop working.
This isn't a surprise to anyone who has operated at scale inside these programs. The mechanics of BaaS unit economics are predictable — and they predict compression at scale with near certainty. Here are the five structural reasons why.
1. The percentage take rate scales with you — forever
BaaS pricing is almost universally a percentage of transaction volume. Fifteen basis points here, thirty there, plus monthly platform fees. At $5M in monthly volume, these numbers feel reasonable. At $50M in monthly volume, you're paying 6–10x more for infrastructure that hasn't changed.
The fundamental problem: there's no operating leverage in a percentage take rate. Your infrastructure cost scales at exactly the same rate as your revenue. Volume growth doesn't improve your unit economics — it just produces the same margin at a larger absolute number.
Mature businesses earn margin expansion from volume. BaaS prevents that by design.
2. Interchange flows to the middleware layer, not to you
In a standard BaaS arrangement, the BaaS provider captures interchange on the bank's behalf and passes a portion — sometimes none, sometimes a fraction — back to the program. The default commercial terms favor the provider. Unless your contract explicitly defines interchange sharing at favorable rates, you are generating interchange for someone else's revenue.
At $10M in monthly card volume, 1% in uncaptured interchange is $100K/month. At $50M, it's $500K/month flowing to your infrastructure provider rather than to you. This is a recoverable gap — but only if the commercial terms are renegotiated or the program model changes.
3. Float economics belong to the bank by default
FBO accounts holding customer balances generate yield. The bank keeps it unless your bank relationship agreement explicitly provides for yield sharing. Most BaaS arrangements do not include float economics — not because they're unavailable, but because they're not surfaced in the standard commercial package.
As rates rose from near-zero to 4–5%, the float economics question went from theoretical to material almost overnight. Programs that never negotiated float terms are now leaving significant annual revenue on the table that wasn't worth fighting for two years ago but absolutely is today.
4. The bank's risk appetite limits your product roadmap
BaaS providers work with one or a small set of sponsor banks. Their commercial model depends on maintaining those bank relationships. When your product roadmap requires capabilities the bank is uncomfortable with — higher-risk merchant categories, novel product structures, international expansion — you hit a wall.
The bank's risk appetite was defined before you arrived. You are a sub-program inside their broader portfolio. The constraints that protect their other programs apply to yours.
This is manageable at small scale when your roadmap is narrow. At growth stage, when product expansion is the business model, it becomes a strategic constraint.
5. Switching costs compound over time
Every month you operate on a BaaS stack, you deepen the integration. Your product is built around their APIs. Your operations team runs their exception handling. Your customer onboarding flows their KYC process. Your data model reflects their ledger structure.
The technical and operational cost of migrating grows with time. This is not unique to BaaS — it's true of all infrastructure dependencies. But BaaS compounds particularly fast because the integration surface is large and the economics pressure to migrate arrives before most teams expect it.
Programs that recognize this early — and design a migration pathway before they need it — pay a much lower switching cost than programs that migrate reactively after economics have already collapsed.
The trajectory most programs follow
$0–$10M monthly volume: BaaS economics are acceptable. Speed-to-market justified the tradeoffs.
$10M–$30M monthly volume: Margin compression becomes visible. Teams start asking why the economics aren't improving with scale.
$30M–$50M monthly volume: Investor pressure on unit economics. The BaaS model is clearly incompatible with the margin targets the business needs at scale.
$50M+ monthly volume: Migration becomes urgent. Switching costs are now at their highest. The program that should have been redesigned at $15M is being rebuilt under operational pressure at $50M.
What to do about it
If you're pre-launch: model the economics at your target scale before selecting a program model. BaaS may still be the right starting point. But the migration pathway should be designed now, not when the economics are already broken.
If you're running BaaS at scale: the question is which specific gaps are most recoverable. Interchange renegotiation, float economics, and bank term restructuring can often be addressed within the existing relationship. Program model migration is a larger undertaking — but the economics analysis usually makes it clear whether and when it's justified.
The BaaS trap isn't that the model is wrong. It's that the model is optimized for a stage of growth you've already passed.