Here’s the scenario that ends badly: six months ago, the compliance officer and the head of sales had a call about a cannabis-adjacent software company that wanted to run payroll through the platform. The risk was borderline. The compliance officer decided it was fine — the actual transactions were clean, the company held appropriate state licenses, and the fund flows were transparent. The customer got onboarded.

Now the sponsor bank is asking about the customer. Or an examiner is reviewing the file. Or the customer has triggered a SAR, and the investigation is working backward through the approval decision. And the compliance officer who made the call has left the company.

There is no memo. There are no notes. The decision existed in a call, an email thread that’s hard to find, and someone’s memory. None of that survives scrutiny.

TL;DR

• The exception memo is not overhead — it’s the artifact that makes your approval decision legible to a future examiner, bank partner, or investigator
• Every restricted-category or escalated customer should have a memo that could stand alone, without the person who wrote it
• The memo must capture: customer identity and category, specific activity, fund flow, prohibited/restricted analysis, controls, monitoring plan, approver(s), bank partner status, and exit triggers
• A memo written retroactively, after a problem emerges, is almost never persuasive — the time to document is before onboarding

What an Exception Memo Actually Does

The FFIEC BSA/AML Examination Manual requires that enhanced due diligence for high-risk customers include documented findings — not just completed steps. Regulators look at whether your institution understood the customer, understood the risk, made a deliberate decision, and recorded it. “We reviewed it” without a record of what you reviewed and what you concluded is not EDD.

An exception memo does three things:

1. It records the reasoning, not just the conclusion. Examiners can verify that a step was completed. What they can’t reconstruct from a checkbox is why the compliance team concluded that a borderline customer was acceptable. The memo captures the analysis — the specific activity, the fund flow assessment, the mitigating factors — so the decision can be evaluated and defended.

2. It creates accountability. When a named approver signs an exception memo, the approval is institutional, not personal. If that person leaves, the decision remains documented and attributable. If the decision later looks wrong, the memo shows what information was available at the time — which is the standard examiners apply.

3. It sets the monitoring baseline. The memo records what conditions the approval was based on. If those conditions change — transaction volume spikes, fund flow patterns shift, license lapses — the memo establishes what would trigger re-review or offboarding. Without a baseline, monitoring has nothing to compare against.

The Elements of a Defensible Exception Memo

A good exception memo is concise. It doesn’t need to be long. It needs to be complete. Here’s the structure:

1. Customer Identification

Basic: legal name, DBA, jurisdiction of incorporation, primary contact, date of application. Include any parent entities or affiliates that are relevant to the risk assessment. If there’s a UBO disclosure, reference it here.

2. Business Category and AUP Classification

State plainly what category this customer falls into under your AUP and why they required an exception or escalated review. Don’t softpedal it: “Customer is a licensed cannabis dispensary operating in Colorado, a restricted category under Section 3.2 of the Acceptable Use Policy” is better than vague framing that obscures why a memo was required.

If the customer is borderline — not clearly restricted but close — document the classification question explicitly and explain how it was resolved.

3. Specific Platform Use and Transaction Types

This is the most important section, and the one most often omitted or vague. Document:

• What products or features the customer is using
• What transaction types they will run (payroll, vendor payments, consumer purchases, B2B transfers, etc.)
• Expected volume and frequency
• Counterparty types (employees, suppliers, retail customers, etc.)

The FinCEN Customer Due Diligence rule and the FFIEC manual both require understanding the purpose and expected nature of the customer relationship. “Cannabis company — general business use” doesn’t satisfy that standard. “Licensed cannabis retailer using the platform exclusively for payroll distribution to ~40 employees, funded from a segregated corporate checking account at [Bank X]” does.

4. Fund Flow Description

Where do the funds originate? Where do they go? Through how many hops? This section should be written as a narrative, not a checklist:

Funds originate from Customer’s Colorado operating account at [Bank X]. Payroll instructions are submitted weekly via ACH. Funds are pushed to employee personal bank accounts. No consumer-facing transactions. No cash component. No third-party intermediaries.

For customers with more complex fund flows — multiple entities, international payments, crypto-to-fiat conversion — diagram or describe the flow in enough detail that a reviewer can spot what would be unusual.

5. Prohibited/Restricted Analysis

Address directly whether the customer triggers any prohibited category under your AUP, your bank partner’s rules, or card network rules. If they’re in a restricted category, state what made approval appropriate:

• Is the underlying activity legal in the relevant jurisdiction?
• Are required licenses held and verified?
• Is the specific platform use within the scope of what you’re permitted to support under bank partner rules?
• Are there any network registration requirements that apply (e.g., MCC registration for certain high-risk categories)?

If you obtained bank partner pre-clearance, reference the date and communication channel. If you didn’t, explain why pre-clearance wasn’t required.

6. Applicable Controls

List the specific controls that apply to this customer based on the risk assessment:

Don’t list controls generically (“enhanced monitoring”) when you can be specific (“transaction monitoring rules adjusted to flag cash-equivalent ACH above $5,000 vs. standard $10,000 threshold”). Generic controls look like boilerplate; specific controls look like risk analysis.

7. Monitoring Plan and Review Schedule

State the re-review date (typically 12 months for restricted customers, 6 months for those close to the prohibited line) and what would trigger an earlier review:

• Material transaction volume change (define the threshold)
• Adverse news or regulatory action against the customer
• License expiration or change in license status
• Bank partner inquiry or RFI
• SAR activity
• Chargeback or fraud rate exceeding threshold

8. Bank Partner Status

Note whether the bank partner relationship was considered in the approval decision:

• Does the bank’s AUP explicitly address this category?
• Was pre-clearance obtained? (Reference date and communication)
• Are there any bank-imposed conditions on this customer type?
• If the bank’s rules don’t directly address this category, note that assessment

This section protects you in both directions: if you did get bank pre-clearance, it’s documented. If the bank later claims surprise, you have a record.

9. Approval and Sign-Off

Name the decision-maker(s), their title, and the date. If the decision was escalated to a committee, reference the meeting date and attach or reference the minutes.

If the approval was conditional, state the conditions explicitly here.

10. Exit Triggers

The conditions under which this customer will be offboarded, independent of any general AUP review:

• Failure to renew required licenses within 30 days of expiration
• Transaction patterns materially inconsistent with described use case
• Fraud rate exceeding [X]%
• Formal request from bank partner
• Regulatory action against the customer
• Customer engages in prohibited transaction types

Writing exit triggers in advance is not pessimistic — it prevents the difficult conversation where nobody wants to make the call because the conditions for calling it weren’t defined.

A Note on Memo Length and Format

A well-constructed exception memo for a typical restricted-category customer is two to four pages. It should be able to stand alone — someone reading it cold, without having been in the conversation, should be able to understand who the customer is, why they required review, what was analyzed, what was decided, and on what conditions.

Longer isn’t better. A memo that runs ten pages because it includes regulatory background and definitions is harder to read and harder to rely on in a time-sensitive review. The structure above covers what’s needed. Fill it with specifics, not boilerplate.

What Examiners Look For — and What Creates Problems

Enhanced due diligence for high-risk customers is assessed both on process (did you complete the steps) and substance (did the analysis actually address the risk). Common deficiencies in exception documentation:

Vague activity descriptions. “General business banking” doesn’t describe the transactions that will actually run. Examiners push back on descriptions that could apply to any business.

No fund flow analysis. Knowing who the customer is isn’t the same as knowing where their money comes from. The FFIEC manual requires understanding the “sources and uses of funds in the account.”

Controls listed but not tailored. Standard monitoring applied to a restricted-category customer raises the question: did you actually adjust anything for the elevated risk, or did you just check a box?

Approver not identified. Compliance “reviewed” is insufficient. Who made the call? What is their title? What information did they have?

Bank partner section missing. In a BaaS context, omitting the bank partner analysis is a structural gap. Your bank will ask; the documentation should already have the answer.

No re-review date. Static approvals for high-risk customers suggest the relationship is not being actively monitored. A specific re-review date (or trigger event) shows the approval is being actively managed.

Tying the Memo to Your AUP Process

The exception memo is the downstream artifact of your AUP decision framework. If your AUP clearly defines prohibited vs. restricted categories and specifies what analysis is required for restricted customers (see Prohibited vs. Restricted Businesses: How Fintechs Should Decide What They Can Support), the memo becomes the record of that analysis being applied to a specific customer.

Without a defined decision framework, memos become inconsistent — each one reflects what the reviewer happened to think of, not a consistent analytical process. Without memos, the framework has no evidence of being applied.

They work together. The framework defines what to analyze. The memo proves you analyzed it.

For the diligence questions specific to cannabis, weapons, adult content, gambling, and crypto customers that feed the memo’s analysis section, see Restricted Business Due Diligence: Questions to Ask Before You Approve.

So What?

Exception documentation isn’t a compliance team favor to the rest of the organization. It’s the record that makes your approval decision defensible to anyone who wasn’t in the room when it happened — an examiner, a bank partner auditor, a new compliance officer, a litigator, or a regulator investigating a problem with the customer.

The review that happened in a phone call last May doesn’t exist for those purposes. The memo does.

Every restricted-category customer onboarded without a documented approval memo is a customer where the decision is undefendable — not necessarily because it was wrong, but because there’s no record of what made it right.

Writing a two-page memo before onboarding takes maybe 30 minutes. Reconstructing why a customer was approved 18 months later, during a regulatory examination, with the original reviewer no longer at the company, takes considerably longer — and may not be possible.

For fintech-specific AUP frameworks, exception memo templates, and restricted business decision matrices, the Compliance Essentials bundle includes ready-to-use documentation for each stage of the customer approval workflow.

For the foundational AUP structure, see Fintech Acceptable Use Policy: How to Handle High-Risk Customers Without Killing Good Business.

Sources: FFIEC BSA/AML Manual — Customer Due Diligence · FinCEN CDD Final Rule · Enhanced Due Diligence for High-Risk Customers (NETBankAudit) · Stripe — Overview of Compliance Fundamentals for Fintechs · Bank-Fintech Partnership Regulatory Scrutiny 2025 (Corporate Compliance Insights)