Banking-as-a-Service Providers Compared: Sponsor Banks and BaaS Platforms

Banking as a service is a licensed bank renting out its charter through an API so a company that isn't a bank can offer accounts, cards, and payments.

Two different kinds of company sell into this space, and founders routinely confuse them. A sponsor bank holds the charter and the deposits. A BaaS platform is software sitting in front of a sponsor bank, providing APIs and program tooling. You will almost certainly end up with both, and which one you contract with directly changes your cost, your timeline, and how much compliance work lands on your desk.

This guide compares the providers at both layers, explains how the arrangement works underneath, and covers costs, timelines, regulation, and what you still have to build yourself.

What is banking as a service?

Banking as a service is an arrangement where a chartered bank provides regulated banking functions to a non-bank through an API.

The bank holds the license, holds the customer deposits, carries FDIC insurance, and answers to regulators. The non-bank builds the product the customer sees and owns the customer relationship. Your customer opens what looks like an account in your app, and the money sits at a bank whose name they may never register.

The functions available through this arrangement:

• Deposit accounts. Checking and savings, usually held in a custodial structure where the bank holds one account containing many customers' funds.

• Debit and credit card issuing. Cards issued under the bank's membership in the Visa or Mastercard network.

• Payments. ACH, wires, RTP, and FedNow access, all of which require a bank relationship to reach.

• Lending. Loans originated by the bank, sometimes sold on to the fintech or a capital partner.

You do not need a banking license to use any of this. You do inherit obligations contractually, which is the part founders underestimate.

How banking as a service works

Understanding the mechanics is what separates founders who evaluate providers well from founders who get surprised in month six.

The money sits in a pooled account. The bank opens one or more custodial accounts, often called FBO (for benefit of) accounts. Your customers' funds sit together inside them. The bank's core system sees the total. It does not see which customer owns what.

A sub-ledger tracks ownership. Somebody has to record that customer A owns $400 of that pooled balance and customer B owns $1,200. That record is the sub-ledger, maintained either by your BaaS platform or by you. The bank's balance and the sum of your sub-ledger entries have to agree, always.

Reconciliation is the process of proving they agree. Every day, the aggregate at the bank gets compared against the sum of the sub-ledger. Differences are called breaks, and breaks get investigated and resolved. A program without automated daily reconciliation is a program that will eventually discover weeks of quiet discrepancies.

Cards run on the bank's network membership. Visa and Mastercard require every BIN to belong to a principal member bank. Your cards are issued under your sponsor bank's BIN, and a processor authorizes each transaction against the balance records. This is what BIN sponsorship means.

Payments originate at the bank. When you instruct a transfer through an API, the bank is the entity submitting the ACH file or the wire. Your instruction is a request, and the bank's systems and cut-off times govern what happens next.

The recordkeeping in this model is drawing regulatory attention. The FDIC has proposed requirements for recordkeeping on custodial accounts with transaction features, which would oblige banks to maintain records identifying the owner of each balance. The proposal has not been finalized, but the direction is clear: the records tracking who owns what are being treated as infrastructure, not bookkeeping.

Banking as a service vs embedded finance

These get used as synonyms and they aren't the same thing.

Embedded finance is the outcome: a financial product delivered inside a non-financial experience. It's the category.

Banking as a service is one supply model inside that category, where a bank provides regulated functions through an API.

A buy-now-pay-later button at checkout is embedded finance with no BaaS involved. A payroll platform holding employer funds in custodial accounts is embedded finance built on BaaS. For the wider map of every layer involved, our guide to embedded finance companies covers all of it. This article goes deep on the banking layer.

Banking as a service vs open banking

Different problem, different providers, frequently confused.

Banking as a service lets you provide banking functions through someone else's charter. Money moves. Accounts exist. A bank is on the hook.

Open banking lets you read data from accounts your customer already holds somewhere else. You verify an account, check a balance, or pull transaction history. No charter is involved and you hold no money.

Plaid and MX are open banking. Column and Unit are banking as a service. A lending product might use both: open banking to underwrite from the applicant's existing bank data, and banking as a service to disburse and collect.

Banking as a service vs banking as a platform

The terms are nearly identical and the direction of the relationship is opposite.

Banking as a service: the bank is the supplier. It provides capability to a third party, who distributes it to end customers.

Banking as a platform: the bank is the distributor. It consumes capability from third-party fintechs and offers it to its own customers inside its own app.

If you're a fintech reading this, you want banking as a service. Banking as a platform is what the bank on the other side of the table is building.

Sponsor banks vs BaaS platforms

The most useful distinction in this market. Getting it right saves months.

Going direct to a bank means slower approval and more operational burden on you, in exchange for better economics and no middle layer. Going through a platform means launching faster with tooling included, in exchange for ongoing fees and a dependency.

The gap between these options has been narrowing, because regulators pushed the industry toward direct bank relationships even where a platform is involved.

Sponsor banks compared

These hold the charter. If your product touches customer funds, one of them is in your stack whether you speak to them weekly or never.

• Column. A nationally chartered bank that built its own API, so there's no middleware between you and the charter. Direct access to ACH, wires, and card issuing from the entity holding the license.

  • Best for: engineering-led teams that want one counterparty instead of two.

  • Watch out for: they're selective and say no often, so keep a second option in motion.

• Lead Bank. A Kansas City bank rebuilt around fintech partnership with its own technology stack rather than a vendor's.

  • Best for: programs that want modern infrastructure and a bank that understands fintech natively.

  • Watch out for: capacity, since demand for credible sponsor banks exceeds supply.

• Cross River Bank. One of the longest-running sponsor banks, heavily used in lending and payments. It has also been through FDIC enforcement and has spoken publicly about bearing responsibility for partner conduct.

  • Best for: lending programs and higher-volume payment flows.

  • Watch out for: large partners get priority, so early-stage programs wait.

• Coastal Community Bank. An established fintech partner bank with a broad program book.

  • Best for: card and deposit programs at scale.

  • Watch out for: diligence is thorough and slow.

• Thread Bank, Sutton Bank, Celtic Bank, Pathward, WebBank, Sunrise Banks, Grasshopper Bank. The working list of banks running meaningful fintech partnership programs, with differing risk appetites by vertical.

  • Best for: finding a fit when the better-known names pass.

  • Watch out for: several banks in this category have been under regulatory enforcement in the last two years, and some have exited the business entirely.

The bank layer is where you have the least leverage and the most exposure. Multiple sponsor banks received consent orders through 2024, regulators have kept pressing community banks on fintech oversight since, and a consent order at your bank can freeze your roadmap for a year regardless of how well your own compliance runs. Ask what enforcement history a bank has, and ask what happened to its partners during it.

BaaS platforms compared

These sit between you and a bank, providing APIs for accounts, cards, and payments plus the tooling to run a program.

• Unit. Account, card, and payment APIs with program management tooling, moving toward putting you in a direct relationship with the bank rather than sitting in the middle of it.

  • Best for: teams that want a full program stack and a fast path to launch.

  • Watch out for: module pricing has been shifting as the category restructures, so get the full fee schedule before you commit.

• Synctera. A marketplace matching fintechs with sponsor banks, now offering direct contracting. It registered a subsidiary as a money services business with FinCEN in 2026 and acquired a compliance monitoring company.

  • Best for: teams that want help finding a bank with monitoring included.

  • Watch out for: you're still subject to whichever bank you're matched with, so diligence the bank as hard as the platform.

• Increase. Direct API access to ACH, wires, RTP, FedNow, and accounts, built for teams that want the rails without a heavy program layer.

  • Best for: engineering teams comfortable owning more of the stack.

  • Watch out for: less hand-holding than a full program manager, so you need in-house capability.

• Treasury Prime. Exited the three-party agreement business in 2024 after regulators objected, and now sells software to banks for managing their own fintech relationships.

  • Best for: situations where the bank is the buyer, not you.

  • Watch out for: the model changed, so comparisons written before 2025 describe a company that no longer works that way.

• Stripe Treasury. Banking features inside the Stripe stack, available where you're already running payments there.

  • Best for: teams deep in Stripe who want accounts without a second integration.

  • Watch out for: concentration risk, since payments, issuing, and banking then share one vendor.

• Braid, Infinant. Newer entrants positioning as technology for banks rather than as intermediaries.

  • Best for: bank-led programs.

  • Watch out for: shorter track records.

Banking as a service providers outside the US

The US stack does not transfer. Different licensing regimes, different rails, different providers.

• ClearBank. A UK clearing bank with direct access to payment schemes, providing accounts and payments to fintechs.

  • Best for: UK programs wanting a licensed bank counterparty.

  • Watch out for: UK-centric, so multi-region needs additional partners.

• Griffin. A UK bank built as software, holding its own banking licence and offering accounts and safeguarding through an API.

  • Best for: UK teams that want charter and API from one company.

  • Watch out for: a young bank with a short operating history.

• Swan. European accounts, cards, and payments through an API across multiple EU markets.

  • Best for: EU-wide programs.

  • Watch out for: country-level differences persist under a single integration.

• Solaris. A long-established German provider that came under BaFin scrutiny over compliance and stepped back from parts of its e-money business before raising further capital.

  • Best for: established DACH programs.

  • Watch out for: the regulatory history is a live diligence item.

• Modulr. UK and European payment accounts and rails, licensed in multiple jurisdictions.

  • Best for: payments-led programs across the UK and EU.

  • Watch out for: the company has been loss-making, which matters for a long-term dependency.

• Treezor, Paynetics. European infrastructure providers, Treezor owned by Société Générale.

  • Best for: teams that prefer a bank-owned or compliance-conservative counterparty.

  • Watch out for: less developer-first than US equivalents.

Europe has consolidated harder than the US. Railsr never reached profitability and was sold through a pre-packaged administration. UniCredit acquired Vodeno, a signal that traditional banks are bringing this capability in-house rather than renting it out. Weigh provider durability as heavily as feature fit.

Benefits and drawbacks of banking as a service

The honest version of both sides.

What you get:

• Speed. Months instead of years, and no charter application.

• No capital requirement. A bank charter requires regulatory capital. Renting one does not.

• Interchange revenue. Card programs generate a revenue line on spending you already have visibility into.

• Customers stay in your product. Money that would otherwise be swept to an outside bank stays where you can see it and build on it.

• Data. Transaction data on your own customers, which improves underwriting, retention, and product decisions.

What it costs you:

• Margin. The bank and the platform both take a cut. Your unit economics are permanently thinner than a bank's.

• Compliance obligations. Flowed down by contract, staffed by you.

• Dependency. Your product runs on someone else's infrastructure and someone else's risk appetite.

• Concentration risk. Your bank's regulatory problems become your roadmap problems.

• Provider durability risk. Several companies in this category have failed or been absorbed, and migration is expensive.

• Product constraints. The bank decides what you can offer, to whom, and in what language you can describe it.

What banking as a service costs

Pricing is rarely published and varies by layer, but the components are consistent.

• Program setup fee. Commonly anywhere from nothing to six figures, depending on complexity and how much the provider wants your program. Often negotiable, and often waived for a program with a credible pipeline.

• Monthly platform minimum. The floor you pay regardless of volume, typically in the low thousands to low tens of thousands per month. This is the number that kills pre-revenue programs, and it's the one to negotiate hardest.

• Per-unit pricing. Per account, per card, per API call, per transaction. Individually small and collectively significant once you have users.

• Interchange sharing. Interchange revenue splits between you, the platform, and the bank, with the bank commonly retaining a meaningful share. The split is negotiated, and it decides whether a card program funds itself or quietly loses money.

• Compliance costs you carry directly. Your monitoring tooling, your reviewers, your annual audits, and the operational hours spent on cases. Annual compliance audits alone run into five and sometimes six figures.

Going direct to a bank lowers the ongoing fees and raises what you spend on people. Going through a platform does the reverse. Model both at the volume you expect in year two, not the volume you have at launch.

The build cost sits on top of all of it. What it costs to build a fintech app covers that side.

How long approval takes

Timelines here are outside your control, and they're the most common reason a launch date slips.

• Direct sponsor bank. Expect six to eighteen months from first conversation to live, with nine to twelve common for a well-prepared program. The stages are screening, due diligence, board approval, contract negotiation, then technical integration. Board approval in particular runs on the bank's calendar.

• Through a BaaS platform. Weeks to a few months, because the platform's compliance framework is already approved by its partner banks. You're being onboarded into an existing program structure rather than creating a new one.

The practical implication: pick your banking path before you build. Teams that choose the bank early launch faster than teams that build the product first and shop afterward, because bank diligence runs in parallel with engineering instead of after it.

Who regulates banking as a service

You are not directly supervised in most cases. The bank is, and its obligations reach you through your contract.

Who supervises the bank:

• OCC for national banks and federal savings associations.

• FDIC for state-chartered banks that aren't Federal Reserve members, plus deposit insurance for all of them.

• Federal Reserve for state member banks and bank holding companies.

• State banking departments alongside the federal regulator for state-chartered banks.

• CFPB for consumer financial protection, which can reach non-bank participants directly.

• FinCEN for Bank Secrecy Act and anti-money-laundering obligations.

Where the rules stand now:

The 2023 interagency guidance on third-party relationships is the operative framework, and it is what your bank's diligence process is built on. In September 2026 the OCC, FDIC, and Federal Reserve proposed a revised version, with comments due in November 2026. The proposal moves away from the 2023 approach after the agencies concluded its detailed examples had become de facto checklists, producing process-driven rather than risk-based decisions and discouraging banks from working with newer providers. The revision would let banks tailor diligence to the actual magnitude and likelihood of harm, rely more on shared assessments and certifications, and skip document-by-document review for lower-risk vendors.

For fintech partnerships specifically, this is not a loosening. The Federal Reserve's accompanying community bank guide explicitly excludes complex bank-fintech partnerships from its simplified treatment, which signals that this segment keeps the heightened scrutiny while ordinary vendor relationships get lighter.

The practical read for a founder: the 2023 guidance still governs your diligence today, and the direction of travel is toward banks having more discretion and being expected to document why they exercised it. A bank that can articulate its risk rationale clearly is a bank that will survive an exam, and one that survives exams is one whose roadmap does not freeze.

What compliance work stays yours

This is the line item founders leave out of the model. The bank holds the license, and you do most of the daily work.

• Customer identification. Running the CIP, collecting and verifying the required information, and documenting the decisions. Our guide to KYC providers for fintech startups covers the tooling.

• Transaction monitoring and alert review. The system generates alerts and a human reviews them. This is headcount, not software.

• Sanctions screening. Screening against OFAC and other lists at onboarding and on an ongoing basis.

• Dispute handling. Regulation E sets timelines for investigating and resolving consumer disputes, and missing them creates liability.

• Complaint management. Logging, responding, and reporting on customer complaints, which your bank will ask to see.

• Marketing and disclosure review. What you can claim, how you describe FDIC insurance, and the disclosures your product has to surface. Your bank reviews this and will reject copy.

• Audit support. Producing evidence when your bank or its examiners ask for it, on their timeline.

What fintech compliance means goes deeper on the obligations themselves.

What you still have to build

A BaaS provider gives you APIs. It does not give you a working financial product. The engineering that remains yours:

• Your own ledger. Double-entry, immutable entries, and a model that handles a pending authorization settling for a different amount. Relying solely on a provider's balance endpoint leaves you unable to answer questions about your own money.

• Reconciliation. An automated daily comparison between your records and the provider's, with breaks surfaced to someone who can resolve them.

• Idempotency. Every write that moves money needs an idempotency key, because payment APIs get called twice and networks time out after the money has already moved.

• Webhook handling. Providers push state changes asynchronously. You need retry logic, out-of-order handling, and a way to replay missed events.

• Audit trails. Who did what, when, and why, stored immutably, for disputes, exams, and your eventual SOC 2.

• Operational tooling. Your support team needs to look up a customer, see their balance history, and resolve a problem without a developer running queries.

APIs in fintech covers how these integrations behave in production.

Banking as a service examples

What this looks like in production:

• A vertical SaaS product offering business checking. Trucking, construction, or salon software giving customers an account and a card, earning interchange on spend the software already sees.

• A payroll platform holding employer funds. Money sits in custodial accounts between the employer's debit and the employee's payday, which requires a bank relationship and careful ledger work.

• A marketplace issuing cards to sellers. Sellers get a card tied to their earnings balance, keeping money on the platform instead of being swept out.

• A neobank for a specific population. A consumer banking product with no charter of its own, running entirely on a sponsor bank relationship.

• An expense management product. Corporate cards with spend controls, built on issuing plus a deposit account.

The common thread is that the distributor already owns the customer relationship and the data, so it can offer a banking product at a moment a bank never sees.

Red flags when evaluating a BaaS provider

• They won't name the bank. If a platform won't tell you which bank will hold your customers' deposits before you sign, that's the answer.

• No clear reconciliation story. Ask how often their ledger is reconciled against the bank's and what happens when they disagree. A provider that redirects to a compliance page has not built this properly.

• Vague on fund segregation. You need to know how customer funds are held and how the sub-ledger tracks ownership.

• No exit plan. Ask what happens to your customers, balances, and data if you leave or if they fail.

• Minimums that assume a scale you don't have. A platform priced for a program ten times your size will not prioritize you either.

• No enforcement disclosure. Bank enforcement history is public. A partner who treats the question as hostile is telling you something.

Questions to ask a banking as a service provider

• Which bank holds the deposits, and what is their enforcement history?

• Do I contract with you, with the bank, or both?

• How often is your ledger reconciled against the bank's, and who reviews the breaks?

• How are customer funds held, and what structure are the accounts in?

• What is the all-in monthly cost at my expected year-two volume?

• What is the interchange split between me, you, and the bank?

• What compliance work remains mine, and what headcount do your comparable customers run?

• How long from signed contract to first live customer?

• What are my data export rights, and what is the notice period to leave?

• Which of your customers look like me, and can I speak to two of them?

Switching banking as a service providers

Worth understanding before you sign the first one, because the cost of leaving shapes how carefully you should choose.

• Accounts usually don't transfer. Moving to a new bank generally means re-onboarding your customers, including fresh identity verification. Expect attrition.

• Cards get reissued. New bank means a new BIN, which means new card numbers for every customer and every stored credential they've set up elsewhere.

• Records have to be preserved. Bank Secrecy Act recordkeeping obligations outlast the relationship, so you need your historical data exported in a usable form.

• Contracts have teeth. Minimum terms, notice periods, and exclusivity clauses all slow an exit. Negotiate data export rights and a reasonable notice period up front, when you have leverage.

Assume a migration takes six to twelve months and costs you customers. That's the reason to diligence the first provider properly rather than picking whoever answers fastest.

Getting your own charter instead

At enough scale, renting stops making sense. The alternatives:

• De novo bank charter. Applying for your own charter is a multi-year, capital-intensive process with regulatory capital requirements and an ongoing supervisory relationship. It changes what kind of company you are.

• Acquiring a small bank. Faster than a de novo application and still subject to regulatory approval of the change in control. This is the path several fintechs have taken.

• Money transmitter licensing. A middle path for payments-focused products that don't need deposits. Licensing is state by state, which is slow and expensive but far short of a bank charter.

• Staying rented. For almost every company between pre-seed and Series A, this is the right answer. The economics of a charter only work at volume that makes the margin share material.

The question to ask is whether the interchange and float you're giving away exceeds what a charter would cost you to run. Below a certain scale it does not come close.

Where TechSuite fits

TechSuite doesn't sell banking as a service. We're a fintech software development firm, and we build the systems that sit on top of these providers: the ledger, the reconciliation, the integration layer, and the product itself.

Most of what we do here is integration work. BaaS platforms, Plaid, Stripe, KYC and AML vendors, and the connections between them, plus the internal ledger that has to agree with all of them. Our team is led by founder and CEO Sam Corso, with more than ten years of fintech engineering behind the practice and 30+ clients shipped, working across digital banking, lending, personal finance, insurtech, blockchain and crypto, and capital markets.

If you're choosing between providers and want an engineering read on which one fits what you're building, book a call. If you've already integrated one and want to know whether your ledger and reconciliation will hold up at volume, that's what our audit engagement covers.

Banking as a service FAQs

What is the difference between a sponsor bank and a BaaS platform? A sponsor bank is a chartered bank that holds the license and the deposits. A BaaS platform is software sitting in front of a sponsor bank, providing APIs and program tooling. Most programs involve both. The difference that matters is which one you contract with and how much compliance work lands on you.

Do I need a banking license to use banking as a service? No. The bank holds the license. You inherit obligations contractually around identity verification, transaction monitoring, dispute handling, and reporting, which is real work even though you aren't the license holder.

How much does banking as a service cost? Expect a setup fee, a monthly platform minimum in the low thousands to low tens of thousands, per-unit pricing on accounts and cards, and an interchange split with the bank and platform. Add your own compliance tooling and headcount.

How long does it take to launch on banking as a service? Through a BaaS platform, weeks to a few months. Direct with a sponsor bank, six to eighteen months. The difference is whether you're joining an approved program structure or creating a new one.

What is the difference between banking as a service and open banking? Banking as a service lets you provide banking functions through someone else's charter, so money moves and accounts exist. Open banking lets you read data from accounts your customer holds elsewhere, with no charter and no money held. Plaid is open banking. Column is banking as a service.

What is the difference between banking as a service and banking as a platform? In banking as a service the bank is the supplier, providing capability to a fintech that distributes it. In banking as a platform the bank is the distributor, consuming fintech capability to offer inside its own app. The direction of the relationship is the difference.

What is BIN sponsorship? The card-specific form of sponsorship. Visa and Mastercard require every BIN to belong to a principal member bank, so a non-bank issuing cards does it under a bank's network membership.

Is my customers' money FDIC insured under banking as a service? Funds held at an FDIC-insured bank are insured against that bank failing, subject to pass-through requirements being met. Insurance does not cover losses caused by inaccurate records of who owns what, which is why the sub-ledger and reconciliation questions matter as much as the insurance question.

Which banking as a service providers work outside the US? ClearBank, Griffin, Swan, Solaris, Modulr, Treezor, and Paynetics cover the UK and EU. The US providers generally do not transfer, since licensing and payment rails are country-specific.

Can I switch banking as a service providers later? Yes, and it's expensive. Accounts usually require re-onboarding, cards get reissued with new numbers, and records have to be exported and retained. Assume six to twelve months and some customer attrition, and negotiate data export rights before you sign the first contract.

Where to start

Work out whether you need to hold customer funds at all. A product that routes payments without taking custody can often skip this entire layer, along with its cost and its timeline, and the customer experience is identical.

If you do need to hold funds, choose between the direct and platform paths on the basis of how much time you have and how much compliance capability you can staff. Then start bank conversations immediately, in parallel with engineering, because that timeline is the one you cannot compress.