In 2024, Blue Ridge Bank unwound its relationships with approximately 40 fintech partners — representing $466 million in deposits — after an OCC consent order cited BSA/AML program failures tied to inadequate oversight of those relationships. The bank exited its Banking-as-a-Service program entirely by year end.

Blue Ridge wasn’t the only one. Evolve Bank received a Federal Reserve cease-and-desist in June 2024. Piermont Bank, Sutton Bank, Thread Bank, Lineage Bank — the consent order list from 2024 BaaS enforcement reads like a who’s-who of fintech-forward banks that failed to scale oversight to match their partner growth.

The common thread: the bank didn’t know what was actually running on its charter until the examiner told them.

TL;DR

• Your sponsor bank’s prohibited and restricted business rules are the binding constraint on your AUP — regardless of what your internal policy permits, the bank’s risk appetite governs what can actually be processed.
• Pre-clearance is not optional for restricted categories: it’s the process that protects both parties and creates the documentation a regulator will look for.
• Rising RFI volume from your bank partner is a KRI signal — it means their risk appetite and your customer mix are diverging, and an intervention is coming.
• AUP-bank alignment should happen at contract negotiation, not after your first customer incident or bank RFI.

The Charter Problem: Why the Bank Always Wins

A fintech’s acceptable use policy reflects the fintech’s risk appetite. The bank’s program agreement reflects the bank’s.

Those two things are not the same, and when they conflict, the bank wins — not because of contractual hierarchy (though that’s usually clear too), but because of regulatory structure. The bank is the chartered entity. Every transaction your fintech processes runs through the bank’s BSA/AML program, the bank’s AML monitoring system, the bank’s compliance management system. The bank is the entity that files SARs, maintains FinCEN obligations, and faces examination by the OCC, Federal Reserve, or FDIC.

When a regulator examines the bank’s fintech partnership program, they don’t examine you. They examine the bank’s oversight of you. And if your customers’ transactions look problematic, the bank bears the primary regulatory consequences.

This is not theoretical. The Federal Reserve’s enforcement action against Evolve Bank in June 2024 cited the bank’s failure to maintain “an effective risk management framework” for its fintech partnerships — which included failure to adequately assess and monitor what fintech clients were doing on its platform. Evolve didn’t have adequate oversight tools. Its risk appetite and its oversight capabilities were misaligned with the scale and risk profile of its fintech program.

The practical implication for fintechs: your AUP needs to be built around your bank partner’s rules, not alongside them. If you don’t know what your sponsor bank prohibits, you don’t have a complete AUP.

The Architecture: Prohibited vs. Restricted vs. Approved

Every bank partner maintains some version of a tiered business category list. The categories and terminology vary, but the structure is consistent:

Prohibited — businesses or activities the bank will not support under any circumstances. These are non-negotiable. Examples typically include: illegal businesses under federal law, businesses operating in OFAC-sanctioned jurisdictions, unlicensed money transmitters, and businesses the bank’s primary regulator has explicitly flagged.

Restricted — businesses the bank will support only with enhanced due diligence, pre-clearance, or specific monitoring requirements. This is where the real compliance work happens. Common restricted categories include: cannabis-adjacent businesses (including hemp and CBD), gambling and gaming platforms, adult content businesses, money services businesses (MSBs), high-volume third-party payment processors, certain crypto businesses, payday lenders, pawn shops, and firearms dealers. The exact list varies significantly by bank — Cross River’s restricted list looks different from Sutton’s, which looks different from Thread’s.

Approved (with standard controls) — businesses the bank will support without enhanced review, subject to standard onboarding due diligence.

Your internal AUP should map each category you accept against the bank’s three-tier structure. Where your customers fall into the bank’s “restricted” category, you need pre-clearance. Where they fall into “prohibited,” they can’t be on your platform regardless of what your AUP says.

Mapping Your AUP to Bank Partner Rules

The mapping exercise is unglamorous but essential. Start by obtaining a copy of your bank partner’s program agreement, acceptable use policy, or prohibited/restricted business schedule — whichever document defines their customer category rules. Most program agreements include this as an exhibit or appendix.

Build a side-by-side table:

Every gap in this table is a compliance exposure. Gaps where your AUP is more permissive than the bank’s rules are particularly dangerous — you may have already onboarded customers the bank doesn’t know about or won’t support.

The fintech acceptable use policy framework goes deeper on how to build the internal decision logic; this article is specifically about what changes when you layer in the bank partner constraint.

Pre-Clearance: When to Ask Before You Onboard

Pre-clearance is the process of getting your bank partner’s explicit approval before onboarding a customer in a restricted category. It’s not always required — your program agreement should specify which categories trigger pre-clearance — but when it is required, it’s not optional.

The mechanics:

1. Identify the trigger. Your intake process needs a question — or a set of questions — that flags customers in restricted categories before underwriting proceeds. This can be part of your AML risk scoring model, your onboarding questionnaire, or a compliance review step triggered by SIC/NAICS code.

2. Prepare the pre-clearance package. This typically includes: the customer’s business description, the specific activity they want to run through the platform, an overview of the fund flows, the AML risk assessment, and your compliance recommendation (approve/decline/approve with conditions).

3. Transmit to the bank partner and document the request. Create a timestamped record of when you submitted the pre-clearance request and what you included.

4. Document the bank’s response. The bank’s approval, denial, or conditional approval should be in writing — email is fine — and stored in the customer’s compliance file. This is the documentation a regulator will want to see.

5. Build the response time into your onboarding SLA. If pre-clearance takes 5–10 business days, your sales team and customers need to know. Surprises at the finish line of underwriting create pressure to cut corners on due diligence.

The most common pre-clearance failure mode is the informal verbal approval — a fintech relationship manager calls their bank contact, gets a verbal yes, and moves forward without documentation. That works fine until the relationship manager changes or the bank examiner asks why a certain customer category is on the platform with no pre-clearance record.

RFI Volume as a KRI

Requests for information from your sponsor bank are compliance events. A single RFI is your bank investigating a specific customer or transaction — you answer it, document your response, and move on.

A pattern of RFIs on similar issues is something different.

If you’re receiving RFIs about the same customer category, the same transaction patterns, or the same business type three or four times in a quarter, your bank partner is telling you something. Not directly — they’re not calling to say “we’re uncomfortable with your customer mix.” They’re asking questions. But the questions are a signal.

Rising RFI volume by category is a meaningful KRI. Track:

• Total RFIs received per month, by customer category
• RFIs resolved vs. pending (and age of pending items)
• Categories generating repeat RFIs — the same category appearing in RFIs multiple times is the clearest signal of bank partner discomfort

Per a 2024 survey of compliance professionals in bank-fintech partnerships, 90% of sponsor banks reported struggling with oversight of their fintech partners’ customer policies. The tools most banks have for monitoring their fintech programs are limited — RFIs are often how they conduct real-time oversight. When the RFI frequency rises, the bank’s risk comfort with your program is declining.

What comes after persistent, unresolved RFI patterns: an informal warning (typically from your relationship manager or compliance contact), a formal letter, a contract renegotiation requiring enhanced controls or category restrictions, or — at the extreme end — program suspension. The BaaS enforcement cycle that swept through 2024 typically started with exactly this pattern.

For a broader view of how to use vendor risk KRIs across your third-party program, including how to build escalation structures that trigger before a relationship becomes a problem.

What the Bank Wants to See

When your bank partner conducts a review of your fintech program — either proactively or in response to an examination — certain documentation will be requested:

AUP mapping. A documented comparison of your acceptable use policy against the bank’s prohibited/restricted business schedule, showing where the categories align and how gaps are managed.

Pre-clearance log. A log of all pre-clearance requests submitted, the date, the customer category, the activity description, and the bank’s response (approval, denial, conditional). The log should be searchable by date and category.

Exception documentation. Any instance where a restricted-category customer was approved without full pre-clearance should have a written exception memo with approver, rationale, controls, and monitoring plan.

AUP review history. Evidence that your AUP was reviewed and updated when bank partner rules changed. If the bank updated their prohibited businesses list and your AUP still reflects the old version, that’s an exam finding.

RFI resolution log. Every RFI you received and how it was resolved. This demonstrates you’re responsive and that your compliance program acts on bank partner feedback.

The 2023 interagency guidance on third-party risk management and the 2024 joint statement on bank-fintech arrangements both emphasize that banks must maintain documented oversight of their fintech partners’ activities — and both are clear that “the bank is responsible for managing risk regardless of whether the activity is performed internally or through a third-party arrangement.”

That language translates directly into what your bank partner needs from you: documentation that demonstrates their oversight is real.

When the Alignment Breaks Down

The most common AUP-bank misalignment scenario: a fintech builds its AUP before engaging a bank partner, approves a customer category, and then discovers the bank won’t support it.

At that point, you have a few options, none of them comfortable:

1. Off-board the customer. Operationally disruptive. Potentially contractual liability. Definitely relationship damage.
2. Negotiate an exception with the bank. Sometimes possible for individual customers with strong due diligence packages. Not a scalable strategy.
3. Find a different bank partner who will support the category. The nuclear option, and one with significant lead time.

The preventive path is straightforward: before finalizing your bank partner selection, verify that the partner’s prohibited/restricted business schedule is compatible with your intended customer base. This is a due diligence step that most fintechs skip because they’re focused on technical capabilities, pricing, and go-to-market speed.

Add it to vendor onboarding due diligence. It belongs there.

And build a contingency: your vendor exit plan for your bank partner should document what happens to restricted-category customers if the partnership ends or the bank restricts your program mid-flight.

So What? The Practical Checklist

AUP-bank alignment is not a one-time project. It’s a continuous compliance obligation that needs structured ownership and periodic review.

The minimum viable process:

• At bank partner selection: Obtain the bank’s prohibited/restricted business schedule. Map it against your intended customer categories before signing the program agreement.
• At contract finalization: Ensure the program agreement specifies which categories require pre-clearance and what the bank’s review timeline is.
• At AUP review (at least annual): Pull the current version of the bank’s category rules and re-run the mapping. Document any changes.
• At pre-clearance decisions: Log every request, response, and outcome.
• Monthly: Review RFI volume by category as a KRI. Escalate rising trend to TPRM governance.
• At any bank partner communication flagging categories or customers: Update the exception log and assess whether AUP revision is needed.

The fintechs that survived 2024’s BaaS enforcement wave largely did so because they had documented programs, responsive compliance teams, and bank relationships built on transparency rather than assumption. The ones that didn’t were operating with AUPs their bank partners had never reviewed and customer portfolios their bank partners didn’t understand.

That’s not a technology problem. It’s a governance problem. And it’s fixable.

The Third-Party Risk Management (TPRM) Kit includes vendor risk tiering templates, due diligence questionnaires, ongoing monitoring frameworks, and contract controls — built for fintechs and financial institutions managing complex third-party relationships including bank partner programs.

Related reading:

• Fintech Acceptable Use Policy: How to Handle High-Risk Customers
• Vendor Risk Management: The Complete Lifecycle
• Critical Vendor Exit Planning