How Does BaaS Work? Architecture, APIs, and the Sponsor-Bank Model

Key Takeaways

• BaaS platforms sit between sponsor banks and fintech clients as an orchestration layer, abstracting banking primitives (accounts, payments, cards, compliance) into composable API endpoints.
• The global BaaS market reached approximately USD 637B in 2024, with projections reaching USD 1.49T by 2030 at a CAGR of 15.7% (Grand View Research, 2024).
• A well-architected BaaS stack has four distinct layers: sponsor-bank core, compliance orchestration, API gateway, and client application - each with clear data boundaries and failure isolation.
• Regulatory divergence across jurisdictions (MAS in Singapore, SFC/HKMA in Hong Kong, AUSTRAC in Australia, OSFI in Canada) means BaaS platforms must implement jurisdiction-aware routing at the infrastructure level.
• The sponsor-bank model shifted fundamentally after the Synapse Financial collapse in April 2024, which froze USD 160-200M in customer funds and triggered a complete regulatory recalibration (Source: Jelena McWilliams, Synapse Financial Bankruptcy Trustee Report, U.S. Bankruptcy Court Central District of California, 2024).

Introduction

Understanding how BaaS works requires looking past the marketing layer. Banking as a Service is an infrastructure model where a licensed financial institution - the sponsor bank - exposes its banking capabilities through APIs, allowing non-bank companies to embed financial products directly into their own platforms. For a deeper introduction to the concept, see our cornerstone guide: What Is Banking as a Service? The Definitive Guide.

This article focuses on what sits between the bank licence and the end-user experience: the architecture, the API contracts, the ledger systems, and the compliance orchestration that make it all work. If you are evaluating how to build or integrate financial services across Hong Kong, Singapore, Australia, or Canada, the architectural decisions covered here will shape your platform’s reliability, compliance posture, and time to market.

The Four-Layer BaaS Architecture

Every production BaaS deployment, regardless of vendor, reduces to four layers. How cleanly these layers separate determines whether the platform scales or collapses under regulatory scrutiny.

Layer 1: Sponsor-Bank Core

The sponsor bank holds the licence and owns the customer relationship from a regulatory perspective. Its core banking system manages the ledger of record, settlement accounts, and regulatory reporting. In a well-designed BaaS arrangement, the sponsor bank retains real-time visibility into all transactions and customer records - a requirement that regulators in all four of Aerapass’s operating jurisdictions now enforce explicitly.

Layer 2: Compliance Orchestration

This layer handles KYC/AML screening, transaction monitoring, sanctions checks, and regulatory reporting. It must be jurisdiction-aware: MAS requires risk-based Customer Due Diligence under the Payment Services Act; HKMA mandates enhanced due diligence for cross-border wire transfers above HKD 8,000; AUSTRAC enforces the AML/CTF Act with real-time suspicious matter reporting; and OSFI requires PCMLTFA compliance with specific thresholds for large cash transactions.

Layer 3: API Gateway and Orchestration

The API layer translates banking primitives into developer-friendly endpoints. A mature BaaS API gateway handles authentication (typically OAuth 2.0 with mutual TLS for production), rate limiting, request validation, idempotency, and webhook delivery for asynchronous events. This is where composability happens - a fintech client assembles the exact combination of banking services it needs without touching the layers below.

Layer 4: Client Application

The fintech or enterprise client builds its user-facing product on top of the API layer. From the end user’s perspective, they interact with the client’s brand - the sponsor bank and BaaS orchestration are invisible. White-label capabilities at this layer allow complete brand customisation of interfaces, statements, and communications.

How the Sponsor-Bank Model Works in Practice

The sponsor-bank model is the legal and commercial framework that makes BaaS possible. A licensed bank partners with a BaaS platform, which in turn serves fintech clients. The bank’s licence covers the regulated activities; the BaaS platform provides the technology; the fintech client provides the distribution and user experience.

Before 2024, many BaaS arrangements used a middleware-heavy model where the BaaS platform acted as a thick intermediary between the bank and the fintech. The Synapse Financial collapse in April 2024 - which froze between USD 160M and USD 200M in customer funds - exposed the fundamental risk of this approach. When the middleware layer failed, neither the bank nor the fintechs had sufficient visibility into the underlying ledger to reconcile customer balances.

The regulatory response was direct. In March 2025, the FDIC, OCC, and Federal Reserve issued joint guidance holding banks fully accountable for all third-party partner actions. This has driven a structural shift toward what the industry calls BaaS 2.0: direct bank-fintech partnerships with daily reconciliation, bank-owned compliance oversight, and real-time data sharing between all parties.

For platforms operating across multiple jurisdictions, this shift has practical implications. In Singapore, MAS expects the licensed entity to maintain operational control over outsourced functions. In Hong Kong, HKMA’s updated Technology Risk Management guidelines require banks to demonstrate end-to-end oversight of all technology partners. In Australia, APRA’s CPS 234 mandates that the licensed entity maintains information security controls over all third-party arrangements.

API Design Patterns in BaaS

BaaS APIs typically follow RESTful conventions with JSON payloads. The specifics of API design vary between platforms and directly affect integration complexity, reliability, and time to market.

Idempotency

Financial APIs must be idempotent - sending the same request twice should not create duplicate transactions. This is typically implemented through client-generated idempotency keys passed in request headers. A well-designed BaaS API stores these keys for a defined window (usually 24-48 hours) and returns the original response for any duplicate request.

Webhook-Driven Event Architecture

Because many banking operations are asynchronous (payment settlement, KYC verification, card activation), BaaS platforms use webhook callbacks to notify clients when operations complete. Reliable webhook delivery requires retry logic with exponential backoff, signature verification to prevent spoofing, and dead-letter queues for failed deliveries.

Versioning and Backwards Compatibility

Production financial APIs cannot break existing integrations. BaaS platforms typically version their APIs through URL paths (e.g., /v2/payments) and maintain backwards compatibility for at least 12 months after a new version is released, giving clients time to migrate.

Ledger Architecture and Reconciliation

The ledger is the heart of any BaaS platform. It tracks every account balance, every transaction, and every fee in real time. Production BaaS ledgers use double-entry bookkeeping: every transaction creates at least two entries (a debit and a credit) that must sum to zero.

The reconciliation challenge in BaaS is significant. The BaaS platform maintains its own ledger, but the sponsor bank also maintains a ledger of record. These two systems must agree at all times. Post-Synapse, regulators expect daily - in some cases intraday - reconciliation between the BaaS ledger and the bank’s core system. Any discrepancy must be flagged, investigated, and resolved within defined SLAs.

For multi-currency operations, the ledger must handle FX conversions, settlement timing differences across time zones, and currency-specific decimal precision (JPY uses zero decimal places; KWD uses three). A platform operating across Hong Kong, Singapore, Australia, and Canada must handle at minimum HKD, SGD, AUD, CAD, and USD, each with its own settlement cycle and cut-off times. For fintechs building cross-border payment products on BaaS infrastructure, a multi-currency payment gateway handles the routing, conversion, and settlement complexity across these currency corridors.

Compliance as Architecture, Not Afterthought

In a multi-jurisdictional BaaS platform, compliance is not a feature bolted on at the end - it is a core architectural decision that influences data flows, storage locations, and processing logic.

Jurisdiction-aware routing means that when a customer in Singapore initiates a transaction, the compliance layer automatically applies MAS rules without the client application needing to know which jurisdiction’s rules apply. The same transaction initiated by a customer in Hong Kong triggers HKMA compliance checks instead.

Data residency requirements add another layer of complexity. Singapore’s PDPA, Hong Kong’s PDPO, Australia’s Privacy Act, and Canada’s PIPEDA each have specific requirements around where personal data can be stored and processed. A BaaS platform must route data to the correct infrastructure based on the customer’s jurisdiction.

Aerapass addresses this through its all-in-one platform approach: a unified technology layer that handles jurisdiction-specific compliance routing, data residency, and regulatory reporting across all operating jurisdictions. Rather than integrating separate compliance tools for each market, platform operators get a single integration that adapts to local requirements automatically. This approach reduces integration complexity and ensures consistent compliance coverage across Customer Management, Global Payments, and Card Issuance solutions. For fintech and neobanking teams evaluating BaaS infrastructure, explore our fintech and neobanking solutions for a complete overview.

Frequently Asked Questions

What is the difference between BaaS and embedded finance?

BaaS is the infrastructure layer - it provides the regulated banking capabilities (accounts, payments, cards) via APIs. Embedded finance is the application pattern - it describes the practice of embedding financial services into non-financial products. BaaS is one of several ways to deliver embedded finance; others include direct bank partnerships and e-money licences.

How long does it take to integrate with a BaaS platform?

Integration timelines vary based on scope and regulatory requirements. A basic payment integration can be completed in 4-6 weeks. A full-stack deployment including accounts, cards, payments, and compliance typically takes 3-6 months, with regulatory approvals often being the longest lead-time item. Platforms that offer pre-built compliance solutions for specific jurisdictions can reduce this timeline by handling regulatory setup in parallel with technical integration.

What happens to customer funds if a BaaS platform fails?

Under the post-Synapse regulatory framework, customer funds must be held in FBO (For Benefit Of) accounts at the sponsor bank, with the bank maintaining a real-time ledger of individual customer balances. If the BaaS platform fails, the sponsor bank retains custody of all funds and can work directly with affected fintech clients to restore access. The key safeguard is daily reconciliation between the platform ledger and the bank ledger.

Do I need my own banking licence to use BaaS?

Not necessarily. The purpose of BaaS is to allow non-bank companies to offer financial services under the sponsor bank’s licence. However, depending on your jurisdiction and the specific services you want to offer, you may need ancillary licences. In Singapore, companies offering payment services must hold a Payment Services Act licence even when using a BaaS provider. In Hong Kong, stored value facility operators need an SVF licence from HKMA. Consult a qualified advisor for your specific situation.

How does a BaaS platform handle multi-currency operations?

Multi-currency support involves several architectural components: a multi-currency ledger with appropriate decimal precision per currency, FX rate feeds from liquidity providers, settlement accounts in each supported currency, and timezone-aware cut-off management. Cross-border payments add complexity through correspondent banking networks, SWIFT messaging, and local clearing systems (CHATS in Hong Kong, FAST in Singapore, NPP in Australia, Lynx in Canada).