Purpose: Provide a structured, repeatable approach for identifying, triaging, and prioritising alerts generated by transaction monitoring systems.

Key Steps:
– Automated alert generation based on rules, scenarios and models (thresholds, velocity, structuring, geo-risk, customer risk).
– Initial de-duplication and technical noise reduction (system errors, duplicate alerts, known benign patterns).
– First-pass suppression of obvious false positives according to documented and approved logic.
– Alert enrichment with KYC profile data, historical behaviour, peer group benchmarks, device and channel attributes.
– Priority scoring based on risk indicators (customer risk, product risk, jurisdiction, transaction pattern).
– Work queue assignment using risk-based routing, SLA targets and analyst skill level.

Controls & Evidence:
– Documented set of TM scenarios and thresholds with version history.
– Defined suppression rules with justification and sign-off by Compliance / Model Governance.
– Audit log of who opened, modified, or closed each alert, including timestamps and comments.
– SLA reporting on alert ageing, backlog and breach thresholds.

Purpose: Ensure that alerts and cases move through a defined, risk-based escalation chain from Level 1 review to complex Level 3 investigation, with clear criteria at each stage.

Level 1 (Initial Review):
– Assess alert context using customer profile, recent activity and simple red flag checks.
– Determine if alert is obviously explainable and benign (e.g. salary, expected business pattern) or requires deeper review.
– Capture rationale for any closure and ensure it aligns with approved guidance.
– Escalate borderline or suspicious alerts to Level 2.

Level 2 (Intermediate Investigation):
– Detailed transactional and behavioural analysis over a longer time horizon.
– Review KYC and EDD information for inconsistencies with behaviour.
– Request additional documentation or clarification from front-office where necessary.
– Identify potential typologies: structuring, layering, mule behaviour, sanctions circumvention, TBML etc.
– Decide whether to close, escalate to Level 3, or recommend EDD / KYC remediation.

Level 3 (Complex / Specialist Investigation):
– MLRO or specialist investigators handle multi-jurisdiction, high-value or highly complex cases.
– Integration of OSINT, adverse media deep dive, network analysis, counterparties and associated entities.
– Coordination with Legal, Fraud, Sanctions and, where appropriate, law enforcement.
– Decision on SAR filing and future relationship with the customer.

Controls & Governance:
– Documented escalation criteria between Levels 1, 2 and 3.
– Role definitions and required competency for each level.
– QC sample review of decisions per level, with feedback loop and training.

Purpose: Standardise how AML investigations are documented so that every case is comprehensible, reproducible and defensible to internal audit and regulators.

Core Case Components:
– Case Header: Unique case ID, customer ID, alert IDs, dates opened/closed, analyst, approver.
– Customer Profile Summary: Risk rating, KYC/EDD status, products, channels, geographies, segment.
– Alert Summary: TM scenarios triggered, rules/models that fired, financial values, volumes and time windows.
– Behavioural Analysis: Narrative explaining why behaviour is typical or atypical for the given customer profile.
– Red Flags: Explicit list of recognised typologies matched to internal and FATF guidance.
– Information Requests: Documentation and information requested from front office or the customer, with responses.
– Decision Rationale: Clear justification for closure, continued monitoring or SAR filing.
– Actions & Follow-Up: KYC remediation, account restrictions, relationship review.

Automation Opportunities:
– Auto-population of customer and alert metadata into the case shell.
– Standardised narrative templates with required fields and prompts.
– Dynamic checklists aligned to risk factors and product types.

Purpose: Create a robust, traceable evidence package for each AML case, enabling internal and external stakeholders to reconstruct the investigation.

Evidence Types:
– Transaction exports (with filters and parameters documented).
– Screenshots or exports from TM systems, screening tools and internal platforms.
– KYC/EDD documentation used in decision-making.
– Copies of email / chat communication where relevant.
– OSINT / adverse media excerpts with links and capture dates.
– Notes of calls or in-person meetings related to the case.

Audit Trail Requirements:
– Who accessed or modified the case and when.
– What data was added, updated or removed.
– Changes to key conclusions or risk ratings, with rationale.
– Time-stamped decisions and approval checkpoints.

Controls:
– Immutable logging in the case management system where possible.
– Restricted editing of closed cases (read-only with defined exceptions).
– Evidence retention policies compliant with AML regulations and data protection laws.

Purpose: Ensure that Suspicious Activity Reports (SARs) / STRs are consistent, high quality, and submitted within regulatory timeframes.

Preparation Workflow:
– MLRO (or delegate) reviews the full case file and evidence package.
– Confirm that suspicion threshold is met according to local regulations.
– Identify all relevant entities: customer, counterparties, associated accounts, intermediaries.
– Construct a clear chronology of suspicious events and behaviours.
– Draft SAR narrative that explains: who, what, when, where, why and how suspicion arose.
– Cross-check monetary values, dates and identifiers for internal consistency.

Filing & Post-Filing:
– Submit SAR via the appropriate FIU or regulatory portal (e.g. NCA SAR Online).
– Capture confirmation of receipt and any reference numbers.
– Log the filing date, any moratorium periods and relevant legal constraints.
– Ensure confidentiality internally (need-to-know principle, no tipping-off).

Controls:
– Standard SAR templates and checklists.
– Defined timelines from suspicion to submission.
– Dual review process for high-value or complex SARs.

Purpose: Manage the ongoing relationship with customers after a SAR has been filed, without breaching anti-tipping-off rules.

Key Treatment Options:
– Continue relationship with enhanced monitoring.
– Restrict certain transactions or channels.
– Place temporary holds pending further guidance from the FIU.
– Gradually exit the relationship in line with risk appetite and legal advice.

Operational Considerations:
– Only limited internal stakeholders are aware of the SAR (MLRO, core AML team).
– Front-office communications avoid any suggestion that a SAR has been filed.
– System flags and controls are configured to enforce enhanced monitoring or restrictions.
– Periodic review of the customer’s status in light of new information or FIU feedback.

Purpose: Assure the quality and consistency of AML investigations, alert handling and SAR decisions.

QA Scope:
– Sample-based review of closed alerts (per scenario, per analyst, per jurisdiction).
– Review of key elements: data used, rationale quality, documentation, timeliness.
– Thematic reviews focused on specific typologies or control weaknesses.
– Remediation actions for poor quality work (coaching, retraining, process changes).

Metrics:
– % of cases with complete documentation.
– % of decisions reversed by QA.
– Time from alert to closure vs SLA.
– Escalation and rework rates by analyst / team.

Feedback Loop:
– Formal feedback channels from QA to AML management, TM model owners and front office.
– Updates to procedures, training material and decision guidance based on QA findings.

Purpose: Govern transaction monitoring models and scenarios so they remain effective, explainable and compliant over time.

Model Lifecycle Stages:
– Design: Define coverage, typologies, thresholds and data inputs.
– Validation: Independent testing for effectiveness, false positive rates and data quality.
– Implementation: Deployment into production with controlled change management.
– Ongoing Monitoring: Performance metrics, backtesting, periodic reviews.
– Change Management: Formal process for adjusting thresholds, adding/removing scenarios.
– Decommissioning: Sunsetting obsolete rules with documented justification.

Controls & Documentation:
– Model inventory including owner, purpose, data sources and regulatory references.
– Version-controlled documentation of logic, assumptions and limitations.
– Periodic independent reviews and sign-off by Compliance and Risk.
– Clear traceability between risk assessment, policies and the scenarios in production.