Financial crime context, governance and control testing

A financial crime process may depend on customer identity, ownership relationships, transaction populations, geographic attributes and dated risk assessments.

Know the distinctions: KYC/CDD concerns understanding customers and relationships; transaction monitoring examines activity for suspicious patterns; sanctions screening compares relevant parties or payments with applicable restrictions; an alert is a signal requiring handling, not proof of criminal activity. Rules, thresholds and regulatory interpretations belong to the authorised domain owners.

Preserve rule and model versions and relevant reference-data versions alongside outputs. Changes in alert counts might reflect population changes, rule changes or actual activity. Do not infer effectiveness from counts alone.

• Customer assessment: which identity, ownership and risk version was valid?
• Transaction monitoring: is the entire eligible population included, with correct currency, status and time?
• Screening: which names, aliases and reference-list version were used?
• Investigation: can an analyst reproduce the evidence available when a decision was made?

The business owner defines purpose and acceptable use. A data steward maintains definitions and quality processes. Engineers implement pipelines. Architects review design and dependencies. Security and privacy owners review controls within their mandates. Compliance and assurance responsibilities depend on the organisation's operating model; an analyst should not assume authority to certify legal compliance.

Do not move customer records, investigation details, credentials or restricted internal architecture into a personal training workspace or unapproved agent. Use synthetic examples. Hashing an identifier does not automatically make personal data anonymous.

• Least privilege, approved roles and controlled service identities.
• Restricted raw data, encryption, logging, retention and reproducible access reviews.
• Test both authorised access and prohibited access.
• Row access policies and masking address different needs; verify feature availability and policy behaviour in the actual account.

A small clean sample does not prove the full population is clean. Do not claim statistical confidence without a defensible sampling method.

1. 01Define the risk and control objective.
2. 02Document how the control is designed, who operates it and what evidence it produces.
3. 03Determine the full population and time period.
4. 04Choose a justified sample or full-population test.
5. 05Check both design and operation.
6. 06Record exceptions, impact and root cause.
7. 07Validate facts with the responsible stakeholder before issuing conclusions.

• Condition: the published risk-history table has two open intervals for customer C1.
• Criterion: the approved contract permits at most one open version.
• Evidence: query ID, batch, timestamp, two version IDs and reproducible SQL.
• Impact: a consumer join can multiply transactions or use inconsistent risk classifications.
• Cause: to be established; duplicated source events are a hypothesis until verified.
• Action: owner to repair affected history, reconcile consumers and implement an overlap gate.
• Closure: independent rerun of the failing test and evidence that affected outputs were corrected.