Embedded Finance: How It Works and How to Build It

Embedded finance is financial functionality delivered inside a product that isn't a bank: the checkout that offers a loan, the software that pays contractors, the marketplace that issues cards to its sellers.

The companies that make this possible operate at different layers of one stack. Some hold a banking charter. Some are software sitting in front of a bank. Some do one narrow job, like verifying an identity or processing a card transaction. They are not alternatives to each other, and signing with one does not complete your stack.

This guide maps the layers, names the companies working at each one, and covers what you're buying when you sign.

What is embedded finance?

Embedded finance is the delivery of a financial product inside a non-financial experience, by a company that is not itself a licensed financial institution.

The financial product is the same one a bank would offer: an account, a card, a loan, a payment, a bank, or an insurance broker. What changes is where the customer encounters it. Instead of going to a bank, the customer meets the product at the moment they need it, inside software they already use.

Three parties are involved in almost every case:

• The distributor. The company whose product the customer is using. This is probably you.

• The enabler. The infrastructure company providing APIs, program management, and operational tooling.

• The license holder. The chartered bank, licensed lender, or insurance producer that legally provides the product and carries the regulatory obligation.

The layers below are how those three roles get filled in practice. Somewhere in your stack there is a license holder, and it is not you unless you went and got a charter. Working out who that entity is, and what they can stop you from doing, is the most useful thing to establish early.

Embedded finance vs banking as a service

Embedded finance is the outcome: a financial product delivered inside a non-financial experience. It's the category.

Banking as a service (BaaS) is one way to deliver it: a licensed bank rents out its charter and balance sheet through an API so a non-bank can offer accounts, cards, or payments. It's a supply model that sits underneath some embedded finance products.

A buy-now-pay-later button at checkout is embedded finance with no BaaS involved. A payroll platform holding employer funds in FBO accounts is embedded finance built on BaaS. Which one you're building determines which half of this map matters to you.

Embedded finance examples and use cases

The pattern repeats across industries. These are the shapes it takes most often:

• Embedded payments. Accepting or sending money inside a software product. A restaurant point-of-sale system that processes card payments, or a freelance marketplace that pays out to contractors.

• Embedded banking. Accounts and cards issued to a platform's users. A trucking software company giving drivers fuel cards, or a vertical SaaS product offering its customers a business checking account.

• Embedded lending. Credit offered at the point of need. A marketplace offering working capital to its sellers based on their sales history, or a home services platform financing a customer's repair.

• Embedded insurance. Coverage sold alongside a purchase. Auto insurance presented when buying a car, coverage options built into a dealership’s financing process, or insurance offered inside a car-buying or vehicle-management app.

• Embedded payroll. Payroll run through software the business already uses. A restaurant management platform paying staff without the owner leaving the app.

• Embedded investing. Brokerage and savings inside a non-brokerage product, like a banking app offering fractional shares.

The commercial logic is consistent across all of them. The distributor already owns the customer relationship and the data, so it can offer a financial product at a moment a bank never sees, and it earns revenue on a product it didn't have to build a license for.

The embedded finance stack at a glance

Sponsor banks for embedded finance

A sponsor bank holds the charter, holds the deposits, and carries the regulatory relationship. If your product touches customer funds, one of these is in your stack whether you speak to them weekly or never.

• Column. A nationally chartered bank that also built its own API, so no middleware layer sits between you and the charter. Best for: teams that want a direct bank relationship and an engineering-led counterparty. Watch out for: they're selective about who they onboard and they say no often.

• Lead Bank. A Kansas City bank rebuilt around fintech partnership with its own technology stack. Best for: programs that want a bank with modern infrastructure rather than a bank plus a vendor. Watch out for: capacity, since demand for credible sponsor banks outstrips supply.

• Cross River Bank. One of the longest-running sponsor banks, heavily used in lending and payments. Best for: lending programs and higher-volume payment flows. Watch out for: large partners get priority, so early-stage programs wait.

• Coastal Community Bank, Thread Bank, Sutton Bank, Celtic Bank, Pathward, WebBank. The working list of banks running meaningful fintech partnership programs. Best for: finding a fit when the better-known names pass. Watch out for: several banks in this category have been under regulatory enforcement in the last two years.

The bank layer is where you have the least leverage and the most exposure. Multiple sponsor banks received consent orders through 2024, and regulators have kept pressing community banks on how well they oversee fintech partners, including a further OCC action in 2026. A consent order at your bank can freeze your roadmap for a year regardless of how well your own compliance runs, so ask about enforcement history before you sign.

Banking as a service providers and embedded finance platforms

These companies sit between you and a bank, providing APIs for accounts, cards, and payments plus the tooling to run a program. The category has changed shape significantly since 2024.

• Unit. Account, card, and payment APIs with program management tooling, moving toward putting you in a direct relationship with the bank rather than sitting in the middle of it. Best for: teams that want a full program stack and a fast path to launch. Watch out for: module pricing has been shifting as the category restructures.

• Synctera. A marketplace matching fintechs with sponsor banks, now with direct contracting options. It registered a subsidiary as a money services business with FinCEN in 2026 and acquired a compliance monitoring company. Best for: teams that want help finding a bank with compliance monitoring included. Watch out for: you're still subject to whichever bank you're matched with.

• Treasury Prime. Exited the three-party agreement business in 2024 after regulators objected, and now sells software to banks for managing their own fintech relationships. Best for: situations where the bank is the buyer. Watch out for: the model changed, so older comparisons of this category describe a company that no longer operates that way.

• Increase. Direct API access to ACH, wires, RTP, FedNow, and accounts, built for teams that want the rails without a heavy program layer. Best for: engineering teams comfortable owning more of the stack. Watch out for: less hand-holding than a full program manager.

• Braid, Infinant. Newer entrants positioning as technology for banks rather than as intermediaries. Best for: bank-led programs. Watch out for: shorter track records.

The direction of travel here matters before you buy. Regulators want banks accountable for their fintech partners, so the three-party arrangement where a middleware company sat between bank and fintech has been unwinding. Platforms are repositioning as software the bank uses rather than as your counterparty. In practice, this means more direct contact with your bank and more compliance obligations landing visibly on you.

Card issuing companies

If your product gives customers a card, this layer processes the transactions and manages the program.

• Marqeta. The largest independent issuer processor, used by companies at real scale. Best for: complex programs and high volume. Watch out for: built for scale, so onboarding is heavier than a small program needs.

• Lithic. Developer-focused card issuing with a lighter path to a first card in production. Best for: early-stage teams shipping a card quickly. Watch out for: you still need a bank relationship underneath.

• Highnote. A newer platform covering issuing and acquiring in one place. Best for: products that both issue cards and accept payments. Watch out for: a shorter operating history than the incumbents.

• Galileo, i2c. Long-established processors serving banks and larger programs. Best for: established programs and bank-led issuance. Watch out for: enterprise sales cycles and older integration patterns.

• Stripe Issuing. Card issuing inside the Stripe stack. Best for: teams already running payments on Stripe. Watch out for: concentration, since payments and cards then share one vendor.

Interchange is the revenue model underneath most card programs, and how it gets shared between you, the platform, and the bank is the commercial negotiation that decides whether the program pays for itself. Ask for the split in writing early.

Embedded payments companies

This layer moves money in and out. The distinction that matters is between accepting payments, sending them, and orchestrating the whole flow.

• Stripe, Adyen. Payment acceptance at scale, with adjacent products covering payouts, issuing, and treasury. Best for: collecting money from customers. Watch out for: the breadth is convenient and it concentrates a lot of your product in one relationship.

• Modern Treasury. Payment operations software: initiating payments across rails, tracking their state, and reconciling them against bank activity. Best for: teams moving money over ACH and wires that need reconciliation handled properly. Watch out for: it sits on top of your bank relationship rather than replacing it.

• Moov, Dwolla. ACH and account-to-account payments with lighter integration overhead. Best for: products where bank transfers are the main rail. Watch out for: narrower card support and international coverage.

• Fragment, Formance. Ledger infrastructure for teams that want the double-entry layer as a product rather than as something they build. Best for: complex balance models, multi-party flows, and marketplaces. Watch out for: a newer category, so in-house expertise is thin.

Reconciliation is the piece founders underestimate. Your system's view and your provider's view will drift, and you need an automated daily process comparing them from the start. Our guide to APIs in fintech covers how these integrations behave in production.

Bank data and open banking companies

These connect your product to your customers' existing bank accounts to read balances, verify account ownership, and pull transaction history.

• Plaid. The US default by coverage and developer familiarity. Best for: most products needing account connectivity. Watch out for: pricing scales with usage in ways that surprise teams later.

• MX. Data connectivity with a stronger emphasis on cleaning and enriching the data. Best for: products analyzing transaction data, not just verifying accounts. Watch out for: a heavier sales process than self-serve.

• Finicity, Akoya. Mastercard-owned and bank-consortium-owned respectively, both leaning on direct bank APIs rather than credential-based access. Best for: programs where banks prefer a permissioned connection. Watch out for: narrower institution coverage than Plaid.

Embedded lending companies

These let a non-lender offer credit inside their product, with the capital and licensing handled by someone else.

• Parafin. Capital for marketplaces and platforms to offer financing to the businesses on them. Best for: marketplaces holding transaction data on their sellers. Watch out for: built around platforms with existing merchant volume.

• Wisetack. Consumer financing embedded into service businesses at the point of sale. Best for: home services, healthcare, and similar verticals. Watch out for: narrower than a general-purpose lending API.

• Liberis. Revenue-based finance embedded into platforms, with strong European coverage. Best for: cross-border platform lending. Watch out for: the product shape is revenue-based rather than term loans.

• Affirm, Klarna. Consumer buy-now-pay-later at checkout. Best for: retail and e-commerce. Watch out for: they own the customer relationship at the financing step.

• Amount, Pipe. Lending infrastructure for banks and platforms building their own credit products. Best for: teams that want to own the credit product rather than resell someone else's. Watch out for: you take on more of the regulatory surface, including fair lending obligations.

Embedded payroll companies

Payroll is one of the stickiest embedded products, because once a business runs payroll through your software, it rarely leaves.

• Check. Payroll infrastructure for platforms, handling tax calculation, filing, and payments. Best for: vertical SaaS adding payroll to an existing business customer base. Watch out for: payroll tax filing is unforgiving, so the operational support model matters more than the API.

• Gusto Embedded. Gusto's payroll engine offered to platforms. Best for: teams that want a proven payroll product behind their interface. Watch out for: less flexibility in how the experience is shaped.

• Zeal, Salsa. Newer payroll APIs targeting platforms that want more control over the product. Best for: teams building a differentiated payroll experience. Watch out for: shorter track records in a category where mistakes create tax liabilities.

Embedded insurance companies

The same pattern applied to insurance: a non-insurer offers coverage inside its product.

• Boost. Insurance infrastructure with carrier, capital, and compliance layers behind an API. Best for: teams building an insurance product rather than reselling one. Watch out for: product-specific, so not every line is available.

• Cover Genius. Embedded protection across many countries and product types, used heavily by marketplaces and travel. Best for: international coverage. Watch out for: built around high-volume distribution.

• Sure, bolttech. Distribution and infrastructure for embedding insurance into digital products. Best for: adding coverage to an existing customer base. Watch out for: the carrier relationships determine what you can offer where.

• Credify. Insurance infrastructure that embeds multi-carrier home and auto quotes into partner platforms through a drop-in widget SDK or hosted link. Best for: banks, fintechs, creators, and membership groups that want insurance revenue from their existing customers without getting licensed. Watch out for: Credify holds the policy relationship as agency of record, so you're earning distribution economics rather than building or owning an insurance product.

Embedded investing companies

Brokerage, custody, and market access behind an investing or savings feature.

• Alpaca. Brokerage APIs for equities and crypto, developer-focused. Best for: teams building a trading or investing feature. Watch out for: you inherit securities regulation obligations, which are a different regime from banking.

• DriveWealth. Fractional share infrastructure with strong international distribution. Best for: global consumer investing products. Watch out for: enterprise-oriented onboarding.

• Atomic. Investing and portfolio management embedded into banking and fintech apps. Best for: adding investing to an existing money app. Watch out for: a narrower product range than a full brokerage.

Compliance and identity companies for embedded finance

Every layer above generates a compliance obligation. This layer is how you meet it.

• Alloy. An orchestration layer routing identity decisions across multiple underlying vendors, with a place to review them. Best for: programs that need to tune decisioning without re-integrating. Watch out for: you still pay the underlying vendors.

• Persona, Socure, Sumsub. Identity verification, each with different strengths across document checks, database verification, and international coverage. Best for: onboarding verification. Watch out for: performance varies a lot by geography and customer type.

• Middesk. Business verification, which is a different problem from verifying a person. Best for: anything serving businesses rather than consumers. Watch out for: KYB is slower and more manual than consumer KYC by nature.

• Unit21, Sardine, ComplyAdvantage. Transaction monitoring, fraud detection, and sanctions screening. Best for: the ongoing obligation after onboarding. Watch out for: tuning these is real work, and a noisy system nobody reviews is worse than no system.

We covered this layer in depth in our guide to KYC providers for fintech startups, and the broader obligations in what fintech compliance means.

Embedded finance companies outside the US

The US stack above does not transfer. Different licensing regimes, different rails, and a different set of providers.

• ClearBank. A UK clearing bank with direct access to payment schemes, providing accounts and payments to fintechs. Best for: UK programs wanting a licensed bank counterparty. Watch out for: UK-centric, so multi-region coverage needs additional partners.

• Griffin. A UK bank built as software, holding its own banking licence and offering accounts and safeguarding through an API. Best for: UK teams that want the charter and the API from one company. Watch out for: a young bank with a shorter operating history.

• Swan. European accounts, cards, and payments through an API, operating across multiple EU markets. Best for: EU-wide programs. Watch out for: country-by-country differences persist under one integration.

• Solaris. A long-established German provider that came under BaFin scrutiny over compliance and stepped back from parts of its e-money business, then raised further capital. Best for: established programs in the DACH region. Watch out for: the regulatory history is a live diligence item.

• Modulr. UK and European payment accounts and rails, licensed in multiple jurisdictions. Best for: payments-led programs across the UK and EU. Watch out for: the company has been loss-making, which is worth weighing for a long-term dependency.

• Treezor, Paynetics. European infrastructure providers, Treezor owned by Société Générale. Best for: teams that prefer a bank-owned or compliance-conservative counterparty. Watch out for: less developer-first than the US equivalents.

The European market has consolidated harder than the US. Railsr never reached profitability and was sold through a pre-packaged administration. UniCredit acquired Vodeno, which is a signal that traditional banks are bringing this capability in-house rather than renting it. Weigh provider durability as heavily as feature fit.

What embedded finance costs

Pricing in this category is rarely published, and the structure varies by layer. The components to expect:

• Implementation or setup fees. Common at the bank and platform layers, often five figures, sometimes waived for programs the provider wants.

• Monthly platform minimums. A floor you pay regardless of volume. This is the number that hurts a pre-revenue program, and it's the one to negotiate hardest.

• Per-unit pricing. Per account, per card, per API call, per verification. Individually small and collectively significant at scale.

• Interchange sharing. On card programs, a share of interchange flows back to you. The split is negotiated, and it's the difference between a card program that funds itself and one that doesn't.

• Compliance costs you carry directly. Your own monitoring tooling, your own reviewers, and the operational time spent on cases. Founders routinely leave this out of the model.

The build cost sits on top of all of it. What it costs to build a fintech app covers that side.

How to choose embedded finance companies

Working through the layers in this order saves rework, because each choice constrains the next.

1. Decide what you need to hold. Holding customer funds pulls in a sponsor bank and everything that comes with it. Not holding funds keeps you far lighter. Founders often find they can move the money without ever holding it, and the customer experience is identical.

2. Pick the bank layer before the software layer. The bank sets what you can offer, who you can serve, and how fast you launch. Choosing a platform first and discovering their bank won't take your use case is a common and expensive sequence.

3. Count your vendors honestly. A program with accounts and cards typically ends up with a bank, a platform, a card processor, an identity vendor, a monitoring vendor, and a data provider. Each is a contract, an integration, and a relationship. Fewer is usually better at the start.

4. Ask about exit before you sign. What happens to your customers, your balances, and your data if you leave or if the provider fails. The companies that lived through this category's failures answer it directly.

5. Check who the provider's other customers look like. A platform whose book is full of companies at your stage will serve you better than one where you're the smallest account.

6. Model the compliance headcount. Every program needs someone reviewing alerts and handling cases. Providers will not tell you this during the sales process, and it's a real line in your budget.

Where TechSuite fits

TechSuite is a fintech software development firm, and we build the systems that sit on top of them: the ledger, the reconciliation, the integration layer, and the product itself.

Most of the work is integration. Plaid, Stripe, BaaS platforms, KYC and AML vendors, and the connections between them, plus the internal ledger that has to agree with all of them. Our team is led by founder and CEO Sam Corso, with more than ten years of fintech engineering experience and 30+ clients shipped across digital banking, lending, personal finance, insurtech, blockchain and crypto, and capital markets.

If you're deciding between providers and want an engineering read on which fits what you're building, book a call. If you've already built something and want to know whether it holds up once real money runs through it, that's what our audit engagement covers.

Embedded finance FAQs

What is the difference between embedded finance and banking as a service? Embedded finance is the category: financial products delivered inside a non-financial experience. Banking as a service is one delivery model within it, where a licensed bank provides accounts, cards, or payments through an API to a non-bank. All BaaS is embedded finance. Not all embedded finance uses BaaS.

Do I need a sponsor bank? Only if you're holding customer funds or issuing accounts and cards. Products that route payments without taking custody can often avoid the bank layer entirely, which removes significant cost and time.

How many vendors does an embedded finance product need? A program with accounts and cards typically involves a sponsor bank, a program platform, a card processor, an identity vendor, and a transaction monitoring vendor. Some platforms bundle several, which reduces your contract count and increases your concentration risk.

What happens if my embedded finance provider fails? It depends on where the funds sit and how well the records are kept. This is the lesson of Synapse: deposit insurance protects against bank failure, not against a middleware company whose ledgers don't reconcile. Ask about fund segregation and reconciliation cadence before you sign.

Is embedded finance regulated? The licensed entity in your stack is regulated, and its obligations flow to you contractually. You'll carry requirements around identity verification, transaction monitoring, and reporting even though you aren't the license holder.

How long does it take to launch an embedded finance product? Bank diligence and program approval commonly run one to three months before engineering finishes, and that timeline is outside your control. Teams that pick their bank early launch faster than teams that build first and shop for a bank later.

Which embedded finance companies work outside the US? ClearBank, Griffin, Swan, Solaris, Modulr, Treezor, and Paynetics cover the UK and EU. The US providers in this guide generally do not transfer, since licensing and payment rails are country-specific.

Where to start

Write down the financial action your product needs to take, in one sentence, from the customer's point of view. Then work out whether that action requires holding money. That single answer tells you whether you're shopping across this entire map or one corner of it, and it's the question most founders skip past on the way to comparing platform pricing.

From there, the bank layer comes first, and everything else follows from it.

Related reading

• How to Choose a Fintech Software Development Company

• 10 Best KYC Providers for Fintech Startups

• What Is Fintech Compliance?

• APIs in Fintech

• How Much Does It Cost to Build a Fintech App?