Embedded finance and Banking as a Service (BaaS) are closely related, but they are not interchangeable. Embedded finance describes the integration of financial products into a non-financial customer journey. BaaS describes a model in which financial capabilities are made available to third parties, commonly through APIs and partnerships with licensed institutions. BaaS can enable embedded finance, but neither model necessarily requires the other.
For banks, finance companies and technology providers, the distinction matters because customer experience, regulated responsibility and technology operations do not always sit with the same organisation.
Is embedded finance the same as BaaS?
No. Embedded finance answers: where does the customer access the financial product? BaaS answers: how are financial capabilities supplied to another business?
For example, a marketplace may offer working-capital finance to its merchants inside its own portal. The marketplace distributes the offer and manages the digital journey; a licensed lender originates or provides the credit under the applicable legal arrangement; and a banking technology platform can support origination, limits, disbursement, servicing, accounting and APIs. This may be an embedded finance arrangement enabled by BaaS, depending on how the services are contracted and delivered.
Embedded finance may also be provided through other partnership or licensing models. Likewise, BaaS can support a fintech’s standalone financial app rather than a non-financial brand’s embedded journey.
Three roles, two names
Most partner-based financial services involve three roles. One organisation may hold more than one of them, and how responsibilities are split depends on the contracts and the licence.
- The brand or distributor leads the customer journey and distributes the financial offer. Its core business is retail, logistics, travel, payroll or software.
- The technology platform is the core banking system, ledger, product rules and APIs that support accounts, payments, lending, limits and servicing.
- The licensed institution is the bank, finance company or e-money institution that provides the regulated service and remains accountable for it under applicable law.
Embedded finance describes what happens in the brand’s journey. BaaS describes how the capabilities behind it are supplied. The technology platform may be run by a separate provider or by the licensed institution itself.
Three roles in a partner-based financial service
Image file: 01-three-roles.png. Alt text: Diagram of three roles: a brand or distributor that leads the customer journey, a technology platform that supports accounts, payments, lending, limits and servicing, and a licensed institution that provides the regulated service and stays accountable for it. Embedded finance labels the brand’s role; Banking as a Service labels the platform and the licensed institution. One organisation can hold more than one role, and neither model necessarily requires the other.
Embedded finance vs BaaS at a glance
| Dimension | Embedded finance | Banking as a Service |
| Primary focus | Financial services inside another business’s customer journey | Supplying financial capabilities to third parties |
| Typical participant | Retailer, marketplace, software provider or other distributor | Licensed institution, potentially supported by a technology provider |
| Customer relationship | Brand often leads the experience; contractual and data roles vary | Licensed provider and distributor allocate servicing and contractual roles by arrangement |
| Revenue model | Conversion, retention, service fees or agreed revenue share | Service fees, transaction fees, margins or agreed revenue share |
| Examples | Checkout lending, merchant finance, in-app wallets | Account, payment, card or lending capabilities exposed to partners |
| Key risks | Consumer outcomes, fraud, data, operational dependencies and reputation | Compliance, third-party oversight, operational resilience, reconciliation and financial risks |
| Technology needs | Secure integration, consistent experience and clear customer disclosures | Partner controls, auditability, reliable records, scalable APIs and reporting |
Ultimately, Where the Critical Distinction Lies: Customer Records and Reconciliation.
A key design question in partner-based financial services is how customer balances, entitlements and transactions are recorded and reconciled. Different operating models may use individual accounts, virtual accounts or pooled accounts supported by customer-level subledgers. The appropriate structure depends on the product, jurisdiction and regulatory framework.
What matters is that the responsible institution has timely access to complete, accurate and auditable customer-level records, clear ownership of reconciliation, and effective oversight of its service providers. However, an individual account in a core system does not, by itself, eliminate reconciliation or operational risk. Similarly, a properly governed pooled-account structure is not inherently defective; rather, the overall level of risk depends on the effectiveness of the governance, reconciliation, and oversight processes in place.
The cost of getting this wrong is visible in the United States. The intermediary Synapse filed for bankruptcy in April 2024. Its partner banks then found they held between $60 million and $90 million less than Synapse’s own records showed, according to the Consumer Financial Protection Bureau’s complaint. Furthermore, the CFPB alleged that Synapse failed to maintain sufficient records to track consumers’ funds, leaving end users unable to access their money for weeks or months while the parties reconciled the records. The CFPB has since allocated about $55.2 million from its Civil Penalty Fund to compensate affected consumers: $46.2 million in November 2025 and $9.0 million in May 2026.
Regulators had already turned to the banks. Banking Dive’s tracker lists six US banks placed under enforcement actions between January and May 2024 over their fintech partnerships, with third-party risk management and anti-money laundering controls as recurring themes.
The lesson is not that BaaS is unsafe, or that one account structure is always right. It is that the responsible institution cannot depend on an intermediary’s books: it needs its own view of every customer’s position and a clear owner for every reconciliation.
Account structures differ. Record requirements do not.
Image file: 02-record-requirements.png. Alt text: The diagram presents three possible account structures—individual accounts, virtual accounts, and a pooled account with a customer-level subledger and shows how each structure leads to the same requirements for the responsible institution: maintaining timely and complete customer-level records, ensuring end-to-end auditability, assigning clear ownership of reconciliation, and exercising effective oversight of service providers.
What this means in the GCC.
Open Banking, Open Finance and BaaS are related developments, but they are not the same regulatory model. Open Banking and Open Finance establish frameworks for authorised data access and, in some cases, payment initiation; BaaS concerns the provision of financial capabilities through commercial partnerships with regulated institutions.
- In the UAE, the Central Bank introduced an Open Finance framework in 2024, subsequently replaced by an updated regulation in 2025 (Circular C 03/2025, now in force).
- In Saudi Arabia, SAMA announced the second release of its Open Banking Framework in September 2024, addressing payment initiation services. In March 2026, after the sandbox phase, SAMA began licensing fintech companies to provide open banking services.
Moreover, while these developments support the continued growth of a broader connected-finance ecosystem, they should nevertheless not be interpreted as blanket authorisation for every Banking-as-a-Service (BaaS) or embedded finance structure. Instead, each model must still satisfy the applicable regulatory requirements and demonstrate effective governance and oversight.
For banks and finance companies in the region, the practical question is less “should we do embedded finance?” and more “can our core serve partners without putting our main system at risk?”
What a bank needs before it offers BaaS
- Separate books per partner. Each programme needs its own products, limits, pricing and reporting, kept apart from the others and from the bank’s own book, under one licence.
- Customer-level records the bank can see. Regardless of whether the structure uses individual, virtual, or pooled accounts, the bank must maintain timely, complete, and auditable records for each end customer. Furthermore, it must clearly assign responsibility for reconciliation to ensure accountability and effective oversight.
- Products configured, not coded. A partner programme should be a set of parameters: product, limits, fees, eligibility. If every new partner needs a vendor change request, the model does not scale.
- Controls the bank can see. Onboarding and KYC hooks, transaction monitoring and limits applied per partner, with the bank able to pause a programme on its own.
- APIs partners can build against. Documented and versioned, with a sandbox that behaves like production.
- An architecture that fits. A bank can extend its existing core, add selected capabilities alongside it, or deploy a dedicated platform for partner programmes. The right choice depends on the product, the volumes and what is already in place.
Which one are you building?
- If you are a licensed institution seeking new distribution, you may be establishing a BaaS proposition. Your decisions include product scope, partner governance, operating model and platform architecture.
- If you are a non-financial brand seeking to add financial services, you are pursuing embedded finance. You need a suitable regulated arrangement, clear customer responsibilities and reliable integration.
- If you are a fintech, you may consume BaaS to deliver your own app, distribute products through other brands, or combine both approaches.
How Fimple fits
Fimple enables financial institutions to deliver modern financial services through an API-first, composable technology platform. Rather than prescribing a single banking architecture, Fimple supports different transformation strategies: institutions can modernise selected customer journeys, integrate digital channels with an existing core, or use configurable banking capabilities to support new products and distribution models. This flexibility matters because launching embedded finance or BaaS does not always require replacing the bank’s core system.
Digital experiences connected to existing cores. For institutions that want to improve customer acquisition and servicing while retaining their current system of record, Fimple’s Mobile Banking and Internet Banking channels can provide the customer-facing experience and connect to existing banking infrastructure. This allows a bank or finance company to introduce digital journeys while keeping core product processing and accounting within its established environment, subject to the integration design.
A practical example. In one live deployment, a financial institution is using Fimple’s Mobile Banking and Internet Banking front ends, integrated with its existing core banking system, to run its digital customer journeys. Customers interact through Fimple-powered digital channels, while the existing core remains the underlying banking system. This shows how Fimple can contribute the digital experience and integration layer without requiring a side-core deployment or a full core replacement.
Why this matters for financial institutions. Furthermore, this approach highlights an important architectural choice by demonstrating how organizations can deliver digital transformation incrementally. An institution can focus investment on a specific customer journey, such as onboarding and deposit acquisition, while preserving its existing core investments and operational processes. The project team must define the actual division of responsibilities. Between the digital channels, integration services, and core system for each implementation.
Composable capabilities for broader financial distribution. Where the business model calls for additional product capabilities or partner programmes, Fimple’s banking platform and APIs can support configurable financial products and integration with external channels. A bank considering BaaS can assess whether to use its existing core, introduce selected Fimple capabilities, or deploy a dedicated architecture. These are design choices, not prerequisites for every embedded finance initiative.
Fimple’s role is to supply technology, not to replace the responsibilities of the licensed institution. Product approval, regulated service provision, customer-funds safeguarding where applicable, financial-crime controls and regulatory accountability remain subject to the applicable legal and operating arrangements. By separating the customer experience, financial product capabilities and regulated responsibilities, institutions can select an architecture aligned with their business strategy.
Related reading: banking as a service with Fimple and embedded finance with Fimple.
Frequently asked questions
Do you need a banking licence for embedded finance?
Not always. Many brands work with appropriately licensed partners, but their own activities may still require registration, authorisation or compliance with other rules depending on the country and product.
Who is responsible for compliance in BaaS?
The licensed institution remains accountable for the regulated activities and outsourced functions for which it is responsible under applicable law. Distributors and technology providers may also have direct legal, regulatory and contractual obligations.
What is embedded banking?
Embedded banking generally refers to banking products, such as accounts and payments, integrated into another company’s experience. Embedded finance is broader and can include lending, insurance and investments.
Planning a BaaS or embedded finance programme? Explore how Fimple’s composable banking technology can support your operating model and integration requirements.
