You're about to deploy an AI model that scores transaction risk, triages alerts, or flags network patterns. Before you proceed, your board, regulator, and audit committee will ask: can you explain what it's doing and prove it meets your AML/CFT Framework obligations?
This checklist guides you through the governance, explainability, and compliance controls needed before putting AI into production for any AML function. It's designed for compliance officers who are accountable when the model makes a decision your examiner will question six months from now.
Prerequisites
Before starting this checklist, confirm you have:
- Written authority from your MLRO or BSA Officer to deploy AI in a regulated AML function.
- Access to model documentation from your vendor or data science team, including training data sources and performance metrics.
- A designated model owner who can explain technical decisions to non-technical stakeholders.
- Legal sign-off that your AI use doesn't conflict with fair lending, ECOA, or other non-discrimination requirements if the model influences customer treatment.
If you're missing any of these, stop. You're not ready to deploy.
Governance and Accountability
1. Document Model Decision Ownership
Requirement: Your AML/CFT Framework must assign clear accountability for every control. AI doesn't eliminate that obligation.
Done when: You have a written role assignment naming the individual (by title and name) accountable when the model generates a false negative that becomes a regulatory issue. This person must have authority to override, tune, or shut down the model.
What good looks like: Your model governance document states: "The BSA Officer retains final accountability for all transaction monitoring decisions, including those informed by the AI scoring model. The BSA Officer has authority to disable the model if performance degrades below the thresholds defined in Section 4."
2. Define Performance Thresholds for Human Review
Requirement: Regulators expect you to know when your controls are failing. AI models drift. You need trip wires.
Done when: You've set quantitative thresholds (false positive rate, false negative rate, alert closure time) and documented the review frequency. You've assigned someone to run the measurement and escalate when thresholds are breached.
What good looks like: "If the model's false negative rate exceeds 8% in any monthly sample, the Compliance Analytics Manager escalates to the MLRO within 48 hours and the model enters supervised mode until root cause is identified."
3. Explain the Model's Logic in Plain Language
Requirement: Model explainability isn't optional. If you can't explain why the model flagged (or didn't flag) a transaction, you can't defend your AML/CFT Framework during an exam.
Done when: You have documentation that translates the model's decision factors into language a non-technical examiner understands. You've tested this explanation with your internal audit team or outside counsel.
What good looks like: "The model assigns risk scores based on four weighted factors: transaction velocity (30%), counterparty jurisdiction risk (25%), deviation from customer profile (25%), and network centrality (20%). For any alert, the system generates a plain-language explanation showing which factors exceeded baseline and by how much."
Regulatory Compliance
4. Map AI's Role to Your Existing AML/CFT Framework
Requirement: Your AML/CFT Framework is a living document. Adding AI means updating it.
Done when: Your written AML/CFT Framework explicitly describes where AI fits in your Customer Due Diligence, Transaction Monitoring Rules, or Name Screening workflows. The description includes what the AI does, what it doesn't do, and where humans retain decision authority.
What good looks like: "Section 6.2 (Transaction Monitoring) now includes: 'AI-assisted risk scoring pre-filters alerts before analyst review. The model does not auto-close alerts. All disposition decisions require human approval per Section 6.4.'"
5. Document Training Data Sources and Bias Testing
Requirement: If your model learned from historical data, it learned your historical biases. Regulators and fair lending enforcers will ask how you tested for disparate impact.
Done when: You have a written summary of your training data (time period, geography, customer segments) and results from bias testing across protected classes and customer risk categories. If you found bias, you've documented your mitigation steps.
What good looks like: "Training data: 2019-2023 transaction records from U.S. consumer accounts. Bias testing (June 2024) showed no statistically significant difference in alert rates across customer income bands after controlling for transaction volume. Testing repeated quarterly."
6. Validate the Model Against Known Typologies
Requirement: Your Transaction Monitoring Rules must detect the typologies relevant to your risk profile. AI models are no different.
Done when: You've tested the model against at least five documented money laundering typologies relevant to your customer base (Smurfing, trade-based laundering, funnel accounts, etc.) and confirmed it generates alerts at acceptable rates. You've documented the test scenarios and results.
What good looks like: "Validation testing (July 2024) confirmed the model flags 95% of simulated Smurfing patterns and 89% of simulated funnel account activity within the first 30 days of the pattern emerging. Test scenarios archived in Model Validation folder."
Operational Controls
7. Build and Review an Override Log
Requirement: When analysts override the model's recommendation, you need to know why. Pattern overrides signal model failure.
Done when: Your system logs every instance where a human analyst disagrees with the model's score or recommendation. You've assigned someone to review the log monthly and escalate patterns to the model owner.
What good looks like: "Override log reviewed monthly by Compliance QA Lead. In September, 18% of overrides involved the model under-scoring cash-intensive businesses. Model owner notified; retraining initiated."
8. Test Your Ability to Operate Without the Model
Requirement: AI is a tool, not a replacement for your AML/CFT Framework. If the model fails, you need a fallback.
Done when: You've documented and tested your manual procedures for handling alerts if the AI system goes offline. Your team knows how to revert to rule-based monitoring without a gap in coverage.
What good looks like: "Contingency plan tested in August 2024 tabletop exercise. Team reverted to legacy rule set within four hours. All alerts during the simulated outage were dispositioned within SLA."
Common Mistakes
Assuming vendor validation is enough. Your vendor tested their model on their data. You need to validate it on your transaction patterns, your customer base, and your risk typologies. Vendor documentation is a starting point, not a finish line.
Treating AI as a black box. If you can't explain it, you can't defend it. Regulators won't accept "the algorithm said so" as a rationale for missing a Suspicious Activity Report.
Skipping the bias testing. Even if your model doesn't directly use protected class data, it can learn proxies. Test for disparate impact before deployment, not after a fair lending complaint.
Forgetting to update your AML/CFT Framework documentation. Your written program is your contract with your regulator. If the AI isn't in the manual, it's not part of your official control framework.
Next Steps
Once you've completed this checklist:
Schedule your first post-deployment review for 30 days out. Set the agenda now: model performance against thresholds, override log review, and any examiner questions received.
Add model performance metrics to your quarterly board reporting. Your board approved the AI investment; they need to see whether it's working.
Plan your annual validation. Independent model validation isn't just for credit risk models. Your internal audit team or a third party should review your AI controls at least annually.
If you can't check every box on this list, you're not ready to deploy. The cost of getting it wrong isn't just a failed model; it's a failed exam and a consent order that names you personally.
