> Payments Model Strategy | ExpandUp Architecture Method
Architecture — Payments Model Strategy

BaaS, direct, or hybrid.
This decision sets every other ceiling.

The BaaS program model, direct MTL, or hybrid decision is the first architecture decision — and it determines the margin structure, compliance exposure, and long-term flexibility of everything built on top of it. Most programs make this decision implicitly, by talking to a BaaS provider first.

Talk with us before your next vendor decision → ← Architecture Overview
The Three Models

BaaS, direct MTL, and hybrid — what each actually means

BaaS
Banking-as-a-Service
The bank (or bank + BaaS layer) owns the compliance and provides the banking infrastructure. You build on top. Speed to market is the tradeoff for economics and control.
Time to market3–6 months
Margin ceilingLower
Compliance exposureManaged by BaaS
Economics at scaleCompresses
Direct / MTL
Direct Money Transmission
You hold the licenses, own the bank relationship, and operate the compliance program. Maximum economics and control. Higher upfront investment and compliance burden.
Time to market12–24 months
Margin ceilingHighest
Compliance exposureFully internalized
Economics at scaleImproves
Hybrid
Hybrid Model
Start on BaaS, migrate specific economics or compliance functions as volume and capability warrant. Requires deliberate architecture from the beginning to make the migration viable.
Time to marketBaaS-speed launch
Margin ceilingMigration-dependent
Compliance exposureEvolves with model
Economics at scaleImproves on migration
Decision Framework

The questions that determine which model fits

Questions about your program
?
What is the target processing volume in 24 months?
BaaS economics that work at $10M become unsustainable at $100M+. Model the trajectory before committing.
?
What compliance capabilities does the team have internally?
Direct MTL requires an internal compliance program. BaaS offloads it. The answer shapes what's viable.
?
What is the speed-to-market constraint?
If 18 months is too long to wait for first transaction, the model options narrow. But that constraint should be explicit, not assumed.
?
Is this a standalone product or a feature within a larger platform?
Embedded payment features in a larger platform have different compliance exposure and economics than standalone programs.
Revenue implications by model
$
BaaS: interchange shared by default
BaaS providers typically retain a share of interchange by default. How much depends on the contract — and most programs don't negotiate it.
$
Direct: full interchange capture possible
Direct programs with well-structured bank relationships can capture the full interchange economics. The ceiling is meaningfully higher.
$
Float economics: model-dependent
Whether customer balance float accrues to the program sponsor depends on both the model and the bank relationship terms. Both need to be designed.
$
Fee structure: always a design choice
Regardless of model, fee structure is a design decision. Programs that treat it as a default consistently undercharge.
See how program model selection affects revenue →
Designing for Scale

The BaaS volume crossover — and why it needs to be modeled before you sign

BaaS is the right launch decision for most programs. It is often the wrong permanent decision. BaaS take rates are flat percentages — the bank's fee, the middleware platform's fee, and the interchange sharing split all scale linearly with volume. The programs that don't model what this looks like at 5x and 10x their launch volume commit to a restructuring conversation at exactly the wrong moment: when volume and operational complexity are highest and the team's capacity for infrastructure change is lowest.

A program processing $10M monthly at 200bps average interchange might pay 35% of gross interchange to the BaaS and bank layers. At $10M, that's $70,000 per month — manageable relative to the speed-to-market the BaaS structure delivered. At $100M, the same rate is $700,000 per month. The one-time cost of migrating to a more direct structure — engineering, compliance investment, potential card reissuance — is typically recovered in under 24 months at that volume. The programs that wait discover this arithmetic at $100M, when the migration is harder than it would have been at $30M.

TRIGGER 01
Define the crossover point at program design
Model BaaS economics at your volume trajectory — at 3x and 10x launch volume. If the economics are untenable at scale, define the migration trigger before the program launches, not after the problem surfaces.
TRIGGER 02
Build the migration into the roadmap
A program that launches on BaaS with a defined volume threshold for evaluating direct structure manages the transition deliberately. A program that discovers the economics problem at $100M manages it reactively — under pressure, with less leverage.
TRIGGER 03
Negotiate the contract for migration optionality
Data portability terms, BIN transfer rights, transition assistance obligations, and no-exclusivity on bank relationships must be in the contract before signing. These terms are negotiable at signing and very difficult to add after.
Full analysis: The BaaS scale problem — when vendor economics break →
Payments Monetization

Program model selection is Lever 04 in the payments monetization framework.

BaaS vs. direct vs. hybrid sets the ceiling on interchange capture, float economics, and fee design. Model the economics against your volume trajectory before committing — not after the contract is signed.

See the full monetization framework →
Not sure which program model fits your volume trajectory? We model the economics across BaaS, direct, and hybrid at your specific volume — before you commit to a structure you can't unwind cheaply.
Start the conversation →

The model decision is made before the BaaS demo.

Most programs let the vendor make the model decision by default. The architecture-first approach defines the program model explicitly — before the first infrastructure conversation.

Talk with us Next: Bank Partner Selection →