Two structurally different models dominate how fintechs access payment infrastructure: Payment Facilitation (PayFac) and Banking Sponsorship (BaaS/direct). The choice between them determines compliance exposure, margin ceiling, speed to market, and long-term flexibility. Most fintechs make this choice implicitly — by talking to a BaaS vendor first — without understanding what they're committing to.
The PayFac model
A Payment Facilitator is a merchant of record that onboards sub-merchants and processes payments on their behalf under a master merchant agreement with a card network acquirer. The PayFac owns the compliance obligations for KYC/KYB of sub-merchants, bears the financial liability for chargebacks and fraud, and keeps a portion of the interchange as its revenue.
PayFac economics are attractive: the program captures interchange spread without holding a banking license. The compliance obligations are real but well-defined: Visa/Mastercard PayFac standards, NACHA if ACH is involved, and AML requirements under applicable state or federal law. The ceiling is the interchange margin minus the acquiring processor's take rate.
The constraint: sub-merchant volume caps, chargeback liability exposure, and the card network's willingness to approve specific merchant categories. Some business types cannot be onboarded as sub-merchants regardless of the program's compliance posture.
The banking sponsorship model
Banking sponsorship — BaaS — puts a licensed bank between the fintech and the regulated activity. The bank holds the charter, sponsors the compliance program, and the fintech builds on top of the bank's regulated capabilities. The bank is the sponsor; the fintech is the program manager.
BaaS economics are simpler and more constrained: the bank takes a share of interchange (or a flat fee per transaction), the BaaS middleware provider takes another share, and the program manager keeps the remainder. At low volume, this structure funds the speed-to-market advantage. At high volume, the cumulative take from bank and middleware erodes margin significantly.
Hybrid and direct models
Programs that start on BaaS and grow to sufficient volume often face a migration decision: continue with compressed BaaS margins at scale, or invest in moving toward a more direct bank relationship or a money transmission license that reduces the intermediary layer. The hybrid model — launching on BaaS while designing for eventual direct migration — is the right architecture for programs with a credible volume trajectory. It requires designing the program from the beginning with migration in mind, not treating BaaS as permanent infrastructure.
Direct MTL (Money Transmission License) programs hold state licenses, own the compliance program fully, and have a direct relationship with the sponsor bank without middleware. The compliance burden is highest and the time to market is longest (12–24 months for full MTL coverage). The economics are best at scale: the full interchange, without BaaS middleware, minus only the direct bank fee.
The decision framework
The right model depends on three variables: the payment types the program needs to support (card-only favors PayFac; bank account-based transfers favor BaaS or MTL), the volume trajectory over 18–24 months (low-volume programs should optimize for speed; high-volume trajectory programs should design for scale economics from the beginning), and the compliance capability the team can build internally (MTL requires an internal compliance program that most early-stage fintechs don't have).
This decision needs to be made explicitly — before the BaaS demo, before the bank conversation, and before the product roadmap is committed to a specific infrastructure path. Programs that make it implicitly inherit the defaults of whoever they talked to first.