What is the embedded finance stack? The layers and companies behind every banking product
Behind every embedded finance experience is a stack of specialist providers working together. This guide breaks down the key layers of the embedded finance stack and explains how they work together to deliver financial services.
- Published
Every embedded finance product relies on multiple specialist providers, with each one responsible for a different part of the technology and infrastructure. This guide looks at five key layers of the embedded finance stack, explains what each one does, and looks at how they work together to deliver financial services within non-bank products.
When you split a restaurant bill inside a ride-hailing app, or choose a payment plan at checkout without visiting a bank, you are using embedded finance. The financial service is delivered within a product whose primary purpose is not banking.
Behind that experience is usually a combination of specialist providers. Understanding these different layers helps explain how embedded finance products are built and how the different parts of the infrastructure work together.
Key points
- Embedded finance integrates financial services into products that are not primarily banking products.
- The stack has five layers: core banking, Banking as a Service, connectivity, transaction data, and identity and risk.
- Banking as a Service provides the regulated infrastructure that allows non-bank companies to offer financial services, while embedded finance describes how those services are incorporated into another product or customer experience.
- Each layer has a different role, but the quality of one layer can affect the performance of others.
- The layer above transaction data is now forming, where enriched data feeds conversational banking interfaces.
What is embedded finance?
Embedded finance is the integration of financial services into products that are not primarily financial products .
A retailer offering installments at checkout, an accounting platform providing business accounts, or a marketplace paying out to sellers automatically are all examples of embedded finance, all built on infrastructure the brand itself does not own.
Building and maintaining all of the underlying financial infrastructure in-house can be complex, which is why companies often rely on specialist providers for different parts of the stack. The non-bank company controls the customer experience, while specialist providers provide much of the infrastructure and technology underneath it.
What are the layers of the embedded finance stack?
There are five: core banking, Banking as a Service, connectivity, transaction data, and identity and risk.
Each layer addresses a different requirement and can interact with the layers around it. Understanding these roles is important when assessing the infrastructure behind an embedded finance product.
| Layers | What it does | Example providers |
|---|---|---|
| Core banking | Holds accounts, balances and the ledger | Mambu, Thought Machine, Temenos |
| Banking as a Service | Provides regulated banking structure | Solaris, ClearBank, Griffin |
| Connectivity | Connects financial data with accounting platforms, ERPs and CRMs | Apideck |
| Transaction Data | Turns payment descriptors into recognisable merchant information | Snowdrop Solutions |
| Identity and Risk | Verifies customers and helps identify fraud and compliance risks | Veriff, Featurespace, ComplyAdvantage |
What does a core banking platform do?
A core banking platform holds accounts, balances and ledger entries. It acts as the system of record for a bank or financial product.
If the core banking system records an account balance of 240 euros, that balance becomes the reference point for the other systems that read from or write to the account.
Many traditional core banking systems were built decades ago and can be difficult to adapt to new products and requirements, which is why a generation of cloud-native providers now competes for replacements. Mambu and Thought Machine both offer configurable core banking platforms designed to launch new products in weeks rather than release cycles. Temenos serves the same need building on a longer history in the banking technology market..
A practical example: a fintech launching a business current account needs infrastructure to hold customer balances and record every debit and credit. The core banking platform provides that foundation.
What is the difference between Banking as a Service and embedded finance?
Banking as a Service provides regulated banking infrastructure that other companies can use, while embedded finance describes the integration of financial services into a non-bank product or experience.
Banking as a Service (BaaS) providers hold a banking or e-money licence and let other companies use it. This layer answers a question the core cannot: who is legally responsible for holding customer money. Suggestion: BaaS can provide access to regulated financial infrastructure, including services such as accounts, payments and card issuing, depending on their regulatory permissions and product offering.
Solaris, ClearBank and Griffin are examples of providers operating in this space in Europe and the UK.
In this sense, a software company that allows its customers to open accounts is offering an embedded finance service. The licensed provider supporting the account infrastructure is part of the Banking as a Service layer.
The two concepts are therefore closely related, but they describe different parts of the ecosystem. BaaS provides infrastructure and regulated services, while embedded finance describes how those services are incorporated into another company's product.
How do banks connect to accounting and ERP systems?
Through the connectivity layer, usually a unified API that maps many platforms to a single data model.
Business customers often expect their banking data to flow directly into the accounting and financial software they already use.
The engineering problem is volume. Platforms such as Xero, QuickBooks, NetSuite, Sage and Exact Online all model the same concepts differently, and building one integration per platform is a permanent maintenance cost. Apideck works this way for banking and fintech use cases, providing an unified API that can connect banking and fintech applications to accounting and ERP systems This can allow financial data to be synchronised with multiple platforms through a common integration rather than requiring a separate connection for each one.
A practical example is a business banking app that allows customers to sync transactions directly into their Xero account. The customer sees one single feature while the underlying infrastructure handles the connection between the banking application and the accounting platform.
Why do bank statements show unrecognisable merchant names?
Because payment descriptors are primarily designed to identify transactions within payment and settlement systems rather than to provide the trading name customers recognise.. Resolving them is the job of the transaction data layer.
This is the layer Snowdrop Solutions works in, as a transaction enrichment provider. The problem is easy to demonstrate and surprisingly persistent. A customer buys coffee and their statement reads:
SQ *BLUE BOTT 4X92 SAN FRAN CA
Nothing about that string helps. The descriptor is generated by the acquirer and the processor, often containing a legal entity name, a terminal identifier and a location code rather than the trading name the end-user knows. Merchant category codes (MCC) are assigned by acquirers with wide variation in accuracy and may not provide enough context to identify the business clearly. The result is a customer who cannot place a purchase they made three days ago.
Transaction enrichment resolves a payment descriptor to a recognisable merchant entity. That same transaction becomes Blue Bottle Coffee, with the correct merchant name and logo, a spending category that supports budgeting features, the location of the branch on a map, and contact details that let the customer query the charge with the merchant before raising a dispute with their bank.
The quality of transaction data can also have an operational impact. Customers recognise their spending, so support queries and unnecessary card freezes fall. Snowdrop's own figures put the reduction in operational support costs at up to 30%. And once transactions are legible, the product features built on top of them become possible: budgeting, carbon footprint estimates, rewards tied to specific merchants. A messy transaction feed makes all of those unreliable.
Getting this right at scale is a data problem rather than a formatting one. Snowdrop enriches more than 2.5 billion transactions a month, and the accuracy question is less about the well-known chains than about the long tail of independent merchants, seasonal traders and businesses that changed name last quarter. The approach and its limits are covered in our note on AI merchant name normalisation.
Who handles identity and fraud in the stack?
The identity and risk layer, which support the other layers of the stack by helping financial providers verify customers, manage compliance requirements and identify potentially fraudulent activity.
Veriff and Onfido provide identity verification at onboarding. Featurespace applies behavioural analytics to fraud detection. ComplyAdvantage screens customers and counterparties against sanctions and other financial crime risks.
These capabilities also depend on the quality of the data they receive. A fraud model reading unresolved merchant strings has less signal to work with than one reading resolved merchant entities, categories and locations. Clean and structured transaction data can therefore support not only customer-facing experiences but also risk and fraud-related use cases.
How do the layers work together?
Following one single payment through the stack shows how the different layers contribute to the same customer experience.
Imagine a customer paying for lunch with a business card. The core banking platform records the debit and updates the account balance. The transaction data layer resolves the payment descriptor into a recognised restaurant with a category, a logo and a location. The risk layer can assess the transaction against relevant fraud signals.. Then, the connectivity layer can synchronise the transaction with the company's accounting platform, where the relevant financial data can be available without requiring the customer or finance team to enter it manually.
The customer may only see one transaction in their banking application, while several different providers and systems can be involved in delivering that experience.
That chain also explains why different layers are connected. An unresolved merchant descriptor may affect the customer experience, but it can also make downstream financial data less useful for accounting, analysis or other applications.
How do you choose a provider in each layer?
When evaluating providers, test their performance against your own requirements and data rather than relying only on headline claims.
The evaluation criteria will vary depending on the layer and the use case, but several considerations apply across the stack..
- Coverage where you actually operate. Global averages can hide regional gaps, Testing a representative sample of your own data can provide a more useful view of performance.
- Treatment of exceptions. Common use cases are often well supported. What separates providers is merchants trading under multiple names, refunds, cross-border transactions, and businesses that have recently changed or ceased trading.
- Regulatory position. Confirm which certifications and regulatory requirements apply to the specific service you are buying. ISO 27001 and GDPR compliance are baseline for anything touching transaction data.
- Latency and integration effort. Ask how long a realistic deployment takes, and the resources required on your side to implement and maintain the integration.
- Pricing at scale. Model the cost at your expected future transaction volume rather than looking only at the current price. Per-call pricing, for example, behaves very differently at ten times your current volume.
Frequently asked questions
What are some examples of embedded finance?
Embedded finance can take many forms depending on the product and the financial service being offered. Common examples include instalment payment options at online checkout, business accounts offered inside accounting software, insurance sold at the point of purchase, and instant payouts to sellers on a marketplace.
What is a merchant category code?
A merchant category code (MCC) is used to classify a merchant according to its type of business. MCCs are primarily used within the payments ecosystem for purposes such as reporting and transaction processing, rather than to provide customers with a detailed or always accurate description of where they spent their money. For this reason, transaction enrichment providers can use MCC as one source of information alongside other transaction and merchant data.
Does embedded finance require a banking licence?
Not necessarily. A non-bank company can offer certain financial services through a Banking as a Service provider or another regulated partner, depending on the service and the regulatory requirements in the relevant market. The regulated provider can provide the underlying infrastructure and permissions, allowing the non-bank company to focus on the customer-facing experience.
How many providers can be involved in an embedded finance product?
The number varies depending on the product and the services it offers. A typical embedded finance solution may rely on several specialist providers covering areas such as core banking, regulated financial services, connectivity, transaction data, identity and risk. Some providers can cover more than one part of the stack, so there is no fixed number of providers required.
What comes after transaction data?
A conversational layer, built on the quality and context of the data beneath it.
As financial data becomes more structured, enriched and contextual, it can also become the foundation for new types of banking experiences. Conversational and agentic interfaces, for example, need reliable transaction data to answer questions about a customer's spending. If a customer asks, “How much did I spend on groceries in June?”, the system first needs to understand which transactions relate to groceries, when they took place and how they should be categorised.
This is where contextual banking comes into the picture. Enriched transaction data provides some of the context that allows financial applications to move beyond displaying transactions and towards helping customers understand and interact with their finances.
