What Is Banking as a Service (BaaS)? A Guide for Cross-Border Platforms

Disclosure: This guide is published by HaiPay, a cross-border payments infrastructure provider. HaiPay is not a bank and does not provide Banking-as-a-Service; this article is educational and not financial or compliance advice. Market figures are dated and sourced; definitions of the BaaS market vary widely between sources.

Banking as a Service (BaaS) is a model in which a licensed bank exposes its regulated banking capabilities — accounts, card issuing, payments, and compliance — to non-bank businesses through APIs, so those businesses can offer banking features under their own brand without becoming a bank themselves. It is the infrastructure layer beneath much of what people call embedded finance. It is distinct from open banking (which is about sharing bank data) and from embedded payments (which is about accepting payments inside an app). For cross-border platforms, BaaS is often paired with a separate cross-border payments layer.

If those four terms already sound tangled, you're not alone — the confusion between them is the single most common reason teams misjudge what they actually need. This guide defines BaaS clearly, shows how it works and who's involved, walks through examples and the real risks, and explains where cross-border platforms hit the edges of a single-jurisdiction BaaS setup.

BaaS vs. embedded finance vs. open banking vs. embedded payments

These four terms overlap but describe different things. Here's how they relate:

The clean way to hold it: BaaS is the licensed banking infrastructure; embedded finance is the umbrella outcome; open banking is about data; embedded payments is about accepting money. BaaS often sits underneath embedded finance, while embedded payments and open banking solve adjacent problems.

Stripe offers a useful comparison of the last two: Open Banking vs. Embedded Finance — A Guide.

Going deeper on the neighbours? See our guides to embedded payments and embedded finance.

How banking as a service works: the components and players

A BaaS arrangement usually involves three parties:

• The licensed bank — holds the banking license, owns regulatory compliance, and provides the underlying accounts, card BINs, and money movement.
• The BaaS platform / middleware — the technology layer that turns the bank's capabilities into clean, developer-friendly APIs (onboarding, KYC/KYB, ledgering, card issuing, webhooks).
• The brand / non-bank business — the fintech, marketplace, or software platform that offers banking features to its own customers under its own brand.

The capabilities typically exposed through BaaS APIs include:

• Accounts — opening and operating deposit or wallet-style accounts.
• Card issuing — issuing branded debit or prepaid cards on a sponsor bank's BIN.
• Payments and money movement — sending and receiving funds over the bank's rails.
• Compliance tooling — KYC/KYB identity checks, AML monitoring, and reporting handled with (or by) the licensed bank.

The brand integrates once and offers banking features natively; the bank and platform handle the regulated machinery underneath.

For a policy-oriented primer covering the regulatory landscape and risk dynamics, see the Wharton School's overview: A Primer on Banking-as-a-Service.

Banking as a service examples

BaaS shows up wherever a non-bank offers banking-like features:

• A software platform issuing branded cards to its business users (for example, a vertical SaaS tool giving its customers a spend card).
• A marketplace providing seller accounts and payouts without each seller opening a separate business bank account.
• A fintech app offering deposit accounts under its own brand, held at a partner bank behind the scenes.
• A gig or creator platform giving workers instant-access balances and cards.

In each case, the end user sees the brand — not the bank that actually holds the license.

The benefits of banking as a service

For non-bank businesses, BaaS turns "become a bank or partner with one the hard way" into an API integration. The main draws:

• Speed to market — launching accounts or cards through a BaaS partner is far faster than pursuing a banking license or negotiating a bespoke bank integration.
• New revenue lines — interchange on issued cards, interest, or premium account features become products the brand can monetize.
• Deeper customer relationships — keeping banking features inside the product increases engagement and retention.
• Less regulatory heavy lifting — the licensed partner carries the core compliance burden (though not all of the brand's responsibility — see risks below).

The market reflects that pull: one industry estimate put the global BaaS market at USD 24.8 billion in 2025, projected to reach USD 126.6 billion by 2035 (a 17.8% CAGR) (Global Market Insights). Treat any single figure with care — market-size estimates for BaaS vary widely depending on how each research firm defines the category.

The risks of banking as a service

BaaS is not a shortcut around responsibility. The risks are real and, in recent years, very public:

• Provider dependency — your product's banking features live on top of one partner bank and one platform. If either has an outage, changes terms, or exits the business, your service is exposed.
• Compliance is shared, not outsourced — the licensed bank owns the charter, but the brand still carries obligations for how it onboards users, markets products, and monitors activity. Regulators have increasingly scrutinized bank–fintech BaaS arrangements where those lines blurred.
• Operational and reconciliation complexity — moving money across the bank, platform, and brand introduces ledgering and reconciliation work that has to be right.
• Concentration and end-customer trust — when a middleware provider between the bank and the brand runs into trouble, end customers can feel the impact, which is why due diligence on every party in the chain matters.

The takeaway isn't "avoid BaaS" — it's "know exactly who holds the license, who owns which compliance obligation, and what happens if a link in the chain breaks."

Stripe's guide provides additional context on what businesses should evaluate: What is Banking-as-a-Service?

Banking as a service for cross-border platforms

Here's an edge most BaaS explainers skip: most BaaS setups are anchored to a single jurisdiction. The partner bank's license, the accounts, and the card programs are typically tied to one country or region. That's fine if your users are there — but cross-border platforms quickly run into the limits.

A platform serving customers in many markets usually needs two different things:

1. Banking capability (accounts, cards, compliance) — which BaaS can provide, jurisdiction by jurisdiction.
2. A cross-border payments layer — the ability to accept and pay out in each market using the local payment methods customers actually use, not just cards.

These are different problems, and a single-jurisdiction BaaS partner rarely solves the second one. This is the layer HaiPay focuses on: HaiPay's payment network spans 150+ local payment methods across 52 regions, which platforms can integrate through an API, Hosted Checkout, or Components — so a product built on BaaS can pair it with cross-border local payment acceptance and payouts. To be clear: HaiPay is not a bank and does not provide BaaS; it's the cross-border payments layer that sits alongside it. Coverage and requirements vary by market.

Building banking features into a cross-border product?

If your platform pairs BaaS with cross-border payments, the deciding factor is usually local coverage and integration fit. Book a demo or talk to a payment specialist to see how HaiPay's cross-border local payment methods and API can sit alongside your banking stack. (HaiPay provides the cross-border payments layer — not BaaS or banking licenses.)

Wesley Wang is part of the team at HaiPay, a cross-border payments infrastructure provider helping platforms accept and move money across borders.