Purpose of the Template
When deploying AI in your AML or sanctions screening program, you need a governance document that satisfies three key audiences: your internal audit committee, your regulator, and the data scientists building the models. This template provides the structure to document how your AI-driven compliance tools are governed, tested, and explained.
The EU AI Act came into force in August 2024. While fraud-detection AI generally doesn't fall into automatic high-risk classification, transparency obligations still apply when systems interact with customers. The NIST AI Risk Management Framework organizes oversight around four functions: govern, map, measure, and manage. This template follows that structure, translating it into decisions your compliance team can document and defend.
Prerequisites
Before customizing this template, ensure you have:
Clean source data. The model's output quality depends on your input quality. Fix any duplicates, missing fields, or inconsistent formatting in your customer, policy, and payment data. A model trained on incomplete data reproduces those flaws at scale.
A baseline risk assessment. Identify where your financial-crime risk concentrates: which products, geographies, and customer segments carry the highest exposure. Your AI deployment should target these areas, not replace human judgment entirely.
Cross-functional ownership. Compliance owns the rules, IT owns the deployment, and data science owns the model. All three need sign-off authority on what goes into production.
Legal review of your jurisdiction's AI rules. If you operate in states that adopted the NAIC Model Bulletin on AI systems or are subject to the EU AI Act, your legal team must confirm which obligations apply to your specific use case before finalizing the template.
The Template
AI MODEL GOVERNANCE FRAMEWORK
For: [Model name and use case, e.g., "Transaction Monitoring Alert Scoring Model"]
Owner: [Name, title]
Last updated: [Date]
Next review: [Date]
1. MODEL PURPOSE AND SCOPE
1.1 Business objective
What compliance decision does this model inform?
Example: "Prioritize transaction monitoring alerts by likelihood of true positive"
1.2 In-scope data
What data feeds the model?
Example: "Transaction amount, frequency, counterparty type, geographic origin"
1.3 Out-of-scope decisions
What does this model NOT decide?
Example: "Model scores alerts; human analyst makes Suspicious Activity Report decision"
2. EXPLAINABILITY STANDARD
2.1 Model type
[ ] Rule-based (fully transparent)
[ ] Decision tree / random forest (interpretable)
[ ] Neural network (requires SHAP or LIME explanation layer)
2.2 Explanation requirement
For each alert scored by the model, the system must produce:
- Top 3 contributing features
- Feature weights or SHAP values
- Plain-language rationale (e.g., "Flagged due to rapid succession of transactions below reporting threshold")
2.3 Audit trail
Every model decision is logged with:
- Input data snapshot
- Model version
- Output score
- Analyst override (if any) and reason
3. DATA QUALITY CONTROLS
3.1 Pre-deployment data validation
Before training:
- Completeness check: [X]% of records must have all required fields
- Consistency check: [describe validation rules, e.g., "Customer ID format matches CRM"]
- Bias check: [describe protected attributes and testing method]
3.2 Ongoing data monitoring
Weekly automated checks for:
- Missing values > [X]% threshold
- Drift in feature distributions (KL divergence > [threshold])
- New data categories not seen in training
3.3 Escalation path
If data quality falls below threshold:
- Pause model scoring
- Revert to rule-based alerts
- Notify: [role/committee]
4. BIAS TESTING AND FAIRNESS
4.1 Protected attributes
Test for disparate impact across:
- Customer geography
- Product type
- [Other attributes relevant to your book]
4.2 Testing frequency
- Pre-deployment: Full bias audit
- Quarterly: Automated disparity metrics
- Post-incident: Ad hoc review if pattern reported
4.3 Acceptable disparity threshold
[Define your threshold, e.g., "Alert rate for any geography may not exceed 1.5x the baseline rate without documented risk justification"]
5. HUMAN OVERSIGHT
5.1 Supervised operation
[ ] Model scores; human reviews and decides
[ ] Model auto-closes low-score alerts; human reviews medium and high
[ ] Model operates autonomously (requires heightened governance)
5.2 Override authority
Analysts may override model score. Overrides are:
- Logged with reason code
- Reviewed monthly for patterns
- Fed back into model retraining cycle
5.3 [Escalation to MLRO](/glossary/escalation-to-mlro)
Model-scored alerts escalate to MLRO if:
- Score is above [threshold]
- Analyst disagrees with score and cannot resolve
- Alert involves [high-risk category, e.g., PEP, high-risk jurisdiction]
6. MODEL MONITORING AND DRIFT DETECTION
6.1 Performance metrics
Track weekly:
- Precision (true positives / total positives)
- Recall (true positives / total actual positives)
- False positive rate
6.2 Drift thresholds
Retrain or recalibrate if:
- Precision drops > [X] percentage points
- Feature distribution shifts > [threshold]
- New regulatory designation changes risk landscape
6.3 Version control
- Model version tagged in all outputs
- Previous version retained for [X] months
- Rollback procedure documented
7. THIRD-PARTY MODEL RISK
(If model is vendor-supplied)
7.1 Vendor obligations
Vendor must provide:
- Model documentation (architecture, training data, limitations)
- Explanation layer or API
- Notification of model updates [X] days in advance
7.2 Internal validation
Before deploying vendor model update:
- Test on holdout sample
- Compare performance to current version
- Review for bias on your data
8. REGULATORY ALIGNMENT
8.1 Applicable frameworks
[ ] EU AI Act (transparency obligations)
[ ] NAIC Model Bulletin (state-specific)
[ ] NIST AI Risk Management Framework
[ ] FATF risk-based approach
8.2 Documentation for examiners
Maintain and update quarterly:
- This governance document
- Model validation report
- Bias testing results
- Performance trend analysis
9. REVIEW AND APPROVAL
Approved by:
- MLRO: _________________ Date: _______
- CTO or Data Science Lead: _________________ Date: _______
- Legal/Compliance Counsel: _________________ Date: _______
Next scheduled review: [Date, at least annually]
Customizing the Template
Section 1: Clearly define what the model does and doesn't decide. If it scores alerts but a human makes the final SAR decision, specify that. Regulators want to see where human judgment remains involved.
Section 2: Your explainability standard depends on your model type. If you're using a neural network, include an explanation layer (SHAP values or LIME) that translates the model's decision into features an analyst can verify. If using a decision tree, the tree itself serves as the explanation.
Section 3: Set data quality thresholds based on your current data state, not an aspirational target. If you currently achieve 95% completeness, don't set a 99% threshold that triggers constant alerts. Improve the data first, then tighten the threshold.
Section 4: Bias testing is essential. Ethical concerns and reputational risk don't wait for legislation. Test for disparate impact across customer segments and document your acceptable threshold. If one geography triggers alerts at twice the rate of another, provide a risk-based explanation for that disparity.
Section 5: Decide your supervision model early. Fully supervised (human reviews every alert) is safest but least efficient. Auto-closure of low-score alerts is faster but requires tighter monitoring. Document which model you're using and what triggers escalation.
Section 7: If using a vendor model, you can't skip validation just because you didn't build it. You're still accountable for its output. Require the vendor to provide performance metrics, explanation logic, and advance notice of updates. Test every update on a holdout sample before deploying it.
Validation Steps
Once you've customized the template:
Run it past your auditors. Internal audit should confirm the governance structure matches your institution's risk appetite and existing model risk policy. If you don't have a model risk policy, this document becomes your starting point.
Test the explanation layer. Take ten alerts the model scored and ask an analyst to reconstruct the rationale using only the logged features and weights. If they can't, your explainability isn't sufficient.
Simulate a regulatory request. Pretend your regulator asks, "Show me how this model decided to flag this customer." Walk through your audit trail, explanation output, and override log. If you can't produce a clear narrative in under ten minutes, tighten your logging.
Schedule the first quarterly review now. Model governance isn't a one-time document. It's a living framework. Set the calendar invite for your first performance review before deploying the model, or it won't happen.
The difference between a model that survives regulatory scrutiny and one that doesn't is documentation. This template gives you the structure to prove you know what your AI is doing and why.
