Given the relative youth of Banking-as-a-Service (BaaS), there remain fundamental questions around how banks should approach these arrangements in comparison to what may now be considered traditional fintech/banking partnerships.

Speaking on a recent teleconference, legal representatives from Mayer Brown LLP worked through a handful of factors that arise for financial institutions and their tech partners in negotiating, drafting, and working within the BaaS space.

From identifying the key characteristics of a typical BaaS model, to understanding nuance in allocating responsibility to certain parties, to understanding the value of data and customer ownership, the representatives raised fundamental considerations that every bank should address when embarking on crafting a BaaS agreement.

What does a BaaS model look like?

Defining BaaS, partner in Mayer Brown’s financial services regulatory and enforcement group, David L. Beam, first notes that the concept generally refers to a variation on a traditional bank/fintech partner model. In this model, a fintech company will typically have a technology platform to provide certain financial services such as loans or transaction accounts and will have technology that allows them to provide it in an innovative way.

However, the fintech company often does not have the licenses or other approvals required to offer the financial service component of its platform, either alone or to the account directly.

Even if it does have the option of offering the product directly, there is regulatory advantage to having a bank offer that product instead. For instance, Beam adds, when making loans, a bank will not generally be subject to state-by-state usury laws, but a fintech would be.

Fintechs can resolve this by setting up a partnership with a financial institution to provide the financial element.

Beam explains that this is typically done on a white or grey label basis. “I think it is a grey label basis rather than only a white label, because oftentimes for various regulatory reasons, it isn't possible to offer a true white labelled banking product through a fintech company.” Given fintechs are fundamentally innovative, the bank must be able to adapt its products to fit the fintech’s model.

While the BaaS model is similar to the traditional fintech/bank partnership, a primary difference is that with the BaaS platform, a bank is offering its products through partnerships with other companies in a way that is designed to be scalable.

That is, while the traditional bank/fintech partnership model focuses on being customisable and flexible, a BaaS platform typically focuses more on scalability and standardisation. Naturally, this limits customisation options.

Who is a typical BaaS partner? What does BaaS offer to banks?

Rohith P. George, partner in the firm’s technology transactions practice, notes that there is a wide range of use cases across industries where a BaaS model is highly effective. These tend to expand beyond the more strategic partnerships into a wider range of partners which can be broken down into a couple of categories.

1. A typical example is that of a fintech seeking to integrate a variety of banking services into its platform, to allow its customers to establish financial accounts directly within its app and execute their finances within the same platform. This BaaS capability would allow the company to engage with a variety of different bank partners, using the bank partners’ BaaS platforms, in order to make a range of products available to customers.

“You could get a recommended loan through one bank, you could open a checking account with another, perhaps even open a credit card with another. The banks ultimately get more reach for their products and the fintech improves the overall stickiness of their platform or their product. It's kind of a win-win for both sides.”

2. George adds that there is a larger set of non-financial companies that see financial services as being an opportunity to improve sales and deepen their relationship with their own customers. While big tech’s major foray into financial services has already started, with leading players offering integrated checking or credit products for instance, George argues that beyond big tech, “lots of companies are interested in the ability to integrate financial services into their products.”

Encouraging the audience to take a “1000-foot view”, George explains that the potential upside for banks is that “they can move from their current walled-garden environments, to becoming a key ‘money lego’, that they can build directly into the ecosystems and platforms of online commerce.”

Is the bank the service provider to the BaaS partner? Or vice versa?

With a focus on digital and outsourced services transactions in Mayer Brown’s technology transactions and corporate and securities practice, partner Joe Pennell, states that the answer – albeit a little complicated, is that both parties could be service providers to one another.

This is because the bank would be supplying banking services to the BaaS partner and its customers, while the BaaS partner would be supplying the bank with a technology platform used to deliver the bank services to the end customers.

“From a contracting and incentives perspective, it's not always going to be a neat and clean ‘we are the service provider’ or ‘we are the service recipient’ scenario that commonly occurs in a traditional outsourcing SaaS or bank fintech platform license licensing arrangement.”

This answer isn’t always favoured by a bank’s business team as they may perceive that numerous regulatory hurdles could be triggered if the BaaS partner is considered the bank’s service provider.

They may believe that labelling the tech company a “partner” instead of a “service provider” would allow them to circumvent these regulatory hurdles.

Yet, as Pennell understands it, “a lot of relevant guidance from the OCC, and other regulators, governs any third-party relationship with a bank, not just relationships with companies that are called a vendor or called a service provider. The nomenclature, doesn't matter too much from a regulatory perspective.”

Beam elaborates that banking is always a service, and when a bank provides a banking product through a BaaS arrangement, it is a service provider. The critical question, rather, is to whom precisely the bank is providing the service.

“The bank has a direct contractual relationship with the end user, which is ultimately the customer of the partner to the bank. They are providing that service directly to that customer - so they are a service provider, but in many respects, they're a service provider to the end user - with respect to the banking services anyway.”

The question in itself could be considered a ‘red herring’ of sorts, he furthers. This is because third-party risk management guidance, which historically emphasised the categorisation of ‘vendor’ or ‘service provider’, has now moved away from that approach. It has done so in part, because it can be a conceptually difficult question to answer.

Guidance from the banking regulator as it exists today, tends to side-step this question of whether we should put the label of ‘service provider’ on the bank or the third party, focusing largely on the risks of the arrangement to the bank and the impact non-performance or misconduct by the third party could impact the bank itself.

“Ultimately, under the third-party risk management principles you don't even need to get to the question of who is the service provider per se - assuming that if you're the lawyer representing the bank, you have a third-party risk management program for the institution that you represent which actually gives you the luxury of sidestepping the labelling question.”

Where data usage enters the fray

Beam furthers that the question around which role each party is playing or which service they are providing is far from black and white. In fact, the situation is even more blurred when looking at the question through a regulatory lens, leaving ample room for disagreement.

“The more integrated a BaaS product is with the other partners, or the partner’s product and services, the more difficult it can be to isolate which activities are activities of the partner done on behalf of the bank, done as a service provider for the bank if you will, or are done on its own behalf in connection with its separate relationship with the end user customer.”

This becomes quite apparent when discussion around data usage rights arises. The bank will generally want to (or may be required by privacy laws to) contractually restrict what the partner can do with customer information that the partner acquires in the course of acting as a service provider for the bank.

“For example, if the BaaS product is an embedded payment solution, where it provides credit or otherwise facilitates payment at checkout and is integrated into the BaaS partners, digital or online checkout process, then isolating what information that the partner acquires in connection with that transaction (in particular with the checkout process) is to be considered, subject to the bank's contractual restrictions on customer financial data. It can be very challenging, and it can lead to a lot of debates.”

Because these transactions tend to be highly integrated, it can be very difficult to separate out what data points are viewed as bank data points or bank customer data (for regulatory or other purposes), as distinct from the data points that the partner acquires through the course of its own transactions with the customer. 

“And remember, tech companies thrive on data, and they may find value in data that seems just completely banal to others and other utterly uninteresting. There could be some contentious negotiations around some pretty seemingly basic data points.”

Leveraging the customer relationship

When it comes who has ownership of the customer relationship, Pennell believes that the short answer is that it is the BaaS partner in most arrangements , because the BaaS platform is the primary channel for interacting with the customer.

The longer answer, according to Pennell, is that ownership of the customer relationship is a complex concept, with several components and the allocation of those components between the parties will be both product and deal specific. Some of these larger components include servicing, exclusivity, cross-marketing rights and rights upon termination.

Beam makes a point of distinguishing the concept of who owns the customer relationship as a commercial matter from whether the person is a customer of the bank for regulatory purposes – where the relevant law uses the term ‘customer’.

He raises the example that privacy laws refer to customers of the financial institution, and the end user in these partnerships will often be customers for purposes of those laws.

Yet, “beyond laws that use a specific term customer, it's important to remember that regardless of how the parties allocate the contractual rights that collectively comprise the concept of ownership of the customer relationship is a commercial matter, at the end of the day, the bank is generally going to have a Terms of Service with the customer and is generally going to be providing those banking services to the customer. As a result, the bank is going to have obligations to that customer, both as a regulatory matter, and as a contractual matter.

“These are going to exist simply because the person has a contractual relationship with the bank and a contractual privity with the bank, which exist independently of how as a commercial matter the parties think about who the end user is the customer of.”