The wrong framing: build vs. buy
The build vs. buy framing misses the actual question in embedded payments. "Build" implies constructing infrastructure from scratch — writing a ledger, building a card network connection, constructing a BSA/AML engine. Almost no SaaS company should do that. "Buy" implies purchasing a complete solution — using a BaaS provider as the permanent infrastructure layer. Most SaaS companies at meaningful volume shouldn't do that either.
The right question is ownership: which elements of the payments program need to be owned by your organization — directly controlled, internally operated, contractually in your name — for the program to generate the economics and product capabilities it should? And which elements can be durably outsourced to infrastructure providers without sacrificing that ownership?
What you need to own
The economics design. This is non-negotiable. The specific commercial terms — interchange share, float yield, fee structure, processing rate — that determine what your program generates cannot be delegated to a vendor's defaults. They must be actively negotiated. The vendor's default terms are designed for the median customer. Your economics requirements are specific to your program's volume, customer segment, and revenue model. Own the economics design or accept the vendor's design by default.
The customer relationship. The relationship between your SaaS platform and your customers is yours. The payment infrastructure should be transparent to customers — they are using your product, not your bank's or your BaaS provider's. This means the customer experience, the dispute resolution process, and the customer communication around payments are yours to own. Vendors that make themselves visible in the customer experience are extracting brand value from your relationship.
The compliance philosophy. Not every compliance implementation detail — but the philosophy: how does the program think about risk appetite, customer segmentation, and compliance investment? These decisions reflect the program's relationship with its sponsor bank, its customers, and its regulators. A compliance philosophy that was designed by the BaaS provider for the median customer may not serve a program with a specific customer segment, risk profile, or bank relationship.
The bank relationship (at scale). At volumes where the economics gap between BaaS and direct exceeds the cost of the bank relationship build, the bank relationship needs to be owned directly. Not outsourced to a BaaS provider who has a bank relationship that they manage on your behalf — owned by your program, with negotiated terms, in your name.
What you can durably outsource
Technology execution. The ledger, the card processor, the ACH origination infrastructure, the API layer — these are technology execution components. They should be selected against your program requirements and contracted to support your program model, but the technology execution itself is not a source of competitive advantage. Outsource it to providers that do it well.
Card network relationships. Your program accesses card network rails through your sponsor bank's membership. The card network relationship is the bank's — and that is appropriate. You don't need to be a Visa or Mastercard principal member to run an embedded payments program. The bank's membership, accessed through your program agreement, is sufficient.
Regulatory licensing (below scale). Operating under a sponsor bank's charter rather than obtaining your own money transmitter licenses is appropriate for most embedded finance programs at most stages. The bank's regulatory infrastructure is legitimate outsourcing — the bank has invested in regulatory relationships, examination readiness, and charter maintenance that your program accesses through the program agreement.
What you can outsource now but should plan to own
The BSA/AML program operations. BaaS providers manage significant BSA/AML infrastructure on behalf of their fintech customers. This is legitimate early-stage outsourcing. The problem is when the program remains dependent on the BaaS provider's compliance infrastructure indefinitely — because when volume justifies a direct bank relationship, the compliance infrastructure needs to be internally owned and bank-ready. Programs that never built independent compliance operations discover this during the bank diligence process, which stalls because they can't demonstrate operational compliance maturity independent of the BaaS provider.
The bank relationship. BaaS is legitimate early-stage outsourcing of the bank relationship. It is not a permanent structure for programs at meaningful volume. Design the path to direct bank ownership before you need to take it.
Interchange and float economics. BaaS providers negotiate interchange share and float terms on behalf of their customers. At early stage, accepting these terms is reasonable — you don't have the volume to negotiate independently. Plan the economics renegotiation — either with the BaaS provider at volume thresholds or with a direct bank — before you reach the volume at which the gap becomes a board conversation.
A practical ownership framework
For each component of your payments program, ask three questions: Does owning this directly improve my program's economics? Does owning this directly improve my program's product capabilities? Does outsourcing this create a dependency that becomes expensive to exit? If the answer to any of these is yes, that component belongs on the ownership roadmap — not necessarily owned now, but with a defined path and trigger for when it needs to be.
Designing your payments ownership structure? The payments model strategy overview maps each model's ownership implications, or talk with us about your specific program.