Embedded Finance: How It Works and How to Build It

Embedded finance is the practice of putting financial services (payments, accounts, lending, cards, insurance) directly inside a product that isn't a bank. You already use it. When a ride ends and your card is charged without you reaching for a wallet, when a checkout offers to split a purchase into four payments, when a marketplace pays its sellers and hands them a branded debit card, that's embedded finance at work. The financial machinery is still there, still regulated, still running on a licensed bank's rails. It's just hidden behind the product's own screens so the user never has to leave.

This guide is written from the builder's chair. Most explainers of embedded finance are sales pages for a platform. This one covers the parts those pages skip: how the stack actually fits together, what to build versus buy, where the compliance risk lives, and what a real project costs. If you're a founder or product leader weighing whether to embed finance into your software, this is the engineering and business framing we use when we scope one.

What is embedded finance

Embedded finance is the integration of banking, payments, lending, or insurance into a non-financial product, so users transact without leaving the app they're already in. The defining word is context. The financial action happens at the exact moment it's useful (pay at checkout, borrow at the point of sale, get insured when you book the rental) instead of bouncing the user to a separate bank or provider and hoping they come back.

For most of the last decade, fintech meant standalone apps. A new neobank, a new payments app, a new lender, each fighting for its own download and its own slice of attention. Embedded finance inverts that. Instead of building a destination people have to choose to visit, you weave the financial service into a product they already use every day. The software company owns the customer relationship and the interface; a licensed bank, reached through APIs, owns the money. That split is the whole idea, and it's why a coffee app, a logistics platform, or a vertical SaaS tool can suddenly offer something that used to require a banking charter and a building full of compliance staff.

How embedded finance works: APIs, SDKs and the BaaS stack

Embedded finance works by stacking three roles, connected by APIs and SDKs: a software platform on top, a banking-as-a-service provider in the middle, and a licensed sponsor bank at the bottom. The platform never touches the regulated core directly. It calls an API to open an account, issue a card, or move money, and the layers beneath translate that call into a real transaction on the banking and card networks.

Start at the bottom. A sponsor bank holds the actual license, the charter that lets it hold deposits, move funds across payment rails, and issue cards under a network like Visa or Mastercard. Banks are slow to integrate with and weren't built to expose their core to dozens of startups. That gap is what banking-as-a-service (BaaS) providers fill. A BaaS provider sits between the bank and the software world, taking the bank's regulated capabilities and re-packaging them as clean, modern APIs: create a ledger account, run a KYC check, issue a virtual card, initiate a payout. It also carries much of the operational compliance machinery the bank requires.

On top sits the platform, which is your product. It consumes those APIs and, often, an SDK (a pre-built library or drop-in UI component) so engineers don't reinvent a card-entry form or an onboarding flow from scratch. Underneath all of it run the payment rails: the networks that actually settle money. Card networks for card payments, ACH for low-cost bank transfers in the US, and real-time rails for instant movement. When a user taps "pay" in your app, the request travels down this stack, from platform to BaaS to bank to network, and the confirmation travels back up. The user sees one screen. Four or five parties did the work.

The main types of embedded finance

Embedded finance comes in several distinct flavors, and they're not interchangeable. Embedding a payment is a far lighter lift than standing up full bank accounts. The table below breaks down the main types, what each one means, and a recognizable example of it in the wild.

The practical takeaway is that these types form a ladder of complexity. Embedded payments is where most products start, because accepting money is a well-trodden payment gateway integration. Embedded cards and full banking sit higher up, because issuing a card or holding a customer balance pulls in card-network rules, deposit handling, and a heavier compliance footprint. Knowing which rung you actually need is the first real decision, and it changes everything downstream.

Embedded finance examples across industries

Embedded finance shows up wherever a transaction already happens, which is to say almost everywhere. The pattern is consistent: a company whose core business isn't finance adds a financial service at the point where its users were already about to spend, borrow, or get paid. The examples below span both well-known brands and projects we've built.

On the brand side, the canonical case is commerce. An online checkout that offers buy-now-pay-later turns a "maybe later" into a sale by embedding a lender at the decision point. Ride-hailing apps removed the payment moment entirely; you just get out of the car, and the charge settles in the background. Marketplaces that pay thousands of independent sellers handle payouts, and increasingly debit cards, without sending anyone to a bank. In each one, the financial service disappears into the product experience.

We build the same patterns for clients, and a few illustrate the range well. Chaindoc is our cleanest example of embedded payments fused with identity. It's an e-signature platform where we wired Stripe Connect so that agreements, KYC identity checks, and payment collection all close inside one regulated flow, so the user signs, verifies, and pays without leaving the document. Fese is embedded banking in one product, running accounts, loan applications, and budgeting together rather than as separate apps. C-Bank is a mobile banking app that grew its monthly active users 40% after launch, which is the kind of retention embedding finance well tends to produce. And Glue shows the investing edge of the spectrum, pairing crypto trading with gold as the base asset inside a single platform. The same investing logic extends into tokenized assets, which we cover in our guide to real-world asset tokenization. Different industries, same underlying move.

Embedded finance vs BaaS vs open banking

Embedded finance, banking-as-a-service, and open banking get used interchangeably, but they describe different things, and conflating them leads to bad architecture decisions. The short version: embedded finance is the experience, BaaS is the infrastructure that powers it, and open banking is a data-sharing framework that's adjacent to both. The table separates them cleanly.

The relationship matters in practice. To ship embedded finance, you almost always sit on top of a BaaS provider, because that's what gives you regulated accounts and rails without holding your own charter. Open banking is a different tool. It's about reading data from a user's existing bank (driven in Europe by PSD2, the EU directive that mandated bank APIs and strong customer authentication), not about embedding new accounts. You might use open banking to verify a borrower's income inside an embedded lending flow, then use BaaS to actually issue and service the loan. They stack; they don't compete.

Why embedded finance matters: the business case and market size

Embedded finance matters because it turns a software product into a financial channel, adding a revenue stream, deepening retention, and removing friction from the exact moment a user is ready to transact. For a platform, the appeal is concrete: you earn a margin on payments or lending you used to send elsewhere, you keep users inside your product instead of handing them off, and you smooth the worst drop-off point in any transaction, which is the hand-off to a third party.

The market data backs the shift up. According to Bain & Company, US embedded finance accounted for $2.6 trillion, or roughly 5%, of total US financial transactions in 2021, and Bain projects that figure to exceed $7 trillion (over 10% of all transactions) by 2026. The revenue pool for the platforms and enablers that supply this infrastructure is growing just as fast: Bain put it at $22 billion in 2021 and expects it to more than double to $51 billion by 2026. Other analysts, including McKinsey, track the same broad trend toward finance embedding itself into software.

The platforms winning at embedded finance treat it as an engineering and compliance program, not a feature toggle. The API call to issue a card is the easy hour. The reconciliation, the audit trail, and the question of who owns the risk are the build.

Behind the headline numbers, the growth isn't evenly spread, and that shapes where it's worth building. Bain expects B2B payments embedded-finance revenue to grow from $1.9 billion to $6.7 billion by 2026, and embedded banking and cards revenue to rise from $2 billion to $11 billion over the same window. Those are the fast lanes. If you're deciding where to embed, the money is moving toward business payments and toward products that hold balances and issue cards.

Reference architecture: how an embedded finance product is built

An embedded finance product is built as a layered stack: your platform's app and embedded UI on top, an embedded-finance API and SDK beneath it, a BaaS provider supplying the ledger, identity, card issuing, and rails, and a sponsor bank with the card networks and processors at the base. Each layer has one job and a clear boundary, and the discipline of keeping those boundaries clean is most of what separates a system that passes an audit from one that doesn't.

Read the stack top to bottom. Your platform app and embedded UI is what the user sees: the checkout, the account screen, the card-management view. Below it, the embedded-finance API and SDK layer is your own integration code plus the provider's SDK, the contract your product speaks to the financial world. Below that, the BaaS provider runs the regulated core: the ledger that tracks every balance, KYC and onboarding that verifies identity, card issuing that mints virtual and physical cards, and the connections to payment rails. At the foundation, the sponsor bank, card networks, and processors settle the money for real. The table lays out each layer and what it's responsible for.

What separates a toy from a production system is the cross-cutting work that spans every layer. Reconciliation is non-negotiable: your records and the bank's records must agree to the cent, every day, and a reconciliation job that flags any drift is what keeps that true. Idempotency protects money movement, because every payment call carries a unique key so that a retried request after a network blip moves the money once, not twice. Webhooks are how the asynchronous financial world tells you what happened (a payment cleared, a card was declined, a payout settled), and handling them reliably, including out-of-order and duplicate deliveries, is real engineering. And an append-only audit log, an immutable record of every financial event, is both an operational safety net and a compliance requirement. We build this layer in the default fintech stack we run: Next.js and React Native on the front, Node.js and Python services behind them, PostgreSQL for the system of record with Redis for caching and queues, all on AWS or GCP provisioned through Terraform. The custom software development page covers how we approach builds at this depth.

Build vs buy, and choosing an embedded finance provider

The build-versus-buy line in embedded finance is clear: buy the regulated infrastructure, build the experience and the integration logic that's specific to your product. Almost nobody should build a ledger, a card-issuing platform, or a KYC engine from scratch, and even fewer should pursue their own banking license early. What you build is the embedded UI, the orchestration between your product and the provider, and the business logic: when to offer credit, how to price it, which flows your users actually need.

The harder question is which provider to sit on, because that decision is expensive to reverse once your money flows run through it. A provider that can't issue cards in a market you need, or whose APIs are immature, or whose economics break at your volume, becomes a wall you hit a year in. The checklist below is what we work through during discovery.

• Coverage. Does the provider support the exact products (payments, cards, lending, accounts) and the geographies you need now and plausibly next? Gaps here are the most common cause of a forced migration.
• Licensing. Which sponsor bank is behind the provider, and what does that bank's license actually permit? The license is the real boundary on what you can offer, not the marketing page.
• API and SDK maturity. Are the APIs documented, versioned, and stable, with sandboxes and webhooks that behave? You'll live inside this integration for years.
• Economics. How does pricing scale with volume, and where does the unit economics curve bend? A rate that's fine at launch can erase your margin at scale.
• Exit risk. How locked-in are you, and how hard is it to move providers or bring functions in-house later? Plan the exit before you sign, because you may need it.

This is the same disciplined call you make on any major piece of software, and the trade-offs generalize. We've written the full framework in our guide to build versus buy for software, and the logic there (buy the commodity, build the differentiator) maps almost one-to-one onto the embedded finance stack.

Compliance and risk: KYC, AML, PCI DSS and the sponsor-bank model

Embedded finance is regulated finance wearing a product's clothing, which means the full weight of financial compliance applies even though the user thinks they're just using an app. Money moving means know-your-customer and anti-money-laundering rules apply; cards mean card-network rules and PCI DSS; and a licensed institution sits behind it all carrying the regulatory relationship. The work isn't optional, and pretending otherwise is how embedded finance products get shut off by their own banks.

The practical controls fall into a few buckets. KYC and KYB, which verify the identity of individual users and business customers, gate who can hold an account or get a card, and they run at onboarding and on an ongoing basis. AML and sanctions screening check transactions and parties against watchlists and flag suspicious patterns; this is continuous, not a one-time check. PCI DSS governs how card data is handled, and the smartest architectural move is to keep card numbers out of your systems entirely by using the provider's tokenization and hosted fields, which shrinks your PCI scope dramatically. The standard itself is published by the PCI Security Standards Council, and the current version is PCI DSS v4.0. In Europe, PSD2 adds strong customer authentication requirements on top, and its successor framework is already taking shape.

The sponsor-bank model is where risk ownership gets concrete, and it's worth being precise about who holds what. The sponsor bank holds the license and owns the regulatory relationship with the authorities. The BaaS provider typically operates much of the compliance machinery on the bank's behalf. The platform, meaning you, owns the user experience and is responsible for feeding the controls correctly: collecting the right identity data, surfacing the right disclosures, and integrating screening into your flows. Who is accountable for each specific control is written into the contract, not assumed, and getting that allocation wrong is a common and expensive mistake.

A word on what an engineering partner can and can't do here, because it's frequently muddled. We build to these standards: PCI DSS v4.0, PSD2 strong customer authentication, SOC 2, ISO/IEC 27001, GDPR, and KYC/AML. That means we implement the technical controls and produce the evidence an audit needs. We do not, and cannot, hand a client a certification. Certification is something the client achieves with their own assessors and auditors; our job is to make sure that when those assessors arrive, the controls and the evidence are already in place. Anyone who tells you their agency "is PCI certified" on your behalf is blurring a line that matters.

What embedded finance costs to build

The cost of building embedded finance depends almost entirely on how much of the stack you take on, so the only honest way to talk about it is in scope tiers rather than a single number. Embedding one payment rail through a provider is a fundamentally different undertaking from standing up multiple financial products on a BaaS platform, which is different again from running your own ledger and chasing your own license. Each tier brings more surface area, more compliance weight, and a different team shape. The table frames the three.

The single biggest cost lever is the same one that drives the architecture: how much you own. Sitting on a provider keeps the build small because you're renting the regulated core. The moment you decide to run your own ledger or hold your own license, the cost moves from a software project to an ongoing operation with compliance and reliability staffing attached. The recurring bill here isn't inference; compliance and operations are. The right move for most products is to start at the lightest tier that delivers real value, prove the flow, and only climb when the economics or the strategy genuinely demand it. For the broader mechanics of pricing a build like this, our custom software development cost guide lays out the drivers in detail, and a scoped discovery against the custom software development team is how a real estimate gets made. Platforms that ship this as a SaaS product tend to start at tier one and grow into tier two as volume justifies it.

The future of embedded finance

The future of embedded finance points toward business payments, broader product coverage, and a regulatory framework that's tightening as the model matures. The clearest signal is in the numbers already covered: Bain projects B2B payments embedded-finance revenue to nearly quadruple, from $1.9 billion to $6.7 billion by 2026, which tells you the next wave is less about consumer checkout and more about embedding finance into the software that businesses run on. Vertical SaaS platforms adding payments, working capital, and cards for their business customers are where a lot of that growth lands.

Two other shifts are worth watching. Embedded insurance, meaning coverage offered at the precise moment of a purchase or booking, is still early relative to payments, and it's a natural next surface for any product that already handles a transaction. And on the regulatory side, Europe's move from PSD2 toward PSD3 signals a direction of travel: clearer rules, stronger consumer protection, and more explicit expectations on the firms that embed finance. That's a feature, not a threat. As the rules firm up, the products that built proper controls, reconciliation, and audit trails from the start are the ones that scale cleanly, while the ones that treated compliance as an afterthought spend the next few years retrofitting. Embedded finance is becoming infrastructure, and infrastructure gets held to a higher standard. Building it right the first time is the whole game.