Policies and Procedures — What Regulators Actually Want to See

The Difference Between a Policy That Passes and One That Fails

Every AML program must have written policies and procedures — this is Pillar 1 of the five pillars framework. But there is an enormous difference between policies that satisfy regulators and policies that don't. The distinction often comes down to specificity, operational relevance, and evidence of implementation. Regulators don't want to see that you copied a template; they want to see that your policies reflect how your compliance program actually operates.

Structure: How to Organize Your AML Policy Framework

Best practice is a three-tier structure:

Tier 1: Board-Level AML/BSA Policy (10-20 pages)

This is your apex document, approved by the board of directors (or equivalent governing body) at least annually. It should include:

• Statement of the institution's commitment to BSA/AML compliance
• Definition of roles and responsibilities (board, senior management, compliance officer, business lines, internal audit)
• Risk appetite statement — what level of ML/TF risk the institution is willing to accept
• Overview of each program element (CIP, CDD, transaction monitoring, SAR filing, sanctions, training, independent testing)
• Escalation and reporting framework (how compliance issues are reported to the board)
• Policy review and update schedule

Tier 2: Departmental Procedures (50-100+ pages total)

These are detailed, operational procedures for each program element. Examples:

• CIP/CDD Procedures Manual: step-by-step guidance for customer onboarding, verification methods, risk rating assignment, EDD triggers, and beneficial ownership identification
• Transaction Monitoring Procedures: how alerts are generated, assigned, investigated, escalated, and closed; what constitutes suspicious activity; documentation standards for alert dispositions
• SAR Filing Procedures: when to file, who approves, how narratives should be written, the 30-day filing timeline, SAR confidentiality requirements (31 U.S.C. § 5318(g)(2)), and what to do when law enforcement requests a hold on filing
• Sanctions Screening Procedures: screening frequency, match disposition workflow, escalation of potential true matches, OFAC reporting requirements
• Record Retention Schedule: what records are retained, for how long, in what format, and how they are retrievable for regulatory requests or law enforcement subpoenas

Tier 3: Operational Playbooks and Job Aids (variable length)

These are the step-by-step guides that analysts use daily:

• Alert investigation playbooks with decision trees for common scenarios
• SAR narrative templates with required elements and example narratives
• OFAC hit disposition worksheets
• EDD questionnaire templates for different customer types
• Quick reference guides for system-specific tasks (how to pull transaction reports, how to file through the BSA E-Filing system, etc.)

Must-Have Elements That Regulators Look For

Based on common examination findings and consent orders, here are the specific elements regulators expect but frequently find missing:

• Specificity of thresholds and timelines: Don't write "SARs will be filed in a timely manner." Write "SARs will be filed within 30 calendar days of the initial detection of suspicious activity, with a 60-day extension permitted if no suspect is identified (per 31 CFR 1020.320(b)(3))." Vague language gives you no safe harbor.
• Escalation criteria and authority levels: Specify exactly who can make what decisions. For example: "Level 1 analysts may close alerts with no suspicious activity. Level 2 analysts may escalate to SAR consideration. The BSA Officer or designee makes all SAR filing decisions and signs all SARs."
• Risk-based differentiation: Your procedures should clearly show how you treat high-risk, medium-risk, and low-risk customers differently. If your CDD procedures are the same for a domestic retail customer and an offshore MSB, that's a red flag.
• Exception handling: Document how exceptions to standard procedures are handled, approved, and tracked. For example, if a customer fails CIP but you want to give them 7 days to provide additional documentation, that should be a documented exception with management approval — not an ad hoc decision.
• Regulatory references: Cite the specific regulations that each procedure implements. This demonstrates that your program is built on a regulatory foundation, not just institutional preference.
• Version control and revision history: Every policy and procedure document must include a revision history showing when it was last updated, what changed, and who approved the changes.

Common Gaps That Lead to Findings

• Policies that don't match practice: The number one finding in AML examinations. If your policy says you screen customers against OFAC daily but you actually screen weekly, that's a violation — even if weekly screening might be acceptable on its own. Your policy sets the standard you're measured against.
• No procedure for 314(a) requests: FinCEN sends 314(a) requests to financial institutions asking them to search their records for information related to money laundering or terrorist financing suspects. You must have a documented procedure for receiving, searching, and responding to these requests within the required 14-day window.
• No suspicious activity examples: Regulators expect your procedures to include examples of what constitutes suspicious activity in the context of your specific products and customer base — not just a generic list from the FFIEC Manual.
• No procedures for currency transaction reporting exceptions: If you're a bank, you must have procedures for the Phase I and Phase II CTR exemption process (31 CFR 1020.315).
• No data governance provisions: With increasing reliance on technology, your procedures should address data quality, system access controls, model validation, and technology change management.

Policy and Procedure Checklist

• ☐ Board-level AML policy approved annually with documented board minutes
• ☐ Departmental procedures covering all BSA requirements with specific thresholds, timelines, and escalation paths
• ☐ Operational playbooks for analyst-level tasks with decision trees and examples
• ☐ Version control and revision history on all documents
• ☐ Annual review of all procedures to verify they match current practice
• ☐ Regulatory citations throughout — tie each procedure to the regulation it implements
• ☐ Exception handling procedures with approval requirements and tracking mechanisms
• ☐ Distribution records showing that relevant staff have received and acknowledged current procedures