Service Description & FAQ
A detailed guide to how we conduct the Transaction Monitoring Rule Performance Review, including data requirements, privacy protocols, and engagement sequencing.
What is this service?
An advisory, evidence-based review of AML/CFT transaction monitoring (TM) rule performance using your historical transactions, alerts, and case/outcome data (where available), combined with a targeted review of governance and alert handling. Typical output is a prioritized, implementable improvement roadmap.
What does the service actually assess?
- Rule/scenario inventory and scope coverage: What exists, what runs, what’s measurable.
- Rule behaviour in production: Volumes, concentration, stability, duplication/overlap.
- Outcomes where supported: Dispositions, escalation patterns, SAR/STR conversion where tracked.
- Calibration and segmentation issues: Drivers of noise or coverage gaps.
- Governance and operating practices: Tuning cadence, change control, documentation, QA expectations, MI.
- Alert handling and investigation workflow: Triage, routing, efficiency bottlenecks.
Is this a model validation or an audit?
No. This is an advisory performance review. It is not a formal audit opinion, independent assurance engagement, or model validation unless explicitly contracted and scoped.
Do you “prove” our AML TM is effective?
No. We avoid “proof” claims. We provide defensible evidence on behaviour and outcomes based on available data, and we clearly document assumptions, constraints, and limitations.
How does the engagement start?
- Kickoff questionnaire: No written answers required.
- Shadowing sessions: Typically 2–3 × ~60 minutes.
- Tailored data requirements: Issued after shadowing.
- Analysis, findings, and deliverables.
Why do you require shadowing before defining the data request?
Because the correct data request is client-specific. Shadowing confirms:
- Workflows (real-time holds vs retrospective review; alert-based vs case-based).
- How outcomes are actually recorded and what disposition codes mean in practice.
- Source-of-truth vs reporting layers (where extracts should come from).
- Reliable identifiers and join paths (customer/account/wallet → transaction → alert → case).
- Rule intent vs operational use.
This prevents wasted extracts and incorrect conclusions.
What data do you need from us?
We take a data-minimised approach by default. Where feasible, we request derived metrics/aggregates and flagged subsets instead of full transaction histories. This reduces data exposure and lowers extraction burden. Full transaction-level extracts are only requested when required for specific modules and agreed explicitly.
Core Analytical Inputs (data-minimised by default)
- Alert & case data: alert IDs, rule IDs, timestamps, dispositions/outcomes (where tracked)
- Alert-linked transaction subset: fields needed to explain alert triggers (as available)
- Derived features / aggregates (preferred): rolling turnover, velocity, corridor flags, peer-group percentiles, etc. (client-specific)
- Client reference data: segmentation attributes (risk rating, customer type, product, geography, industry, onboarding date)
Transactions (minimised approach)
We do not always require a full extract of all transactions. In many engagements we use a data-minimised approach, relying on:
- alert-linked transaction records (only the subset needed to explain triggers), and/or
- derived features and aggregates (e.g., rolling turnover, velocity, counterparty/geography flags), and
- reference attributes for segmentation (risk rating, customer type, product, country, industry)
Where denominators are needed (e.g., alerts per 1,000 transactions), we request aggregate counts/volumes by segment/channel/time period rather than raw transaction-level data.
Some analyses (e.g., full pattern reconstruction or replay testing) may be limited without broader transaction-level data; we document constraints and alternatives.
Will this require downtime?
No. This is an offline exercise. We analyse extracts/reporting outputs in a secure non-production environment. No production changes are required to perform the review.
How do you protect our data?
We align to your security requirements and apply least-privilege access and secure handling in transit and at rest. Where required, we can work within your environment (with appropriate analytics/BI tools). We generally recommend you control the data transfer mechanism.
Do you need personal data?
Usually not. We apply data minimisation and typically work with tokenised/pseudonymised identifiers plus the attributes required for segmentation and AML interpretation. Free-text fields are avoided unless explicitly needed and controlled.
What happens to our data after the engagement?
Client data is used only to deliver the engagement. After final deliverables are accepted, we securely delete operational datasets and (where recorded) session recordings, unless retention is required by contract or law.
What metrics will you calculate?
- Conversion ratios (Primary Focus): Alert → Case → Escalation → SAR/STR (where tracked).
- Alert volume & concentration: Which rules/scenarios drive most workload.
- Normalized alert rates: E.g., alerts per 1,000 transactions (only where denominators are reliable).
- Overlap/duplication: Activity flagged by multiple rules/scenarios.
- Stability over time: Period-to-period shifts, spikes, drift after changes.
Why are conversion ratios a primary focus?
Conversion ratios are often the most decision-relevant indicators of whether alert volume translates into meaningful AML outcomes. They help distinguish high-volume rules that rarely progress from rules that materially contribute to reporting activity.