TL;DR

• A fintech AUP needs more than a list of prohibited industries — it needs a complete structure: seven sections, a three-tier decision table, a documented approval path, post-approval monitoring triggers, and bank partner alignment.
• The three tiers — Prohibited, Restricted (enhanced review), and Permitted-with-monitoring — give the compliance team a shared framework for making consistent decisions without relitigating every gray-area customer.
• Approval paths for restricted customers must be documented before the customer relationship starts, not improvised during an RFI or examination.
• In 2024, more than a quarter of FDIC enforcement actions targeted sponsor banks in embedded finance partnerships — and the common thread was inadequate oversight of what fintech clients were doing on the bank’s charter.

Getting an acceptable use policy right requires structure. Most fintechs start with a list — prohibited businesses on one side, some version of “everything else is fine” on the other — and call it a policy. Then a cannabis dispensary applies. Or a weapons dealer. Or a crypto exchange operating in jurisdictions that make the sponsor bank nervous. And the compliance team starts improvising decisions that should have been settled before the first application came in.

The problem isn’t the list. The problem is that a list without structure isn’t a policy. It doesn’t tell anyone how to make a decision when a customer doesn’t fit cleanly on either side of the line. It doesn’t document how the decision gets made, by whom, with what evidence, or under what conditions. And it doesn’t tell the sponsor bank’s examiner what your program is actually designed to prevent.

This template gives you the structure. The list is something you’ll customize to your business. The seven sections below are what every fintech AUP needs, regardless of which industries you serve.

The Regulatory Stakes of Getting AUP Wrong

The enforcement record from 2024 makes this concrete. More than a quarter of the FDIC’s enforcement actions that year targeted sponsor banks involved in embedded finance and Banking-as-a-Service programs. The consistent theme: the bank failed to adequately oversee what fintech clients were doing on its charter.

Blue Ridge Bank unwound approximately 40 fintech partnerships — representing $466 million in deposits — after an OCC consent order cited BSA/AML failures tied to inadequate oversight of fintech programs. Evolve Bank received a Federal Reserve cease-and-desist in June 2024. Piermont, Sutton, Thread, Lineage — the 2024 BaaS consent order list is long.

What does this mean for fintechs? When a regulator examines the bank’s fintech program, they look at whether the bank understood what was running on its charter. If the fintech’s AUP didn’t give the bank clear answers — or worse, if the fintech’s AUP didn’t align with the bank’s own prohibited and restricted categories — the bank bears the regulatory consequence and the fintech bears the program consequence.

A well-structured AUP is both a compliance control and a bank partner document. It demonstrates that your program is built to make consistent, defensible decisions — not to maximize acceptance rates.

The Seven-Section AUP Structure

Section 1 — Scope and Purpose

This section defines what the AUP covers and who it applies to. It should state:

• Products covered: Which products and services the AUP governs (payments, lending, deposit accounts, card programs)
• Entities covered: Which legal entities, operating brands, or market segments are in scope
• Customer types covered: Businesses, individuals, merchants, or specific customer segments
• Policy hierarchy: How the AUP relates to your BSA/AML policy, KYC policy, and bank partner program agreement

The scope section matters because it prevents scope creep arguments when a restricted customer applies through a product line that compliance didn’t think the AUP covered. Scope everything.

Section 2 — Three-Tier Customer Classification

The core of any AUP is a classification system that gives the business and compliance a shared language. Three tiers work:

Tier 1 — Prohibited. Categories and activities the platform will not support under any circumstances. No exceptions, no escalation path, no revenue justification sufficient to approve. These are your absolute limits.

Tier 2 — Restricted (Enhanced Review Required). Categories the platform may support, but only after enhanced due diligence, senior approval, bank partner pre-clearance where required, and specific monitoring conditions. The majority of gray-area decisions live here.

Tier 3 — Permitted with Standard or Enhanced Monitoring. Categories the platform accepts with standard onboarding or with elevated but not exceptional monitoring. Lower-risk segments that don’t require the full restricted-customer approval workflow.

Section 3 — Specific Category Lists by Tier

This is where most AUPs stop — and it’s only one-third of what’s needed. The lists should cover:

Prohibited categories (examples — customize to your bank partner and risk appetite):

• Illegal goods, services, or content under applicable law
• Child exploitation material
• Unlicensed gambling or lottery operations
• Sanctions-listed or OFAC-blocked persons and entities
• Unlicensed money transmission
• Ponzi schemes, advance fee fraud, and investment fraud
• Activities prohibited by card network rules (Visa, Mastercard operating regulations)

Restricted categories (examples requiring Tier 2 approval path):

• Cannabis and hemp/CBD businesses (state-legal, federally complex)
• Online gambling and gaming with monetary prizes (varies by state licensing)
• Adult entertainment and content platforms
• Firearms, ammunition, and accessories dealers
• Money services businesses, currency exchanges, and check cashers
• Crypto exchanges and virtual asset service providers
• High-volume third-party payment processors and payment facilitators
• Payday lenders and high-cost credit products
• Debt settlement and credit repair companies
• Multi-level marketing organizations
• Pawnbrokers and precious metals dealers

Importantly: a restricted category is not a prohibited one. Stripe’s restricted businesses list and Finix’s prohibited and restricted policies are instructive examples of how major payment platforms draw these distinctions publicly. Your list may differ — but the structure should be explicit.

Section 4 — Approval Path for Restricted Customers

The approval path is the most operationally important section. Without it, every restricted-category decision becomes a one-off negotiation between sales and compliance.

A documented approval path includes:

The approval path should also specify what happens when a restricted-customer application is denied. Denial should be documented with rationale — both for audit purposes and to ensure consistency across similar applications.

For alignment with your sponsor bank’s requirements, refer to the guidance in the post on bank partner AUP alignment. Your approval path needs to account for the bank pre-clearance step — not just your internal review.

Section 5 — Monitoring Triggers After Approval

Approval is the beginning of the relationship, not the end of the risk. Restricted customers require defined post-approval monitoring that goes beyond standard transaction monitoring.

Volume triggers. Set a baseline transaction volume for each restricted customer at approval. If monthly volume exceeds the baseline by more than 20–30% without a documented business explanation, a compliance review is triggered. Unreported volume growth is a common indicator that the platform is being used for something other than the approved use case.

Transaction pattern triggers. Monitor for transactions inconsistent with the approved activity — different counterparties, different jurisdictions, different product types. A cannabis dispensary whose account starts receiving high-value wires from international counterparties is using the platform differently than approved.

Complaint and chargeback thresholds. Set lower complaint and chargeback rate thresholds for restricted customers than for standard customers. High chargeback rates can indicate consumer harm or fraud. For restricted categories, the tolerance for elevated chargeback rates is lower because the baseline regulatory risk is already higher.

Licensing and compliance re-verification. At least annually, verify that the customer’s licenses are still in good standing, that their business hasn’t changed materially, and that they haven’t been subject to enforcement actions, regulatory sanctions, or adverse media since the original approval.

Annual relationship review. Every restricted-category relationship should trigger an annual formal re-review: same approval path, updated EDD, updated risk rating, bank partner confirmation if required.

Section 6 — Bank Partner Alignment

Your AUP cannot be finalized until you have mapped it against your sponsor bank’s program agreement. The bank’s prohibited and restricted categories are the binding constraint — your fintech cannot process transactions the bank won’t support, regardless of what your internal AUP says.

The alignment documentation should capture:

• Which of your AUP’s permitted categories are prohibited by the bank (these must move to your prohibited list)
• Which restricted categories require bank pre-clearance before you can approve a customer
• Which categories the bank has placed additional monitoring requirements on
• The bank’s process for raising concerns about specific customers or transaction patterns

For the KYC policy and AUP to function together, restricted-category customers should also be flagged in the KYC system for enhanced monitoring — the KYC risk rating, onboarding documentation requirements, and ongoing review cadence should all reflect the AUP classification.

Review this alignment at least annually and whenever your bank partner issues updated program requirements or communicates concerns about your customer mix via RFI or formal correspondence.

Section 7 — Exception Process

Sometimes a customer or transaction doesn’t fit cleanly into any tier — or fits into restricted but the circumstances are unusual enough that a standard approval path doesn’t cover the decision.

The exception process should define:

• What constitutes an exception: A customer category not covered by the current lists, a use case that sits between tiers, or a compliance override request
• Who can request an exception: Typically limited to senior relationship managers or product leads, not frontline sales
• The exception memo format: Customer description, specific activity, fund flow, why it doesn’t fit the standard framework, risk analysis, proposed controls, and recommended decision (see exception memo guidance for more on this format)
• Who approves exceptions: At minimum the CCO; for significant exceptions, the risk committee or board sub-committee
• How exceptions feed back into the AUP: Recurring exception requests on the same category are a signal that the category list needs updating

So What? Building an AUP That Holds Up

The seven-section structure is not bureaucratic overhead. It’s the difference between a policy that functions as a compliance tool and one that functions as a filing exercise.

In 2025, AML-related fines against fintechs and payment processors exceeded $160 million globally, driven largely by insufficient controls over what was moving through platforms — including what types of customers were approved without adequate due diligence. The common examiner and enforcement finding: vague policies that didn’t give compliance teams clear direction, approval paths that were improvised deal by deal, and no monitoring program that would have surfaced customer behavior that diverged from the original approval.

An AUP with a clear three-tier classification, a documented approval path, defined monitoring triggers, and bank partner alignment addresses each of those failure modes. It doesn’t guarantee a clean examination. It does guarantee that compliance can defend every decision with documentation that shows the decision was deliberate, reviewed, and monitored.

The Compliance Essentials bundle at risktemplate.com includes an acceptable use policy template, a restricted-customer intake form, an exception memo template, and monitoring trigger documentation designed for fintechs building or upgrading their AUP frameworks.