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:

• When paying with a card on a point-of-sale terminal, the BaaS provider must verify the PIN.
  
• When paying online, the end-user will receive a text message to their phone. This has to be used as a second verification factor.
  

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:

• Text messages are not the best solution due to numerous security concerns.
  
• When using a text message for an authentication code, there is still a requirement to provide a secure execution environment.
  
• Text messages can, at best, only provide the possession factor. With 2FA requirements, BaaS providers also need to verify either a knowledge or inherence factor. More so, these two factors have to be collected by the entity doing the SCA. (For more on this, see this post on the basics of SCA.) 

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:

• Unlicensed/unregulated businesses, such as the grocery chain example above.
  
• Licensed/regulated businesses, perhaps with some kind of e-Money license (also known as an EMI). An example is a classic eWallet provider, which also runs a cryptocurrency exchange.

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. 

Outside of who can authenticate the end-user, there are a few other interesting questions that we should be asking:

• Who is required to manage the credentials, such as passwords and secret codes, for end-users? 
• Does it matter what kind of operation the end-user does? What if the operation doesn’t directly involve money? What if it is a cryptocurrency transaction? If SCA always has to be done by the BaaS, it can quickly become complicated to cover every authentication scenario. 
  
• The customer of the BaaS provider typically provides the user interface that the end-user sees. But just how much can a BaaS provider trust an unlicensed business? What if the business tries to sign on fake end-users and do fake transactions? If an end-user becomes a victim of fraud, the licensed BaaS doing SCA would be liable. But if a malicious company tricks the BaaS provider, is the BaaS provider still liable for that fraud? 

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.