B2B Embedded Finance in 2026: Unit Economics and Risk

B2B embedded finance puts payments, lending, accounts, cards or insurance inside software that a business already uses. A construction platform might connect an approved invoice to payment or financing; a restaurant system might surface a working-capital offer. The useful question in 2026 is not whether the product is "embedded," but which party earns the contribution, carries the regulated obligations and absorbs the losses.

That distinction matters more than a market-size forecast. A payments feature can create revenue while destroying value after partner fees, fraud, disputes, compliance, servicing and engineering are included. The model below keeps those components visible.

What is B2B embedded finance?

Embedded finance describes financial services delivered at the point of need, inside a non-financial product, rather than through a separate trip to a bank or a standalone fintech app. The "B2B" qualifier matters because the economics, the customers, and the risks differ sharply from the consumer version most people picture.

Consumer embedded finance is the buy-now-pay-later button at checkout. B2B embedded finance is the vertical software platform for dentists, freight brokers, law firms, or gyms that adds a business bank account, a corporate card, invoice financing, or payouts to the workflow its customers are already living in. The financial product is not the destination. It is a feature of the thing the business came to do anyway.

In 2019 the Andreessen Horowitz partner Angela Strange gave a talk with a title since quoted to the point of cliché: "Every company will be a fintech company."^[1] The useful part of the argument was that financial infrastructure would become easier for software businesses to integrate through APIs. What the slogan left unresolved is how regulatory responsibility, customer funds, losses and unit economics are allocated after the integration.

Why B2B can support a different embedded-finance case

The consumer side gets the headlines; the business side can support stronger unit economics when payment volume, balances and loss-adjusted credit contribution justify the extra operating burden. Three structural reasons explain why it is worth testing.

First, transaction values can be larger and tied to recurring business workflows. That can create more addressable payment volume and more observable receivables per customer than a low-frequency consumer feature, but the advantage must be measured for the actual vertical and customer mix.

Second, finance can deepen an existing workflow integration. A business that runs scheduling, invoicing or payroll through one platform may value payments or financing in the same interface. Whether that actually lowers churn or raises account contribution should be measured by cohort rather than assumed from product breadth.

Third, workflow data may be more current than a periodic credit file. A platform that sees a contractor's job pipeline, payment history and customer concentration can add cash-flow signals to an underwriting decision. Whether those signals improve loss-adjusted returns must be established with controlled portfolio data, appropriate permissions and the same validation and adverse-action discipline described in our AI underwriting framework.

There is no defensible universal revenue multiple for embedded finance. Contribution depends on addressable payment volume, balances, net yield share, funding costs, credit losses and operating cost. The original scenario model below makes those assumptions explicit instead of borrowing a headline market multiple.

Methodology: CloudFintech models payments contribution as volume × net margin; balance contribution as average balance × net yield share; and credit contribution as average book × (gross yield − funding cost − credit losses − operating cost). The scenarios are illustrative, not observed performance, valuation or forecast.

Primary sources: Federal Reserve Regulation II FAQs; CFPB Synapse enforcement record; Federal Reserve Evolve enforcement action; European Commission PSD2 legislation page

Download underlying dataset

The four revenue streams

When a software platform "embeds finance," it is usually reaching for one or more of four distinct income lines. They are not equally easy, and they are not equally safe.

Payment and interchange margin. A platform may receive a contracted share of payment economics after processor, scheme, partner and programme costs. Card issuing is a common entry product, but the net margin depends on geography, card type, network rules, fraud, rewards and the regulated partner agreement.

Lending contribution. Working capital, invoice financing or revolving credit can produce a spread between customer yield and the combined cost of funding, losses, fraud, servicing and operations. It is profitable only when that loss-adjusted spread remains positive through the cycle and after any first-loss or repurchase obligation.

Balance contribution. A platform may receive a contractual share of the economics on customer balances; the legal form and language depend on whether the product is a bank deposit, e-money or another arrangement. This can avoid direct borrower-default risk for the platform, but it still carries safeguarding or deposit-record, liquidity, counterparty, operational and regulatory obligations.

Software uplift. A useful financial workflow might support retention, adoption or pricing of the core product. That effect should be measured through comparable cohorts and net revenue retention; it should not be counted merely because the feature exists.

A platform that relies on interchange alone is exposed to thin margins, scheme economics and regulation. Lending and balance products can add contribution, but only after funding, losses, safeguarding, compliance and operating cost are included.

The infrastructure layer: who provides the rails

Most software platforms do not hold the bank or e-money authorisation that supports the financial product. They rely on a regulated bank, electronic-money institution or other licensed provider, sometimes through a Banking-as-a-Service middleware layer. The contract and ledger design determine which party holds funds, performs regulated activities, owns reconciliation and answers to the end customer; an API does not transfer those responsibilities by itself.

In a US sponsor-bank model, a chartered institution may hold customer deposits while the software and middleware layers provide the interface and ledger services. Not every embedded account is a bank deposit, however: European e-money models use safeguarding rather than deposit insurance, and even US pass-through insurance depends on the legal and record-keeping requirements being satisfied. Product labels should therefore follow the underlying regulated structure.

Under Regulation II, an issuer holding the debited account is exempt from the interchange-fee standards when its consolidated assets were below $10 billion at the relevant prior year-end^[2]. That threshold can affect sponsor-bank card economics, but it does not guarantee a particular interchange rate or platform revenue share. Network terms, programme costs and the partner contract still determine the result.

The Synapse warning: what the 2024 collapse taught the industry

For most of the 2010s the BaaS story was told as pure upside. Then Synapse happened, and the industry got a hard lesson in where the risk had been hiding all along.

Synapse provided middleware between non-bank fintech platforms and partner banks. It filed for Chapter 11 protection in April 2024. In a later proceeding, the Consumer Financial Protection Bureau said^[3] Synapse had failed to maintain adequate records of where consumer funds were held and to keep those records aligned with partner-bank records. The Bureau reported a $60–90 million shortfall between the banks' holdings and Synapse's records, with consumers losing access for weeks or months. Deposit insurance protects against an insured bank failure; it does not cure a non-bank ledger and reconciliation failure.

The episode forced a distinction the marketing had blurred. A software platform can present a bank-like account without being the regulated bank, but the programme still needs an authoritative, reconciled record of each customer's entitlement and the location of the corresponding funds. Contracts, controls and audit evidence should identify exactly who owns that record and how discrepancies are resolved.

The Federal Reserve's June 2024 enforcement action against Evolve^[4] cited deficiencies in anti-money-laundering, risk-management and consumer-compliance programmes and required stronger oversight, monitoring and recordkeeping for fintech partnerships. The action was independent of Synapse's bankruptcy, but it illustrates why partner governance is a first-order design constraint and why a serious RegTech stack must produce evidence across the whole chain.

The European picture

Europe starts from a different regulatory structure. The EU's Interchange Fee Regulation^[5] caps consumer debit and credit interchange without the US small-issuer threshold described above. That changes the available card margin, but it does not by itself determine whether payments, accounts or lending is the best product for a particular vertical.

The licensing route differs too. European programmes may operate through an electronic-money institution under the e-money and PSD2^[6] frameworks, or through a bank or payment institution, depending on the product and jurisdiction. An account-like interface can therefore represent e-money rather than an insured bank deposit.

That distinction carries real consequences. E-money is not covered by deposit-guarantee schemes in the same way as a bank deposit; authorised institutions must safeguard relevant customer funds under the applicable rules. Safeguarding and deposit insurance are different protections, so the customer disclosure, reconciliation design and insolvency analysis must match the actual product.

The EU payment-services package remains time-sensitive. The Council record^[7] shows that the final compromise text for PSD3 and the accompanying Payment Services Regulation was confirmed with a view to agreement in April 2026. The package addresses payment-service and electronic-money rules, but firms should check the final Official Journal texts and application dates before treating a proposed requirement as operative. The UK follows a separate domestic framework.

The design implication is the same in both regions: the regulated entity, authoritative ledger, safeguarding or deposit structure and allocation of customer responsibility must be selected before the interface and revenue share are optimised.

Where contribution may accrue in 2026

Two models are worth separating rather than treating as guaranteed winners.

The first is a vertical-software platform with deep workflow use and customers that genuinely need capital or cash-management tools. Shopify's own product documentation^[8], for example, shows Capital, Balance and Credit inside its merchant finance interface while identifying the banks and payments providers behind those products. That integration can create useful distribution and underwriting signals; it does not prove that a platform will price credit risk better than a generalist lender.

The second is lending delivered through a specialist provider. The platform may supply distribution and permissioned workflow data while the provider supplies capital, underwriting and servicing, but the allocation varies by contract and jurisdiction. Economics should be evaluated after funding cost, losses, fraud, servicing, compliance and any first-loss or repurchase obligation, rather than from the headline customer rate.

Credit and balance products can contribute more than interchange in some scenarios, but their economics are also more sensitive to funding, losses and regulatory structure. Interchange may be an entry product; it should not be treated as proof that the broader model works. New settlement options such as stablecoins should be assessed with the same end-to-end corridor test rather than assumed to lower cost.

What this means for incumbent banks

The incumbent's instinct is to read all this as disintermediation: software platforms stepping between the bank and its customer, capturing the relationship and the data, leaving the bank as a commoditised balance sheet for hire. That reading is half right.

The visible customer relationship may sit with the software platform even when a bank or e-money institution provides the regulated product. That can reduce the regulated partner's brand visibility, but the partner still retains the responsibilities allocated by law and contract. Clear customer disclosure matters precisely because the interface and regulated entity may differ.

A partner bank can make programme governance a specialist capability: customer-fund records, compliance oversight, change approval, audit rights and orderly exit all require durable controls. The business case must include that control cost rather than treating sponsorship as a cheap source of deposits. The economics of the underlying systems also matter; any modernisation dependency should be evaluated alongside the cloud-core migration plan.

The practical lesson is narrower than the slogan: financial components can be integrated, but regulatory accountability, ledger integrity and losses cannot be abstracted away. A platform should proceed only when it can show positive contribution under stressed assumptions and name the owner of every material control.

Sources & methodology. Regulatory and incident statements are grounded in Federal Reserve Regulation II material, the CFPB's Synapse enforcement record, the European Commission's PSD2 material and the European Parliament's PSD3/PSR legislative update. The unit-economics model is original, illustrative CloudFintech analysis. It is not observed platform performance, a market benchmark, valuation or forecast; replace every assumption with product-, contract- and cohort-specific evidence. CloudFintech is an AI-assisted publication edited under the standards set out on our editorial standards page.