Okay LogoOkay Logo
Go back to Okay blog

Back to Basics: Embedded Finance and BaaS

First published: 04/05/2022

updated: 21/10/2022


Embedded finance allows businesses to utilise the benefits of financial products and services without actually needing a banking license. Over time, this has changed the landscape of what businesses can do, how they are innovating, and the ‘power monopoly’ of banks. This is why embedded finance and its close companion Banking-as-a-Service each have enormous roles in the financial ecosystem. Here’s all you need to know.

Embedded Finance vs Banking-as-a-Service

Embedded finance is defined as the seamless integration of 3rd party financial products and services into a receiving company offering, while the receiving company retains complete control over the offering and customer experience. Such financial products and services include digital wallets, payments, money transfers, remittances, and debit/credit cards. In other words, processes that manage money. (Vopy)

Together, embedded finance and BaaS are tied to the digital marketplace and the efforts to simplify and streamline financial services for consumers and businesses alike. While they are nearly one and the same, the slight difference is that BaaS is necessary to deliver embedded finance. If this were the proverbial chicken vs egg question, BaaS would be the chicken and embedded finance the egg. Here is another way to look at it:

Embedded finance connects a non-financial service provider (like Starbucks) with a financial institution (your bank). In this example, you don’t need to use cash or card to pay for your morning coffee. Instead, you hit the pay button in the Starbucks app at checkout and walk out the door.* However, the Starbucks app that makes this transaction is BaaS at work, as it gives you access to standard banking features through APIs. In other words, embedded finance centres on the integrated access to financial services and solutions, while BaaS centres on the technological foundation that banks rely on to deliver those financial services and solutions. 

*Note that some BaaS providers offer non-financial service provider customers with virtual cards (e.g. MasterCard). This is so transactions can be done ‘behind-the-scenes’ as card payments from a “wallet” that the end-user transfers money into. Other BaaS providers use open banking as the payment method, where the end-user has registered their bank account in the app, so payments are taken directly from the account.

Why is Banking-as-a-Service Important?

BaaS providers help financial institutions adapt to the current digital shift by offering their customers an omnichannel experience. They do so by building web and mobile applications for customers to access their accounts digitally. In this way, BaaS providers make it simple to integrate banking services into non-licensed (or unregulated) businesses, so the non-licensed business doesn’t have to touch the customer’s money directly. 

A simple and typical example is a big grocery store chain that offers debit cards to their customers through the incentive of extra discounts. BaaS is a beneficial solution because it is impractical for the grocery store chain to become a regulated payment service provider, mainly because of mandatory compliance regulations.

Banking-as-a-Service Before PSD2

BaaS is also known as ‘white-label banking’ because the services are delivered through the branded product of the non-bank. However, the BaaS provider must still be in charge of ‘know-your-business’ and ‘know-your-customer (KYC)’ procedures when onboarding a new end-user for banking services. Verifying the end-user’s identity has traditionally been made by verifying a PIN when paying by card at a point-of-sale terminal or receiving a text message to their phone (OTP by SMS) when paying online.

In both scenarios, the BaaS provider provides an API to either onboard the end-user or so that the end-user can do basic banking from the website of the unlicensed business. Providing an API and leaving the front-end to the customer was the typical way for BaaS providers to operate before PDS2 came to be.

Banking-as-a-service After PSD2

After PSD2, the originally-accepted customer authentication methods became slightly problematic. First off, text messages were seen as highly risky as they give rise to numerous security concerns. Even if this was not the case, PSD2 laid out a new requirement to provide a secure execution environment, which OTP by SMS does not fulfil.

Additionally, after PSD2 outlined new 2FA requirements, text messages could only provide the possession factor. That means BaaS providers must also now verify either a knowledge or inherence factor, collected by the entity doing the SCA.

Something to keep in mind: the grocery store chain example represents the unlicensed/unregulated business category of BaaS customers. But there is another category of customers BaaS providers typically work with called licensed/regulated businesses. For the unlicensed business, the BaaS provider takes care of everything. But is this also the case for a licensed business? The answer to this question is a bit complex, but if you are interested, we expand on it in an earlier post dedicated to the 2021 BaaS Dilemma.

Looking Ahead

As the fintech industry continues to evolve and digitalise, BaaS and embedded finance undoubtedly have an essential role to play, especially since so many countries are introducing open banking regulations. Moreover, as the world moves towards this open, omnichannel infrastructure that supports shared data, consumers will have new expectations on how they make their payments. 

Just look at the UK, where new revenue potential generated through open banking SMEs and retail customer propositions came to £500 million ($700 million) in 2018, and is expected to reach £1.9 billion ($2 billion) by 2024. (Insider Intelligence). Even if BaaS providers are still figuring out the new landscape between the pre and post PSD2 world, the rise of open banking and digital payments has certainly secured them a place in the fintech world for many years to come.


This is the final post of a four-part series reviewing some of the basics of SCA. The first post covers the origins of PSD2. The second covers the origins of SCA, and the third covers digital fraud.

Follow us on LinkedIn