A banking-as-a-service deal looks, on the surface, like any other vendor selection: compare the API docs, check the sandbox, read the pricing page, pick the fastest integration. That comparison misses the part that actually determines whether your card program or deposit product survives its first regulatory exam. When you sign with a BaaS provider, you are not buying infrastructure. You are renting access to someone else’s banking license, and every account your customers hold sits on top of a chain of liability that you do not control and often cannot see.
This matters because the BaaS market has had several public failures where the provider in the middle, not the sponsor bank and not the fintech, turned out to be the weak link. Programs have been frozen, customer funds have been delayed, and fintechs have had to explain to their own users why money they thought was in a bank account was suddenly inaccessible. None of that showed up in an API comparison. It showed up in the contract structure, the compliance division of labor, and the sponsor bank relationship that nobody asked about during the sales call.
This piece is built around that distinction. Treat it as a checklist for the regulatory and structural questions that determine whether your BaaS partner is a stable foundation or a liability you inherit the moment something goes wrong.
A BaaS partner is a regulatory bet before it’s a technical one
Every card, account, or loan you embed in your product is, legally, a product of a chartered bank. Your BaaS provider’s job is to connect you to that bank, manage the operational layer in between, and keep the whole arrangement compliant with banking regulation. The technology is the visible part. The license, the compliance program, and the contractual chain of responsibility are the part that decides whether your product keeps running.
A founder evaluating BaaS providers the way they’d evaluate a payments API or a KYC vendor is solving the wrong problem. A payments API failing costs you uptime. A BaaS relationship failing can mean your sponsor bank exits the program, your provider loses its ability to originate new accounts, or your existing customer accounts get frozen while regulators sort out who was responsible for what. The question isn’t just “does this work.” It’s “who is accountable if it stops working, and what happens to my customers in the meantime.”
Who actually holds the banking license, and why that changes everything
Some BaaS providers are themselves chartered banks. Most are not. The common structure is a middleware company that has a relationship with one or more sponsor banks, and your contract is really with that middleware company, with the bank sitting one layer further back and often invisible to you until something goes wrong.
That structure matters in several concrete ways:
- Single sponsor bank risk. If your BaaS provider relies on one sponsor bank and that bank exits the BaaS business, decides to tighten its risk appetite, or faces its own regulatory action, your program can be disrupted even though you did nothing wrong. Ask explicitly how many sponsor banks the provider works with and what happens contractually if one of them exits.
- Direct bank relationships versus platform relationships. A provider with a direct, named relationship to a specific sponsor bank is a different proposition than one that resells access through another BaaS platform, which itself sits on a sponsor bank. Each layer adds a point of failure and a party whose risk appetite can change without much notice to you.
- Who the regulator actually examines. Banking regulators examine the sponsor bank, and the sponsor bank’s examination increasingly extends into its BaaS partners and their fintech clients. Ask your provider how recently their sponsor bank relationship has been through a regulatory exam, and whether any findings touched the BaaS program specifically.
Get the sponsor bank’s name, confirm it directly rather than taking the provider’s word for it, and understand whether your contract gives you any visibility or rights if that relationship changes. If a provider is reluctant to name the sponsor bank or vague about how many banks back their programs, treat that as a direct answer in itself.
Program management: what the provider runs versus what stays your problem
“Program management” is the term for the operational layer sitting between the sponsor bank’s core systems and your product, and it covers things like transaction monitoring, dispute handling, card issuance operations, ledger reconciliation, and regulatory reporting. Different BaaS providers draw this line in different places, and the line determines how much operational and compliance work lands on your team.
Before you sign, get a clear, written answer to each of these:
- Who handles chargebacks and disputes day to day, and what SLA governs how fast they’re resolved?
- Who owns the general ledger and reconciliation between the sponsor bank’s core and your product’s records?
- Who is responsible for card production, replacement, and lifecycle management if you’re issuing physical or virtual cards?
- Who files the regulatory reports, and who absorbs the cost if a filing is late or wrong?
- If there’s a service outage at 2am, whose team gets the page?
A provider that markets itself as “full-stack” BaaS should be able to answer all of these without hedging. A provider that answers several with “that depends on your program setup” is telling you that the division of labor is negotiable, which means it needs to be negotiated and written down, not assumed.
Where AML and KYC obligations really sit in the partnership
Anti-money laundering and know-your-customer obligations are the area where BaaS arrangements most often go wrong, because the regulatory obligation technically sits with the sponsor bank, the contractual obligation to perform the work is often delegated to the BaaS provider, and the actual operational burden frequently lands partly on the fintech anyway. Three parties, one set of obligations, and a lot of room for something to fall through the gap.
Ask specifically:
- Does the BaaS provider run its own AML transaction monitoring and KYC onboarding, or does it expect you to bring your own tools and vendors?
- If the provider runs monitoring, what’s the escalation path when a transaction gets flagged, and how fast does a human actually review it?
- Who is responsible for filing suspicious activity reports, and does your team get visibility into what’s been filed on your program?
- Has the sponsor bank’s examiners ever flagged AML program deficiencies tied to this BaaS provider’s other clients?
If the answers suggest you’ll be running your own KYC and transaction monitoring stack regardless of what the BaaS provider offers, that’s a legitimate setup, but it changes your buildout and your budget. A founder’s roadmap to fintech compliance is a useful reference for sequencing this kind of buildout against the rest of what a growing program needs to handle, because AML ownership in a BaaS contract isn’t a one-time checkbox, it’s an ongoing operational commitment that scales with your transaction volume.
Whatever the split, get it in writing, because “the BaaS provider handles compliance” is not a specific enough sentence to survive an examination.
Pricing structures that look cheap at launch and expensive at scale
BaaS pricing is usually structured around per-account fees, per-transaction fees, and minimum monthly commitments, and the combination that looks attractive at a few thousand accounts can become the most expensive line item on your income statement at a few hundred thousand.
Watch for:
- Per-account fees that don’t decline with volume. A flat per-account cost makes sense early. At scale, a provider unwilling to renegotiate that rate is taking a growing cut of a margin you’re supposed to be improving, not shrinking.
- Minimum monthly commitments set for a growth curve you haven’t hit yet. Providers often price contracts around a projected ramp. If your actual growth is slower, you’re paying for capacity you’re not using; if it’s faster, check whether the minimum caps anything in your favor or only locks in a floor.
- Add-on fees for things you assumed were included. Card replacement, dispute handling above a certain volume, expedited KYC checks, and dedicated support tiers are common places where the headline price doesn’t match the invoice.
- Pass-through costs from the sponsor bank or card networks that aren’t transparent in the contract. Ask for a full breakdown of every fee category that could appear on an invoice, not just the ones in the pricing deck.
Model your costs at your current volume and at ten times your current volume before you sign. A provider that’s genuinely competitive at scale will have no problem walking through that math with you. One that gets evasive about unit economics at higher volume is telling you where the margin pressure will eventually land.
What happens to your accounts if the partnership ends
This is the question founders skip most often, because at signing time nobody wants to plan for the breakup. It’s also the question that determines how much leverage you have in every renegotiation afterward, because a provider that knows you can’t leave has no incentive to improve pricing or service once you’re live.
Before you sign, get specific written answers on:
- Data portability. Can you export full account histories, transaction records, and KYC documentation in a usable format, or only summary data?
- Customer continuity. If you move to a new BaaS provider, do existing customer accounts migrate, or does every customer need to re-onboard with new account numbers and routing details?
- Wind-down timelines. What’s the contractual notice period if either side terminates, and is it long enough to actually migrate a live program without disrupting customers?
- Funds in transit. What happens to customer balances held at the sponsor bank during a transition, and who is responsible for making sure no customer loses access to their own money during the switch?
A provider confident in its own service shouldn’t resist these terms, because they only cost them something if the relationship was already heading toward a bad outcome. If a provider pushes back hard on portability and exit terms during contract negotiation, that resistance is itself useful information about how they expect the relationship to go.
The questions to put to every BaaS provider before you sign
Bring this list to every vendor conversation, and insist on specific, verifiable answers rather than marketing language:
- Who is the sponsor bank, and can we speak to someone there directly?
- How many other fintech programs run on this same sponsor bank relationship?
- What exactly does program management cover, and what’s excluded?
- Who owns AML monitoring and KYC, operationally and contractually?
- What’s the full fee schedule at our current volume and at ten times that volume?
- What are the data portability and account migration terms if we leave?
- Has this sponsor bank relationship been through a regulatory exam in recent memory, and were there findings related to the BaaS program?
Many of these questions apply beyond BaaS specifically, and a broader fintech vendor risk assessment checklist can help you structure the diligence process across your whole vendor stack, not just the banking layer.
If you’re embedding cards, accounts, or lending into your platform, the technical integration is the easy part to evaluate and the easy part to get right. The sponsor bank relationship, the compliance ownership, and the exit terms are harder to see and far more consequential, and they deserve at least as much diligence as the API documentation before you commit your product and your customers to someone else’s banking license.