Investigation Process from Alert to Decision

A financial-crime alert is not a conclusion. It is a prompt to ask a question. A transaction-monitoring rule may have detected unusual velocity, a relationship manager may have raised a concern, a sanctions analyst may have referred activity that is not a sanctions match but still looks suspicious, a fraud team may have identified a mule account, or law-enforcement information may have created a reason to revisit a customer. The investigation process exists to turn that signal into a defensible decision.

The simplest mental model is signal → question → evidence → judgement → action → record → feedback. The signal tells the bank where to look. The question defines what the investigator is trying to understand. Evidence tests plausible explanations. Judgement determines whether the concern is resolved, remains unexplained, or reaches the reporting or escalation threshold under the applicable law and policy. Action then follows through the correct route. The record preserves what happened and why. Feedback improves the upstream control that generated the case.

That sequence matters because weak investigation programmes often confuse activity with outcomes. A team can clear thousands of alerts while still producing poor investigations. A case can contain dozens of screenshots and still lack a coherent explanation. A report can be filed defensively without showing that the bank understood the behaviour. A technically correct workflow can also fail if evidence is stale, case ownership is unclear, deadlines are hidden, or analysts are rewarded mainly for closure speed. Investigation quality is therefore not a matter of writing longer notes. It is the ability to reconstruct the risk question, the evidence considered, the reasoning applied and the resulting decision.

FATF provides the global architecture but not one universal investigation script. Recommendation 10 requires ongoing due diligence and scrutiny of transactions so that activity remains consistent with the institution's knowledge of the customer, business and risk profile. Recommendation 11 expects records sufficient to reconstruct transactions and retains the results of analysis. Recommendation 20 requires prompt reporting to the financial intelligence unit where the institution suspects or has reasonable grounds to suspect that funds are criminal proceeds or related to terrorist financing. Recommendation 21 addresses confidentiality and tipping-off. Countries implement those standards through their own laws, regulations, reporting thresholds, timelines and procedures. A bank must therefore distinguish the global control objective from the local legal trigger.

This chapter focuses on the bank's investigation process before, around and after the reporting decision. It does not try to replace the separate chapters on detailed customer review, SAR/STR decisioning, tipping-off, account restriction or law-enforcement requests. Instead, it shows how those specialist activities connect inside one case lifecycle.

1. The investigation starts before an analyst opens the case

The quality of an investigation is partly determined upstream. An alert should arrive with enough information to explain why it exists. A useful trigger normally contains the customer or entity, the relevant account or product, the activity or event that generated concern, the time period, the triggering rule or referral reason, and any risk indicators already known. If the case begins with a cryptic label such as Scenario 47 breach, the investigator spends valuable time reverse-engineering the detection logic instead of assessing risk.

Different trigger sources carry different context. A transaction-monitoring alert may be rich in transaction attributes but poor in customer narrative. A staff referral may contain qualitative observations but little structured data. A fraud referral may include device, authentication and beneficiary intelligence that the AML platform does not normally ingest. A sanctions hand-off may explain why a name match was cleared while highlighting unusual routing or ownership. An adverse-media referral may begin with an allegation that has not been verified. A law-enforcement request may have strict handling restrictions. The case model should preserve the trigger type because it affects what the investigator can infer and what additional work is required.

A mature bank also distinguishes alerts from cases. One customer can generate several alerts that are better investigated together because they describe one pattern. Conversely, one alert may involve several customers or counterparties and require linked cases or a network investigation. Treating every alert as a self-contained investigation creates fragmentation: one analyst sees cash deposits, another sees outbound transfers, a third sees a device or beneficiary signal, and none sees the whole story. Case creation and alert aggregation are therefore control decisions, not just workflow configuration.

2. Triage is a risk decision, not a shortcut

Triage answers two questions: how urgent is this? and what type of investigation is needed? It should not decide the final suspicion question using a thinner evidence set than the investigation itself.

Urgency can come from several factors. An instant-payment scam or active mule network may be moving funds in minutes. A terrorist-financing indicator may require accelerated review under local procedures. A sanctions or asset-freeze issue may require immediate legal action independent of an AML reporting decision. A customer who appears vulnerable may need a fraud or safeguarding intervention. A historical lookback alert may be important but not time-critical in the same way. Triage should therefore consider risk severity, time sensitivity, value at risk, potential customer harm, legal deadlines, ongoing activity and the possibility that delay will destroy evidence or allow funds to move.

Triage also establishes routing. Some matters belong in standard AML investigation. Others need a specialist fraud, sanctions, trade-finance, bribery/corruption, tax-crime or cyber-financial-crime team. Many require joint ownership. A bank should avoid a design where one team simply closes its alert because another risk domain is involved. The hand-off must retain the original concern and create traceable ownership until the matter is resolved.

The best triage outcome is usually a defined investigation scope. That scope may say, for example: review the customer's activity for the previous six months, focus on incoming third-party credits and rapid onward payments, compare behaviour with expected account use, identify common counterparties, check whether prior fraud referrals exist, and determine whether the activity can be reasonably explained or requires escalation. This is more useful than an instruction to “review account activity.”

3. Build a case hypothesis without deciding the answer too early

A case hypothesis is a working explanation for what the alert might mean. It gives the investigation direction while remaining open to disproof. Good investigators use hypotheses to organise evidence; weak investigators use them to justify the conclusion they expected from the start.

Suppose a small trading company receives multiple credits from unrelated individuals and sends most of the money within hours to two overseas counterparties. Plausible hypotheses include legitimate marketplace collections, payment aggregation on behalf of related businesses, undisclosed money-transfer activity, scam-proceeds laundering, or pass-through activity for another party. The investigator should identify what evidence would support or weaken each plausible explanation.

This approach reduces two common errors. The first is confirmation bias, where the investigator only looks for information that supports suspicion. The second is premature reassurance, where a plausible explanation is accepted without testing whether the facts actually support it. If a customer says “these are client payments,” the question is not whether that sentence sounds possible. The question is whether the customer profile, counterparties, invoices, product use, transaction pattern and independent information support that explanation.

The case-management system does not need an elaborate scientific-hypothesis feature. A simple structured field for the concern, the main questions and the evidence needed can be enough. What matters is that the reasoning is visible and can evolve when new information arrives.

4. Scope the time window deliberately

The alert window and the investigation window are not always the same. A rule may look at seven days, but understanding the pattern may require twelve months of history. A customer may have behaved normally for years before a sudden change. Conversely, reviewing five years of transactions by default can bury the relevant behaviour in unnecessary data.

The investigation window should be driven by the risk question. Useful considerations include when the pattern first appeared, whether similar activity existed previously, whether a customer-profile change occurred, whether linked counterparties appear earlier, whether funds were rapidly dissipated, and whether previous alerts or reports relate to the same conduct. The investigator should also consider whether older evidence remains reliable. A five-year-old occupation or business description may no longer explain current activity.

Time-scoping should be reproducible. If policy says “review an appropriate period,” the procedure should provide examples and escalation criteria so analysts do not use wildly different windows for similar cases. Where the investigator expands or narrows the period, the reason should be recorded.

5. Reconstruct the customer and relationship context

The investigator needs enough customer context to judge whether the activity is unusual and whether an explanation is credible. That normally includes identity, customer type, occupation or business activity, products held, account opening purpose, expected activity, source-of-funds or source-of-wealth information where relevant, geography, risk rating, beneficial ownership or controllers for entities, and significant changes over the relationship.

The point is not to repeat the entire KYC file in the case note. The point is to identify what matters to the investigation. For a salaried retail customer, an unexplained sequence of large business-like credits may be relevant. For a wholesale business, high payment volume may be normal while new corridors or unrelated consumer payers may be the anomaly. For a charity, donors, beneficiaries and operating countries may matter more than transaction size alone. For a correspondent-bank relationship, the direct customer profile may not reveal the underlying parties at all, so the investigation needs a different evidence strategy.

Customer risk ratings are context, not verdicts. A low-risk customer can behave suspiciously. A high-risk customer should not be treated as suspicious merely because of the rating. The investigation must remain activity-led and evidence-led.

6. Reconstruct the money movement, not just a transaction list

Raw statements rarely tell the full story. Investigators should reconstruct the flow of value. That means understanding incoming sources, outgoing destinations, sequencing, timing, amounts, currencies, payment methods, cash withdrawals, card use, virtual-asset off-ramps, merchant payments, internal transfers and any relevant payment-message details.

The important unit is often the flow, not an individual payment. A single incoming credit of 2,000 may be ordinary. Twenty unrelated credits followed by near-immediate transfers to a small set of beneficiaries may create a different risk picture. Circular movement between related accounts can matter. So can rapid splitting, consolidation, repeated near-threshold behaviour, unexplained round amounts, transactions inconsistent with business operating hours, or payment descriptions that conflict with known customer activity. None of those features proves crime; they identify questions that require explanation.

Payment data should be interpreted carefully. ISO 20022 or legacy message fields can identify debtor, creditor, agents, ultimate parties, purpose or remittance information, but data may be absent, truncated, transformed or populated by intermediaries. Investigators should know whether a field was customer-supplied, system-derived, enriched by the bank or changed during message transformation. Treating all displayed fields as equally authoritative can create false confidence.

7. Follow counterparties and networks where the risk question requires it

Financial crime frequently appears as relationships rather than isolated customer behaviour. Common beneficiaries, shared devices, repeated counterparties, common addresses, directors, beneficial owners, merchants, wallets or correspondent routes can connect cases that look unrelated when viewed account by account.

Network analysis should still be proportionate. An investigator does not need to build a graph for every low-complexity alert. But the case should expand when the evidence suggests coordination. If ten customers receive funds from victims and send them to one aggregator, the network may be the real subject. If an apparently unrelated company shares a director, phone number and beneficiary with the customer, entity-resolution data can materially change the case.

The bank should distinguish observed facts from inferred relationships. “Both customers used the same IP address” is a fact if the data is reliable. “They are controlled by the same criminal group” is a hypothesis unless supported by stronger evidence. Case notes and diagrams should preserve that distinction.

8. Use external information as evidence, not decoration

External research may include company registries, regulatory notices, sanctions lists, trusted adverse-media sources, official court records, public corporate websites or other open-source information. The source, date, relevance and reliability matter. A search result snippet is weaker than the underlying official record. An allegation in a news article is not a conviction. A company website is useful for understanding claimed business activity but is not independent verification of that activity.

Analysts should avoid “search until you find something negative.” External research should be driven by the case question. If the concern is undisclosed remittance activity, verify whether the business is licensed where applicable and whether its public business model is consistent with the account. If the concern is a counterparty's identity, use authoritative registries where available. If adverse media is relevant, record why the article relates to the same person or entity and why the allegation matters to the transaction pattern.

Data privacy, bank secrecy and employment-monitoring rules can constrain what information may be accessed, shared or retained. Those rules differ by jurisdiction. The investigation design should therefore encode access controls and lawful-use restrictions rather than assume that “more data” is always permissible.

9. Requests for information should be purposeful

Sometimes existing data cannot resolve the concern. The bank may need information from the customer, a relationship manager, another internal team, a correspondent institution or another authorised source. A request for information should be specific enough to close a known gap.

Weak questions invite weak answers. “Please explain these transactions” often produces a generic response. A better request identifies the activity and asks for the commercial purpose, relationship to counterparties, supporting documentation, source of funds, expected future activity or other facts needed to test the case hypothesis.

Investigators should also think about tipping-off and confidentiality risk before contacting a customer. FATF Recommendation 21 establishes a global principle against disclosing that an STR or related information is being filed, while local law defines the exact prohibition and exceptions. In some cases, ordinary customer due diligence can continue safely. In others, a poorly worded question may reveal that a suspicious activity investigation or report is under way. Procedures should define when analyst contact is allowed, when legal or MLRO guidance is needed and how the rationale is recorded.

A request for information is not automatically a reason to stop the clock. If a local reporting obligation is already triggered, waiting for perfect documentation may cause a late report. AUSTRAC's current Australian guidance, for example, explicitly says that once reasonable grounds for suspicion are formed, the reporting entity should not delay the suspicious matter report merely to complete enhanced CDD. Other jurisdictions use different legal tests and deadlines, so the operational rule must be mapped locally.

10. Evaluate explanations against the whole evidence set

A good investigation asks both what supports concern? and what reasonably explains it? The conclusion should reflect the balance of evidence rather than a count of red flags.

Legitimate explanations should be tested for coherence. Do transaction amounts fit the stated business? Do counterparties make sense? Does documentation match payment dates and values? Is the explanation consistent with historic behaviour? Does independent information support the business model? Are there contradictions? Did the customer answer the question actually asked?

Suspicious explanations can also be over-stated. A customer declining to provide optional information may be frustrating but does not automatically prove criminality. Use of cash can be normal in some sectors and geographies. Transfers to a higher-risk jurisdiction may have legitimate purpose. A shared address can reflect a co-working provider. The investigator's task is not to eliminate all innocent possibilities; it is to determine whether, under the applicable legal and policy standard, the facts create suspicion or reasonable grounds for suspicion, or whether the activity can be reasonably resolved.

This is where professional judgement becomes visible. Two competent investigators may weigh ambiguous evidence differently. A strong programme reduces unnecessary inconsistency through clear decision criteria, calibration, quality review and escalation for difficult cases rather than pretending judgement can be eliminated.

11. Separate the suspicious-activity decision from other bank decisions

One of the most important architectural principles is that a SAR/STR decision is not the same as an account, payment or customer decision.

A bank may have grounds to report suspicious activity but still keep the account open, subject to local law, risk appetite and any law-enforcement considerations. It may decide to restrict or exit a relationship without filing a report if the legal reporting threshold is not met but risk appetite is exceeded. A payment may need to be blocked under sanctions law even if the AML investigation has not reached a suspicion conclusion. A fraud team may attempt recovery or protect a vulnerable customer while AML separately assesses whether the recipient account is being used for laundering. These outcomes intersect but should not be collapsed into one status such as SAR = close account.

The case model should therefore capture separate decision dimensions: reporting, customer relationship, transaction handling, sanctions/legal restraint, fraud/customer protection, KYC refresh or EDD, and control remediation. Each decision needs an owner, basis and timestamp.

12. The global standard and the local legal trigger

FATF Recommendation 20 sets the global expectation that a financial institution should be required by law to report promptly to the FIU when it suspects or has reasonable grounds to suspect that funds are criminal proceeds or related to terrorist financing. The Interpretive Note also states that suspicious attempted transactions should be reportable regardless of amount. Those principles are intentionally high-level.

Local law answers the operational questions: who is a reporting entity, which suspicion test applies, what offences are covered, whether monetary thresholds exist for particular report types, when the reporting clock starts, who can make the decision, what form is used, what information must be included, whether additional reports are required, how continuing activity is handled and what confidentiality restrictions apply.

The United States and Australia illustrate why the distinction matters. The FFIEC BSA/AML Manual describes a U.S. bank process in which unusual activity is researched, findings move to an authorised decision maker and escalation is defined from detection to disposition. Its documentation discussion must be read alongside the October 2025 interagency SAR FAQs: the BSA and its implementing regulations do not require or create an expectation that a bank document a decision not to file a SAR. Where a bank chooses to retain that reasoning, documentation should be proportionate to its risk-based internal policies and the complexity of the case. The bank is not expected to prove the underlying crime; criminal investigation is a law-enforcement responsibility. AUSTRAC's guidance, under Australian law, frames the decision around whether there are reasonable grounds for suspicion and specifies Australian reporting deadlines and enhanced-CDD consequences. Those are useful operating examples, not universal rules for every bank.

A global bank should therefore maintain jurisdictional decision tables rather than teach analysts one worldwide threshold. The common workflow can remain consistent while legal parameters are configured by booking entity, branch, customer, product, location and report type.

13. Document the reasoning, not every click

Case documentation should let another competent reviewer reconstruct the investigation without repeating it from scratch. At minimum, the narrative should explain why the case was opened, what scope was used, what material evidence was reviewed, what important facts supported or weakened concern, what gaps remained, what decision was reached and why.

The case note should distinguish facts, customer explanations, analyst interpretation and final judgement. Phrases such as “customer is suspicious” are weak because they collapse evidence and conclusion. Stronger reasoning explains the observed behaviour, why it is inconsistent or unexplained, how the customer responded, what corroboration exists and which policy or legal test was applied.

Attachments and screenshots should not substitute for a narrative. They may preserve evidence, but screenshots can become unreadable, stale or detached from context. Where possible, structured data and durable source references should support the note. The system should preserve the version of evidence available at the time of decision so that later data changes do not silently rewrite history.

FATF Recommendation 11 reinforces the importance of reconstructable transaction records and retaining the results of analysis. Local retention periods and legal-hold requirements vary, so the case platform should support configurable retention rather than a single global deletion rule.

14. Closure is an outcome, not an eraser

When concern is reasonably resolved, the case can close without escalation. That does not mean the alert was pointless. The explanation may improve the customer profile, reveal a data-quality issue, show that a scenario threshold is poorly calibrated, or create useful context for future alerts.

A closure rationale should say why the observed activity is consistent with the customer or otherwise satisfactorily explained. Generic phrases such as “activity reviewed and no suspicion found” provide little value. If the activity is unusual but legitimate, record what made it legitimate. If an alert was caused by stale KYC data, trigger the appropriate profile correction. If a rule fired on a known payroll cycle, feed that information into tuning rather than forcing analysts to rediscover it repeatedly.

When concern remains unresolved but the reporting threshold is not yet reached, policy may allow continued monitoring, further information gathering or escalation. This state needs active ownership. A queue of “pending investigation” cases without next actions becomes a hidden backlog and can allow legal deadlines to pass.

15. Escalation should preserve the reasoning chain

Escalation is not merely moving a case to a senior queue. It should communicate the question that needs a decision. The receiving reviewer needs the evidence, the unresolved issue, the analyst's view and any time-sensitive constraint.

Escalation may be required because the legal threshold is difficult to interpret, the customer is high-profile, the case spans jurisdictions, sanctions or fraud issues overlap, law enforcement is involved, customer contact creates tipping-off risk, an account action could cause material harm, or analysts disagree. The escalation route should reflect expertise, not hierarchy alone.

Where a committee makes final decisions, governance should define quorum, conflicts, tie-breaking, urgent decisions, documentation and delegation. The U.S. FFIEC manual explicitly notes the need for a clearly defined process to resolve differences of opinion where a committee is used. Other jurisdictions may not prescribe the same structure, but the governance principle is broadly useful: the person or forum making the decision must have clear authority.

16. The investigation can produce several legitimate outcomes

An investigation may result in one or more of the following: closure with documented explanation; customer risk refresh or enhanced due diligence; escalation to an MLRO or authorised reporting decision maker; SAR/STR filing under local law; sanctions or legal review; fraud/customer-protection action; law-enforcement liaison; relationship restriction or exit review; historical lookback; data-quality remediation; scenario tuning; or referral to another specialist team.

These are not interchangeable. A high-quality case makes clear which outcome belongs to which risk domain. It also records whether follow-up tasks were completed rather than assuming that closing the investigation closes every downstream action.

17. Roles and governance across the investigation lifecycle

The investigator owns analysis, not every decision in the bank. The transaction-monitoring or referral team owns accurate case creation. KYC teams own customer-profile maintenance. Fraud teams may own victim protection and recovery actions. Sanctions teams own sanctions-specific legal analysis and interdiction processes. The MLRO or delegated authority may own suspicious-reporting decisions depending on local governance. Relationship teams may provide commercial context but should not be able to suppress an investigation because the customer is valuable. Legal may advise on privilege, confidentiality, law-enforcement requests or difficult jurisdictional questions. Quality assurance tests consistency and evidence. Second line challenges control effectiveness. Internal audit provides independent assurance over governance and control design.

A RACI diagram alone is not enough. Systems need enforceable permissions and workflow states. For example, the person who created an alert should not be able to delete the evidence trail. Overrides should require reasons. Senior customers should not disappear from queues because of manual reprioritisation. Sensitive case access should be limited and logged. Delegated reporting decisions should be auditable.

18. Capacity and backlog are control risks

Investigation quality deteriorates when analysts are overloaded. Old cases accumulate, customer context becomes stale, deadlines tighten, staff rely on shortcuts and complex cases are repeatedly deferred. Management therefore needs more than a simple open-case count.

Useful operational indicators include case ageing by risk, cases approaching legal or policy deadlines, rework rates, quality defects, reopened cases, escalation rates, workload by complexity, time spent waiting for information, concentration of cases with particular analysts or teams, unresolved system/data issues and the proportion of cases requiring manual searches outside the case platform.

Volume alone is a poor effectiveness metric. A team that closes more cases may simply be receiving lower-quality alerts or writing thinner investigations. Wolfsberg's 2024 and 2025 statements on Monitoring for Suspicious Activity emphasise broader outcomes beyond traditional transaction monitoring and encourage financial institutions to measure effective risk detection, useful reporting and integration of customer behaviour and other data. That industry guidance is not law, but it supports a more meaningful operating-model question: are investigations producing better risk decisions, or only more throughput?

19. Quality assurance should test the decision process

Quality review should not become grammar checking. It should test whether the case scope was appropriate, the right evidence was considered, important contradictions were resolved, the rationale supports the decision, local requirements were applied, confidentiality was protected and downstream actions were completed.

Sampling can combine random and risk-based methods. Random samples help measure baseline quality. Targeted samples can focus on high-risk customers, new typologies, complex cases, analysts with high or low filing rates, rushed closures, aged cases, unusual override patterns, cases near deadlines or matters involving sensitive customer segments. QA findings should use a defect taxonomy so that the organisation can distinguish a training problem from a data, workflow, policy or capacity problem.

The purpose of QA is not to force every analyst to write identical prose. It is to make comparable facts produce reasonably consistent decisions and to expose systemic weaknesses before supervisors or law enforcement find them.

20. Mini case study: when a normal trading account becomes a pass-through network

The following case is fictional and uses illustrative facts.

Orion Components Ltd is a small domestic electronics wholesaler. At onboarding, the bank documented expected monthly turnover of roughly 250,000 in local currency, mostly payments from five commercial buyers, with supplier payments to established domestic and regional vendors. The company has traded for three years without significant monitoring concerns.

A monitoring scenario generates an alert after the account receives 38 incoming credits from individuals over twelve days. Most values are between 1,000 and 8,000. Within hours of receipt, funds are transferred to two newly added overseas beneficiaries. Payment references on the inbound credits include phrases such as “invoice,” “refund” and first names. The activity is not itself proof of laundering, but it does not fit the customer's documented wholesale model.

The investigator begins by defining the concern: why is a business-to-business wholesaler receiving numerous consumer-like credits and rapidly forwarding the value overseas? The initial hypotheses include a new retail channel, marketplace collections, undisclosed payment services, scam proceeds or another entity using the account.

The customer profile shows no recorded move into retail sales. Corporate registry information is unchanged. Transaction history shows that the pattern started abruptly three weeks earlier. Several payers are first-time counterparties. Fraud intelligence reveals that two incoming credits were previously reported by sending banks as scam-related. Device intelligence shows normal corporate login behaviour, which weakens the hypothesis of account takeover but does not explain the incoming funds. The overseas beneficiaries are companies in a different industry from Orion's existing suppliers.

The relationship manager says Orion recently hired a sales consultant but was not told of a business-model change. The investigator asks, through the approved customer-contact route, for the commercial purpose of the incoming payments, the relationship to the new beneficiaries and supporting invoices. Orion states that it is “collecting money for partner businesses” and provides several invoices. The invoices do not match a number of payer names or values, and the partner businesses are not parties to the invoices.

At this point the evidence does not prove a particular predicate offence, and the bank does not need to do law enforcement's job by proving one. The pattern nevertheless remains materially inconsistent with the known business, contains confirmed fraud-linked incoming payments, shows rapid onward movement and is not credibly explained by the documents provided. The investigator records the evidence, the customer explanation, the contradictions and the relevant local suspicion test, then escalates to the authorised reporting decision maker.

The reporting decision is made under the law applicable to the bank entity. Separately, fraud teams coordinate on the confirmed scam credits, customer-risk teams reassess the relationship, and the business decides whether restrictions or exit review are required. Those decisions are recorded independently so that a later reviewer can see that the suspicious-reporting decision did not automatically dictate every other outcome.

QA later identifies that the monitoring scenario only saw Orion's transaction pattern after the number of individual payers crossed a threshold. The bank adds a network signal using confirmed fraud-originator referrals and improves the case screen so analysts can see payer diversity and onward-payment timing together. The case therefore creates not only a disposition but also a control improvement.

21. What a business analyst should turn into requirements

A BA working on investigation tooling should begin with the decisions and evidence, not the screen layout. Requirements should define trigger provenance, mandatory case attributes, case-linking rules, investigation scope, evidence sources, workflow states, permissions, time stamps, deadline logic, customer-contact controls, escalation routes, decision authorities, rationale fields, attachments, source/version metadata, downstream task creation, closure conditions, audit logs and MI outputs.

The BA should also ask what happens when data is missing or late. Can the case proceed while an enrichment service is unavailable? Does the workflow distinguish “no evidence found” from “source unavailable”? What happens if a customer profile changes while the case is open? Can an analyst see which version was used in the decision? If two alerts merge after separate analysts have already started work, which evidence and notes survive? Can sensitive fraud or law-enforcement information be restricted to authorised roles without hiding the existence of a required action?

Requirements for reporting should avoid hard-coding one jurisdiction's rules into a global workflow. Deadlines, decision thresholds, report types, approver roles and disclosure restrictions should be mapped to legal entities and jurisdictions through controlled configuration where feasible.

22. What architects and developers should protect

The architecture should preserve evidence integrity and decision traceability. Core design concerns include unique case and alert identifiers, event timestamps, immutable audit history, source-system lineage, access control, encryption, segregation of sensitive cases, versioned customer and transaction snapshots, linkages to reports and downstream tasks, and resilience when enrichment services fail.

A case platform should not silently overwrite historical facts. If customer risk rating changes after a decision, the case should still show the rating and supporting profile that the investigator saw. If a transaction is repaired or enriched, the system should preserve original and revised values where both matter. If external data expires, the case should retain enough evidence to explain the original decision within legal and licensing constraints.

Search and retrieval also matter. Investigators need to find linked parties, prior cases and related alerts without exposing unrelated sensitive information. Entity-resolution logic should communicate confidence rather than present weak matches as fact. Workflow APIs need idempotency so that retries do not create duplicate cases or duplicate downstream reports.

23. What testers should prove

Testing must cover more than the happy path. Positive tests should show that genuine risk patterns can be investigated end to end. Negative tests should show that legitimate activity can be resolved without artificial escalation. Boundary tests should cover deadline calculations, time zones, merged cases, reopened cases, duplicate alerts, customer changes during investigation and conflicting data.

Data-quality tests should verify missing identifiers, stale KYC data, truncated payment fields, unavailable enrichment services and late-arriving fraud intelligence. Permission tests should confirm that sensitive cases are visible only to authorised roles while supervisors retain required oversight. Audit tests should prove that edits, decisions, overrides and downstream actions are reconstructable. Failure-mode tests should simulate case-platform outage, queue spikes and partial upstream feeds.

Decision-consistency tests can use seeded cases with the same facts presented through different trigger sources. If a staff referral and an automated alert describe the same activity, the system should not produce different evidence standards merely because the entry point changed. QA teams can also use historical anonymised cases, where legally permitted, to test whether policy or workflow changes unintentionally change outcomes.

24. Common failure modes

The most common investigation failures are rarely dramatic. They are ordinary weaknesses repeated at scale: vague case scope, stale customer profiles, transaction dumps without analysis, over-reliance on one red flag, failure to consider contradictory evidence, unsupported assumptions about counterparties, customer explanations accepted without corroboration, copied closure text, untracked requests for information, unclear escalation ownership, late decisions, incomplete downstream tasks and case notes that cannot be understood months later.

Other failures are architectural. Separate fraud and AML platforms may hide related intelligence. Alert deduplication may incorrectly suppress repeat activity. A new payment rail may not feed the monitoring platform. A case may show current KYC instead of the version used at decision time. Report-filing status may not reconcile to case status. Vendor upgrades may change field semantics without alerting investigators. Access controls may be too broad, creating confidentiality risk, or too narrow, hiding material evidence.

The control response should match the cause. Training does not fix a missing data feed. More analysts do not fix poor alert quality. A new model does not fix unclear decision authority. Additional mandatory fields do not fix a workflow that encourages copy-and-paste narratives. Root-cause thinking is essential.

25. Key takeaways

An alert is a lead, not a finding. A defensible investigation starts with a clear risk question, scopes the relevant period, reconstructs customer and transaction context, tests plausible explanations, distinguishes facts from inference, records contradictory evidence and applies the reporting standard relevant to the bank entity and jurisdiction.

The reporting decision should remain separate from customer, payment, sanctions, fraud and relationship decisions even when the same facts inform them. Evidence must be reconstructable, decision authority must be explicit, confidentiality must be protected and downstream actions must be traceable.

Most importantly, the investigation should improve the control environment. Every well-understood false positive, confirmed typology, data gap, missed link, weak escalation and QA finding is information that can make the next investigation better.

Operational deep dive: building an investigation that can survive review

The base chapter describes the investigation lifecycle. This deep dive focuses on the machinery underneath it: how alerts become cases, how evidence is assembled without losing provenance, how workflow states and deadlines are controlled, how investigators collaborate across specialist teams, and how the final decision can be reconstructed later without relying on the memory of the person who handled the case.

A useful design principle is that the case-management platform is not merely a note-taking tool. It is the control record for a regulated decision process. It should show what entered the process, what information was available, what the investigator did, which judgement points occurred, who had authority, what actions were triggered and what changed afterwards.

1. Alert intake needs provenance

Every investigation should begin with a traceable trigger. The case should know whether it originated from automated transaction monitoring, a manual employee referral, fraud intelligence, sanctions screening, adverse media, a customer complaint, a regulator or law-enforcement request, an FIU or public-private partnership alert, KYC refresh, correspondent-bank information, or another source.

That source is operationally important. An automated alert should preserve model or scenario name, version, rule parameters, score, input population, evaluation time and the data that triggered it. A manual referral should preserve who raised it, when, the factual observation and any supporting evidence. A cross-team referral should retain the source case identifier and original concern so that the receiving investigator can see what has already been established rather than starting from a paraphrased summary.

The trigger should also preserve time context. If a monitoring rule fires on Monday using data loaded through Sunday, the case should not later imply that Monday evening activity was part of the original alert. That distinction matters when reviewers ask whether the investigator should have known about a later transaction at the time of decision.

2. Case creation, linking and deduplication

A case should represent a coherent risk question, not simply one alert record. This creates three recurring design problems: duplicate alerts, related alerts and network cases.

Duplicate alerts arise when the same event is detected more than once, perhaps because several scenarios overlap or an upstream message is replayed. Deduplication can prevent waste, but it must not erase evidence. The system should retain the suppressed alert identifier, detection reason and decision that it was duplicative.

Related alerts are different. Several alerts may each add meaning. A cash pattern, beneficiary pattern and fraud referral may together explain the risk better than any one alert alone. The platform should support aggregation into a case while keeping the original alerts visible. Aggregation rules should be transparent because aggressive consolidation can create oversized cases and conceal distinct legal deadlines, while no consolidation creates fragmented investigations.

Network investigations add another level. One case may centre on a customer but link to several related customers, accounts, businesses, devices or counterparties. The platform should distinguish a case subject from a related entity and record how the relationship was established. The connection might be deterministic, such as the same beneficial owner, or probabilistic, such as a likely device match. That distinction should remain visible.

3. Workflow states should describe control meaning

Case statuses often begin innocently and then become a source of confusion. Open, In Progress, Pending, Escalated and Closed sound clear until each operations team gives them a different meaning.

A better design defines states around control conditions. For example:

• Created: trigger captured, not yet assigned.
• Triage: urgency, ownership and scope being established.
• Investigation: evidence gathering and analysis under way.
• Waiting for information: a defined evidence gap exists and an accountable request is outstanding.
• Decision pending: analyst work is complete and the authorised decision maker is reviewing.
• Downstream action: reporting, KYC, fraud, sanctions or relationship tasks remain open.
• Quality review: selected for QA before or after final closure.
• Closed: investigation and mandatory downstream tasks have been completed or transferred with traceable ownership.

Banks may use different names, but each state should have entry conditions, exit conditions, permitted roles and deadline behaviour. A case must not become Closed merely because an analyst clicked a button while a required report or customer-risk action is still unassigned.

4. Deadlines should be event-driven

The investigation platform should not assume one timer. Different clocks may exist for internal service levels, suspicious-reporting obligations, sanctions or fraud responses, customer commitments and law-enforcement requests. The legal trigger for a reporting deadline may also differ from the alert creation time.

This matters because an alert can sit in a queue before enough information exists to form suspicion, or an investigator can form suspicion before completing every planned analytical step. The workflow should therefore capture the relevant decision event, such as the time an authorised person formed the suspicion under local law, rather than blindly counting from alert generation.

Australian AUSTRAC guidance provides a current example of this distinction. It expects timely review of suspicious activity and relevant material, then a decision on whether reasonable grounds for suspicion exist. Once that Australian legal threshold is formed, the applicable SMR reporting timeframe follows. The United States uses a different statutory and regulatory framework. A global platform should not turn either model into a universal timer.

Deadline logic should handle weekends, local business calendars where applicable, time zones, reopened cases, merged cases, transferred legal entities and revised decisions. If a deadline can be paused, the legal basis and permitted pause reasons should be explicit rather than embedded in undocumented operational practice.

5. Evidence needs source, time and meaning

Investigators often work with a mixture of structured data, documents, screenshots and external research. The case should help them distinguish evidence from display.

A customer name shown in a case screen might come from the core banking system, a KYC master, a payment message or a third-party enrichment service. If those sources differ, the investigator needs to know which one is authoritative for the question being asked. A displayed address might be current even though the payment under investigation used an older address. A beneficiary name might be customer-entered while a validated account-holder name came from another service. A risk score may have changed after the alert.

For material evidence, the case should record source system, source record or identifier, extraction time, business-effective time where relevant, transformation or enrichment status and enough version information to reconstruct the state seen by the investigator. This does not require copying every source database into case management. It requires deliberate provenance for facts that influence the decision.

6. Transaction reconstruction should preserve sequence

Financial-crime behaviour is often temporal. Investigators need to see not only totals but sequence: money arrives, value is split, converted, withdrawn, passed to a beneficiary, returned or transferred again. Sorting transactions in a flat table by booking date can miss that story.

The case platform should support timelines and linked flows. For payments, fields may include instruction time, execution time, value date, settlement time, channel, payment rail, amount, currency, debtor, creditor, ultimate parties, agents, remittance text, purpose, transaction reference and message identifiers. Which fields are available depends on the rail and the bank's role.

Derived features can help: time-to-onward-payment, number of unique originators, beneficiary concentration, velocity, cash-to-transfer ratios, corridor change, counterparty novelty and flow-through percentage. Derived metrics should show definitions. A label such as rapid movement = true is less useful than evidence showing the threshold, time window and transactions that created it.

7. Evidence gaps need their own state

A missing fact is not the same as a negative fact. If a registry lookup returns no director information because the service is unavailable, the case should not record “no directors found.” If transaction history covers six months because older data failed to load, the investigator should not conclude that no older activity exists.

This distinction is critical in automated case enrichment. Systems should classify results such as confirmed no match, not applicable, not found after successful search, source unavailable, permission denied, timeout and data not retained. Analysts then understand whether absence itself is evidence.

Material gaps should generate an action or caveat. If an important source remains unavailable near a deadline, the investigator may need to decide based on the evidence reasonably available, escalate the limitation or use an alternative source. The record should show the constraint rather than quietly presenting an incomplete view as complete.

8. Customer contact should be workflow-controlled

Contacting a customer can clarify activity, but it can also create confidentiality or tipping-off risk. The case platform should therefore distinguish ordinary information gathering from sensitive contact requiring approval.

A controlled customer-contact task can identify the question, permitted wording, owner, due date, response, documents received and whether the response was independently corroborated. If contact is prohibited or deferred, the reason should be recorded without exposing sensitive information to staff who do not need it.

Responses should be treated as evidence with provenance. A statement from a relationship manager about what the customer said is weaker than the actual customer response unless the communication channel and record are reliable. Documents supplied by the customer may be genuine but still need consistency checks against transaction data and independent information.

9. Investigation notes should separate four layers

Strong case notes become clearer when they separate:

Observed facts. What the bank's systems and reliable sources show.

Explanations. What the customer, relationship manager or another party says the activity means.

Analysis. How the investigator interprets the relationship between the facts and explanations.

Decision. The conclusion under the relevant policy and legal standard.

Mixing these layers creates ambiguity. “Customer laundered funds through several companies” may sound like a fact but could be only the investigator's inference. A safer formulation describes the companies, transaction pattern, ownership or counterparty links, customer explanation, contradictory evidence and why the activity remains suspicious. The final report can then state suspicion without pretending the bank has proven a crime.

This distinction is particularly important because the FFIEC BSA/AML Manual, in the U.S. context, explicitly distinguishes a bank's obligation to evaluate and report suspicious activity from law enforcement's responsibility to investigate or confirm the underlying crime.

10. Decision authority belongs in the data model

An investigation may involve several recommendations before the final decision. The system should distinguish an investigator recommendation from an authorised reporting decision, a quality-review outcome and a relationship-management action.

Decision records should capture the decision type, decision value, decision maker, authority or delegated role, timestamp, applicable jurisdiction or entity, rationale and evidence references. If a committee decides, the system may also need meeting or quorum evidence and a way to resolve disagreement without exposing unnecessary personal detail.

Overrides require special care. A senior manager should not be able to reverse an investigator's escalation without leaving a reason and authority trail. Conversely, the platform should allow a qualified decision maker to disagree with the analyst where evidence supports a different outcome. Governance should protect independent judgement while preventing invisible pressure from commercial teams.

11. Reporting and case-management systems must reconcile

A frequent operational weakness is the gap between case decision and external report submission. The investigator or MLRO marks file SAR, but the report is drafted in another system, submitted later and assigned a separate regulator reference. Without reconciliation, the bank cannot prove that every filing decision resulted in a successful submission.

The control should reconcile at least case identifier, report type, jurisdiction, filing status, submission timestamp, external acknowledgement or reference where available, amendment status and any continuing-activity linkage. Failures or rejected submissions should create exceptions that cannot disappear simply because the investigation case is closed.

The same principle applies where reporting is outsourced or centralised. The originating legal entity remains accountable according to the applicable framework even if a group service centre prepares the report. Workflow should make that responsibility visible.

12. Handoffs to fraud, sanctions, KYC and relationship teams

Financial-crime cases increasingly cross traditional silos. A fraud team may identify victim payments into a customer account. AML may see laundering risk in the recipient. KYC may need to refresh occupation, business activity or beneficial ownership. Sanctions may need to assess a newly identified counterparty. Relationship management may need to decide whether to maintain, restrict or exit the relationship.

A mature case system creates linked downstream tasks rather than relying on email. Each task should have an owner, status, due date and completion evidence. Sensitive information should be shared on a need-to-know basis. A downstream team should receive enough context to act without receiving restricted SAR/STR information where local confidentiality law prohibits it.

The originating investigation should remain aware of material outcomes. If fraud identifies ten additional victim payments after the AML case decision, that may create new suspicion or require an amended or additional report under local rules.

13. Information barriers and confidentiality

Investigation data can be highly sensitive. SAR/STR information, law-enforcement requests, whistleblower referrals, employee investigations and certain sanctions matters may need tighter access than ordinary customer information.

Role-based access should therefore be supplemented by purpose and case sensitivity. Administrators who maintain the platform should not automatically gain unrestricted access to case content. Support teams may need metadata without narrative. Relationship managers may need to know that a customer query is pending without seeing the suspicion rationale. Audit and regulators may require controlled read access.

Access events should be logged. Bulk extraction should be restricted and monitored. Search results should avoid leaking sensitive case titles or snippets to users without permission. Non-production environments should not contain identifiable investigation data unless properly protected and authorised.

14. Case versioning and evidence preservation

Investigations are not static. A customer risk rating changes, transactions are corrected, an adverse-media article is updated, a beneficiary is later identified, or an alert model is re-scored. The case should preserve the evidence state relevant to the decision.

Versioning can be implemented through snapshots, immutable event logs or references to versioned source data. What matters is that a reviewer can answer: what did the investigator know at the time? A current customer profile alone cannot answer that question if it has changed since the case closed.

FATF Recommendation 11's record-keeping principle supports reconstructability, but retention periods and legal-hold rules must be mapped locally. Deletion processes should also respect cases under investigation, litigation, regulatory review or preservation order.

15. Search, entity resolution and related-case discovery

Investigators need to find previous activity without creating privacy and false-match problems. Search should support exact identifiers such as customer number, account, company registration number, tax identifier, payment reference, device or wallet address where lawfully available. Fuzzy name matching may be useful but should communicate confidence and matching fields.

Entity resolution should not turn a weak similarity into a fact. If two people share a common name, the case should not link them without corroborating identifiers. If several companies share an address because they use the same corporate-services provider, the link may be relevant but does not establish common control.

Related-case discovery should also respect time. A connection that existed two years ago may no longer be current, but it can still matter historically. Effective dates on ownership, addresses, directors and account relationships are valuable for this reason.

16. Queue design and work allocation

Queues are part of the control environment. A simple first-in-first-out queue may be inappropriate when cases differ in urgency, legal deadlines, customer harm and complexity. Risk-based prioritisation can consider trigger severity, customer risk, ongoing activity, potential sanctions or terrorism-financing nexus, fraud loss, vulnerability, case age and reporting deadlines.

Prioritisation logic should be explainable and monitored. If a scoring model consistently deprioritises certain products or regions, management needs to know whether that reflects risk or a design flaw. Manual reprioritisation should require a reason. High-value customers should not automatically receive lower priority because commercial teams ask for quick closure.

Work allocation should consider skills. Trade-based laundering, virtual assets, correspondent banking, private banking and sanctions-sensitive investigations may require specialists. Queue metrics should distinguish waiting time from active analyst time so leaders know whether delays come from capacity, evidence requests or process bottlenecks.

17. Backlog management without quality collapse

When a backlog grows, the temptation is to reduce review depth uniformly. That can create more risk than the backlog itself. A defensible response begins by understanding why inventory increased: a new scenario, data defect, event spike, staffing issue, model change, regulatory remediation or genuine threat increase.

The bank can then prioritise high-risk cases, temporarily add trained capacity, tune obviously defective detection logic, automate low-value enrichment, extend working hours where appropriate, or seek governance decisions on lower-risk inventory. Any temporary measures should be documented and subject to quality sampling.

Backlog MI should show age bands, risk bands, deadline exposure, inflow/outflow, rework, analyst capacity, evidence-wait time and defect sources. A falling backlog is not success if closure-quality defects rise at the same time.

18. Quality assurance as a feedback system

QA should evaluate the process, not only the final narrative. A useful review checks whether the alert was correctly scoped, material evidence was available, the investigator considered both incriminating and exculpatory information, customer contact was appropriate, local policy was applied, the decision was authorised, downstream actions were completed and confidentiality was maintained.

Defects should be classified. Examples include scope defect, data defect, analysis defect, decision defect, documentation defect, timeliness defect, workflow defect, confidentiality defect and downstream-action defect. Trend analysis can then reveal systemic causes.

A recurring analysis defect may require training or clearer guidance. A recurring data defect may require engineering work. A timeliness defect concentrated in one queue may indicate capacity or routing problems. A downstream-action defect may show that case closure is not properly gated. QA becomes useful when it changes the system rather than simply scoring analysts.

19. Management information should connect activity to risk

Operational dashboards often over-emphasise counts: alerts generated, cases opened, cases closed, SARs filed. Those numbers are useful but can be misleading without context.

Management should also see quality and risk indicators such as time to triage, time to decision by risk tier, overdue legal actions, proportion of cases waiting for data, reopened cases, QA defect rates, decision reversals, report-submission failures, repeated alerts after closure, referral sources, typology mix, network-case growth, concentration in particular products or geographies and feedback from FIUs or law enforcement where available.

Filing rate should never be treated as a simple target. A very high rate might indicate precise alerts or it might reflect defensive filing. A low rate might indicate poor detection or it might reflect strong contextual data that resolves false positives. The question is whether the programme is identifying material risk and producing useful, timely decisions.

20. Current monitoring innovation changes investigations too

The Wolfsberg Group's 2024 statement deliberately uses the broader term Monitoring for Suspicious Activity rather than limiting the concept to transaction monitoring. It argues that customer behaviour and attributes combined with transactions can provide stronger insight. Its 2025 follow-up discusses transition, validation and explainability for more innovative approaches.

For investigations, the practical implication is that future alerts may be less like simple rules. A case may be triggered by a combination of device behaviour, customer changes, network relationships, transactions and external intelligence. Investigators therefore need to understand why the system produced the lead and which features were material.

Where machine learning or advanced analytics are used, the case should expose enough explanation for a trained investigator to act. A score without interpretable drivers creates operational risk. Conversely, forcing advanced models to mimic every legacy rule can prevent useful innovation. The bank should test whether investigators receive decision-relevant explanations, not whether every mathematical detail appears on screen.

21. Root-cause feedback should have a destination

An investigation can reveal weaknesses upstream: stale KYC, poor payment data, missing beneficiary information, duplicate customer records, scenario noise, a new typology, inadequate fraud-to-AML sharing or a product that is not covered by monitoring.

The case should be able to create a structured control-feedback item with owner, priority and evidence. That item might enter a KYC remediation backlog, monitoring tuning process, data-quality issue register, product-risk review or training plan. Without ownership, “feedback” becomes another note no one reads.

Closing the loop also improves explainability to regulators and auditors. The bank can show not only that it investigated individual cases but that it used investigation outcomes to improve the control framework.

22. A practical target data model

A useful conceptual data model contains several linked objects:

Trigger. Source, detection reason, score, scenario/model version, event time and source identifiers.

Case. Case identifier, subject, legal entity, jurisdiction, product, risk class, owner, state, priority and deadlines.

Party and relationship. Customer, beneficial owner, counterparty, device, account, merchant, wallet, address or other entity plus relationship type and confidence.

Evidence item. Source, record identifier, extraction time, effective time, content or reference, classification, version and reliability notes.

Action. Information request, customer contact, specialist referral, escalation, report drafting, KYC refresh or relationship task.

Decision. Decision type, outcome, decision maker, authority, timestamp, rationale and evidence references.

Report. Report type, jurisdiction, submission state, regulator/FIU reference, amendment and continuing-activity linkage.

QA finding. Sample reason, defect type, severity, corrective action and closure evidence.

The exact schema will differ by bank, but separating these objects is powerful because it prevents one free-text case record from carrying every control responsibility.

23. Mini operational scenario: one alert becomes three linked decisions

Consider a fictional retail customer whose account receives six incoming transfers from unrelated senders followed by a large payment to a cryptocurrency exchange. A monitoring alert opens because the activity is new and rapid.

The case platform enriches the alert with customer occupation, historic payment profile, fraud referrals and beneficiary information. One of the incoming senders has reported a scam to another bank. The customer's device behaviour is stable, making account takeover less likely. The investigator contacts the customer through an approved route. The customer says the incoming transfers are repayments from friends but cannot explain the sender with the fraud report.

The investigator escalates the case. The authorised AML decision maker concludes that the pattern meets the local suspicion threshold and initiates the required report. At the same time, fraud operations opens a recovery task for the scam-related credit, and KYC opens a customer-risk refresh because the activity is inconsistent with the known profile. Whether the account remains open is assessed separately under relationship and customer-protection procedures.

The case therefore contains three linked decisions: suspicious reporting, fraud recovery/customer protection and relationship/KYC action. A good data model keeps them connected without pretending they are the same control.

24. What good operational evidence looks like

A strong closed case can answer the following questions quickly: what created the case, which customer and activity were in scope, what data was available, what additional information was requested, what the customer said, what contradicted or supported that explanation, what legal or policy test applied, who made the decision, what downstream actions followed, whether deadlines were met and whether QA or feedback identified anything to improve.

If those answers require searching email, opening several disconnected platforms and asking the original analyst what happened, the investigation may have been analytically sound but the control record is weak. Operational maturity means the reasoning survives the people who performed it.

Advanced practice: requirements, testing, calibration and control improvement

A strong investigation programme is not defined only by experienced analysts. It depends on requirements that make good judgement possible, technology that preserves evidence, testing that proves the workflow under difficult conditions, quality assurance that detects inconsistent reasoning, and governance that turns case outcomes into better controls. This supplement translates the investigation lifecycle into delivery and assurance practices for business analysts, product owners, architects, developers, testers, operations leads and compliance teams.

1. Start requirements with decisions, not screens

When teams replace a case-management platform, requirements often begin with familiar interface features: dashboard, alert list, notes box, attachments and status dropdown. That approach can reproduce the old process without asking whether the control itself is sound.

A better starting point is a decision inventory. List every material decision that the workflow must support: urgency classification, case aggregation, investigation scope, evidence sufficiency, customer contact, specialist referral, escalation, suspicious-reporting decision, KYC refresh, fraud hand-off, sanctions/legal review, relationship action, closure, QA outcome and control feedback.

For each decision, define the evidence needed, the authorised role, the event that starts any deadline, the permissible outcomes, the rationale requirement and the downstream action. Once those are clear, the UI can be designed around the control instead of the other way around.

A practical BA requirement might read: “When an investigator recommends escalation, the case must record the recommendation timestamp, unresolved risk question, supporting evidence references and target decision authority; the receiving authority must be able to accept, return for defined additional work or redirect to a specialist team, with all state changes preserved in the immutable case history.” That is testable. “System should support escalation” is not.

2. Define a canonical investigation event model

Complex case systems become easier to test when important actions are represented as events rather than overwritten fields. Typical events include case created, alert linked, owner assigned, priority changed, scope changed, evidence added, evidence source failed, information requested, response received, customer contacted, specialist referral created, recommendation recorded, decision recorded, report initiated, report submitted, account action requested, QA selected, QA completed, case reopened and case closed.

Each event should carry actor, timestamp, case identifier, event type, previous state where relevant, new state and reason. Sensitive details can remain in controlled evidence objects, while the audit log preserves the fact that the event occurred.

An event model helps with reporting and reconstruction. Instead of asking only “what is the current state?”, teams can measure how long cases remained in evidence gathering, how often they were returned by decision makers, how many were reopened, where information requests create delay and which control changes increase rework.

3. Build acceptance criteria around evidence sufficiency

A workflow should not force every case to collect the same evidence. The evidence needed for a cash-structuring alert differs from a trade-finance case or virtual-asset investigation. Yet the platform can still enforce general completeness principles.

For example, before a case moves to Decision Pending, acceptance criteria can require a defined risk question, investigation period, material transaction or event set, customer context, explanation of material gaps, analyst assessment, and evidence references supporting the recommendation. Specialist modules can add requirements relevant to the typology or product.

Hard mandatory fields should be used carefully. If the system requires a source of wealth value for every case, analysts may enter meaningless text when the field is irrelevant. Better designs use conditional requirements based on case type, customer type, risk question and local policy.

4. Preserve uncertainty explicitly

Financial-crime investigations rarely produce perfect certainty. Systems should allow investigators to record unresolved uncertainty without treating it as a system error.

Useful structured concepts include confirmed fact, customer-provided explanation, corroborated explanation, unresolved inconsistency, data unavailable, possible relationship, confirmed relationship and analyst hypothesis. These labels help prevent the common problem where a tentative inference becomes a permanent fact after being copied across cases.

Uncertainty should also influence escalation. If a material fact cannot be established before a deadline, the decision maker may need to assess the case using available evidence. The record should show the limitation and how it affected judgement.

5. Design investigation journeys by risk pattern

One universal case template usually creates either excessive work for simple cases or insufficient structure for complex ones. A configurable journey can preserve common governance while adapting analytical prompts.

A retail mule case might emphasise incoming victim reports, device signals, beneficiary changes and onward movement. A corporate pass-through case may focus on business purpose, counterparties, invoices, turnover and ownership. A correspondent-banking case may require respondent context, nested activity and message data. A virtual-asset case may need exchange/VASP information, wallet exposure and blockchain-analytics evidence.

The danger is creating too many rigid templates. The platform should guide rather than constrain. Investigators need a way to expand scope when the case changes character.

6. Positive testing: prove the control can reach the right concern

Positive tests should use realistic seeded cases that contain enough information to justify escalation under the bank's policy. The aim is not to test whether an alert fires; it is to test the entire investigation journey.

A seeded mule scenario might include a retail customer with a stable salary history, sudden credits from unrelated persons, one fraud referral, rapid onward transfers and a customer explanation that does not fit transaction evidence. The test should prove that the alert enters the correct queue, relevant data is visible, the investigator can scope and analyse the case, the fraud referral is not hidden, the case can escalate to the authorised decision maker, deadlines are calculated correctly, and downstream reporting or fraud tasks can be created without losing the original evidence.

Another positive test can use a corporate customer whose activity changes after a new beneficial owner appears. The platform should reveal the effective date of ownership and distinguish old from new profile data.

7. Negative testing: prove legitimate activity can be resolved

A system that only proves escalation paths is incomplete. Negative tests should show that legitimate but unusual behaviour can be closed with a clear rationale.

For example, a customer receives several large transfers after selling a property. The pattern may breach a monitoring threshold, but the bank already holds a documented sale agreement, source-of-funds information and expected account-use update. The case should allow the investigator to link that evidence efficiently and close without forcing irrelevant EDD tasks or a suspicious-reporting workflow.

Negative testing helps identify design features that encourage defensive escalation. If closing a case requires substantially more effort than escalating it, analysts may unconsciously choose the easier path. Workflow design should not bias outcomes.

8. Boundary tests: where real control failures hide

Boundary cases deserve deliberate testing. Examples include:

• the case is created just before a local reporting deadline or timezone cutover;
• suspicion is formed after a customer response arrives but before the planned investigation is complete;
• two cases merge after separate deadlines have started;
• the customer changes legal entity or booking location during investigation;
• the investigator leaves the team and ownership transfers;
• the case is reopened after a new fraud referral;
• a sanctions issue emerges inside an AML case;
• the report submission service rejects the filing after the case is marked decision-complete;
• a high-risk customer is moved between portfolios while the case is open;
• an evidence source becomes unavailable and then recovers with different data.

Testing these conditions is more valuable than running dozens of identical happy-path scripts.

9. Data lineage testing

A case should be tested from source to screen and from screen back to source. For material fields, testers should know which source created the value, what transformation occurred, what update frequency applies and how the case handles corrections.

Payment data is especially important. If a transaction field changes through parsing, enrichment or ISO 20022 transformation, the investigation view should not silently alter meaning. Party roles such as debtor, creditor, ultimate debtor, ultimate creditor and agents should be mapped correctly. References used to join payments across systems should be tested for duplicates and missing values.

Customer data needs similar checks. Test historic versus current occupation, beneficial ownership, risk rating, address and expected activity. The case should not present a current profile as if it were the profile at the time of the transaction unless that is the intended design.

10. Resilience and degraded-mode testing

Investigation tooling depends on many services: KYC, transaction stores, fraud systems, adverse-media providers, sanctions platforms, document stores, identity services, case databases and report-filing interfaces. Partial failure is inevitable.

The platform should distinguish source failure from genuine “no result,” queue failed enrichments for retry where appropriate and tell the analyst what is unavailable. Critical decisions should not depend on a blank field whose underlying service timed out.

Resilience testing can disable one enrichment source, delay transaction history, return malformed documents, simulate duplicate API responses and interrupt the report-submission service. The expected outcome should be controlled degradation, visible exceptions and recoverable state rather than silent data loss.

11. Permission and confidentiality testing

Test personas should include investigator, team lead, MLRO or reporting authority, fraud analyst, KYC analyst, relationship manager, QA reviewer, second-line compliance, auditor, system administrator and support engineer.

Each persona should see only what is needed. A relationship manager may receive a request to collect ordinary business information without seeing that an SAR/STR decision is under consideration. A support engineer may diagnose a workflow error using technical metadata without reading the case narrative. QA and audit need appropriate evidence access but should not be able to alter the original decision record.

Tests should include search, exports, notifications, email integrations, mobile views, reporting dashboards and audit logs. Confidentiality can fail outside the main case screen through an overly descriptive notification or unrestricted data export.

12. Testing decision consistency

The system cannot eliminate human judgement, but governance can detect unjustified variation. Calibration exercises present the same anonymised case to several investigators or decision makers and compare how they scope, analyse and conclude.

The goal is not 100% identical wording. Differences are expected in ambiguous cases. The useful question is whether variation comes from legitimate judgement or from inconsistent policy interpretation, missing evidence, poor training or workflow bias.

Calibration can also test senior decision makers. If one committee systematically files reports that another would close on similar facts, the bank needs to understand why. Consistency is particularly important in global teams where local law may differ but shared policy principles should remain coherent.

13. QA sampling should combine random and targeted review

Random sampling measures baseline quality. Targeted sampling looks for elevated control risk. A mature QA plan can include cases with high severity, short investigation times, long investigation times, high-value customers, sensitive customer types, unusual closure reasons, manual overrides, no customer contact despite unexplained activity, repeated alerts, reopened cases, reporting decisions near deadlines and investigators with outlier filing or closure rates.

Sampling should not be used to punish analysts for statistical outliers without context. An investigator specialising in complex cases may have a higher escalation rate for legitimate reasons. QA should examine case quality and allocation context before drawing conclusions.

14. Define a useful defect taxonomy

Without consistent defect categories, QA becomes anecdotal. A practical taxonomy can include:

Scope defect: investigation period or subject too narrow or unjustifiably broad.

Evidence defect: material data missing, unreliable or not reviewed.

Reasoning defect: conclusion not supported, contradictory evidence ignored, or assumption treated as fact.

Decision defect: wrong authority, wrong legal/policy test or unsupported outcome.

Timeliness defect: deadline missed or avoidable delay.

Documentation defect: another reviewer cannot reconstruct the reasoning.

Confidentiality defect: inappropriate access or disclosure risk.

Workflow defect: status, ownership or hand-off failed.

Downstream-action defect: required reporting, KYC, fraud, sanctions or relationship action not completed.

Defect severity should reflect risk. A typo is not equivalent to a missed report or an unreviewed fraud referral.

15. Corrective action should follow root cause

A defect is only useful if it leads to the right fix. If analysts repeatedly miss a counterparty data set because it is hidden behind three screens, training alone is a weak answer. If cases are late because an enrichment provider takes two days to respond, adding a reminder may not address the dependency. If closure rationales are generic because the template has one small text field, the UI may be causing the behaviour.

Root-cause categories can include policy, procedure, training, data, system design, detection quality, capacity, vendor dependency, governance and external constraint. Remediation should have owner, target date, evidence of completion and effectiveness check.

16. Metrics that measure investigation effectiveness

Throughput metrics remain necessary for workforce management, but effectiveness needs broader evidence.

Useful measures include priority-risk coverage, quality of escalations, FIU or law-enforcement feedback where available, proportion of cases with complete evidence, QA pass rates, repeat defects, rework, reopened cases, downstream-action completion, time to identify linked networks, data-source failure, customer-impact incidents and control improvements generated from investigations.

Wolfsberg's Monitoring for Suspicious Activity work is useful industry context here. Its 2025 paper discusses priority-risk coverage, expanded risk indicators, precision, recall, SAR/STR quality feedback and downstream integration as potential success indicators for modern monitoring. Banks should adapt such concepts to their own risk appetite and regulatory environment rather than treating an industry paper as a binding metric list.

17. Avoid the filing-rate trap

The percentage of investigated cases that produce SARs/STRs can be informative, but it is not a universal quality target. A sudden drop may indicate poor alerts, but it could also reflect richer contextual data that resolves cases correctly. A sudden increase may indicate stronger detection, but it could also reflect overly broad escalation or defensive filing.

Use filing rate alongside alert precision, case quality, typology mix, customer segment, detection source, QA results and external feedback. Targets that reward a particular filing percentage risk distorting investigator judgement.

18. Monitor analyst productivity carefully

Case closures per analyst can help capacity planning, but crude productivity targets encourage shallow investigations and avoidance of complex cases. Complexity-adjusted workload is better.

A bank can classify cases by expected effort or specialist need and compare performance within similar groups. Waiting for customer information or another team should be separated from active analysis time. QA rework should be visible so that high closure speed with high defect rates is not rewarded.

The strongest productivity improvements usually come from removing unnecessary searching, duplicative data entry and repetitive low-value alerts rather than asking investigators to read faster.

19. Use investigation outcomes to improve detection

Closed cases provide labelled information. A high-quality closure can explain why an alert was legitimate. A confirmed suspicious case can identify useful features and typology indicators. A case that began from a fraud referral may reveal signals not present in transaction monitoring. QA defects can reveal data gaps that affect entire alert populations.

Feedback should therefore be structured. Detection teams need the alert identifier, scenario or model version, disposition, material evidence, false-positive reason where appropriate, typology, network links and any known blind spot. Privacy and confidentiality rules must be respected; a model-training data set should not automatically receive every case note.

Where machine learning is used, labels should be carefully defined. SAR filed is not identical to confirmed criminal activity. A defensive filing can be a poor positive label, while a closed case may still contain unusual behaviour. Model teams and compliance SMEs should agree what outcome each label represents.

20. Change management for monitoring and case tooling

New detection models can change case volume, complexity and explanation needs. The case-management workflow should be included in change impact assessments before a monitoring change goes live.

Questions include: will investigators understand the new trigger? Are new data sources visible? Does the case template support the typology? Is analyst training ready? Will queue capacity absorb volume? Do QA scripts cover the new logic? Are local reporting teams prepared for different case patterns? Can the old and new alert identifiers be reconciled during transition?

Wolfsberg's 2025 statement highlights “case investigation readiness” when moving to more sophisticated monitoring approaches. That is a practical point even outside institutions adopting machine learning: detection innovation fails if downstream investigators cannot interpret or operationalise the new signals.

21. Vendor change should not change the control unnoticed

Case-management and monitoring vendors regularly update data models, scoring, workflows and UI behaviour. Banks should treat material vendor changes as controlled changes.

Regression tests should verify field mappings, alert links, permissions, deadline logic, report interfaces, audit history, exports and diagram/document rendering where relevant. Release notes should be assessed for control impact. Configuration changes made by operations administrators should be versioned and, where material, subject to approval and testing.

Exit planning also matters. The bank must be able to retrieve case records, evidence, audit history and report linkages in a usable form if it changes provider. Regulatory record-keeping obligations do not disappear because a vendor contract ends.

22. Outsourced investigation still requires bank governance

Some banks use group service centres or external providers for alert review. Outsourcing can improve scale but creates hand-off and accountability risks.

The bank should define scope, permitted decisions, escalation requirements, access controls, training, quality standards, audit rights, service levels, data location, confidentiality, incident handling and exit arrangements. Where local law requires a particular reporting decision maker or responsible officer, outsourcing cannot silently transfer that accountability.

QA should sample outsourced work using the same or stronger standards as internal work. Metrics should expose rework and escalation quality, not just contractual throughput.

23. A realistic end-to-end test scenario

The following test scenario is fictional.

A long-standing retail customer receives eight transfers from new payers over three days, then sends most of the value to a newly added business beneficiary in another jurisdiction. One payer later reports an authorised-push-payment scam to its bank. The customer's device history is stable and authentication is valid. KYC says the customer is employed locally and has no recorded business activity.

The test begins with the fraud referral and monitoring alert arriving independently. The system should link them without deleting either trigger. Triage should increase priority because ongoing funds movement may continue. The case should display the customer's prior transaction baseline, the new payer concentration, the rapid onward movement and the fraud referral.

The investigator asks a defined question: whether the account is being used to receive and pass on scam proceeds. Customer contact is permitted under the bank's local procedure using neutral wording. The customer says they are helping an online acquaintance receive business payments. No credible relationship or business evidence is provided.

The investigator records facts separately from the customer's explanation and escalates. The authorised decision maker applies the local legal reporting test. The test environment should prove that the reporting decision, fraud recovery task, KYC risk refresh and relationship review can all proceed as separate but linked actions. It should also prove that users without permission cannot see restricted reporting information.

After the case is closed, QA samples it. QA confirms appropriate scope and reasoning but identifies that the case screen did not show one payer's prior fraud referral until the analyst opened a separate system. A remediation item is created for data integration. The test is therefore not complete until that feedback action is visible and owned.

24. Acceptance checklist for a production-ready investigation workflow

Before a new or materially changed investigation workflow goes live, the delivery team should be able to demonstrate that trigger provenance is retained; duplicate and related alerts are handled without losing evidence; workflow states have clear control meaning; deadlines use the correct events and jurisdictional configuration; source failures are distinguishable from no-result outcomes; evidence has provenance and versioning; customer contact is controlled; investigation reasoning is reconstructable; decision authority is explicit; report submission reconciles to case decisions; specialist hand-offs remain traceable; access is role-appropriate; audit history is immutable; queue prioritisation is explainable; QA defects can feed remediation; and archived records remain retrievable for the required period.

No single checklist proves effectiveness forever. It establishes the starting control. Production MI, QA, audit, regulatory feedback, threat changes and investigation outcomes must keep testing whether the workflow continues to serve its purpose.

25. Final perspective

Investigation technology should make professional judgement stronger, not hide it behind automation. The best workflow brings the right evidence together, exposes uncertainty, preserves chronology, assigns accountable decisions and prevents required actions from disappearing between teams.

For delivery teams, the central question is therefore not “did we build the case screen?” It is “can a competent reviewer understand why this case existed, what was known, how the bank reasoned, who decided, what happened next and whether the control learned from the outcome?” If the answer is yes under both normal and stressed conditions, the investigation process is becoming a real control rather than an administrative queue.

References and further reading

The investigation framework in this chapter is deliberately jurisdiction-neutral at its core. FATF provides the global AML/CFT architecture, while the FFIEC/FinCEN and AUSTRAC sources below are used as clearly scoped examples of how particular jurisdictions translate suspicious-activity review, decisioning, documentation and reporting into operational expectations. Wolfsberg material is industry guidance, not law.

Global standards

• Financial Action Task Force (FATF), The FATF Recommendations, current consolidated edition as amended June 2026: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html
• FATF, Guidance for a Risk-Based Approach: Banking Sector: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-rba-banking-sector.html
• Basel Committee on Banking Supervision, Sound management of risks related to money laundering and financing of terrorism: https://www.bis.org/bcbs/publ/d505.htm
• Egmont Group, Financial Intelligence Units: https://egmontgroup.org/about/financial-intelligence-units/

United States operational examples

• Federal Financial Institutions Examination Council (FFIEC), BSA/AML Examination Manual — Suspicious Activity Reporting: https://bsaaml.ffiec.gov/manual/AssessingComplianceWithBSARegulatoryRequirements/04
• Financial Crimes Enforcement Network (FinCEN), Suspicious Activity Report Supporting Documentation: https://www.fincen.gov/resources/statutes-regulations/guidance/suspicious-activity-report-supporting-documentation
• FinCEN and the U.S. federal banking agencies, Frequently Asked Questions Regarding Suspicious Activity Reporting Requirements, 9 October 2025: https://www.fincen.gov/resources/statutes-regulations/guidance/frequently-asked-questions-regarding-suspicious-activity

Australia operational examples

• AUSTRAC, Suspicious matter reports, updated 9 September 2026: https://www.austrac.gov.au/industry-and-business/obligations-and-guidance/your-amlctf-program/reporting-us/suspicious-matter-reports
• AUSTRAC, How to monitor your customers: https://www.austrac.gov.au/industry-and-business/obligations-and-guidance/your-amlctf-program/customer-due-diligence/ongoing-customer-due-diligence/how-monitor-your-customers
• AUSTRAC, What you must monitor for: https://www.austrac.gov.au/industry-and-business/obligations-and-guidance/your-amlctf-program/customer-due-diligence/ongoing-customer-due-diligence/what-you-must-monitor

Industry practice on effective monitoring and investigations

• Wolfsberg Group, Statement on Effective Monitoring for Suspicious Activity, Part I: Moving Beyond Automated Transaction Monitoring, 2024: https://wolfsberg-group.org/resources/general/168
• Wolfsberg Group, Statement on Effective Monitoring for Suspicious Activity, Part II: Transitioning to Innovation, 2025: https://wolfsberg-group.org/resources/195/202

These sources should be read together with the law, regulation, FIU guidance, supervisory expectations and approved policy applicable to the bank entity handling the case. Reporting triggers, deadlines, confidentiality rules, account actions and decision authorities are not globally identical.