Aml Compliance

AML / Compliance

When to Use

• Design or mature a risk-based AML/CFT program (policies, roles, three lines of defense)
• Scope and execute KYC, CDD, EDD, periodic refresh, and PEP/sanctions screening workflows
• Conduct AML risk assessment (customer, product, channel, geography) and map controls
• Define transaction monitoring scenarios, thresholds, alert triage, and escalation paths
• Draft SAR/STR narrative structure, supporting facts, and internal escalation (not filing legal advice)
• Plan recordkeeping, audit trails, and exam readiness (requests, walkthroughs, sampling)
• Map obligations at a high level to FATF Recommendations, BSA/USA PATRIOT concepts, EU AMLD/AMLA, UK MLR
• Address crypto/virtual asset AML, blockchain analytics touchpoints, and travel rule operational design
• Support correspondent banking and wire due diligence, MLRO and board reporting packs
• Scope training, independent testing, and AML analytics model validation (conceptual)

When NOT to Use

• Implement SOC 2, ISO 27001, HIPAA, or PCI technical controls and evidence automation only → compliance-engineer
• Cloud shared-responsibility, FedRAMP/PCI-in-cloud evidence packages → cloud-compliance-specialist
• GRC program charter without AML/financial-crime lens → compliance-specialist
• Legal advice, regulatory interpretation as counsel, contract redlines, or DPA negotiation → commercial-counsel
• Internal/IT audit workpapers, COSO walkthroughs, ITGC testing without AML program focus → auditor
• Cloud billing, tagging, and FinOps cost optimization → finops-analyst
• Build SIEM rules, IdP, or TM software implementation (primary) → information-security-engineer
• On-chain investigation for law enforcement or victim tracing narratives → blockint / on-chain-investigator-agent skills
• Sanctions oracle/API integration engineering only → chainalysis-sanctions-screening (pointer), then route AML context here

Related skills

Core Workflows

1. Program scoping and risk assessment

1. Inventory legal entities, licenses, products, channels, and geographies 2. Document inherent risk by customer type, product, delivery channel, and geography 3. Define residual risk after controls; align appetite with board 4. Prioritize gaps with owners, due dates, and evidence of remediation 5. Refresh on trigger events (new product, corridor, enforcement action, exam finding)

See `references/aml_compliance_scope.md` and `references/risk_assessment_and_program_governance.md`.

2. Customer due diligence and screening

1. Tier customers (retail, SME, corporate, PEP, correspondent, VASP) 2. Apply CDD vs EDD triggers; define refresh cadence and event-driven reviews 3. Run PEP, sanctions, and adverse media with match disposition and audit trail 4. Document beneficial ownership and control persons where required 5. Escalate true matches and inconclusive cases per policy—not ad hoc overrides

See `references/kyc_cdd_and_screening.md`.

3. Transaction monitoring and alert operations

1. Map scenarios to risks (structuring, rapid movement, high-risk geography, mule patterns) 2. Calibrate thresholds using labeled data and analyst feedback loops 3. Define alert triage queues, SLAs, investigation steps, and closure codes 4. Separate AML alerts from fraud/chargeback where systems differ 5. Track false positive burden and tune with documented approvals

See `references/transaction_monitoring_and_alerts.md`.

4. Suspicious activity reporting and records

1. Decide escalation threshold for SAR/STR consideration (internal policy) 2. Assemble narrative structure: who, what, when, where, why suspicious, amounts, accounts 3. Maintain supporting documentation index; restrict need-to-know 4. Do not advise whether to file, legal sufficiency, or regulator strategy—escalate to MLRO/counsel 5. Retain records per jurisdictional schedule; protect confidentiality

See `references/sar_str_reporting_and_records.md`.

5. Crypto, travel rule, and examinations

1. Classify virtual asset activities (custody, exchange, transfer, staking) in risk assessment 2. Integrate blockchain analytics as decision support with documented limitations 3. Design travel rule counterparty data exchange and exception handling 4. Prepare exam readiness: org chart, policies, risk assessment, sample populations, tuning logs 5. Coordinate independent test and model validation scope for AML models

See `references/crypto_travel_rule_and_exam_readiness.md`.

When to load references

Operating principles

• Risk-based — proportion controls to documented inherent and residual risk
• Audit trail — decisions, overrides, and dispositions retrievable with actor and timestamp
• No legal conclusions — provide fact packs and draft structures; MLRO/counsel decide filings
• Separate roles — first line owns customers; second line AML compliance; third line audit
• Tune with governance — threshold changes versioned, approved, and back-tested where possible
• Label uncertainty — screening and blockchain analytics are heuristic; document confidence

AML compliance scope

Table of contents

1. Mission 2. In scope 3. Out of scope 4. Handoffs 5. Operating principles 6. Deliverable patterns

Mission

Support AML, counter-financing of terrorism (CFT), and financial-crime compliance program design and operations: risk-based policies, customer due diligence, screening, transaction monitoring, suspicious activity workflows, governance, and exam readiness. Optimize for defensible documentation, proportionate controls, and clear escalation—not for building TM platforms, attesting ISO/SOC controls, or substituting legal counsel.

In scope

Out of scope

Handoffs

From product / engineering:

• Provide: new product or corridor description, customer types, settlement rails, jurisdictions, and planned go-live date
• Receive: AML risk rating, required CDD tier, TM scenarios to implement, and monitoring KPIs

To `compliance-engineer`:

• Deliver: control objectives and evidence requirements for automated KYC/TM/logging
• Request: evidence collectors, retention configs, and access logs—not policy drafting alone

To `commercial-counsel`:

• Escalate: novel regulatory interpretations, regulator correspondence, contractual AML clauses, and filing decisions

To `auditor`:

• Provide: risk assessment, policy suite, tuning documentation, sample alert populations for independent review
• Distinguish: second-line AML compliance testing vs third-line internal audit plan

To blockint skills:

• Request: on-chain tracing for investigation support with labeled confidence; AML owns disposition and SAR narrative

Operating principles

• Risk-based and documented — every control ties to assessed risk and named owner
• Quality over volume — reduce false positives with governed tuning, not silent threshold changes
• Need-to-know — SAR/STR materials and EDD files restricted; access logged
• Jurisdiction-aware — flag multi-license entities; do not assume one rule set globally
• No legal advice — frameworks mapped for orientation; counsel confirms obligations
• Human in the loop — automation supports; analysts and MLRO decide material outcomes

Deliverable patterns

Reference Documentation for Aml Compliance

This is a placeholder for detailed reference documentation. Replace with actual reference content or delete if not needed.

Example real reference docs from other skills:

• product-management/references/communication.md - Comprehensive guide for status updates
• product-management/references/context_building.md - Deep-dive on gathering context
• bigquery/references/ - API references and query examples

When Reference Docs Are Useful

Reference docs are ideal for:

• Comprehensive API documentation
• Detailed workflow guides
• Complex multi-step processes
• Information too lengthy for main SKILL.md
• Content that's only needed for specific use cases

Structure Suggestions

API Reference Example

• Overview
• Authentication
• Endpoints with examples
• Error codes
• Rate limits

Workflow Guide Example

• Prerequisites
• Step-by-step instructions
• Common patterns
• Troubleshooting
• Best practices

Crypto, travel rule, and exam readiness

Table of contents

1. Virtual asset AML touchpoints 2. Blockchain analytics 3. Travel rule 4. Correspondent and fiat ramps 5. Exam readiness 6. Request list preparation 7. Common findings

Virtual asset AML touchpoints

Map activities to risk assessment:

Classify VASPs and non-custodial models per license; do not assume one control set fits all products.

Blockchain analytics

Use on-chain tools as decision support, not sole proof:

Workflow:

1. Document why analytics were pulled (alert, EDD, SAR support) 2. Capture screenshot or export with timestamp and tool version 3. State confidence and alternative explanations 4. Route law-enforcement-grade investigations to blockint skills

For sanctions checks on addresses, see chainalysis-sanctions-screening as engineering pointer; AML owns disposition.

Travel rule

FATF Travel Rule — transmit originator/beneficiary information with virtual asset transfers between obliged entities.

Operational design elements:

Document sunrise issues and corridor-specific gaps; escalate legal interpretation to counsel.

Correspondent and fiat ramps

• Fiat on/off ramps — bank partners, MSB relationships, nested flows
• Correspondent due diligence — questionnaire, AML attestation, onsite/sampling for high risk
• Payable-through accounts — prohibited or heavily restricted in many programs
• Wire due diligence — OFAC and AML dual checks; originator/beneficiary fields

Align crypto flows with traditional TM where fiat touches the bank.

Exam readiness

Maintain standing exam packet (refresh quarterly):

Assign exam coordinator; single point for requests and legal privilege coordination.

Request list preparation

When regulators or auditors request samples:

1. Define population — date range, business line, alert type 2. Sample size — per methodology (statistical or judgmental) 3. Pull uniformly — avoid cherry-picking 4. Index files — control ID, customer ID, disposition, approver 5. Redact — third-party PII; SAR confidentiality rules 6. Walkthrough script — who presents, system demo path, known limitations

For IT-dependent controls, involve compliance-engineer for log exports and system evidence.

Common findings

Themes from AML examinations (illustrative):

Track findings in issues register with root cause and retest evidence.

KYC, CDD, and screening

Table of contents

1. Definitions 2. Customer risk tiers 3. CDD data elements 4. EDD triggers 5. Screening workflow 6. Beneficial ownership 7. Ongoing monitoring 8. Quality and audit

Definitions

Customer risk tiers

Typical tiering (calibrate to firm risk assessment):

Document rationale for tier assignment and re-rating triggers (volume spikes, adverse media, STR filing).

CDD data elements

Collect and verify per policy (not every field for every tier):

• Legal name, aliases, date of birth or incorporation, jurisdiction
• Government ID or corporate registry references (where applicable)
• Address and contact; verify using independent sources where required
• Nature of business and expected activity (volume, products, counterparties)
• Source of funds / wealth for higher-risk relationships
• Purpose of account and anticipated transaction profile
• Related parties: signers, controllers, UBOs

Record verification method (documentary, non-documentary, reliable third party) and date.

EDD triggers

Apply EDD when any trigger fires (examples—firm policy may expand):

• PEP or close associate (domestic or foreign)
• High-risk country or corridor per firm list
• Correspondent banking, nested accounts, payable-through
• Virtual asset service providers and unhosted wallet business models
• Adverse media indicating financial crime, fraud, or regulatory action
• Unusual ownership (shell layers, nominee directors, bearer shares where relevant)
• Prior SAR/STR, law enforcement inquiry, or account restriction history
• Material change in activity vs stated profile

EDD outputs: source-of-funds/wealth narrative, senior approval, enhanced monitoring frequency, shorter refresh.

Screening workflow

onboarding / periodic / event-driven
  → run lists (sanctions, PEP, adverse media)
  → algorithmic matches + analyst review
  → disposition: false positive | true positive | inconclusive
  → document rationale + approver
  → update risk tier and monitoring

Match disposition rules:

• False positive — different person/entity; document distinguishing factors (DOB, ID, address)
• True positive — escalate per sanctions program; do not proceed without compliance/legal path
• Inconclusive — obtain additional data; freeze or restrict per policy pending resolution

Maintain list version, screening timestamp, and analyst ID in audit trail.

Beneficial ownership

For legal entities, identify ultimate beneficial owners and control persons per jurisdictional thresholds (e.g., 25% ownership tests—confirm locally with counsel).

• Collect ownership chain for complex structures
• Identify control without ownership (directors, POA, trust protectors)
• Refresh on material ownership changes
• Reconcile UBO with screening results

Ongoing monitoring

CDD is not onboarding-only:

Quality and audit

• QC sample of onboarding and dispositions with second-line review
• Metrics: time-to-complete, EDD backlog, false positive rate, true positive escalation time
• Do not delete screening hits; retain superseded dispositions with reason
• Align retention with sar_str_reporting_and_records.md and local law

Risk assessment and program governance

Table of contents

1. Enterprise AML risk assessment 2. Risk factors 3. Control mapping 4. MLRO and second line 5. Board reporting 6. Framework orientation 7. Training and culture 8. Independent testing

Enterprise AML risk assessment

Purpose: identify inherent risk, evaluate controls, and document residual risk with board-approved appetite.

Steps:

1. Scope — entities, licenses, products, channels, geographies, customer segments 2. Inherent risk — score or rank each cell (customer × product × channel × geography) 3. Controls — map preventive/detective controls; rate design and operating effectiveness 4. Residual risk — inherent minus control mitigation; flag above appetite 5. Action plan — owners, dates, evidence for remediation 6. Approval — MLRO and board (or delegated committee) with date 7. Refresh — annual minimum; triggers on new product, M&A, exam findings, enforcement trends

Store methodology, data sources, assumptions, and dissenting views.

Risk factors

Weight factors per firm strategy; avoid copy-paste scores without business context.

Control mapping

For each material risk, document:

Gaps become issues with severity, compensating controls, and target dates.

MLRO and second line

Money Laundering Reporting Officer (or equivalent):

• Owns AML/CFT program oversight and regulatory liaison
• Reviews escalations, SAR/STR decisions (with counsel where required)
• Approves high-risk relationships and policy exceptions
• Reports to board; ensures resources for compliance

Second line (AML compliance function):

• Sets standards, monitors first-line execution, challenges risk ratings
• Performs thematic reviews and quality assurance on investigations
• Manages regulatory change horizon scanning (facts to counsel for interpretation)

First line — business units own customers and day-to-day CDD/TM execution.

Third line — internal audit independent assurance (auditor).

Board reporting

Typical MLRO pack (quarterly or per charter):

Use trends, not point-in-time vanity metrics; explain false positive burden and tuning actions.

Framework orientation

High-level mapping only—confirm obligations with counsel:

Use fatf-glossary-reference for standardized terms—not as legal advice.

Training and culture

• Role-based training: front office, ops, TM analysts, executives, board
• Frequency — annual minimum; refresh on material policy change
• Attestation — completion tracked; exceptions escalated
• Speak-up — escalation paths without retaliation; document referrals to compliance

Independent testing

Scope second-line or external testers to evaluate:

• RA reasonableness and refresh
• CDD/EDD sample quality
• Screening disposition accuracy
• TM scenario coverage and tuning governance
• SAR decision documentation (redacted samples)
• Training completion and issue management

Findings rated by severity with management responses and retest dates.

SAR, STR reporting, and records

Table of contents

1. Scope and boundaries 2. Internal escalation 3. Narrative structure 4. Supporting documentation 5. Confidentiality 6. Recordkeeping 7. Post-filing considerations

Scope and boundaries

This reference covers internal workflows and narrative drafting structure for suspicious activity reports (SAR) and suspicious transaction reports (STR) in various jurisdictions.

Do not:

• Advise whether filing is legally required in a specific case
• Draft final filings for submission without MLRO/counsel review
• Communicate filing decisions to customers (tipping off risk)
• Provide regulator negotiation or enforcement strategy

Escalate filing decisions to MLRO and legal counsel per firm policy.

Internal escalation

Typical escalation path:

analyst investigation → team lead → AML compliance → MLRO (+ counsel)

Document at each stage:

• Summary of suspicious facts
• Why rule-out explanations are insufficient
• Amounts, dates, accounts, instruments, jurisdictions
• Prior alerts and dispositions
• Recommendation: file | do not file | need more information

Materiality thresholds — firm-defined dollar or risk-based triggers for mandatory MLRO review.

Narrative structure

Use clear, chronological, fact-based prose. Suggested sections:

1. Subject information — name, identifiers, addresses, occupation/business, relationship to firm 2. Account / product summary — accounts involved, open dates, stated purpose 3. Summary of suspicious activity — what happened, when, where, instruments 4. Detailed transaction description — table or narrative of key transactions (date, amount, type, counterparty) 5. Why activity is suspicious — red flags tied to typology; deviation from expected profile 6. Other related activity — linked accounts, parties, prior alerts 7. Investigation steps — databases checked, outreach, documents reviewed 8. Law enforcement — prior inquiries if known and disclosable per policy 9. Action taken — account restrictions, termination, continued monitoring

Writing rules:

• Facts vs suspicion — label inferences explicitly ("based on pattern, it appears...")
• Avoid legal conclusions ("money laundering occurred") unless counsel directs
• Use active voice and precise amounts/currencies
• Do not include gratuitous PII beyond form requirements in shared drafts

Supporting documentation

Maintain an index (not necessarily attached to regulator filing):

Redact third-party PII not necessary for internal review.

Confidentiality

• Need-to-know access to SAR/STR workspace
• No customer notification that a report was or will be filed
• Train staff on tipping off and safe harbor concepts (counsel briefing)
• Separate IT permissions from general case management where possible

Recordkeeping

Retain per jurisdictional schedule (often five years from filing—confirm with counsel):

• Draft narratives and final filed copies (where retained)
• Supporting investigation files
• Decision memos for no-file determinations with rationale
• Training records for analysts involved

Immutable audit logs for access to SAR repositories.

Align with enterprise records management and cross-border data transfer rules.

Post-filing considerations

Operational items (policy-driven, not legal advice):

• Continuing activity — ongoing monitoring level; new alerts handling
• Account disposition — maintain, restrict, or exit relationship per risk committee
• Law enforcement requests — route to counsel; document subpoenas
• Repeat filings — link prior SAR reference numbers in narrative when applicable

Do not use SAR filing as substitute for immediate law enforcement contact when imminent harm—follow crisis/IR playbooks.

Transaction monitoring and alerts

Table of contents

1. TM program components 2. Scenario design 3. Thresholds and tuning 4. Alert triage 5. Investigation playbook 6. Typologies 7. Metrics and governance 8. Model validation touchpoints

TM program components

Separate AML TM from fraud or credit systems where possible; if shared, tag alert type and route to trained analysts.

Scenario design

Each scenario should document:

Cover onboarding (misuse of product), ongoing activity, and exit (draining accounts).

Thresholds and tuning

Govern tuning as a controlled change:

1. Hypothesis — why change (typology shift, false positive burden, new product) 2. Analysis — historical alert population, SAR yield, sample review 3. Approval — AML compliance + second-line sign-off; MLRO for material shifts 4. Implementation — versioned deploy; back-test where feasible 5. Post-change review — alert volume, quality, SAR outcomes at 30/90 days

Avoid silent threshold edits in production without documentation.

Alert triage

Queue design principles:

• Priority — high-risk customer, large amount, sanctions proximity, law enforcement flags
• SLA — time to first touch and to disposition by severity
• Skill-based routing — complex correspondent vs retail
• Escalation — team lead → AML compliance → MLRO

Triage checklist (first 15 minutes):

• Confirm customer identity and tier
• Validate alert fired correctly (not data defect)
• Compare to expected activity profile
• Check open cases and recent screening hits
• Decide: close with rationale | investigate further | escalate

Investigation playbook

Deeper investigation steps:

1. Activity chart — credits/debits over review window; counterparties 2. KYC refresh — still accurate? trigger EDD? 3. Screening — rescreen if stale or new names appear 4. External research — adverse media (licensed tools); document sources 5. Customer outreach — if policy allows; document questions and responses 6. Conclusion — reasonable explanation vs unexplained; recommend SAR referral or not 7. Supervisor review — mandatory for closures above materiality or SAR paths

Attach supporting extracts (redacted) to case; never paste full SAR drafts into general tickets.

Typologies

Reference typologies (not exhaustive):

Pair typologies with red flags list in investigation notes; distinguish facts from inference.

Metrics and governance

Review metrics in AML committee with first-line and MLRO.

Model validation touchpoints

When TM uses machine learning or scoring models:

• Document model purpose, features, training data, and known bias
• Independent validation: conceptual soundness, outcomes analysis, ongoing monitoring
• Define override policy and logging
• Align with firm model risk policy; separate from IT change management

Validation is conceptual structure here—specialist model risk teams may own execution.