Store credit has existed since the 1800s. General Motors started offering auto financing in 1919. Retailers have been bundling financial products into non-financial buying experiences for well over a century, long before anyone coined the term "embedded finance" and long before a single open banking API existed anywhere.
That history matters because it exposes a conflation that shows up constantly in fintech writing: treating open banking and embedded finance as synonyms, or assuming one is a subset of the other. They're related, but they describe different things. Getting this wrong produces bad product decisions and worse policy arguments.
What is open banking?
Open banking is a regulatory and infrastructure construct. Its core function is giving customers the ability to share their financial data with third parties through standardized APIs, with a consent mechanism and, in most markets, a regulatory mandate behind it.
The major frameworks in force today:
The UK's open banking regime, launched by the Competition and Markets Authority in 2018, is the most cited model. Open Banking Limited reported 13.3 million active open banking users in the UK as of March 2025, up 40% year on year, with 31 million payments processed that month alone. Variable recurring payments (VRPs) now account for 13% of total open banking transactions, enabling consented, programmable account debits without card network involvement. The EU's PSD2 required banks across the European Economic Area to open read-access APIs by 2019. Its successor, PSD3, is currently in legislative process and is expected to tighten API quality standards and strengthen consumer protections around consent. Australia launched the Consumer Data Right (CDR) in 2020, starting with banking and expanding toward energy and telecommunications. Brazil's open finance framework, built by Banco Central do Brasil, went further than most by mandating not just data sharing but payment initiation from launch in 2021. India's Account Aggregator network gives regulated data intermediaries a consent-based bridge between financial institutions and third-party apps, with participation from major public and private sector banks. The United States moved later than most: the CFPB finalized its open banking rule under Section 1033 of Dodd-Frank in 2024, requiring depository institutions to make customer account data available to authorized third parties upon request.
What all these frameworks share: they create a right for customers to share their financial data. They do not create embedded financial products. They create the data layer that other things can build on.
The Open Banking Tracker monitors 54,000+ financial institutions across 30+ jurisdictions to document exactly this layer: which markets have live frameworks, which institutions are compliant, and where the gaps are. It is a map of data access infrastructure, not a map of every fintech product that has ever been embedded in a non-financial platform.
What is embedded finance?
Embedded finance is the practice of placing financial products inside non-financial contexts. A Shopify merchant receiving a working capital advance based on GMV. A gig economy app paying workers at the end of every shift instead of every two weeks. The common pattern is that the customer encounters a financial product without leaving the platform they're already using, and without a traditional banking relationship in the foreground.
Embedded finance does not require open banking. The GM example from 1919 ran through a captive finance subsidiary with no API layer. Most embedded lending today uses bank partnerships, Banking-as-a-Service (BaaS) infrastructure, and proprietary platform data rather than open banking rails. Affirm underwrites every transaction using proprietary models trained on its own transaction and behavioral data, not open banking feeds. Shopify Capital uses merchant GMV from within Shopify's own platform. Neither requires a customer to have consented to share their bank data.
BaaS infrastructure (providers like Griffin in the UK or Treasury Prime in the US) is categorically different from open banking. BaaS gives non-banks access to account infrastructure, payment rails, and in some cases regulatory licensing. Open banking gives authorized third parties access to existing customer data at established banks. Both are infrastructure, but they solve different problems and are governed by entirely separate regulatory regimes.
Open banking vs embedded finance: the key differences
| Open banking | Embedded finance | |
|---|---|---|
| What it is | Regulated data access layer | Distribution model for financial products |
| Core mechanism | API access to customer bank data (with consent) | Financial products embedded in non-financial platforms |
| Requires a regulatory mandate? | Yes, in most active markets | No |
| Depends on the other? | No | No |
| Typical use case | Account verification, credit underwriting, direct bank payments | Lending at checkout, instant pay, in-app insurance |
| Revenue model | Data-driven services, API fees, direct payment processing | Transaction fees, interest, insurance premiums |
The table above is deliberately simple. In practice, the two models overlap in places, which is where most of the confusion comes from.
How open banking and embedded finance work together
The relationship is real, just more specific than the conflation suggests. Open banking data can improve embedded finance products in ways that proprietary platform data cannot always replicate.
Account verification via open banking APIs reduces fraud and speeds up onboarding for embedded financial accounts. A SME accounting tool offering embedded lending can use open banking transaction history to build a richer credit picture than bureau data alone. In Brazil, where the open finance framework covers credit, insurance, and investments alongside banking, embedded products have access to a broader financial picture than most markets allow.
The UK is the clearest case where open banking has expanded what embedded finance can do. VRP in particular is starting to enable embedded payment patterns that bypass card networks entirely, with lower fees and programmable consent flows. That is a material change for platforms that process high-frequency, low-value transactions.
But these are use cases for open banking data within embedded finance contexts. A market map that puts every embedded finance company under the open banking umbrella will include a lot of companies that have nothing to do with API-based data access from regulated institutions.
We're currently running the State of Embedded Finance survey, tracking how companies across fintech, vertical SaaS, and banking are building with embedded financial products in practice: which infrastructure they use, where open banking data fits in, and where it doesn't. The survey takes under five minutes.
Why the distinction matters
The conflation does real damage in specific ways.
Policy debates around open banking often get contaminated by embedded finance hype. When advocates argue for stronger open banking mandates, they sometimes point to embedded finance outcomes as justification. But most of those outcomes (buy now pay later, embedded lending) do not depend on open banking existing. They depend on BaaS infrastructure and commercial data arrangements. Pointing to Klarna to justify PSD2 expansion is a category error.
For builders, the confusion leads to overestimating what open banking data actually gives you. If you're building an embedded lending product and assume open banking will solve your data problem, you'll find that transaction data from bank feeds is often less clean and less predictive than platform-native data. Consent drop-off is real. Coverage is patchy in most markets outside the UK.
For analysts and trackers, the distinction is definitional. A country where a fintech company offers an embedded payments product through a bank partnership is not automatically an open banking market. The product may exist. The regulatory framework may not.
The data layer and the distribution layer
A cleaner way to think about it: open banking is part of the data layer, and embedded finance is a distribution model. Data layers and distribution models interact but are governed by different forces. Open banking is shaped by regulators, bank compliance timelines, and API standardization bodies. Embedded finance is shaped by distribution economics and the willingness of platform operators to take on regulated activity.
The interesting question for the next few years is whether jurisdictions building out open finance frameworks (expanding beyond banking into insurance and pensions) will produce embedded finance use cases that couldn't exist without them. A consolidated open finance data picture could support personalized embedded products that platform data alone can't replicate. That depends on API coverage, consent flow design, and whether regulators push for payment initiation alongside read access.
That's the thing worth watching. The terminology is secondary.
