This article was co-authored by Joe Pennell (partner); David Beam (partner); Rohith George (partner); Matthew Marvin (associate) at Mayer Brown LLP. This article is the second in a three-part series from Mayer Brown on digital transformation and its impacts
on financial institutions.
Financial services have historically been the domain of regulated financial institutions, but when technology companies began building and offering financial products, fintech was born. Financial products, though, are subject to a multitude of financial
regulations and, to be able to deliver these products to their customers, fintechs have over the years sought to collaborate with banks and other financial institutions, most often through bespoke agreements and custom technology integrations.
Increasingly, regular companies (not just banks and fintechs) are seeking to embed and deliver financial products to their customers at their point of need, and banks and other financial institutions are turning to what is often called a “Banking as a Service,”
or BaaS, model for future partnerships. BaaS is a variation on the traditional bank-fintech collaboration model that is focused on scalability. BaaS models generally involve the bank’s delivery of services via APIs, either developed by itself or in collaboration
with a BaaS platform partner that serves as the interface between the bank and different companies. These APIs enable integration with many different companies at scale and allow additional opportunities to broaden the customer base for the bank’s core products.
BaaS collaborations allow these companies, which we will refer to in this article as “Partners”, to embed financial features and functionality into their existing products. For example, a fintech that provides automated personal finance advice based on
customer-provided information could offer customers the option to establish financial accounts directly within its app using a bank’s BaaS platform. Similarly, a home appliance retailer could use a BaaS platform to build a buy-now pay-later offering directly
into its sales platform.
Whatever the use case, banks, fintechs and other businesses interested in BaaS arrangements need to understand the complexities and risks involved. This article will focus on five key topics for these types of arrangements: (1) compliance with the bank’s
third-party risk management obligations, (2) complexities in data ownership and use, (3) handling of the customer relationship, (4) contract structuring, and (5) challenges from the BaaS Partner’s perspective.
Third party risk management for the Bank
Establishing a BaaS program does not in itself relieve a bank of any of its obligations to oversee and manage the risk associated with third parties with which it enters into relationships. There are some unique characteristics of the BaaS model, however,
that impact the bank’s analysis.
Historically, banking regulators have asked whether a third party qualifies as a “vendor” or “service provider” for purposes of assessing the bank’s risk management requirements. On the surface, BaaS may appear to classify banks into the role of a service
provider, much like a technology company who is providing Software as a Service or “SaaS”. In a BaaS arrangement, however, the distinction of who is the service provider is not intuitive, and both parties may be considered service providers to one another.
That is, a Partner will be marketing, promoting and sourcing customers that will ultimately use the bank’s products and the bank will be providing financial services to the Partner and its customers.
Regulatory guidance in recent years, however, has been more likely to focus on the risks presented by any third-party relationship that a bank may enter into, regardless of whether the label “service provider” or “vendor” is attached to a particular third
party. Bank regulatory guidance today is more likely to address questions like: “what are the risks in this arrangement to the bank?” or “how could non-performance or other misconduct by the third party, such as a BaaS Partner, cause harm to the bank?”
These types of questions will frame the level of due diligence a bank must employ to evaluate each Partner with which it is considering a BaaS relationship. Generally, third-party risk management guidelines require banks to perform an appropriate level
of due diligence on potential third parties with which the bank is considering entering into an arrangement. Banks need to tailor the scope and level of due diligence they perform on a Partner based on a variety of factors, including:
- the nature of the BaaS arrangement and the particular risks it presents (including particular legal or reputational risks);
- the criticality of the functions performed by the Partner; and
- the level of oversight the bank plans to have over the Partner.
If the allocation of responsibility for various aspects of the BaaS Program and the oversight process that the bank will employ to monitor its Partners are all baked into the BaaS platform and standardised, then the bank’s due diligence process will likely
just be a matter of setting minimum standards and verifying that each prospective Partner complies with those standards. Conversely, if a bank’s BaaS platform supports more flexibility in terms of (a) allocating responsibility for critical functions or (b)
how the bank oversees the Partner, then the bank’s due diligence process will probably categorise potential Partners into different risk “tranches” (with each tranche associated with differing levels of initial diligence and ongoing oversight activity by the
Complexities in allocation of data ownership and use rights
Negotiating terms that allocate data use rights and restrictions can be challenging given the integrated nature of the parties’ roles in BaaS relationships. The bank will want, and may in some cases be required by law, to restrict what the Partner may do
with customer information obtained in connection with the provision of the bank’s financial services. The Partner, however, is likely to disagree with the bank in drawing the line between customer information belonging to the bank versus the Partner.
To illustrate this point, consider a BaaS credit product that is integrated into a retail Partner’s online checkout process. The Partner is unlikely to agree to any restrictions on its use of customer-provided information that is used to effect both the
BaaS credit transaction and the Partner’s checkout process generally. The Partner is likely to point out that it would have captured this information even if the customer had not used the bank’s credit product at all.
It is important, therefore, to treat data that the Partner acquires through the course of its own transactions with the customer as distinct from the data that the Partner acquires in connection with the provision of the financial service, even if they overlap.
Negotiating these distinctions will be important to both sides.
Control of the BaaS customer relationship
Determining which party controls the customer relationship can also be a tricky issue. Often, for regulatory reasons, end customers receiving BaaS products and services will always be a customer of the bank. From a commercial perspective, however, the
BaaS Partner usually has the primary relationship with the customer, which is logical, since the Partner’s platform is the principal channel for interacting with the customer. Control of the customer relationship, however, can be divided into several different
components, including servicing, exclusivity, cross-marketing rights, and post-termination rights, and the parties can allocate control over those components in a variety of ways.
BaaS customer relationship – servicing
Servicing generally includes supporting and interfacing with the end customer in relation to the BaaS products and services. The Partner will typically provide the user interface, first level customer support, and delivery of disclosures and other customer
communications. However, banks may sometimes want to handle some aspects of the servicing functions directly, including in relation to know-your-customer and other customer identification requirements under FinCEN rules and other money laundering laws.
BaaS customer relationship – exclusivity
Exclusivity provisions, or the lack thereof, in a BaaS program agreement may be very dependent on the nature of the BaaS products and services and the relative contracting leverage of the parties. In some BaaS arrangements, the Partner may want to retain
full rights under the program agreement to offer products and services from competitor institutions. In other BaaS relationships or in circumstances where the bank has substantial leverage vis-à-vis a Partner, the bank might be able to negotiate a limitation
on the Partner’s ability to offer products and services from other financial institutions to the end customers.
BaaS customer relationship – cross-marketing rights
Another key customer relationship negotiation point related to exclusivity is the parties’ rights to cross-market other products and services to end customers outside of the BaaS arrangement. The Partner, as the party with the principal channel for interacting
with the customer, will likely push to retain full rights to cross-market other products. At the same time, the Partner may push hard to restrict the bank’s ability to cross-market other products and services to end customers independent of the BaaS program
(e.g., to preserve the Partner’s ability to route customers to other banks and financial institutions and better control the customer experience for individuals the Partner has introduced to the bank). These types of restrictions, if the bank is willing to
consider them, may raise complex anti-competition legal issues that the parties should carefully consider with antitrust counsel.
BaaS customer relationship – post-termination rights
Every BaaS program agreement should address what happens upon termination of the BaaS relationship, which may be heavily dependent on the nature of the specific products and services being offered. Among other things, the parties should negotiate disengagement
services provisions that require the parties to smoothly transition end customers and other bank-performed functions to the Partner’s new financial institution.
Contract structuring challenges
BaaS arrangements require a thoughtful contracting approach. Trying to use an ordinary SaaS or outsourcing agreement template will be insufficient to address the complex allocation of roles and responsibilities between the bank and its Partner. Unlike
a typical service agreement, services will be flowing in two directions and the BaaS Partner may be performing key functions for the bank, like handling customer complaints, transmitting disclosures, and otherwise directly communicating with customers. Therefore,
the contract needs to clearly segregate these multifaceted roles and responsibilities, particularly with respect to end customer contracts, regulatory compliance and customer service.
Additional challenges from the Partner perspective
BaaS arrangements raise a number of unique challenges for Partners. Partners will want the BaaS program agreement to preserve their rights to change and evolve their customer-facing platforms and related user experience elements with as little interference
as possible from the bank. Banks will seek to limit that flexibility, especially in relation to changes that may impact the customer experience or have any compliance with laws impact.
Additionally, Partners will want flexibility to market the bank’s financial products and services through their existing sales and distribution channels. Banks will negotiate hard to maintain input and approval rights over those marketing efforts from a
quality control and branding perspective, especially if the bank’s branding will be featured.
Partners also will want to preserve options to use other bank providers or to terminate the relationship if the bank is not meeting its performance obligations, including in relation to any critical service levels that may be documented in the agreement.
Finally, the Partner will want to retain ownership of intellectual property rights in its platform as it evolves in relation to the BaaS program, with the exception of intellectual property rights such as the bank’s trademarks and branding.
The rising popularity of BaaS arrangements underscores the rapidly changing ways that financial services are delivered by banks, fintechs and other companies. Although these arrangements present their own unique challenges, banks and their Partners can
successfully manage their BaaS relationships by implementing thoughtful due diligence and contracting processes that are tailored to address BaaS-specific concepts and risks.
Catch up on Part 1 of this series of articles here:
Addressing the IP pitfalls in data monetisation projects