Embedded Finance APIs: Turning Apps into Financial Platforms

Why embedded finance APIs are a product decision, not just an integration

Embedded finance APIs let a company that is not a bank put a financial product inside its own interface: a checkout that settles into a balance, a card issued in an app, a working-capital advance offered at the moment an invoice is uploaded, an account with an IBAN or a routing number that customers treat as their main one.

The commercial logic is straightforward — financial services sit close to transaction flow, and revenue attaches to money already moving. Bain & Company and Bain Capital sized US embedded financial services at $2.6 trillion of transaction value in 2021, nearly 5% of all US financial transactions, and projected that it would exceed $7 trillion by 2026, with platform and enabler revenue rising from $22 billion to $51 billion over the same period. BCG's 2024 global fintech report, co-authored with QED Investors, puts worldwide embedded finance revenue above $320 billion by 2030 — roughly $150 billion from small and medium-sized businesses, $120 billion from consumers and $50 billion from enterprise.

Commercial market-research houses publish much smaller totals, because they count a different population of firms, revenues or fees. That spread is itself the lesson. Depending on whether you count transaction value, platform revenue or licensed entities, the same market looks an order of magnitude larger or smaller. Treat the headline numbers as direction of travel, not as planning inputs for your own model.

The four building blocks

Almost every production stack is assembled from four API families, and each one maps to a different permission.

Payments: acceptance, payouts and the ledger

Card acceptance, bank transfers, payouts and balance-holding are usually the first blocks a product adds. You can accept card payments today as an ordinary merchant through an acquirer, or as a payment facilitator where your platform is the merchant of record for sub-merchants. Payouts increasingly run over instant rails; the EU's Instant Payments Regulation obliges banks and payment firms to offer euro credit transfers in seconds, with verification-of-payee duties phased in — we cover the details in EU Instant Payments Regulation: What Banks and Fintechs Must Change.

Interchange is the revenue line most teams underwrite first, and it is capped. In the EU, Regulation (EU) 2015/751 limits interchange on consumer debit card transactions to 0.2% and on consumer credit card transactions to 0.3% of transaction value. In the US, the Federal Reserve's Regulation II caps the base interchange fee for large issuers' regulated debit transactions at 21 cents plus 5 basis points of value, with an extra 1 cent for issuers meeting fraud-prevention standards. Commercial cards in the EU are not subject to those caps, and US credit interchange is not capped in the same way, which is why "we will make money on interchange" produces very different answers in Berlin, London and New York. Our explainer on card interchange fees and the payment orchestration breakdown cover the routing decisions that sit on top.

Account opening and safeguarding: e-money versus deposits

Holding customer balances is where non-financial companies hit the licensing wall. Accepting deposits is a banking activity. The standard workarounds are an e-money institution (EMI) licence or a partner bank under a banking-as-a-service arrangement, where deposits sit on the bank's balance sheet and customers see your brand.

The capital and safeguarding rules differ by licence. Under PSD2, minimum initial capital is €20,000 for money remittance, €50,000 for payment initiation services and €125,000 for other payment services, while e-money institutions face a higher figure under the second E-Money Directive. Customer funds must be safeguarded separately from the firm's own money, and account information providers register rather than seek authorisation. In the US, customer funds sit with an insured depository institution, and pass-through deposit insurance depends on records that identify the underlying beneficiaries — an operational and audit burden rather than a marketing feature.

The EU is restructuring this area. PSD3 merges the payment institution and e-money institution licences into a single regime, repeals the E-Money Directive and requires existing EMIs to re-authorise, alongside new capital thresholds. Non-bank money is also developing its own regulatory track; see our coverage of stablecoin reserve rules in the EU and US for how that alternative is supervised.

Lending: a different licence and a different balance sheet

Lending is not a payment service, so a payments authorisation does not reach it. In the EU, credit and credit intermediation are governed by national banking and consumer-credit rules, with creditworthiness assessment duties for consumer lending. In the US, non-bank lenders typically operate under state lending licences or through a bank partner that originates the loan.

The economics are also different in kind. Interchange does not apply, revenue comes from interest and fees, and you carry funding, credit-loss and servicing costs. Because consumer credit pricing is regulated in most markets, embedded lending rewards disciplined underwriting far more than it rewards distribution alone.

KYC and onboarding: the block that decides your cost per customer

Identity verification, sanctions and politically exposed person screening, and ongoing transaction monitoring are obligations you can outsource operationally but never transfer legally. In the EU, these duties sit in the anti-money-laundering framework, now consolidated in Regulation (EU) 2024/1624 with direct application across member states, layered on top of the payment rules. In the US, they flow from the Bank Secrecy Act, whose customer due diligence rule requires covered institutions to identify the beneficial owners of legal entity customers above an ownership threshold.

This is the block that scales worst, because cost is per customer and quality failures surface later as remediation, fines or de-risking.

Matching product to permission

Categories on our research watchlist

We do not recommend providers, but three categories are worth tracking as the market matures: banking-as-a-service and card-issuing platforms that supply the licence and ledger; identity and screening vendors whose pricing per verification directly drives onboarding economics; and orchestration layers that sit above multiple partners and make switching cheaper. Each carries concentration risk: if your licence, ledger and settlement all run through one partner, your product's uptime and compliance posture are the same as theirs.

Where the rulebook is heading

The EU's payment reforms are the single most important planning input for anyone building in Europe. The European Commission published the PSD3 and PSR proposals in June 2023, the Parliament and Council reached a provisional agreement in November 2025, and the Council adopted its first-reading positions in October 2026, with the Parliament's second reading to follow. Both texts are drafted to apply 21 months after entry into force, with a longer window — around 27 months — for the rules on matching a payee's name to the account identifier and liability for getting that verification wrong. Practical compliance dates therefore fall in 2028 or later.

Two changes matter for product teams. First, liability shifts: a payment service provider that fails to apply adequate fraud-prevention measures can be held liable for customer losses, must check that the payee's name matches the account identifier and refuse mismatched orders, and must refund impersonation fraud in defined cases. Second, card scheme fees must be unbundled and disclosed in a standard format, with advance notice of fee changes and a single public EU repository of scheme rules — which should eventually make cost comparisons between partners less opaque.

Resilience regulation applies too: payment and e-money institutions now sit inside the EU's digital operational resilience regime, so outsourcing an API does not outsource operational risk expectations.

Risks and costs

The costs of embedded finance APIs are rarely a single headline fee. Expect a stack of them: scheme and acquirer fees plus chargebacks on payments; BIN sponsorship and programme management fees on card issuing; safeguarding, reconciliation and audit on balances; funding and credit losses on lending; and per-verification pricing on identity checks.

The risks are structural as much as financial.

• Partner concentration. One provider failing, exiting a market or losing its licence can halt onboarding, settlement or the whole product.
• Revenue ceiling. Capped interchange means payments volume alone rarely funds a platform; the margin usually comes from software fees, FX or lending, each with its own regulation.
• Fraud and liability. Under the incoming EU rules, weak fraud controls translate into refund obligations and supervisory attention, not just losses.
• Credit and liquidity risk. Lending embeds your balance sheet into a third party's customer journey.
• Customer-harm and conduct risk. Selling a regulated product inside a non-financial app invites complaints about disclosure, pricing and suitability.
• Operational and data risk. Outsourced onboarding concentrates personal data with vendors and creates a single point of failure.
• Regulatory divergence. Rules labelled EU or US do not travel: a licence, a disclosure or a fee cap in one jurisdiction can be absent or stricter in the next.

Bottom line

Embedded finance APIs are a licence-and-permission exercise wrapped in a developer experience. The integration is usually the easy part. Before writing code, map each feature to the permission it requires, work out which interchange cap or fee disclosure applies in your jurisdiction, and price the safeguarding, screening and fraud obligations that come with it. Teams that do that mapping first tend to ship slower and stay live longer.