Banking as a service (BaaS) is a model in which a technology provider sits between a licensed bank and a non-bank company, giving that company access to the bank's products through APIs. Companies use BaaS to build financial products, such as accounts, cards, and payments, without becoming a bank themselves. The BaaS provider manages the bank relationship and acts as the intermediary layer.
TLDR:
- BaaS puts a middleware intermediary between you and the bank, creating ledger gaps and requiring 10-15 additional vendor integrations.
- You don't need a banking license to offer accounts, cards, or money movement through a licensed bank partner.
- Direct-access financial infrastructure removes the intermediary, giving you one shared ledger and a direct bank relationship.
- BaaS middleware often pools end-user funds in FBO accounts tracked outside the bank, raising reconciliation and regulatory risk.
- Unit is a financial infrastructure provider where end-user funds sit in real bank accounts and businesses hold a direct bank relationship.
Who uses banking as a service?
Software and fintech companies building financial products are the main users. Their customers already run their business or daily life inside the product, so adding financial capabilities makes the product more useful and opens new revenue.
Examples by industry:
- Fintech: Mercury built business banking for startups. Ramp built corporate cards and spend management around automated expense tracking.
- Vertical SaaS: Toast added payroll, cards, and financing for restaurants. Housecall Pro added banking and cards for home services businesses, so contractors can run jobs and money in one place.
- Marketplaces and gig platforms: DoorDash and Uber pay dashers and drivers into in-app wallets. Companies like these build payout accounts and instant transfers so workers and sellers get paid faster.
- Lending companies: These pair credit products with accounts and cards, so borrowers can receive, spend, and repay in one place.
For all of these companies, the financial product is a business in its own right. It brings revenue, retention, and new data, but also new responsibilities in compliance, risk, and operations.
How companies build financial products today: two models
Companies building financial products in the US generally choose between two infrastructure models. The difference comes down to one question: is there an intermediary between you and the bank?
Model A: Banking as a service (middleware)
In the BaaS model, a middleware provider (Treasury Prime is one example) connects your company to one or more partner banks. The provider holds the bank relationship and exposes the bank's products through its API.
This model made it possible for many companies to launch financial products quickly. It also creates structural problems that show up as a company scales:
- The intermediary owns the bank relationship. Your contract is often with the provider, not the bank. That makes it harder for the bank to oversee your program, and harder for you to resolve issues directly.
- Funds are often pooled. End-user funds typically sit in a pooled FBO ("for benefit of") account. Individual balances are tracked on the provider's ledger rather than as accounts in each user's legal name.
- The ledger sits outside the bank. When the provider keeps its own records separate from the bank's system of record, the two can drift apart. Reconciliation becomes a recurring risk, and in a dispute it may be unclear whose numbers are right.
- You assemble the rest yourself. Middleware covers bank access, not the full product. Companies typically integrate 10-15 additional vendors for onboarding, fraud, AML, card processing, and security. They also write and operationalize 15-20 compliance policies (KYC, KYB, AML, fraud, information security, complaint management, and more) and hire compliance and banking operations teams to run them.
- Legacy cores limit flexibility. Many BaaS setups pass API calls through to bank cores that are decades old. That rigidity limits how you can configure pricing, terms, and features for different customers.
Regulators have also stepped up scrutiny of bank-fintech partnerships. That includes enforcement actions against partner banks and proposed recordkeeping requirements for custodial accounts, both aimed at the gaps this model can create.
Model B: Financial infrastructure with direct access
A newer category of providers removes the intermediary. These companies connect directly to the underlying rails: the Federal Reserve for ACH, wires, and real-time payments, and the card networks for issuing.
Some, like Column, are chartered banks that offer their infrastructure through APIs. Others, like Increase and Unit, connect directly to the Federal Reserve and card networks on behalf of their bank partners. In every case, the bank's system of record and the provider's ledger are the same picture, not two versions to reconcile.
Built for developers. The biggest practical difference for the team doing the work is the developer experience. Direct-access providers are built API-first, on modern ledgers rather than legacy cores. In practice, that means:
- Clean, consistent APIs and real sandboxes. Engineers can build and test the full product before launch, instead of waiting on bank-side processes.
- Programmatic control. You can authorize card transactions in real time, query and filter every transaction, and tag and enrich data for your own logic.
- Real-time events through webhooks. Your product can react to money movement as it happens.
- Fewer integrations. Capabilities that middleware leaves to third-party vendors are often native to the platform.
- Faster iteration. Pricing, terms, and product changes are configuration, not a bank change request.
Within this category, providers differ mainly in how much of the operating model they leave to you. API-first providers give deep access to the rails, but often expect the company to own large parts of compliance, risk, disputes, reconciliation, and bank coordination, along with the team that runs them.
Unit is a financial infrastructure platform that enables technology companies to store, move, spend, and lend money inside their product. The Unit Platform has three parts:
1. Building blocks: All of these run through direct Federal Reserve connectivity, direct card network issuing, and a single native ledger.
- Payment rails: ACH, wires, RTP, checks, and international payments.
- Account primitives: deposit accounts, wallets, and credit accounts.
- Card issuing.
2. Tooling: APIs, a dashboard, and UI components.
3. Program management: a modular set of capabilities and operations companies can delegate, covering compliance (KYC, KYB, AML), fraud, manual reviews, reconciliation, reporting, support, and bank coordination.
Unit is designed to support all four use cases (store, move, spend, and lend) on one ledger. Companies can therefore build the exact product they need without stitching providers together. They also choose how much of the operating model to own and can change that mix as they scale.
Two structural commitments shape every Unit program:
- A direct bank relationship. Every company on Unit has a direct legal relationship with its bank partner.
- Real bank accounts. End-user funds sit in actual bank accounts, in the end user's legal name, at the bank. Unit is the record-keeping system for both the company and the bank, so there is never a second version of the ledger.
Unit supports more than $100B in annual transaction volume and more than 5M accounts, handles more than 11M API calls a day, and holds PCI and SOC 2 certifications.
BaaS vs. financial infrastructure with direct access
| BaaS (middleware) | Financial infrastructure with direct access | |
|---|---|---|
| Bank relationship | Held by the intermediary | Direct between your company and the bank (or the provider is the bank) |
| Where end-user funds sit | Often pooled FBO accounts | Bank accounts at the bank, tied to the end user |
| Ledger of record | Provider's ledger, separate from the bank's | One ledger shared with the bank |
| Connection to payment rails | Through the bank's legacy core | Direct to the Federal Reserve and card networks |
| Developer experience | API wrapper over legacy systems | API-first, modern ledger, programmatic control |
| Vendors to integrate | Often 10-15 additional tools | Few or none, depending on the provider |
| Compliance and operations | Largely owned by your company | Ranges from self-managed to delegated program management |
How to choose the right model for your company
Before choosing a provider, get clear answers to these questions:
- Will my users' funds sit in real bank accounts in their own legal names? This affects how you can market the product, how interest is reported, and how protected your users are.
- Do I have a direct contract with the bank? A direct relationship gives you a clearer line of accountability and more stability.
- Whose ledger is the source of truth? If the provider's ledger and the bank's can disagree, ask how they reconcile and how often.
- How developer-friendly is the platform? Test the sandbox, read the API docs, and count how many separate vendors you would need to integrate.
- Which compliance and operations functions will I need to staff? Map KYC, KYB, AML, fraud, disputes, reconciliation, and support to either your team or the provider.
- Can I change how much I own as I scale? The right operating model at launch is rarely the right one three years later.
Which model fits whom:
- A company with a large compliance team and bank relationships already in place may be comfortable owning most of the operating model.
- A company that wants deep control of the product without building a full fintech function should look for direct-access infrastructure that includes program management.
- Unit is built for that second group: depth on the rails, with the option to delegate the hard parts of running a financial product.
Frequently asked questions
Is Unit a BaaS provider?
No. Unit is a financial infrastructure platform that enables technology companies to store, move, spend, and lend money inside their product. Unlike BaaS middleware:
- Unit requires a direct legal relationship between each company and its bank partner.
- End-user funds sit in real bank accounts in the end user's name.
- Unit's ledger is the shared system of record for both the company and the bank.
What is the difference between banking as a service and embedded finance?
Embedded finance describes the outcome: financial products offered inside a non-financial company's product. Banking as a service is one infrastructure model for getting there, using an intermediary between the company and the bank. Financial infrastructure with direct access is another.
Do I need a banking license to offer financial products?
No. Companies can offer accounts, cards, and payments through a licensed bank partner. The infrastructure model you choose determines how that bank relationship is structured and how much of the compliance work you own.
What is an FBO account?
An FBO ("for benefit of") account is a pooled account held at a bank on behalf of multiple end users. Individual balances are tracked on a separate ledger, often maintained by an intermediary rather than the bank.
Which model is most developer-friendly?
Direct-access infrastructure providers are generally the most developer-friendly. They offer API-first design, modern ledgers, full sandboxes, and programmatic control over transactions, without routing through legacy bank cores.
The content in this article is provided for general informational and educational purposes only and should not be construed as legal, tax, accounting, or regulatory advice. Unit does not warrant or guarantee the accuracy, completeness, adequacy, or currency of the information provided, and the content may not reflect all considerations relevant to a particular business, product, or use case.
Unit is a financial technology company and is not a bank. Banking services are provided by Unit's bank partner(s), Members FDIC.
