Banking as a Service (BaaS) refers to the services and tools that allow financial institutions to adapt to the current digital shift by offering their customers an omnichannel experience. BaaS providers are the ones that build the web and mobile applications for these institutions so that customers may access their accounts digitally. But has this environment changed since the release of PSD2? Let’s take a look.
In my previous post, I wrote about some of the major trends in the payment market popping up over the past year. But one trend I didn’t mention - one that influences the entire payment market - is the growth of banking-as-a-service (BaaS) providers.
A traditional BaaS provider makes it simple to integrate banking services into non-licensed (or unregulated) businesses, where the non-licensed business doesn’t directly touch the customer’s money. Take a big grocery store chain as an example, providing debit cards to their customers incentivised by extra discounts. BaaS becomes a practical solution because it is impractical for most grocery store chains to become regulated payment service providers themselves, mainly because of all the required compliance regulations.
BaaS is also referred to as ‘white-label banking’ because the banking services are delivered through the branded product of the non-bank. In this model, the BaaS provider must be in charge of both ‘know-your-business’ and ‘know-your-customer (KYC)’ procedures when onboarding a new end-user for banking services.
When accessing funds, the BaaS provider also has the responsibility of verifying the identity of the end-user. Typically this identification has been made in two ways:
In both of these scenarios, the BaaS provider can either provide an API to onboard the end-users or an API so the end-users can do basic banking from the website of the unlicensed business. Providing an API, and leaving the front-end to the customer, has been the typical way for BaaS providers to operate.
As of 2021, in the wake of the Second Payment Services Directive, the customer authentication models above have become slightly problematic. This is because:
As we see it, the solution that best combines security, compliance, and user-friendliness is when the BaaS provider requires their customers (e.g., the grocery store chain) to do SCA through an app on their smartphone. This solution ensures that both the ‘know-your-customer’ and the ‘end-user authentication’ can be done securely.
Additionally, the BaaS provider can choose to provide a software development kit (SDK) that enables Strong Customer Authentication in the customer’s app. They can also offer a separate app to be used just for authenticating the end-user. This works nicely with the grocery store chain example mentioned above. That is, as long as most of the end-users have smartphones.
Unfortunately, the situation becomes a bit more complicated when we dive deeper into the types of customers BaaS providers traditionally work with. There are two categories:
For an unlicensed business, it is pretty clear that the BaaS provider must take care of everything. But is this also the case for a licensed business?
To answer this question, we ask ourselves two other crucial questions: If a licensed e-Money provider onboards the end-user, is the BaaS provider required to do their own onboarding, or can they trust the e-Money provider? Similarly, is it possible for the licensed business to do SCA if a BaaS onboarded the end-user?
From our perspective, the answer is no, as there must be a robust chain of trust between the end user's identity (established during the onboarding process) and the identity that is verified through strong customer authentication. However, we admit that this is something we can be wrong about, depending on the circumstances.
Unlock updates, insights, and exclusive content delivered to you.
Outside of who can authenticate the end-user, there are a few other interesting questions that we should be asking:
The final question comes down to who “owns” the customer in a BaaS scenario. Suppose the BaaS provider is required to do the ‘know-your-customer’ and the SCA on the end-user in every authentication scenario. In that case, the BaaS customer becomes dependent on the authentication service provided by the BaaS. If the end-user, for some reason, can’t authenticate, they also can’t use the services.
Ultimately, as the fintech industry continues to evolve and digitalise, we do expect BaaS to eventually find its footing. But until that time comes, it remains a complex topic stuck between the pre and post PSD2 environments.
If you do find this topic interesting and want to further the discussion, please reach out to us - we may not have all the answers to legal questions, but we can certainly help provide technical solutions for some of these challenges.