What Banking as a Service means
Banking as a Service (BaaS) is a delivery model in which regulated banking capability is packaged so that another company can offer it to its own customers. Instead of building a ledger, obtaining every permission, integrating payment schemes and issuing cards from scratch, a brand plugs into a platform that already has those pieces assembled and connects to a licensed institution that carries the regulatory responsibility.
The practical result is that a fintech, a marketplace or an established consumer brand can launch accounts, cards and payments in its own name, with its own pricing and its own user experience, while the heavy machinery sits underneath. The customer sees your product. The plumbing — accounts, balances, settlement, screening — runs on infrastructure you did not have to build.
How the BaaS model works
Three roles combine in almost every BaaS programme.
- The licence holder. A bank or electronic money institution authorised to hold client funds and access payment schemes. It owns the regulatory permissions and ultimately the risk appetite for the programme.
- The technology layer. The BaaS platform: the ledger, the account and card management, the payment orchestration, the compliance workflows, the back office and the APIs. This is where the product actually runs day to day.
- The brand. Your company — the distribution, the customer relationship, the pricing and the proposition. You decide who the product is for and how it is positioned.
These roles can be split across three organisations or combined. Some clients already hold their own licence and only need the technology. Others need help mapping to a partner institution before anything can go live. The contractual shape differs, but the division of labour is consistent: regulated capacity, technology, and distribution.
What a BaaS platform includes
The phrase covers a lot of ground, so it is worth being specific about the components a serious platform provides.
Accounts and the ledger
A multi-currency ledger is the heart of the system: every balance, hold, fee and movement recorded in a way that reconciles cleanly. Around it sit account structures — personal, business, sub-accounts, safeguarding or segregated arrangements where those apply. If the ledger is weak, everything above it eventually becomes an operations problem. More detail on this layer is in our guide to core banking software.
IBANs and account identifiers
Customers expect an account they can receive salary or supplier payments into. Depending on the programme and jurisdiction, that means IBANs or local account identifiers issued through the partner institution and mapped to ledger accounts.
Cards
Virtual and physical issuing, card controls, limits, tokenisation for mobile wallets, and the authorisation logic that decides in real time whether a transaction is approved against the available balance.
Payments
Domestic and international rails, batch and single payments, scheduled transfers, and the routing rules that decide which rail a payment should take. Add FX where customers hold or convert multiple currencies.
Compliance workflows
Onboarding for individuals and businesses, document collection, sanctions and watchlist screening, transaction monitoring rules, case management, and audit trails. These are workflows your compliance team operates — the platform provides the tooling and the record, not the judgement.
Back office and APIs
An operations console for support and finance teams, role-based access control, reporting, and an API surface so the capability can be extended into your own applications.
BaaS versus building in-house
Building the same stack internally is possible and occasionally correct. It is also a multi-year commitment in which most of the effort goes into work no customer will ever notice: reconciliation, scheme certification, screening integrations, ledger correctness, card authorisation edge cases, dispute handling.
The honest comparison is not "cheap versus expensive" but "where do you want your engineering attention". With a platform you spend it on the proposition, the onboarding funnel and the pricing model. In-house, you spend a large share of it on infrastructure parity with products that already exist. Buying gets you to market in a fraction of the time of building in-house; building gives you total control over every component and a permanent obligation to maintain it.
A useful test: if a capability would be identical no matter which company shipped it, it is infrastructure, and infrastructure is usually better bought than built. Differentiation lives in brand, user experience, segment focus and pricing.
BaaS versus embedded finance
The two terms overlap and are often used interchangeably, but they describe different sides of the same arrangement. BaaS is the supply side: the licensed capacity and the technology that make banking functions available to a third party. Embedded finance is the demand side: a non-financial product placing those functions inside its own experience — a payout wallet in a gig platform, a card in an expense tool, an account inside a marketplace.
In other words, embedded finance is usually delivered through BaaS. If your starting point is "we already have users and want to add financial features", read our embedded finance platform guide. If your starting point is "we want to launch a financial product as the product", the white-label neobank route is closer to what you need.
Who uses BaaS
- Neobanks. Consumer or SME-focused challengers that want a full banking experience without owning every layer. See white-label digital banking.
- E-wallets and payment apps. Products centred on holding balances, sending money and spending with a card.
- SME and B2B finance. Accounting tools, payroll providers and vertical software that add accounts, payouts and expense cards to an existing workflow.
- Crypto platforms and OTC desks. Businesses that need fiat accounts, settlement and compliance operations alongside digital-asset activity.
- Licence holders. Institutions that already hold permissions but need modern technology to serve customers with them.
How to choose a BaaS platform
- Ledger and currency model. Can it handle every currency, account structure and fee pattern you plan to offer, in real time?
- Rail and provider coverage. Which payment rails, card programmes and verification providers are already integrated, and how are new ones added?
- Compliance tooling. Are onboarding, screening, monitoring and case management part of the platform, and can your team configure rules without an engineering ticket?
- Modularity. Can you start with accounts and payments and add cards, FX or crypto later without a re-platforming exercise?
- API quality. Documentation, sandbox, webhooks, idempotency, and how much of the product is reachable programmatically.
- Operational fit. What does support look like at 2am when a payment file fails, and who is accountable for what between you, the platform and the licence holder?
- Exit and portability. How is your data extracted if you change providers or bring the stack in-house later?
If you already know the shape of the product you want, the fastest way forward is usually a working session against your own requirements rather than a feature matrix. You can book a demo and walk through the modules with us, or start with the practical launch guide if you are still mapping the route.