The trap most fintechs fall into: build a list of industry codes and call it a policy. Cannabis: prohibited. Gambling: prohibited. Weapons: prohibited. Adult content: prohibited. Then the head of sales brings in a deal — a SaaS company whose customers happen to be cannabis dispensaries, or a manufacturer of firearm safes, or a licensed sports betting operator in three regulated states — and suddenly nobody agrees on what to do.

The list fails because business category is the wrong unit of analysis. The activity that touches your platform is the right unit. The specific transaction type matters. The fund flow matters. The list is where you start, not where you stop.

TL;DR

• Prohibited means never, regardless of controls — driven by network rules, legal prohibitions, or hard bank partner exclusions
• Restricted means not without a documented process: pre-approval, enhanced diligence, defined controls, ongoing monitoring
• The correct question is not “what industry are they in?” — it’s “what transactions run through the platform, from whom, to whom, and why?”
• Fintechs that substituted a list for a decision framework created the conditions for the BaaS enforcement wave of 2024

Why Industry Labels Aren’t Enough

Card networks assign merchants a Merchant Category Code (MCC) at onboarding. The MCC describes the core business activity — drug stores, gambling, fuel dealers, adult content. Acquirers use MCCs to assess risk and flag prohibited business types before signing up a merchant. Networks maintain explicit lists of prohibited MCCs and high-integrity-risk categories that require special registration.

But MCCs categorize businesses, not transactions. A licensed firearms retailer (MCC 5941 — Sporting Goods Stores) processing in-store retail card transactions looks different from a manufacturer of military hardware running B2B wire transfers. Same industry. Very different risk. Same MCC range. Very different compliance posture.

The BaaS sector learned this at scale and in public. Evolve Bank & Trust received a Federal Reserve cease-and-desist order in June 2024 for deficiencies in AML, risk management, and consumer compliance programs. Among the specifics: inadequate diligence over what fintech partners were actually onboarding, and insufficient assessment of customer categories. The consent order barred Evolve from adding new fintech partners or new product categories without prior supervisory approval. That is the regulatory cost of treating a category list as a due diligence process.

Blue Ridge Bank entered an OCC consent order in early 2024 that found the bank in “troubled condition” following its BaaS expansion — partly because oversight of fintech partner customer bases lagged the pace of growth. More than a quarter of the FDIC’s enforcement actions in 2024 targeted sponsor banks in embedded finance partnerships. The pattern is consistent: institutions that let their fintech partners self-certify category compliance without meaningful oversight got caught.

The Three-Bucket Framework

Every business your platform could serve falls into one of three categories. The lines between them need to be explicit, written, and defensible — not just to regulators, but to your own sales and product teams who need consistent answers.

Bucket 1: Prohibited — Full Stop

Prohibited businesses cannot be supported regardless of controls, enhanced monitoring, bank relationship history, or how the deal is structured. Prohibition is typically anchored to one of four sources:

Card network hard bans. Visa and Mastercard maintain explicit lists of prohibited transaction types and merchant categories. Some MCCs require special registration; others are outright prohibited in certain jurisdictions or transaction configurations. These rules override anything in your internal policy.

Legal prohibition. Federal illegality is the clearest example: cannabis remains a Schedule I controlled substance under federal law, which puts the underlying business activity in conflict with BSA obligations for most federally regulated bank partners. Sanctioned entities. Unlicensed money transmission. Activities requiring licenses that cannot be verified or that don’t exist.

Bank partner absolute exclusions. Your sponsor bank’s own AUP may hard-prohibit certain categories regardless of your controls. If your bank won’t touch cannabis, your internal policy approving cannabis means nothing — and onboarding cannabis customers without bank awareness creates a debanking risk that is far more disruptive than the lost deal.

Internal categorical exclusions. Businesses you’ve independently assessed as carrying unacceptable risk: dark web platforms, unlicensed crypto exchanges in high-risk jurisdictions, pyramid schemes, unregistered investment products.

The test for prohibited: no realistic set of controls makes this acceptable. If you find yourself asking whether better monitoring might change the answer, it probably belongs in Bucket 2.

Bucket 2: Restricted — Pre-Approval Required

Restricted businesses can be supported — but only with explicit pre-approval from compliance (and often legal), enhanced due diligence on the specific business and use case, defined controls, and an ongoing monitoring plan. Categories that commonly land here:

The test for restricted: the activity is legal, the risk is manageable with the right controls, but you cannot approve a customer in this category without understanding the specific business, what it does on your platform, and what the fund flow looks like.

Bucket 3: Permitted — Standard Onboarding

Businesses that pass standard CDD/KYC, aren’t in a flagged category, and whose transaction types fall within your normal operating scope. Even permitted businesses can trigger enhanced review based on volume, velocity, counterparty flags, or adverse news hits — that’s operational monitoring, not a category classification.

The Questions That Actually Separate the Buckets

The category bucket is the starting point. For anything in Bucket 2, you need answers to five questions before the customer touches your platform.

What transactions will actually run through the platform? This is the most important question. A dispensary using your platform for payroll and accounts payable looks nothing like a dispensary processing consumer retail sales. Same business, same MCC exposure — but fundamentally different transaction risk. Get specific: which transaction types, what counterparties, what volume, what use case.

Where do the funds come from and where do they go? Cash-intensive businesses with opaque fund sources create AML risk regardless of their legal status. A licensed firearms retailer with transparent card-transaction revenues from retail customers may carry lower actual risk than an apparently benign business running complex layered fund flows. The FFIEC BSA/AML Examination Manual is explicit: EDD for high-risk customers requires understanding sources and uses of funds, not just identity verification.

Is the activity licensed and verifiable? Cannabis, gambling, MSBs, and debt collectors all operate under state licensing regimes. Firearms retailers require FFLs. Document the license, record its expiration, and build a process for renewal tracking. If the license can’t be verified, the customer cannot be approved.

Does this require bank partner pre-clearance? Your internal approval process doesn’t operate in a vacuum. Your sponsor bank has its own AUP, and their rules take precedence over yours when it comes to what can actually run on their rails. If you’ve been getting RFIs about similar customers, treat that as an early signal of bank discomfort. Pre-clear in writing before you commit to the customer. For a detailed walkthrough of mapping your AUP to bank partner requirements, see Bank Partner Alignment for AUPs.

What is the exit trigger? Before you onboard a restricted customer, document what would cause you to offboard them: license loss, transaction pattern deviation, fraud rate exceeding threshold, bank partner direction, regulatory action. Writing the exit conditions in advance removes the ambiguity when a real trigger event occurs.

The Fund Flow Test in Practice

Here’s a worked example. A weapons manufacturer wants to use your B2B payments platform to distribute dividends to investors.

• Transactions: Dividend distributions, U.S. corporate treasury to domestic shareholders
• Fund source: Corporate bank account — transparent, verifiable treasury function
• Counterparties: Domestic accredited investors, standard identity verification
• Prohibited/restricted analysis: Weapons manufacturer falls in the restricted category. The specific use case — corporate treasury distributions — is entirely unrelated to the manufacturing activity, is fully legal, and creates no unusual compliance exposure
• Bank partner: Needs written pre-clearance based on the customer’s primary business category
• Assessment outcome: Approve with documentation of the specific use case review, fund flow analysis, and bank partner confirmation

Now flip it: the same weapons manufacturer wants to process retail sales of firearm cleaning kits through your consumer payments stack. Different transaction mix, different counterparty base, different chargeback risk profile, different network registration requirements. Same company. A different analysis is required because the platform use is different.

The category is the same. The decision is different. That’s the point.

What Examiners and Bank Partners Actually Ask

When regulators review your customer base — or when your sponsor bank conducts an annual review of your program — they are not running down a list of industry codes. They’re asking:

• What did you know about this customer at onboarding?
• What did you review about their specific platform use?
• Who approved it, when, and what was the documented rationale?
• What controls apply to this customer?
• What monitoring have you conducted since onboarding?

An AUP that captures category without activity gives you nothing useful to show them. Stripe’s prohibited and restricted business guidance reflects this layered logic: some categories are hard-prohibited, others are restricted pending approval, and the approval process evaluates the specific business — not just the industry label.

For the documentation side — what the exception memo should contain when you approve a restricted customer — see AUP Exception Memos: How to Document a High-Risk Customer Approval.

Building the Framework

The structure that holds up:

1. Define your prohibited list — anchored to network rules, legal prohibitions, bank partner hard exclusions, and documented internal decisions. This list should change rarely, and any change requires legal or CCO sign-off.

2. Define your restricted list — businesses that can be supported with pre-approval. Specify the approval path, required diligence, applicable controls, monitoring obligations, and re-review triggers.

3. Build a fund-flow assessment template — for restricted customers, capture the specific transaction types, fund flow description, counterparties, license documentation, monitoring plan, and exit triggers. This becomes your exception memo.

4. Establish the approval chain — who reviews, who approves at each tier, and what triggers escalation to risk committee or executive sign-off.

5. Align with bank partner rules — map your internal categories against your sponsor bank’s prohibited and restricted lists. Any category the bank prohibits should be at minimum restricted for you; onboarding a customer the bank prohibits without their knowledge is a debanking event waiting to happen.

6. Build review triggers — restricted customers require re-review at least annually, and sooner when transaction patterns change materially, adverse news emerges, or license status changes.

So What?

The fintechs that ended up in front of regulators over customer categories typically didn’t build a bad list. They built a list without a decision process behind it. When edge cases arrived — and they always do — there was no framework to apply, so decisions happened inconsistently, informally, and undocumented.

“Prohibited vs. restricted” isn’t a compliance labeling exercise. It’s a commitment to a specific analytical process every time a gray-area customer walks through the door. If you can explain to an examiner why customer A is in Bucket 2 and customer B is in Bucket 3, and produce documentation of the analysis, you’re in defensible territory. If the answer is “we use a list,” you’re not.

The question isn’t just whether your policy says the right things. It’s whether anyone can follow that policy to a consistent decision.

For due diligence questions specific to cannabis, weapons, adult, gambling, and crypto customers, see Restricted Business Due Diligence: Questions to Ask Before You Approve. For the template structure behind a defensible AUP, see Acceptable Use Policy Template for Fintechs.

The Compliance Essentials bundle includes AUP templates, exception memo formats, and restricted business decision frameworks built for fintech practitioners.

Sources: Federal Reserve Evolve Bank Enforcement Action (June 2024) · FFIEC BSA/AML Manual — Customer Due Diligence · Stripe Prohibited and Restricted Businesses FAQ · LegitScript — Merchant Category Codes and Card Brand Compliance · Bank-Fintech Partnership Regulatory Scrutiny 2025 (Corporate Compliance Insights)