BaaS pricing is designed for early-stage programs. The economics — a take rate on interchange, a per-transaction fee, a monthly platform fee — are structured to make the launch decision easy. At $5M or $10M in monthly processing volume, the numbers work. The program is growing, the BaaS provider is providing genuine value, and the cost feels like a fair exchange for the speed to market the BaaS model delivered.
The problem surfaces later. BaaS take rates are flat percentages. Your revenue scales with volume. Your BaaS cost scales with volume at the same rate. The economics that worked at $10M per month look very different at $50M, and look untenable at $150M. The crossover point — where the cost of staying on BaaS exceeds the cost of migrating to a more direct structure — is predictable. Most programs don't model it before they commit to the structure.
What BaaS actually costs at scale
A typical BaaS arrangement involves three layers of cost: the sponsor bank's fee (typically 10–25bps on interchange or a flat per-transaction fee), the BaaS middleware platform's fee (typically 15–40bps or a per-transaction charge), and the interchange sharing agreement (the program sponsor keeps 50–75% of interchange, with the remainder split between the bank and BaaS provider).
At low volume, these costs are manageable relative to the speed-to-market value the BaaS structure provides. At high volume, they compound. Here's a simplified illustration using a card program with 200bps average interchange:
| Monthly Volume | Gross Interchange | BaaS + Bank Take (35%) | Net to Program | Direct Program Net (est.) | Monthly Gap |
|---|---|---|---|---|---|
| $10M | $200,000 | $70,000 | $130,000 | $160,000 | $30,000 |
| $50M | $1,000,000 | $350,000 | $650,000 | $800,000 | $150,000 |
| $100M | $2,000,000 | $700,000 | $1,300,000 | $1,600,000 | $300,000 |
| $200M | $4,000,000 | $1,400,000 | $2,600,000 | $3,200,000 | $600,000 |
These are illustrative numbers — actual figures vary significantly by program, BaaS provider, card network, and negotiated terms. But the directional pattern is consistent: the absolute dollar cost of the BaaS structure grows linearly with volume, while the complexity and cost of migrating away from it also increases as the program scales. The programs that wait to address this until $100M+ in volume are making the migration harder with every month of growth.
The migration decision — and when to make it
Migration from BaaS to a more direct structure — whether that's a direct sponsor bank relationship with fewer intermediary layers, a money transmission license, or a hybrid that moves specific economics while retaining BaaS for other functions — involves real cost and risk. Engineering work to integrate directly with the bank and processor. Compliance investment to support a more direct regulatory relationship. Potential card reissuance if the BIN migrates. Operational disruption during the cutover period.
The migration cost is real but one-time. The BaaS cost is ongoing. The break-even calculation compares the one-time migration investment against the monthly economics improvement — and at most volume levels above $30–50M monthly, the break-even period is well under 24 months.
The right time to make the migration decision isn't when the economics are already painful — it's at program design, when the volume trajectory can be modeled and the decision can be built into the roadmap. A program that launches on BaaS with a defined migration trigger ("we will evaluate direct structure when monthly volume reaches $X") manages the transition deliberately. A program that discovers the economics problem at $100M manages it reactively.
The hybrid model — migrating specific components
Full migration from BaaS to direct isn't always the right answer, and it's rarely a single step. The hybrid model moves specific economic components to a more direct structure while retaining BaaS for others — separating the functions where direct economics are most valuable from the functions where BaaS remains the most efficient delivery mechanism.
The most common hybrid migration sequence: first, negotiate a direct interchange sharing agreement with the sponsor bank that bypasses the BaaS middleware take rate on interchange (while keeping the BaaS platform for everything else); second, move float management to a direct bank relationship with explicit float economics terms; third, evaluate whether the bank relationship and compliance infrastructure are now mature enough to move additional processing functions direct.
Each step reduces the BaaS cost layer without requiring a full platform migration. The program retains BaaS benefits — card issuance infrastructure, compliance support, operational tooling — while progressively eliminating the economic layers that don't deliver proportional value at scale.
What the BaaS contract should say
Programs that are designing for eventual migration need specific contract terms from the beginning. Four matter most.
Data portability. The program owns its customer data, transaction history, and card program data. The contract should specify that all data is available for export in a defined format at any time, not just at contract termination. Programs that can't access their own transaction history can't migrate their underwriting models, reconciliation history, or customer records without rebuilding from scratch.
BIN transfer rights. If the BIN is registered to the BaaS provider rather than the program sponsor, migrating the card program requires either reissuing all cards (major customer disruption) or negotiating a BIN transfer. The contract should address BIN ownership and transfer rights upfront, not when the migration is already in process.
Transition assistance. The contract should define what technical and operational support the BaaS provider will provide during a migration — API access continuity, data export support, parallel operation period. BaaS providers have no economic incentive to make migration easy. The contract is the only leverage for requiring them to provide it.
No-exclusivity on bank relationships. Some BaaS arrangements include exclusivity provisions that prevent the program from establishing a direct relationship with the sponsor bank or another bank. These provisions directly block the most common migration path. They should be identified and negotiated out before signing.
Designing for the migration from day one
The programs that manage this transition well didn't leave it to chance. They modeled the volume crossover point during program design, defined the migration trigger in the product roadmap, negotiated contract terms that preserve migration optionality, and built the compliance and operational infrastructure that a more direct structure requires — progressively, in parallel with program growth, rather than all at once when the economic pressure makes a rushed migration unavoidable.
The BaaS decision is the right decision for most programs at launch. It's the wrong permanent decision for most programs at scale. The gap between those two statements is the migration plan — and the best time to write it is before the launch, not after the economics break.