The BaaS sales process is genuinely good

BaaS providers are well-resourced, developer-friendly, and exceptionally good at demonstrating what their platforms enable. The demo shows fast onboarding, clean APIs, impressive feature sets, and a compelling path from zero to live in 90 days. For early-stage platforms evaluating whether to build financial products, the BaaS pitch is legitimately compelling.

What it doesn't cover — not because BaaS providers are dishonest, but because it's not in their interest to lead with — is the complete picture of what BaaS programs cost at scale, what they constrain, and what migration looks like when you outgrow them.

What the interchange economics look like after the BaaS layer

See the economics
The payments economics waterfall — where interchange goes at each layer
Visual breakdown of what BaaS captures vs. what flows to your program at $10M monthly volume.
View the waterfall →

BaaS providers typically share interchange economics with platforms through a revenue share arrangement. The platform receives some percentage of interchange generated by its customers' card transactions. What the sales demo doesn't model in detail is what that percentage looks like as volume scales.

BaaS interchange share arrangements vary significantly — some platforms receive 30–40% of interchange, others receive 50–60%. What this means in practice: at 175 bps card interchange, a platform receiving 40% captures 70 bps. A direct bank relationship at the same volume captures 150–175 bps. At $10M monthly card volume, the annual gap is $960K–$1.26M. The BaaS provider captures the difference — not through deception, but through the commercial structure of the agreement.

The exit clause problem

BaaS contracts typically include minimum volume commitments, contract terms of 2–3 years, and exit provisions that require significant notice and transition periods. Platforms that want to migrate to a direct bank relationship after outgrowing BaaS often discover that their contract requires 6–12 months of notice and continued minimum fees during the transition period.

The integration architecture problem compounds this. Platforms that built deeply against the BaaS provider's specific API and data structures — rather than building abstraction layers that could accommodate a future migration — face significant re-architecture when they try to move. A migration that takes 6 months for a well-abstracted integration takes 18 months for one that's tightly coupled to the BaaS layer.

The compliance ownership transfer that catches platforms off-guard

BaaS providers manage significant compliance infrastructure on behalf of platforms — transaction monitoring, KYB/KYC services, SAR filing support. This is genuinely valuable and part of what justifies the BaaS margin.

What isn't always clearly communicated: as regulatory scrutiny of BaaS programs increases, banks are requiring BaaS providers to hold platforms to higher compliance standards — and BaaS providers are passing those requirements downstream. Platforms that relied on BaaS compliance infrastructure and didn't build their own internal compliance capability are discovering that the compliance requirements they thought the BaaS handled now require significant internal investment.

The 2023–2024 regulatory environment around BaaS has made this more acute. Multiple BaaS providers received enforcement actions or consent orders that required them to strengthen their fintech oversight programs. Platforms operating under those providers faced unexpected compliance demands and, in some cases, program restrictions during the remediation period.

The product ceiling you discover too late

BaaS providers build products for the median fintech customer. If your program requires capabilities that sit outside the BaaS provider's standard feature set — custom BIN structures, specific card network agreements, product types the bank doesn't support, or fee structures the BaaS layer doesn't enable — you discover this constraint after you've already built on the platform.

The most common product ceiling encountered at scale: card issuing volume limits (some BaaS programs cap monthly card issuance), international payment capabilities (most US-focused BaaS programs have limited international support), and commercial card BIN access (purchasing card BINs that generate higher interchange are not available through all BaaS providers).

Already on BaaS and wondering whether the economics or constraints justify moving? Read about payments economics recovery, or talk with us.