BaaS, Compliance, and the Path Forward for Community Banks

Banks have always been highly reliant on third parties.

Whether it’s for technology or staff augmentation or importing critical subject matter expertise that they don’t have in-house, third parties have played a critical (and often under-discussed) role in the growth and success of banks.

This is especially true for community banks, which are at a severe (and ever-worsening) disadvantage when it comes to competing with big banks and big tech companies.

Third parties enable community banks to minimize the impact of the resource disparity between themselves and their larger bank and non-bank peers.  

It’s a bit like playing basic strategy in blackjack – the odds are still against you, and you’ll probably still lose in the long run, but you’ve minimized your disadvantage.

This is the essential logic that permeates the sales pitches for most technology vendors and other third-party service providers that sell to community banks – buying our digital/cloud/AI/chatbot/customer service widget will put you in the best possible position to be competitive with big banks and big tech.

It’s a compelling pitch, which is why, like clockwork, the same four technologies come up at the top of the list for investment by mid-size and community banks every year in Cornerstone Advisors’ annual What’s Going on in Banking survey:

For the last decade, your average community bank CEO has behaved as though they genuinely believed that their bank was one great digital account opening experience away from being able to effectively compete with Apple and JPMorgan Chase.

Was that delusional? 

Yes. 

Did they actually, deep in their hearts, believe that was true? 

Maybe not, but in the absence of a better answer, that was the path they pursued.

That path is becoming increasingly untenable.

The technology gap between community banks and big banks and big tech is widening. Innovation cycles are shortening and becoming more difficult for laggards to capitalize on (look at generative AI for the most recent example of this). Community bank M&A, which has been largely paused for the past year or so due to rising interest rates and underwater bond values, is expected to resume at a torrid pace in 2024, a pace that will lead to the U.S. having dramatically fewer community banks ten years from now than it has today.

The forces of creative destruction driving this consolidation can’t be stopped, no matter how effectively a community bank leverages third-party service providers. 

It’s eat or be eaten.

Unless you shoot the moon.

Shooting the Moon  

Community banks have been dealt a crappy hand of cards. Playing that hand carefully, skillfully, and in accordance with the odds won’t change that.

However, in some games, you can shoot the moon.

Allow me to explain.

My favorite card game, by far, is pinochle. In pinochle, two teams of two players each, compete by creating combinations from the cards that they are dealt to earn points and then playing those cards in a particular sequence in order to take tricks and earn more points. In my family, the first team to 1,500 points wins and earns vicious bragging rights over the losers (we’re very competitive).

In pinochle, there are obviously good hands (lots of aces and high cards in the same suit create good combinations that are worth a lot of points) and obviously bad hands (if you get dealt a bunch of 9s, don’t bother bidding), and, pretty quickly, you learn how to value and play those hands accordingly.

The trickiest hand to play in pinochle is the one that doesn’t have a lot of high-value combinations, but that can be played in such a way that your team doesn’t lose a single trick. If you have a hand that looks like that, you have a choice. You can play it out the regular way (likely leading to mediocre results), or you can shoot the moon. If you choose to shoot the moon, you are making a bet that you can take every trick in that round. If you do it, your team earns 500 points. If you fail, if the other team takes just one trick, your team loses 500 points. 

It’s a high-risk, high-reward gambit that requires precision, discipline, and a bit of luck to pull off. If you’re winning, it’s probably not worth it. But if you’re losing, and you keep getting dealt bad hands, it can be a lifesaver.

For community banks, banking-as-a-service (BaaS) is shooting the moon.

The Risks and Rewards of BaaS

Banking-as-a-service is a partnership model in which a financial institution leverages its bank charter to enable one or more non-bank companies to offer financial products directly to consumers or businesses.

What’s interesting about BaaS is that it represents a monumental shift in the relationship between banks and third-party service providers. Unlike traditional technology vendors and consulting firms, BaaS fintech partners directly help banks generate revenue. 

This simple truth has profound implications.

On the positive side, BaaS is an incredibly efficient mechanism for driving growth.

Growth in banking is usually really expensive. You want more interchange revenue? Be prepared to pay up in rewards to get it. You want more commercial loans? Go hire a bunch of commercial bankers with big Rolodexes. You want more deposits, in an environment where everyone desperately wants deposits? Get ready to pay at or above market rates in order to attract that hot money.

BaaS makes growth affordable for community banks, as BaaS banks have demonstrated in this current fight for deposits:

A group of 42 community banks focused on banking-as-a-service outperformed peers across some key metrics in the first quarter and showed signs of deposit growth resiliency.

During the first quarter, banks focused on banking as a service (BaaS) recorded median deposit growth of 4.0% … while all community banks posted median deposit growth of 0.2%.     

And if you can harness the value of that BaaS-driven growth with smart, disciplined balance sheet management, you can produce startlingly great results.

For just one example, take a look at The Bancorp, which was ranked #16 overall on Bank Director’s 2022 Ranking Banking Report thanks to its 54% year-over-year growth in net income and a return on equity (ROE) of 20% (which is significantly better than the average ROE in banking, which hovers around 12%). 

As Bank Director’s Fintech and Banking Editor Kiah Haslett explained to me on a recent podcast, The Bancorp’s fintech partnerships business (combined with short-term lending into price-sensitive niches and clever balance sheet management) has been instrumental in helping continue to grow its profitability without growing its assets, a feat that is largely unheard of in the banking industry.

On the negative side, BaaS introduces risks that are significantly greater and more challenging to deal with than the standard third-party risks associated with technology vendors and consulting firms.

Because fintech companies directly generate revenue for their bank partners, they have leverage. BaaS banks have to compete for the best fintech programs. This is a very different dynamic than the one between banks and their traditional vendors (in which the bank usually has most of the leverage). And because of this unique dynamic, BaaS banks will sometimes do things that they know they shouldn’t. They’ll cut corners in order to help their fintech partners get to market quickly. They’ll give too much control and autonomy to their fintech partners too quickly. They’ll source new fintech partners indirectly through middleware platforms that obfuscate the risks of their programs.   

And the costs of these risky decisions are becoming increasingly clear.

Over the past couple of years, we’ve seen a major regulatory crackdown on BaaS, with the OCC, the Federal Reserve, the FDIC, and the CFPB all weighing in with their concerns regarding the insufficient oversight of fintech and non-bank activities enabled through BaaS and similar partnership arrangements.

As a result of this crackdown, Blue Ridge Bank entered into a consent order with the OCC, requiring it to strengthen its BSA/AML program and oversight of fintech programs, among other corrective actions, and imposing restrictions on the bank’s onboarding of new fintech partners or new activities with current partners. 

And more recently, Cross River Bank entered into a similar consent order with the FDIC over fair lending concerns in its fintech partnership business. The consent order requires the bank to address deficiencies with its lending and third-party compliance controls and to seek approval from the FDIC before offering new credit products or adding new fintech partners. 

(Editor’s note – Cable has been maintaining a very useful timeline of regulatory developments relating to BaaS and bank-fintech partnerships. Check that out if you want to dig into this in more depth.)

In order to successfully shoot the moon in pinochle, you have to play your hand flawlessly. Any mistake, no matter how small, can cost you the game.

In banking-as-a-service, we’ve seen a lot of banks make mistakes. These mistakes haven’t been too costly yet (we’re still early in the game), but as the BaaS ecosystem matures and regulators sharpen their focus on it, the consequences for any mistake will become significantly greater.

In order to avoid these consequences and reap the massive benefits that BaaS can provide, banks will need to invest significantly in an area that hasn’t historically been a priority – compliance.

Needed: A New Model for Compliance   

Let’s start by being crystal clear – banks are solely and entirely responsible for ensuring that everything facilitated through their charters is done in full compliance with all applicable laws and regulations.

There is no version of banking-as-a-service where this is not true.

Regulators have been strongly emphasizing this point every time they talk about anything even tangentially related to third-party risk management or bank-fintech partnerships. Here is how the interagency guidance from the OCC, the FDIC, and the Fed on third-party risk management puts it:

Importantly, the use of third parties does not diminish or remove banking organizations’ responsibilities to ensure that activities are performed in a safe and sound manner and in compliance with applicable laws and regulations, including but not limited to those designed to protect consumers (such as fair lending laws and prohibitions against unfair, deceptive or abusive acts or practices) and those addressing financial crimes.

Translation – if a third party that you are working with causes a screw-up on BSA/AML, fair lending, UDAP, Reg E, etc., you are responsible. Full stop.

Traditionally, banks design their risk, governance, and compliance processes across three lines of defense:

• Frontline Controls. These are the processes, people, and technologies that are put in place for each business line or product at the bank to prevent bad things (fraud, money laundering, discriminatory lending, etc.) from happening. 
• Compliance Management, Testing, & Oversight. This is typically where the bank’s compliance team sits. They are responsible for assessing risk, continually monitoring the effectiveness of the frontline controls, and investigating and remediating any problems that are identified. 
• Independent Assurance. This is a separate group, either within the bank or external to the bank, that is responsible for independently evaluating the effectiveness of both the frontline controls and back-office compliance functions and reporting their findings to key stakeholders at the bank (C-suite, Board, etc.)  

These core risk management functions sit underneath the entire customer lifecycle. The frontline controls look a bit different, depending on where they sit in the lifecycle, while the back-office compliance, testing, and independent assurance are a bit more standardized (though highly manual).

It looks, roughly, like this:

It works fairly well for traditional banking models, as long as you don’t put too much stress on it.

For example, if a community bank wants to grow by opening up a new branch, this model works great. The bank simply extends its existing risk, governance, and compliance infrastructure to support it. The compliance team trains the frontline employees at the branch on its policies, procedures, and controls. The new branch uses the same account onboarding and transaction monitoring systems that all the other branches use. Maybe you tweak a few small things to account for the unique characteristics of that branch and the community it’s serving, but it’s 99% the same. The same brand. The same products. The same set of incentives.

BaaS breaks this model.

To repurpose the prior example, imagine if a community bank’s compliance team had to support not the opening of one new branch, but the opening of nine new branches, all within an 18-month period. And those branches are being set up and managed not by employees of the bank, but by independent contractors to whom the bank is oddly deferential. And those contractors are insistent on inventing new products rather than selling the banks’ existing products and equally insistent on reinventing every process and procedure from the ground up in order to maximize the end customer’s experience. Ohh, and also, each new branch has completely distinct branding and marketing materials and is owned by people who were obsessed with growth at all costs. 

You can see how this would cause some problems.

So banks have had to adapt their approach to risk, governance, and compliance in order to support fintech partner programs.

Specifically, there are three different models that banks have been experimenting with for BaaS.

Three Different Models for BaaS Compliance

#1: Compliance-as-a-Service

In this model, the bank requires that all of its fintech partners use its existing risk, governance, and compliance infrastructure. The fintech company doesn’t take on any of the frontline work of setting up and operating controls nor any of the back-office compliance monitoring and case management. The bank does it all (hence why it’s referred to as “compliance-as-a-service”).

The benefit of this model for banks is that they maintain full control over all risk, governance, and compliance functions, just like they do when opening a new branch. For fintech companies, the benefit is that they literally don’t have to lift a finger. They don’t need to shop for an ID verification vendor or staff up a compliance team. They just do what the bank says.

The problem with this model for banks is that it’s not very scalable. As it adds fintech programs, it must invest in capacity to deal with the resulting increase in compliance work. This also causes a problem for the fintech companies. In order to pay for all those additional compliance resources, the bank needs to charge its fintech partners for this compliance-as-a-service offering, which means that this model for BaaS will always be expensive. Additionally, and more importantly, because fintech companies care deeply about creating a differentiated customer experience, most aren’t comfortable outsourcing every decision relating to fraud and compliance to the bank partner. They want to pick the IDV vendor!  

#2: Program Management

In this model, the bank outsources the majority of the risk, governance, and compliance work to a middleware platform, which acts as the technical and operational interface between the bank and its fintech programs. The bank gets some high-level reports on what its fintech programs are doing, but otherwise is fairly hands-off. The fintech company is similarly abstracted away from the bank and is given a bit more control to design onboarding and transaction monitoring processes that will create great experiences for its customers. The middleware platform is the program manager.

(Editor’s note – I am referring to this model as “Program Management” intentionally in order to differentiate between BaaS middleware platforms that provide both technical integration and program management from those that only provide the technical integration. The first group of platforms are the ones that I am focused on for this model.)  

The benefits of this model for banks are that it’s easy to get started with and it’s highly scalable. Essentially all of the day-to-day compliance work is eliminated, and the bank is able to be a much more passive participant in the partnership and is able to support a larger number of programs. For fintech companies, this model is similarly easy to get started with (no need to deal directly with the bank and all their annoying demands!) and faster and more enjoyable to build in (BaaS middleware platforms generally have more modern tech stacks, are easier to integrate with, and are flexible in terms of the compliance systems and processes that fintech companies can use).

The big problem with this model for banks is that it makes risk, governance, and compliance really difficult. 

Program management is a model that has worked in card issuing, where a bank may act as a BIN sponsor for a non-bank card program, but outsource a great deal of the operational and compliance work to a third-party program manager. However, card issuing and BIN sponsorship is a very narrow, well-established space with a lot of built-in controls and risk monitoring (much of which flows down from Visa and Mastercard). BaaS, by contrast, is wide open. It’s the wild west. Blindly trusting a third-party program manager to navigate all of the risks inherent to BaaS without the benefit of any pre-existing guardrails, is a bad idea. It’s not an accident that most of the BaaS banks that have run into serious regulatory trouble were using this model.  

These risks are also problematic for fintech companies. What’s the point of building on top of a middleware platform that is designed to get you to market quickly if your product gets shut down after six months because of compliance failures at your partner bank? 

Finally, this model is expensive for both banks and fintech companies, as the middleware platform represents another mouth to feed from the rev share.

#3: Bank-as-Regulator

In this model, the bank directly manages all of its fintech programs. However, the bank will allow the fintech companies to, over time, take on a lot of the first and second-line risk management and compliance work, including the design and operation of the frontline controls. Instead of doing all that day-to-day work, the bank focuses its energy on closely monitoring its fintech programs and testing their processes and controls. It essentially plays the same role for its fintech partners that government regulators play for it.

(Editor’s note – this model is equally applicable to programs in which the bank and the fintech company are directly integrating with each other’s systems and where that integration goes through a BaaS middleware platform. The key is that there is no third-party program management.) 

This model sits in the middle of the continuum, between “Compliance-as-a-Service” and “Program Management,” and is, in many ways, the best of both worlds. 

Banks are able to achieve a balance between scalability (they’re not paying for all frontline controls and back-office compliance work) and risk management (they have direct line of sight on all the programs). Fintech companies maintain control over the systems and processes that impact their products and customers while minimizing the risk that their program will run into disruptive compliance problems down the road.

In my research for this essay, I spoke with a bunch of experts in the BaaS compliance space, including multiple bank executives who are in the midst of building out fintech partner programs. There was broad consensus among these experts that this third model – “Bank-as-Regulator” will be the model that wins out over time, especially as government regulators focus more of their time and attention on BaaS.

These experts were also quick to point out that even if a bank chooses to go down the “Bank-as-Regulator” path, there is no silver bullet or easy button for building a world-class banking-as-a-service compliance function.

But they did have a few suggestions for how to get started.

Go Slow. Invest in Tech.

Fintech moves fast, and the temptation for community banks that want to partner with fintech companies is to match their pace.

Community banks should resist this temptation. As they say in the Navy, slow is smooth, and smooth is fast.

One expert who I spoke with recommended that banks take a crawl-walk-run approach.

1. Crawl. Acquire one high-quality fintech program to get started with (pay up for it if you have to). Integrate your onboarding and transaction monitoring systems with theirs so that they can run in parallel as the program gets up and running. The purpose of this is to figure out with the fintech company where to “set the dials” for those systems. You will be incentivized to keep those dials turned all the way down (in order to minimize risk), and the fintech company will be incentivized to turn them up to 11 (to drive growth). What you need to do at this stage is figure out a middle ground that everyone is comfortable with. 
2. Walk. Once you have the settings dialed in, you can take a small step back. You are still getting all of the data from the fintech company’s control systems, but you only monitor a portion of it (maybe 25%) in order to ensure that the systems are working as expected and there are no unexpected risks cropping up. You’ll want to walk with the fintech company in this fashion for six months to a year. 
3. Run. If nothing concerning persists during the walk phase, you can give the fintech company some room to gallop. At this point, you are treating them the same way that you would treat any trusted critical vendor. They will be doing a vast majority of the first and second-line compliance and risk management work, and you will be concentrating on the third-line – assurance testing of their controls and compliance processes.

Once a bank has developed a fintech program onboarding methodology that works and has mastered it at a slow speed and a low volume, it’s time to ramp things up.

Technology can help.

Remember, the central challenge in BaaS is building scalability without compromising risk, governance, and compliance. Humans are great at managing risk, but to scale them, you need technology.

Here are a few areas where banks are investing in technology to strengthen their BaaS compliance capabilities:

Risk Assessment 

This was a big focus of the Blue Ridge Bank consent order. The OCC found that the bank’s process for evaluating the risks posed by potential fintech partners was significantly lacking. 

I can’t speak to Blue Ridge Bank’s risk assessment process specifically, but I can say that, in general, the upfront risk evaluation process in BaaS is a highly manual one, filled with Excel spreadsheets and inconsistently-worded questionnaires. 

This is an area where technology – digital forms, document capture, and automated risk scoring – can make a big difference. What you’d want, in an ideal world, is the ability to capture all of the necessary information to understand the inherent risks posed by potential fintech partners and the proposed controls that they would put in place to mitigate those risks. And if we’re really reaching for the stars, it’d also be great to have the ability to roll up those risks so that you could see how the risks of a specific program (or group of programs) impact your bank’s overall risks.   

Systems Integrations

The crawl-walk-run onboarding methodology (and any similar approach to third-party risk mitigation) depends on the ability to feed data from the fintech companies’ control systems into the bank’s control and monitoring systems. 

Today, this is often a highly manual process involving CSV files or custom-built system-to-system integrations. However, over time, I expect that much of this integration work will become more standardized, especially as the BaaS middleware platforms increasingly play the role of a centralized API hub.

Document and Workflow Management 

In BaaS, a lot of documents are collected – compliance policies, business continuity plans, SOC 2 certifications, website and marketing materials, etc. – and then reviewed, stored, re-collected, and re-reviewed, ad infinitum. 

Managing that process is best done in a designed-for-purpose document workflow and case management system, not through a MacGyvered combination of email, spreadsheets, and Google Drive.

Real-time Transaction Monitoring

I was surprised by the number of folks that I spoke with who mentioned the need to move to real-time transaction monitoring. The general thinking seemed to be that the bigger a bank’s BaaS business becomes and the more programs they are managing, the more challenging it will be for that bank to quickly catch and address any risks that emerge. 

Real-time transaction monitoring is seen as a solution for staying on top of those risks. And it will likely lead to some new technology investments, as many of the legacy transaction monitoring systems that banks use today weren’t designed to operate in real-time nor to support the multi-level risk structures common to BaaS.

Automated Assurance

Sampling is the traditional method that banks use to do assurance testing of frontline controls and back-office compliance monitoring. You create a checklist of all the things that should be happening in order to comply with all applicable laws and regulations, and then you get a random sample of performance data (e.g. 10 random customer data files produced by the onboarding process) that a bank employee or external consultant checks against that checklist in order to look for anything unexpected that might indicate a regulatory breach or control failure. 

At best, it’s a terribly inefficient process that cannot be easily scaled to accommodate a large portfolio of fintech programs. At worst (and not uncommonly), it is a completely ineffective way to actually assure yourself that everything is working the way that it should. 

Let me give you an example – a very common control in banking is to not open accounts for consumers under the age of 18 (providing financial services to minors in the U.S. comes with a lot of complexities). Now, every fintech company that a bank talks to is going to reassure them that yes, of course. We know that, and we collect the date of birth for every applicant, and anyone under the age of 18 is automatically declined. They’re all going to say that. But what if someone forgets to hardcode it into the onboarding system, and kids under the age of 18 are able to slip through? That would be a problem, and it would be extremely difficult to catch with sampling because the actual incidence rate of the problem would be rare enough that it might not show up in a sample set of customer data for years. That, of course, would lead to years worth of compliance failures and necessary remediation work once the problem was finally identified.

Technology offers an attractive alternative. If you can digitize that checklist and you can access the necessary customer and transactional data, you can build an automated assurance system that doesn’t have to constrain itself to looking at a sample of data; it can look at all of your data across all of your programs and instantly identify and diagnose every regulatory breach and control failure.

(Editor’s note – Cable pioneered automated assurance testing and has extensive experience implementing it within a suite of tools purpose-built for the BaaS context. You can learn more about Cable’s Partner Hub here, and if you’re interested in speaking to the team over there, let me know, and I’ll happily make an introduction!)

Win BaaS

Banking-as-a-service represents the most attractive alternative to the community bank M&A treadmill to ever come along.

It’s a remarkable path to profits. So remarkable, in fact, that it sounds like a cheat code – you’re telling me there’s a way for my bank to reach a 30% ROE without growing my assets at all?

It sounds like a cheat code, but it’s not.

It’s a high-risk strategy that depends on patience, excellent execution, and machine-like consistency.

The best BaaS banks rarely make mistakes, and when they do, they promptly correct them. They anticipate where their regulators are headed, and they meet them there proactively. They understand that blind trust doesn’t make for good partnerships and that risk management and scalability don’t have to be at odds. They don’t have the most fintech programs, but they have the best ones.

Exceptional compliance sits at the core of all of these attributes, which is why the banks that want to win BaaS tomorrow are investing in compliance today.

---

About Sponsored Deep Dives

Sponsored Deep Dives are essays sponsored by a very-carefully-curated list of companies (selected by me), in which I write about topics of mutual interest to me, the sponsoring company, and (most importantly) you, the audience. If you have any questions or feedback on these sponsored deep dives, please DM me on Twitter or LinkedIn.

Today’s Sponsored Deep Dive was brought to you by Cable.

Cable helps BaaS banks grow faster with more confidence in their financial crime regulatory compliance with its Partner Hub, which provides complete compliance infrastructure purpose-built for bank-fintech relationships, including automated risk assessments, automated assurance, quality assurance, management information, reporting, and more. Cable recently raised an $11M Series A and announced partnerships with several US and UK BaaS banks amid growing regulatory scrutiny of bank-fintech partnerships.