The Path to BaaS Compliance
Stick with me, because this will be a longer post than normal, but an important topic. Banking as a Service (BaaS) has quickly become one of the most talked about subjects in financial services. From projections to the market being a $25B opportunity to more and more financial institutions (FIs) joining the ranks of BaaS sponsor banks, it seems BaaS is set to keep expanding. There has been some concern, however, about compliance within these BaaS constructs for both established players and new entrants to the space. So how does an FI get into BaaS and stay compliant?
What compliance and regulatory needs apply to BaaS?
First, it's important to cover what compliance means for BaaS products. Compliance covers many different areas and is impacted by variables of what is offered and what FI is sponsoring the offering. One main piece to consider is third-party relationship guidance, which will directly impact compliance and monitoring. The short answer to what applies is — it depends.
Product Type
The compliance and regulatory guidelines are going to be significantly impacted by what product type is being offered by the fintech. If it is a credit card, for example, Regulation Z and Regulation B apply, among many others. If it is a depository account, Regulation E and Regulation DD would apply (again, among others). Even these are changed by what end client is being served. Different regulations either do or do not apply based on if the product is a consumer or business product.
Product Features
Sometimes the product features can impact what regulations apply. For example, if a depository account offers a debit card, then the debit card has specific requirements that must be followed. If lending products are being offered, the specific lending type will determine some requirements that either do or do not apply. Again, the end client being a consumer or business also has impact for each feature.
Size and Type of FI Sponsor
The size and type of FI sponsor also impacts what regulations apply. The Durbin Amendment, for example, has restrictions on interchange for debit cards, but this only applies to FIs of a certain asset size. The regulatory body that monitors and guides each FI is also different depending on the size and other factors. The below figure may give a little more clarity on how much can change based on the type of product, type of FI, etc.
How do BaaS constructs impact compliance?
There are quite a few constructs out there, so let's go over a few. First, let's level set with some definitions:
BaaS Sponsor — A financial institution sponsoring a non-financial institution using its charter for financial products (BIN, depository accounts, etc.)
Intermediary — A company that sits in between the non-financial institution being sponsored and the BaaS Sponsor (e.g., Synctera, Unit, Treasury Prime, etc.)
Core — A back-end system that processes banking transactions across the various digital and physical branches of a bank, including deposit, loan and credit processing
For Benefit Of (FBO) — A pooled account that allows an FI to manage funds on behalf of, or “for the benefit of,” one or more of its users
Fintech — the entity being sponsored by the BaaS Sponsor and offering products to the end client
Fintech Platform — The entity being sponsored by the BaaS Sponsor and offering products to another fintech which offers them to the end client
Direct Bank and Intermediary Models with Single-FBO
This model offers a single FBO on the FI’s core which pools all opened fintech accounts into one account. The sub-ledgering for each account would be housed either with the fintech or its vendor, or with the intermediary. While this may be one of the easiest setups internally, it does offer some challenges from a compliance standpoint.
If all fintech accounts are pooled, the FI must maintain instant visibility and have real-time access to sub-ledgering data to maintain full view into what amounts relate to which end client account. Monitoring can also be a challenge to identify and track funds as they come in and go out. From an oversight standpoint of an FI, this could be a difficult contstruct to get right.
Direct and Intermediary Models with Multi-FBO
This construct offers an FBO per fintech, which allows the pooled funds and limits the number of accounts opened on the core (which could be costly). It also allows funds to be separated for each fintech partner the FI supports, which gives more separation and allows for delineation internally between fintechs for monitoring, alerts, etc.
This can offer some operational challenges as the FI will need to figure out how to designate each fintech internally with unique identifiers that ideally carry across systems. The FI can audit and report on each fintech’s activity, as well as reconcile activities per fintech.
Direct and Intermediary Models with Direct Core Accounts
This is one of the most streamlined constructs for compliance. The FI is able to utilize existing monitoring, audits, and policies. The main external requirements will involve monitoring and auditing fintech activities, changes, and operations. This is also one of the more expensive options for an FI, as it will require more accounts to be opened directly on the FIs core, rather than utilizing pooled accounts.
This also can limit the fintech’s ability to customize and scale due to the internal architecture, vendors, and systems used by the FI. This could limit the FI from being more broadly marketable, depending on how the FI has structured its product.
Direct and Intermediary Models with Fintech Platform
This is one of the more complex constructs. The fintech being sponsored are themselves acting as a BaaS platform and supporting fintechs who are then supporting an end client. Compliance becomes even more complex and involves more third-party risk and monitoring.
This construct, while it has the ability to scale and provide additional revenue, can be very complicated from an oversight perspective. The FI will need to ensure visibility into each level of the construct, as well as audits to ensure the policies, regulations, and agreements are being followed at each stage.
Sorting Through the Complexity
Once it is determined which regulations apply, understanding the regulation is not often the difficult part — operationalizing the compliance is. Creating processes, access, and reporting as well as putting personnel in place to carry out each piece can be overwhelming, and the more steps away from the charter the activity is, the more difficult it is to monitor and manage. Here are a few things to keep in mind:
Track Approvals and Document, Document, Document
It is incredibly important to show FI oversight in every facet of the BaaS construct, and each phase. From sales to ongoing monitoring, the FI should have a handle on what is in and outside of its policies. Initially, the FI should show approvals from executives within the BaaS group for each new fintech to be onboarded.
Also, ideally the FI has a committee made up of pertinent stakeholders throughout the enterprise (risk, compliance, IT, etc.) that approve each new fintech partner the executives within the BaaS group have already approved. This will show enterprise review and approvals and consistent policies for each new prospect.
Finally, all procedures, processes, approvals, project plans, etc. should all be documented extensively. These documents should be maintained and reviewed periodically (typically annually) by relevant stakeholders to make sure they are working as intended and no changes are needed.
Access to Data and Reporting
No matter the construct chosen by the FI, access to data and reporting should be paramount. Not only access, but timely access depending on the type of data or report. This could be detrimental if an issue were to occur, and the FI has no way of knowing in a reasonable time frame to either be involved in or initiate intervention and resolution.
If using an intermediary, what access does the FI have? Is it real-time? Is the data replicated somewhere internally at the FI to use for its own reporting and monitoring purposes? What oversight tools does the FI use that may need to be applied to the intermediary?
Unwinding Process
This is a touchy topic but is unavoidable. Statistics show that not every fintech the FI sponsors are going to be successful. There will be an eventual failure, and the FI needs to have clear processes in place that detail how the unwinding process will be done. Also, the FI should have monitoring in place so that any failure is not a surprise, and it can work with the fintech ahead of time to handle each situation to the best benefit and care of the end client.
Complex But Possible
While compliance for BaaS can be complex, it is not only possible but a necessity for the survival of fintechs and BaaS as a product. Most importantly, compliance is necessary to protect and give the best experience to the end client. Compliance knowledge is important but operationalizing it for BaaS is key.
