How Banking as a Service (BaaS) Works
BaaS operates through a layered model connecting three parties: the licensed bank (sponsor), the BaaS platform or middleware, and the end client building the product. Each layer has distinct responsibilities, and understanding the hand-offs is essential for anyone evaluating a BaaS integration.
Sponsor bank holds the licence
BaaS platform abstracts complexity
Client integrates via API
KYC and onboarding run at the client layer
Money moves on the bank's rails
Revenue is shared and fees are invoiced
Why Banking as a Service (BaaS) Matters
BaaS has reshaped who can offer financial products. Before BaaS, launching a current account required years of regulatory approvals and hundreds of millions in capital. Today, a well-funded startup can go live in under six months. This compression of time and cost has structurally altered competitive dynamics across retail, SaaS, and e-commerce.
The numbers support the scale of the shift. According to Allied Market Research, the global BaaS market was valued at approximately $19.65 billion in 2021 and is projected to reach $74.55 billion by 2030, growing at a CAGR of 15.7%. A 2023 Mambu survey found that 85% of banks were either actively building or planning BaaS programmes within two years—indicating that wholesale banking distribution is becoming a core revenue line for traditional institutions, not a niche experiment. Meanwhile, McKinsey estimates that embedded finance revenue pools—largely enabled by BaaS—could reach $230 billion in the US alone by 2025, up from $22.5 billion in 2020.
Regulatory momentum
Banking as a Service (BaaS) vs. Open Banking
Both BaaS and open banking involve APIs and bank data, but they solve fundamentally different problems. Understanding the distinction prevents misaligned vendor selection.
| Dimension | Banking as a Service (BaaS) | Open Banking |
|---|---|---|
| Primary function | Embed banking products in non-bank platforms | Share bank account data with authorised third parties |
| Regulatory basis | Sponsor bank licence + programme agreement | PSD2, CDR, or equivalent data-sharing mandate |
| Who holds the licence | Sponsor bank | Incumbent bank (data provider) |
| Product creation | Yes — accounts, cards, loans, FX | No — data access only |
| Customer relationship | Client platform owns the UX | Aggregator/PISP owns the UX |
| Revenue model | Interchange, platform fees, interest | API subscription, data fees |
| Typical use case | Fintech building a neobank, brand launching a card | PFM app, lending underwriting, account switching |
| Compliance burden on client | High (KYC/AML programme required) | Moderate (consent management, data security) |
Types of Banking as a Service (BaaS)
BaaS is not monolithic. Providers specialise by product area, geography, and client segment. Understanding the variants helps narrow vendor selection early.
Deposit and account BaaS covers IBAN provisioning, current accounts, savings accounts, and multi-currency wallets. Providers in this category connect clients to SEPA, Faster Payments, and SWIFT rails.
Card issuing BaaS enables clients to issue physical and virtual debit or prepaid cards under Visa or Mastercard programmes. The BaaS provider acts as the issuer processor or connects to one, handling authorisation, clearing, and settlement.
Lending BaaS powers buy-now-pay-later, instalment loans, and working capital products. The sponsor bank originates loans on its balance sheet; the client handles origination UX and marketing. Credit risk underwriting models may be provided by the BaaS platform or built by the client.
FX and cross-border BaaS offers multi-currency accounts, FX conversion, and international transfers. This variant is critical for payment gateway operators and marketplaces with cross-border seller bases.
Full-stack BaaS combines accounts, cards, payments, and compliance tooling in a single platform. Providers like Railsr, Swan, and Treezor operate in this space in Europe.
Best Practices
BaaS integrations succeed or fail on the quality of programme design and ongoing governance. Best practices differ depending on whether you are a merchant embedding financial products or a developer building the integration.
For Merchants
Define the business case before signing. BaaS platforms have significant setup and compliance costs. Model interchange revenue, customer LTV uplift, and competitive differentiation before committing. Marginal use cases rarely cover programme overhead.
Select a sponsor bank with relevant regulatory exposure. A sponsor bank regulated in your target market is non-negotiable. EU-facing programmes need an EEA-licensed institution; UK programmes require FCA authorisation post-Brexit. Mismatched licensing creates unresolvable compliance gaps.
Negotiate programme governance upfront. Understand exactly which compliance decisions require sponsor bank approval, what SLAs apply to policy changes, and what happens if the sponsor bank exits the market. Lock these terms into the contract.
Plan for KYC friction at launch. First-time embedded finance users will encounter identity verification steps they don't expect. Design onboarding flows that contextualise why verification is required and offer fallback options for users who fail automated checks.
For Developers
Treat the BaaS API as a regulated dependency. Unlike a typical SaaS API, changes to BaaS endpoints may be driven by regulatory requirements with short notice periods. Build abstraction layers that let you swap provider-specific calls without refactoring business logic.
Implement idempotency everywhere. Payment and account APIs must be called idempotently. Duplicate transactions caused by retry logic or network timeouts can trigger compliance flags and are operationally complex to reverse.
Log everything with timestamps. Regulators may request transaction logs going back years. Design your data retention strategy before launch, not after. Store raw API request/response payloads in append-only storage with tamper-evident audit trails.
Test the compliance webhooks, not just the happy path. BaaS platforms emit webhooks for KYC outcomes, transaction monitoring alerts, and account freezes. These are critical operational events—test them with the same rigour as payment confirmation webhooks.
Common Mistakes
Underestimating compliance programme overhead. The BaaS provider handles the licence; the client handles KYC/AML execution. Many first-time BaaS clients budget for API integration but not for the compliance operations team, ongoing transaction monitoring, and periodic regulatory reporting that the programme requires.
Treating the sponsor bank as invisible. Customers must be informed they are banking with a regulated institution. Burying this disclosure violates scheme rules and, in most jurisdictions, consumer protection regulations. Prominent disclosure also builds trust—many customers appreciate transparency about who holds their money.
Ignoring concentration risk. Building critical business infrastructure on a single BaaS provider creates existential risk if that provider is acquired, loses its licence, or changes its commercial terms. Architecture decisions should preserve the ability to migrate to a secondary provider within 60–90 days.
Launching without a sanctions screening flow. Transaction monitoring and sanctions list screening are minimum requirements of any BaaS programme. Launching without an automated screening integration—even during beta—exposes both client and sponsor bank to enforcement action.
Misreading interchange economics. Consumer debit interchange in Europe is capped at 0.2% under the Interchange Fee Regulation. Models built on US-style interchange assumptions (often 1.5–2%) will significantly overestimate BaaS revenue in European markets.
Banking as a Service (BaaS) and Tagada
BaaS provides the banking infrastructure layer; payment orchestration determines how money moves across that infrastructure in production. Tagada sits at the orchestration layer—routing transactions, managing provider failover, and normalising settlement data across multiple acquirers and payment methods.
For merchants running hybrid stacks—BaaS for account and card issuance, traditional acquirers for e-commerce—Tagada provides the connective tissue that prevents fragmented reconciliation and blind spots in payment analytics.