Skip to main content
Promotional banner for the pentest readiness checklist
Throwing Money at AML Won't Fix Your ProgramAML Framework
4 min readFor Regulatory Affairs Professionals

Throwing Money at AML Won't Fix Your Program

The Conventional Wisdom

After a major enforcement action, the typical response is to increase budgets, hire more analysts, and invest in new transaction monitoring software. When American Express National Bank faced a $350 million penalty from the OCC for BSA/AML deficiencies, the industry followed this script. Vendors pitched AI platforms, consultants promised overhauls, and LinkedIn buzzed with posts about "investing in compliance infrastructure."

The problem is, money and technology alone don't fix a broken program.

The Real Issue

The OCC didn't penalize American Express for lacking technology. The order cited a failure to "establish and maintain a BSA/AML compliance program reasonably designed to assure and monitor compliance with the BSA and its implementing regulations." This isn't about technology; it's about design.

You can't buy your way out of a program that wasn't "reasonably designed" from the start. "Reasonably designed" means your program must match your actual risk profile, not a vendor's template. Your controls must align with what your institution does, not a consultant's framework.

Most BSA/AML programs fail because they're built backward. Teams start with compliance outputs like SARs filed and alerts generated, then work backward to controls. Instead, start with risk scenarios specific to your business model and build controls forward from there.

Understanding the Evidence

The OCC's action didn't mention a lack of transaction monitoring systems or failure to file Suspicious Activity Reports. The deficiency was at the program level: the bank couldn't "assure and monitor" compliance.

This points to governance failures. When regulators say you can't "assure" compliance, they're questioning whether your board and senior management understand your actual risks. When they say you can't "monitor" compliance, they're challenging whether your first and second lines can prove the controls work.

The FATF Recommendations make this clear in Recommendation 1: financial institutions must "identify, assess and understand the money laundering and terrorist financing risks" for their customers, countries, products, and delivery channels. Technology helps execute that assessment but doesn't replace it.

Consider what "reasonably designed" means in practice. If you're a credit card issuer with cross-border merchant relationships, your customer due diligence program needs different controls than a domestic retail bank. If you process high-value wire transfers for commercial clients, your transaction monitoring thresholds should reflect that reality, not generic industry benchmarks.

The $350 million penalty signals that American Express's program didn't match its business model. That's not a technology problem you can solve with a bigger budget.

Steps to Take

Start with your actual money laundering risk scenarios, not those from a vendor's library. Focus on scenarios specific to your products, customer base, and geographic footprint.

Map each scenario to the three lines of defense. Your first line (business units) should own the risk. Your second line (compliance) should design controls that match the risk. Your third line (internal audit) should test whether the controls work. If you can't draw a straight line from a specific ML/TF risk through all three lines, you have a design problem.

Build program governance before buying new tools. Your board needs to understand what ML/TF risks the institution accepts, which ones you mitigate, and how you measure control effectiveness. This understanding can't come from a quarterly dashboard with green status indicators. It needs to come from scenario analysis that connects business decisions to compliance obligations.

Test your controls against your risk assessment, not your policy manual. If your risk assessment identifies trade-based money laundering as a material risk, you should be able to show how your customer due diligence, transaction monitoring, and SAR decision-making processes specifically address that scenario. If you can't, your program isn't "reasonably designed" for your risk profile.

Invest in the foundational work: data quality, case management workflows, escalation protocols, and management information that informs decisions. The OCC wants to see that you can "monitor" compliance. You need metrics that prove your controls catch what they're designed to catch, not just that they're operating.

Only after fixing the design should you upgrade the technology. Better transaction monitoring software won't help if you're monitoring for the wrong scenarios. AI-powered name screening is useless if your customer risk ratings don't reflect actual exposure.

When Technology and Budget Matter

Technology and budget do matter, but only after you've built a program that's reasonably designed for your risks.

If you've done the hard work of risk assessment, mapped controls to scenarios, and established governance that connects business decisions to compliance obligations, then yes, invest in better tools. Modern transaction monitoring platforms can reduce false positives. Network analysis can identify previously invisible relationships. Natural language processing can speed up SAR narrative review.

If your board understands your ML/TF risk profile and your three lines work together to manage it, then hire more analysts. A well-designed program with insufficient resources will fail just as surely as a poorly designed program with unlimited budget.

The conventional wisdom isn't wrong about what you need. It's wrong about the order of operations. You can't automate your way out of a program that wasn't designed to match your actual risks. The OCC's enforcement action against American Express is a $350 million reminder that compliance programs fail when they're built from vendor catalogs instead of risk assessments.

Fix the design first. Then spend the money.

Application Security Isn’t Optional Anymore.

You Might Also Like