Financial Intelligence Units, SAR Quality and Feedback Loops

A financial intelligence unit (FIU) receives and analyses financial information and disseminates relevant intelligence to competent authorities. Under FATF Recommendation 29 it is a national centre for suspicious transaction reports and other relevant information. An FIU may have an administrative, law-enforcement, judicial or hybrid structure. It is not automatically the investigating police force or the bank's supervisor.

A bank's SAR or STR communicates suspicion under the applicable local threshold. It is not an accusation proved beyond doubt, a substitute for a fraud complaint or permission to freeze every account. Identify the reporting entity, threshold, deadlines, submission channel and decision authority from national rules; FATF Recommendation 20 is the international reporting standard rather than a global filing form.

Useful reporting explains who is involved, what happened, when, where, how and why it is suspicious. Include relationships, amounts, currencies, transaction identifiers and evidence supporting the concern. Separate facts, customer explanations, analytical inferences and unresolved uncertainty. A list of transactions without a reason for suspicion leaves the FIU to reconstruct the bank's reasoning.

Protect the SAR and information revealing its existence. US agencies' 2 September 2026 joint statement clarifies that existing SAR confidentiality requirements do not categorically prevent customer communication about suspicious or potentially fraudulent transactions or account closures. It does not change the law or permit disclosure of a SAR. Other jurisdictions' tipping-off rules need separate analysis.

Understanding the intelligence chain

An FIU becomes useful when it can connect information that no individual reporting institution can see alone. A bank may observe salary credits, a merchant's settlement account or a sequence of foreign payments. Another institution may hold the receiving account, and a competent authority may know that a company is associated with a wider investigation. A clear report gives the FIU a reliable starting point for making those connections. It should not pretend that the reporting bank has already reconstructed every subsequent transaction or established the final offence.

Consider an investigator who sees a small business receiving payments from unrelated individuals and sending most of the funds to an overseas supplier. The bank can identify its customer, its own credits and debits, the payment references it received and the explanations it obtained. It may infer that the account is being used as a collection point. It cannot responsibly assert that the overseas recipient is a criminal network solely because the recipient's name resembles a company mentioned in an unverified article. The report gains value when those boundaries are explicit: the receiving-account identity is established to one level, the business relationship remains uncorroborated, and a possible external connection is presented as a lead.

Operational intelligence examines particular subjects, transactions, relationships and events. Strategic analysis examines broader patterns, methods and vulnerabilities. A public typology bulletin may therefore help a bank design monitoring without confirming that one customer's activity is suspicious. Conversely, a case-specific request may seek records about an existing investigation without making the bank responsible for deciding the prosecution strategy. The bank should identify the purpose of the communication before changing customer controls, sharing information internally or treating the communication as evidence of wrongdoing.

The useful professional question is what additional understanding the report makes possible. A narrative that identifies a recurring beneficiary, shows how the customer explanation conflicts with observed movement, and explains the reliability of the connection can support analysis. A narrative stating only that the customer is high risk shifts the whole reasoning task to the FIU. Risk ratings, product labels and automated scores can be context; they do not supply the reason for suspicion by themselves.

The reporting institution and its decision makers

A group can operate through several branches, subsidiaries and service companies. The investigator needs to know which institution is the reporter, which institution holds the account, which entity observed the relevant activity and which officer is authorised to decide a filing. A central team may investigate for several entities, but central processing does not automatically make one entity the legal reporter for every case. A workflow that records only the group brand can obscure the applicable deadline, reporting portal, data-protection rules and confidentiality restrictions.

The reporting officer owns the filing decision within the bank's delegated framework. Investigators establish facts and develop the analysis. Relationship managers may explain the customer's business and facilitate factual requests. Payment operations confirm transaction execution, return, rejection or repair details. Fraud teams provide victim reports, recovery actions and authentication evidence. Legal advises on jurisdiction, protected information and any authority to pause a transaction. Technology and reporting operations support reliable submission. These contributions should be visible without converting every contributor into an approver of the final suspicion assessment.

An effective record identifies the actual decision maker, the decision time and the evidence version reviewed. A shared mailbox name is not enough when several people can send messages through it. If an officer acts under temporary delegation, the bank should retain the scope and period of that delegation. If a material fact arrives after approval, the workflow must show whether the original decision still stands or whether a new assessment is required. Recording those changes protects both the institution and the individual reviewer from a later reconstruction based on incomplete chronology.

Group coordination can help identify duplicate reports or related activity, but it needs lawful information-sharing routes. A group investigator should not assume that access to an operational case automatically permits access to every subsidiary's protected SAR record. The report itself, knowledge of its existence, the underlying transaction facts and legal advice may require different treatment. A practical access design uses those distinctions rather than one unrestricted folder for everything associated with the customer.

Reports, referrals and requests have different purposes

An internal referral is a request for bank investigation. A SAR or STR is a protected external report under the applicable reporting framework. A police complaint about a scam may describe victimisation. An FIU information request may seek additional facts. A supervisory request may examine the bank's compliance. A court instrument may compel production or restraint. These items can concern the same customer while creating different obligations, access permissions and decision paths. A common case identifier can connect them, but it should not erase their legal identities.

For example, a customer reports that a fraudster persuaded them to send money. The fraud team may immediately attempt recovery, support the customer and notify the receiving bank through a permitted scheme process. An AML investigator separately assesses the receiving-account information and any pattern suggesting proceeds movement. The bank may have reasons to submit a SAR or STR, but the report should explain the reporting bank's suspicion and the facts supporting it. It should not merely attach the victim complaint and assume that the complaint substitutes for the bank's own analysis.

An authority request may provide valuable intelligence, but the bank should establish its authenticity, scope and legal handling route before disclosing records. A request for information is not automatically a direction to freeze the customer account. A request that asks the bank to preserve documents is not necessarily a request to stop ordinary payments. Where a valid instruction requires a particular action, the bank should record that instruction and its authority separately from its own risk-based customer decision.

Clear status language prevents confusion. “Investigation open,” “filing approved,” “submission rejected,” “report accepted,” “authority request received” and “account restricted” describe different events. A dashboard showing only “reported” may hide a rejected submission or a report that was drafted but never sent. A customer-service tool showing the same status may also disclose information that should remain protected. Both accuracy and confidentiality depend on choosing the right status for the audience and purpose.

What the bank can and cannot know

The reporting bank should distinguish observed records, customer statements, third-party information and analytical inference. Observed records include transactions processed by the bank, account-opening information and communications retained in its systems. A customer explanation is evidence that the customer made that statement; it is not automatically proof that the statement is true. A public registry can establish a recorded company relationship at a particular date, while a social-media allegation may provide only a weak lead. An inference connects facts through reasoning and should be labelled accordingly.

Confidence can vary within one case. The bank may be confident about the amount and execution time of a transfer, moderately confident about the recipient's trading identity and uncertain about the purpose of the relationship. Replacing these distinctions with one case-level confidence score hides information the FIU needs. The narrative can say which facts are verified, which remain uncorroborated and what steps were taken to resolve the uncertainty. Missing information is often useful when its significance is explained rather than concealed.

The bank should also distinguish absence of evidence from evidence of absence. It may find no invoices in the documents supplied, but that does not establish that invoices never existed. It may see no incoming sales credits in the reviewed account, but the business could receive revenue elsewhere. Those limitations do not necessarily defeat suspicion. They change the way the concern is expressed and the additional inquiry that would be useful. A precise report can explain that the claimed business model remains unsupported by records available to the bank without asserting knowledge of every external account.

Time matters. A customer may have owned a company during the reviewed payments but sold it before the investigator searched the registry. A current address may differ from the address used at account opening. A payment may have been attempted, rejected and later resubmitted. A careful report identifies the relevant dates and the version of each record. Otherwise, a correct current fact can create a misleading historical account.

Local reporting thresholds and defensible judgement

Training should not teach one universal trigger for suspicion. Local legislation, reporting rules and supervisory guidance determine the applicable threshold and any reporting period. The bank's investigator must understand that framework and the institution's delegation rules. An automated alert, a customer risk score or a transaction exceeding an amount may cause review; none necessarily determines when a statutory reporting clock begins. A procedure should explain how the institution identifies the relevant legal event and records that assessment.

The assessment should be reasoned rather than mechanical. An unusual pattern may be legitimate after corroboration. A superficially ordinary transaction may be suspicious when combined with reliable information about concealment, coercion or a linked network. The investigator should record why the available explanation succeeds or fails, which facts remain material and how the local threshold was applied. A decision not to file should not rely solely on the customer being commercially important, the amount being small or the investigation queue being large.

Seeking more information can be appropriate, but it should not become an indefinite reason to postpone a decision where the applicable threshold has already been met. Conversely, filing a weak report simply to clear a queue can burden the FIU and obscure the cases that need attention. The bank should distinguish necessary corroboration, optional enrichment and unresolved questions that must be disclosed in the report. The reporting officer can then decide on a defensible factual basis without pretending that every uncertainty must be eliminated first.

The institution should preserve the version of the relevant policy and legal interpretation. If reporting rules change, later reviewers need to understand the rules that applied when the decision was made. A policy update is also a reason to review forms, routing, deadlines and training. It is not enough to alter a paragraph in the policy library while operational systems continue to use the old clock or the wrong reporting entity.

Customer treatment alongside reporting

Reporting and customer treatment are related but separate. A bank may need to prevent a further scam payment, repair missing information, comply with a sanctions restriction, consider relationship risk or respond to a valid restraint instrument. The report itself does not automatically provide authority for any of those actions. The customer decision should identify its own legal or contractual basis, decision owner, scope and review conditions. That distinction helps avoid both unsupported restrictions and failure to act where a separate duty applies.

Proportionality matters when an account supports wages, benefits, food, rent or a small business's ordinary expenses. The bank should assess lawful alternatives and the consequences of its action while protecting the investigation and complying with applicable restrictions. A vulnerable customer who has been manipulated by a scammer should not be automatically treated as a knowing participant in laundering. The bank may need both fraud support and AML analysis, with different personnel, evidence and communication rules.

Customer communications require jurisdiction-specific handling. The US September 2026 joint statement confirms that existing SAR confidentiality rules do not categorically prohibit discussing suspicious or potentially fraudulent transactions or account closure with customers. That is not permission to reveal a SAR or its existence, and it is not a global statement about other jurisdictions' tipping-off rules. Staff need practical examples showing which underlying facts can be discussed through an approved route and which protected information must remain restricted.

An investigator should therefore design a factual request around the information needed rather than exposing the bank's protected reporting deliberation. Asking for an invoice, explaining an account-verification requirement or discussing a customer's scam experience may be appropriate under the relevant framework. Saying that the bank is preparing a SAR is a different disclosure. Training, templates and permissions should make the distinction usable during a live call, not leave staff to resolve it from a broad confidentiality slogan.

From internal escalation to intelligence

An internal referral should identify the trigger, customer and linked parties, relevant transactions, supporting documents and steps already taken. Investigators corroborate information, consider plausible explanations and assess whether the local reporting threshold is met. The reporting officer records the decision and rationale, including decisions not to file when that is required by the bank's procedure.

Describe the sequence in the narrative before presenting detailed records. State which activity differs from the expected profile and why the explanation fails or remains unresolved. Avoid unexplained abbreviations, copied alert text, speculative criminal labels and unsupported certainty. If data is missing, name the limitation and its effect; do not invent a beneficiary or identify two same-name people as one individual.

Technical submission controls matter. Validate mandatory fields, reconcile attachments to the case, preserve the submitted version and retain acknowledgement or rejection responses. A queued message is not proof that the FIU received an accepted report. Route rejection or failed submission to a named owner with urgency reflecting the applicable deadline.

Relationship management continues separately. Assess any required restriction, fraud protection, legal consent process or account decision under local law. A reporting backlog must not become an excuse to ignore an immediate sanctions duty. Equally, filing a report does not by itself supply legal authority for seizure.

Building a reportable chronology

Chronology gives the FIU a route through the evidence. Start with the relevant customer background, identify the activity under review and describe the sequence that produced concern. Explain changes in counterparties, values, frequency, channels or account use. Include the customer's explanation and the bank's corroboration steps at the points where they affect the assessment. A chronology should make clear which activity preceded the explanation, which action the bank took and which fact arrived later.

Transaction dates need careful labelling. Instruction time, booking date, value date, execution time and return date may differ. An investigator analysing movement within hours should not substitute a statement's displayed date for the payment engine's event timestamp. Where the reporting form permits only a date, the narrative or supporting schedule can explain relevant timing. Time zones should be preserved or explicitly converted so that cross-border records do not appear to reverse the sequence of events.

Amounts and currencies should remain understandable. Do not add a dollar amount to a euro amount and present the result as one total without a stated conversion method. Distinguish attempted activity from completed activity, outgoing amounts from incoming amounts and a returned transfer from an additional independent payment. A useful schedule gives each material transaction an identifier and a status, then reconciles the schedule to the narrative. That prevents the same economic movement being counted repeatedly because it appears in several system messages.

The chronology does not need every transaction ever processed for the customer. The investigator should identify the review period and explain why it is relevant. Supporting schedules can provide detail while the narrative explains the material pattern. If the FIU cannot tell which events matter and why, more rows may reduce usefulness. Good reporting selects and organises evidence without hiding facts that contradict the suspicion or materially change the interpretation.

Identity and network evidence

Party identification is a reporting-quality control. Names should be accompanied by identifiers available through the applicable reporting framework and bank records. The investigator should distinguish legal names, trading names, aliases, account holders, authorised users, beneficial owners and payment beneficiaries. Two records sharing a name may concern different people, while one person may use several names. A report should explain how the bank established the connection rather than quietly merging records.

Network evidence also needs provenance. A shared phone number can reflect a household, an employer's administrative contact, an agent or an organised scheme. A common device can indicate control but may also be explained by a shared terminal or assistance provided to a vulnerable customer. The investigator should identify the source, relevant period and significance of the shared attribute. A tentative link can be worth reporting when clearly labelled, but it should not be presented as established common ownership without supporting evidence.

Corporate networks require historical ownership and role distinctions. A director is not necessarily an owner. A nominee arrangement may be lawful but require further transparency. A company-formation address can be shared by many unrelated customers. A supplier relationship may explain repeated payments between entities. The narrative should show which links are verified, which are inferred and which legitimate explanations were considered. This helps the FIU combine the bank's evidence with other sources without inheriting an unsupported conclusion.

The bank should preserve the identifiers used for matching. If an investigator finds a connection through a later customer-profile update, the report should identify the update date and its source. Historical transaction analysis and current network intelligence can coexist, but their timelines should remain visible. A subsequent ownership link can justify new inquiry without proving that the original reviewer possessed the same information.

Submission as an accountable delivery process

A report is not successfully delivered merely because a batch job completed. The bank should distinguish drafting, approval, transmission, technical receipt, validation, acceptance and any subsequent correction. The reporting portal may reject a mandatory field, an attachment or a schema version. A network outage may leave the institution uncertain whether a submission reached the FIU. Each state needs an owner and a recovery procedure that reflects the applicable filing deadline.

Retries create a particular risk. If a timeout occurs after receipt, blindly sending a fresh report may produce a duplicate. If the bank assumes success without checking, the report may never arrive. The delivery process should retain the submission identifier, the exact payload, response details and the relationship between attempts. The preferred handling depends on the FIU channel, but the bank should be able to explain why it retried, how it checked acceptance and how it prevented the case being closed prematurely.

Amendments and supplementary reports should preserve history. Correcting an identifier, adding a material transaction or explaining a newly established connection can improve intelligence. It should not silently overwrite the version previously submitted. The record should link the later communication to the original report and identify what changed, why it changed and who approved it. The reporting officer should consider whether the new fact affects the original suspicion assessment or only improves the supporting detail.

Operational resilience includes people as well as systems. The bank needs a lawful approved alternative when its normal portal, signing mechanism or reporting team is unavailable. Contact details and instructions should be current, and exercises should use fictional material or another approved safe environment. A fallback that depends on one officer's personal mailbox creates both availability and confidentiality weaknesses. The institution should prove that a report can be submitted and acceptance can be confirmed during a realistic disruption.

Vendor services and the bank's reporting accountability

A bank may use a vendor to host case management, assemble reporting forms or transmit files. The contract can allocate operational tasks, but the bank still needs an accountable decision process under its applicable obligations. It should identify who supplies facts, who develops the analysis, who approves a report and who monitors acceptance. A vendor-generated draft is a working product that needs appropriate review. A successful vendor delivery message is evidence to reconcile, not an automatic substitute for confirmation from the reporting channel.

The service assessment should cover data access and support practices. Support staff may need a submission identifier and error code to diagnose a failed transmission without needing the full narrative. A test environment should not casually use live reports. Data-location arrangements, subcontractors, retention and export procedures need review under the relevant legal framework. The bank should understand how protected information could be accessed during maintenance, incident response or recovery, rather than examining only normal investigator permissions.

Change management should address form versions and reporting-channel updates. A new mandatory field can cause rejection even when the bank's existing case information is adequate. A vendor may alter the way it transforms identifiers or maps transaction types. The bank should test those changes against the applicable reporting specification, preserve representative results and ensure that operational staff understand new rejection messages. The reporting officer needs assurance that the submitted content still expresses the approved assessment accurately.

Exit readiness matters because historical reports may be needed long after a contract changes. The bank should be able to retrieve submitted payloads, attachments, acknowledgements, corrections, decision records and access history in a usable format. An export containing only the latest narrative loses the filing chronology. A PDF without linked identifiers may be readable but difficult to reconcile. Migration testing should demonstrate that an authorised reviewer can reconstruct selected reports and their delivery states from the replacement environment.

Retention, legal holds and responsible retrieval

Reporting records should follow the retention framework applicable to the institution and record type. The bank should not assume that all jurisdictions, all documents and all communications use the same period. A report, supporting transaction records, legal advice, customer correspondence and system logs may have different requirements. A valid preservation or legal-hold instruction can also affect deletion. The operational policy should identify those categories and the owner who resolves conflicts or uncertainty.

Retrieval should be tested before a live authority request. An archive may store the submitted file while losing the attachment index, or retain an acknowledgement without the payload it confirms. Encryption-key changes can make records technically present but unreadable. A case identifier may change during migration. The bank should select historical examples across relevant system versions and prove that the report, supporting records and correction history can be reconstructed. The test should document gaps rather than treating storage inventory as proof of usable evidence.

Responsible retrieval also limits access. An authorised reviewer may need the historical report for quality assurance or a valid legal request, while a relationship manager may need only an operational account fact. The archive should preserve those distinctions. Search results should not reveal protected filing status to a broad audience. Bulk exports deserve particular controls because a single authorised task can create a large unprotected copy if the destination and purpose are not checked.

Deletion requires an auditable process when it is permitted. Staff should not manually delete a report to make a customer file appear clean or remove an error from view. Corrections preserve historical truth through the approved reporting route. When retention expires, the institution should apply its authorised schedule and any holds, then retain appropriate evidence of the disposal process. The policy must remain consistent across live systems, archives, backups and vendor environments, with any practical limitations made explicit.

Feedback, quality and confidentiality testing

FIU feedback can be strategic, typological or case-specific; a bank will not necessarily learn the outcome of every report. Lack of feedback does not prove that a filing was useless. Use public indicators and lawful feedback to improve typologies, narrative quality and investigation training without treating every new indicator as a deterministic reporting rule.

Quality assurance checks the reason for suspicion, chronology, party identifiers, amounts, source references and consistency with attachments. Review a sample of non-filed cases as well as filed cases to test under-reporting. Volumes and conversion rates can reveal changes but cannot establish intelligence usefulness on their own.

Test reporting-record access, export, search indexing, support tools and customer correspondence. A protected report can leak through a ticket attachment or a customer-visible note even if the main case screen is restricted.

Reading FIU feedback without overstating it

Feedback can describe report-quality defects, emerging typologies, useful indicators or case-specific information. The bank should identify which kind it received and the intended audience. A broad bulletin may inform training and monitoring design. A correction request may require a specific filing amendment. Protected case intelligence may require restricted access and careful use. Routing all feedback to one general mailbox without classification can either leak sensitive material or leave important operational changes unimplemented.

Lack of case-specific feedback is not proof that a report had no value. The FIU may combine it with other reports, retain it for later analysis or be unable to reveal operational details. Likewise, an acknowledgement does not establish that the bank's narrative was useful. The institution should use measures within its control: factual accuracy, clarity, timeliness, accepted delivery, reproducible analysis and correction rates. External outcomes are informative when available, but they cannot be assumed for every filing.

A typology should become a testable risk hypothesis rather than an automatic reporting rule. If feedback describes accounts receiving many unrelated credits followed by rapid onward movement, the bank should identify the products, customer populations and data fields relevant to that pattern. It should compare lawful collection models and other legitimate explanations. A detector can prioritise review, while investigators assess the evidence and the local reporting threshold. Treating every account matching the pattern as reportable would skip the very reasoning the feedback is intended to improve.

The feedback loop should have a closure test. A narrative-quality issue might require coaching and independent sampling. A missing identifier might require form validation and source-data repair. A typology gap might require scenario development, testing and capacity assessment. Recording a bulletin as “read” does not demonstrate that the relevant control changed. The bank should retain the decision, owner, implementation evidence and subsequent review of whether the change addressed the original issue.

Fictional case: correcting a mistaken identity without deleting history

A fictional retail bank drafts a report about a customer named Adrian Silva. The investigation includes a public article concerning a person with the same name and a company relationship found in a commercial database. Before final submission, a quality reviewer notices that the article concerns a different date of birth and residence. The commercial database has combined two profiles. The bank's transaction concerns remain real, but one external link is unreliable. The correct response is to remove or qualify the unsupported link, not to discard the entire investigation automatically.

The reviewer first identifies where the mistaken link influenced the assessment. It may appear in the narrative, a network diagram, a risk-rating rationale and a proposed account restriction. A local correction to one paragraph is insufficient if the same assertion remains elsewhere. The investigator should trace the claim to its source and record the evidence establishing that the identities differ. The bank then reassesses the material decisions affected by the error, including whether the filing threshold remains met on the remaining facts.

If the report has already been accepted by the FIU, the institution follows the relevant correction or supplementary-report procedure. It preserves the original submitted version and clearly explains the corrected identifier and the effect on the assessment. An authorised reviewer should be able to see that the bank discovered the error, investigated its scope and acted transparently. Silently replacing the local copy would create a false impression that the FIU received the corrected information originally, while leaving the external intelligence problem unresolved.

Customer treatment requires its own review. If the mistaken public link contributed to a restriction or exit decision, the accountable owner should reconsider that action using corrected facts. The bank may still have other reasons for concern, but the erroneous connection cannot continue to support the decision. Where communication or redress is appropriate, legal and customer-protection teams should determine the permitted explanation. Confidentiality restrictions do not justify retaining a known factual error in internal records used for future decisions.

The root-cause assessment distinguishes a one-off reviewer mistake from a systemic matching defect. If a data provider merged records, other cases using that provider may be affected. If analysts routinely treat same-name articles as established identity matches, training and quality sampling may need revision. If the case system copies external links into several outputs without source identifiers, technology changes may be necessary. The corrective action should target the failure mechanism, not simply instruct staff to be more careful.

For the learner, the key test is whether the bank can show the claim's lifecycle. Identify the original source, the point where it became a bank inference, the decisions that relied on it, the discovery of the conflict and the correction route. Explain why a report can retain valid suspicious-activity analysis while withdrawing an invalid external association. Good intelligence quality includes the ability to correct uncertainty and error without rewriting the history of what was actually submitted.

Fictional case: incomplete correspondent visibility

A fictional correspondent bank observes several payments from a respondent institution into an account used by an export business. The payment messages identify immediate parties, but information about the respondent's underlying customer is limited. A later request reveals that another institution supplied the customer relationship. The bank suspects that the respondent is providing access to an undisclosed nested institution. The evidence may justify inquiry, yet the correspondent should not claim that it has performed full CDD on every downstream customer or knows every participant's role.

The investigator separates the payment chain from the relationship chain. The message identifies institutions acting in this payment. The correspondent's agreement identifies the respondent as its customer. Information from the respondent may describe another institution using the service. These records answer different questions. The bank should identify what was known at onboarding, what changed in the reviewed period and which facts are established through payment records rather than respondent statements. A report that labels every institution as a direct customer would misdescribe the bank's visibility and responsibilities.

The bank requests information necessary to understand the relevant activity through an approved route. It asks about service scope, underlying institution, customer type and the business explanation for the payments. It does not disclose protected reporting deliberations to justify the request. Responses are assessed for completeness, coherence and corroboration. A slow response may be an operational problem; a contradictory response about the underlying institution may be a substantive concern. The investigator should explain the distinction and the effect on the remaining assessment.

If the local threshold is met, the report can describe the suspected undisclosed access and the supporting transactions. It should distinguish observed records, the respondent's explanation and unresolved downstream information. The FIU may have access to other reports that help resolve the network. The correspondent's role is to provide accurate intelligence from its own position, not to manufacture certainty about external accounts. The narrative should also identify any relevant limitation in payment data and the steps taken to address it.

Relationship remediation is a separate decision. The bank may require better transparency, revise permitted service scope, conduct enhanced due diligence or consider restriction under its framework. It should not assume that filing a SAR or STR automatically requires immediate termination of the respondent relationship. Equally, ongoing commercial access should not continue without an accountable assessment of the unresolved exposure. The customer decision records its own rationale and legal or contractual basis, including the effect on legitimate downstream payments.

The learner should identify which facts would support three different conclusions: a routine data-quality defect, a breach of agreed respondent service scope, or suspicious concealment requiring reporting consideration. Explain what additional evidence would distinguish them. The same incomplete message may contribute to more than one issue, but the report should make the reasoning clear rather than presenting missing data as automatic proof of laundering.

Worked report-quality case

A fictional report says only that a customer made unusual transfers. The case contains multiple payments to a new beneficiary immediately after credits from unrelated people, inconsistent business explanations and linked accounts. Rewrite the narrative as a sequence, state the amounts and currencies, explain the concern and distinguish verified links from tentative matches.

Then identify which facts may be discussed in a fraud-protection call and which SAR information must remain protected under the relevant law. Do not assume that the US communication clarification applies globally.

Fictional case: the collection account with two plausible explanations

Harbour Events is a fictional small company whose account was opened to receive deposits for conferences. Its profile describes seasonal receipts from corporate customers and payments to hotels, caterers and venues. During a twelve-day period the bank observes eighteen credits from sixteen individuals, totalling EUR 92,000. Most funds leave within the next business day to a newly introduced overseas company described as a marketing supplier. Several payer references mention an investment opportunity. The monitoring alert identifies the rapid movement, but the company's seasonal business model could also produce concentrated receipts and supplier payments.

The first investigator task is to define the concern without deciding it prematurely. The pattern is not suspicious simply because there are many payers or an overseas supplier. The potentially material inconsistency is that the payer references and payment purpose may not match the declared events business. The investigator records the review period, the actual credited and debited amounts, the new beneficiary and the origin of the alert. The case also records which customer records are current and whether the original expected-activity profile has been refreshed since onboarding.

The relationship manager obtains a customer explanation through the bank's approved factual inquiry process. Harbour says that the payments concern a new investor conference and that the overseas company arranges advertising. It supplies six invoices. The investigator checks whether the invoices correspond to the actual payers, amounts and dates. Four identify the same event, two refer to unrelated consulting services, and none explains the investment wording. Those observations do not prove fraud, but they make the explanation incomplete. The case should record the documents and their specific limitations instead of merely writing “customer explanation not satisfactory.”

Payment operations confirm that the outbound transfers were executed rather than rejected or returned. Their records also show that the beneficiary account details were introduced shortly before the first credit. A public company record supports the beneficiary's existence but does not establish the claimed marketing services. The investigator therefore distinguishes verified recipient details, the customer's claimed relationship and the uncorroborated commercial purpose. If the payment message lacks a field the investigator would like, the report should state that limitation. It should not invent an ultimate recipient to make the narrative appear complete.

The bank then receives a fraud referral from one payer. The payer states that they were promised a high investment return and were told to label the transfer as an event deposit. This is materially different evidence from the original alert. The investigator preserves the referral source and date and checks whether the payer's account and transfer can be matched to the observed credit. The report can describe what the payer said and the matched payment. It should not claim that every other payer was defrauded unless that conclusion is supported by further information.

The reporting officer assesses the combined facts under the applicable local threshold: inconsistent payment descriptions, rapid onward movement, incomplete invoices and a corroborated fraud allegation about one transfer. A defensible narrative explains each element and its limits. The institution separately considers customer risk, possible recovery actions and any lawful restriction. The SAR or STR decision does not itself authorise seizure of the balance. If the bank communicates with Harbour or affected payers, it uses an approved route that respects the jurisdiction's reporting confidentiality and tipping-off rules.

The teaching exercise is to write two short assessments from the same case. One should explain why the initial alert required inquiry but did not establish a conclusion. The other should explain how the later payer evidence changed the assessment. Identify which facts belong in the report, which uncertainty remains and what additional information would help the FIU connect the account to a wider pattern. The answer should preserve the distinction between suspicion, verified fraud victimisation and a final criminal finding.

Fictional case: urgent scam proceeds and reporting-system failure

A fictional instant-payment fraud team identifies funds arriving in a newly opened account from three customers who independently report impersonation scams. The receiving customer immediately initiates transfers to several other banks. Some funds remain available in the receiving account. The fraud team has time-sensitive recovery and customer-protection tasks, while the AML investigator needs to assess the account holder's role and any reporting duty. The bank's normal FIU portal becomes unavailable during the investigation. This case combines urgency, separate decisions and a delivery problem.

The team should not wait for a finished narrative before considering lawful urgent protective action. It should also avoid treating the urgency as permission to bypass decision rights. Fraud operations establish the status of the payments and available recovery routes. The authorised control owner assesses any restriction under applicable law, contract and policy. The investigator preserves victim referrals, payment identifiers, onward movement and authentication evidence. The reporting officer determines the local reporting threshold and timing. Each decision remains visible even when staff coordinate through one incident channel.

The account holder may be a knowing participant, a recruited money mule, a deceived customer or someone whose account has been compromised. The investigation should test those alternatives through available evidence. Device records, account-access history, beneficiary setup, customer communications and the pattern of retained fees may inform the assessment. A valid login does not establish that the account holder understood the source of funds. A victim allegation establishes a reason for inquiry but does not by itself prove the receiving customer's intent.

The reporting-system outage should trigger the approved contingency process. Reporting operations identify the failure, preserve the prepared submission and check whether any attempt was accepted before the outage. The team uses current official contingency instructions and approved contacts for the relevant jurisdiction. It records the alternative channel, authorisation, transmission and confirmation. A personal email to an unverified address is not an acceptable substitute merely because the normal portal is unavailable. The decision record should show what the institution did to meet the applicable duty during disruption.

After the portal returns, reconciliation matters. The bank should determine whether the contingency filing needs a linked portal submission or another documented handling step. It should avoid duplicate reports without losing the original delivery evidence. Any later report must identify the relationship to the contingency communication where the channel permits. The case remains open operationally until the bank has resolved the submission state and any material outstanding facts. Marking it “submitted” because a file was generated would conceal the actual uncertainty.

The exercise asks the learner to draw four parallel tracks: fraud recovery, customer/account action, AML assessment and FIU delivery. Place the same transaction identifiers on each track, then identify the separate decisions, owners and legal bases. Explain which actions can proceed before the reporting portal recovers and which need a verified external channel. The result should show coordinated urgency without collapsing a scam allegation, suspicion assessment, account restriction and accepted report into one status.

Laboratory: reconstruct the report from a reviewer’s evidence packet

Give the learner a fictional packet containing an account-opening record, a customer-profile update, a payment schedule, two invoices, one customer email, a fraud referral and a draft narrative. The draft states that all incoming payments were from victims and all funds were sent abroad. The schedule shows that only one payer supplied a fraud complaint, two payments were returned and several transfers remained domestic. The customer-profile update occurred after the reviewed activity. The laboratory asks the learner to identify every assertion that exceeds the evidence.

The learner should create an assertion register with the statement, source, relevant date, confidence and proposed treatment. Verified facts can remain. Unsupported certainty should become a qualified inference or be removed. Material contrary evidence should be incorporated into the assessment. A returned payment should not be counted as proceeds retained by the customer unless another basis supports that interpretation. A later profile update should not be represented as information available to the original decision maker. The final narrative must remain readable while reflecting those corrections.

Next, the learner reconciles amounts. They calculate completed incoming and outgoing activity for the stated review period, identify duplicate rows and distinguish economic payments from system messages. They preserve original currencies and explain any conversion used for analytical totals. The objective is not to produce the largest suspicious-activity amount. It is to produce an amount and chronology that another authorised reviewer can reproduce. If an amount remains uncertain, the narrative states the limitation and the available evidence rather than hiding it inside a rounded estimate.

Finally, the learner produces a short filing recommendation and a separate customer-action recommendation. The reporting recommendation applies the relevant fictional jurisdiction's supplied threshold and explains the material facts. The customer recommendation identifies its own lawful basis, urgency and review owner. The assessment is marked wrong if it treats the report as a freezing order or treats the customer action as proof that a report was accepted. This laboratory tests analytical discipline, evidence reconciliation and decision separation rather than memorisation of one reporting phrase.

Delivery controls for reporting systems

Keep investigation status, filing decision, submission status and acknowledgement status distinct. Preserve the version filed and link later supplements or corrections to it. Technology should make rejection handling visible and prevent a case being marked fully submitted merely because the outbound job ran.

Reporting officers define local field and timing requirements; investigators own the factual narrative; operations monitor delivery; security and legal validate confidentiality controls. Use fictional reports to test invalid identifiers, oversized attachments, outages, duplicate retries and rejected submissions.

The final record should let an authorised reviewer reproduce why suspicion arose, who decided, what was submitted and whether delivery succeeded. Intelligence quality depends on clear analysis and reliable transmission, not the number of reports alone.

Laboratory: test confidentiality beyond the case screen

A fictional reporting application restricts the SAR tab to authorised investigators. Its designers therefore conclude that reporting confidentiality is complete. The laboratory follows the same case through search results, document previews, export files, notification emails, support tickets, analytics tables, customer-service notes and audit logs. The learner identifies where protected content or information revealing a report's existence could become available to people without a permitted purpose. A strong screen-level permission does not protect an unrestricted attachment in a downstream system.

The test plan uses synthetic reports and agreed accounts. It includes a user who can view ordinary transaction details but not reporting records, a support user who can troubleshoot delivery errors, a manager who needs aggregate reporting metrics and a customer-service colleague handling a fraud call. For each role, the learner states the task, permitted information and expected denial. The plan distinguishes access to underlying facts from access to the report itself, and it considers the applicable jurisdiction instead of applying one country's communication rule to all entities.

Exports need particular attention. A case export may combine narrative, attachments, identifiers and filing status into a single file. A reporting metric may expose a customer name and filing date when only an aggregate is required. A technical error may include the full payload in a log accessible to broad engineering teams. The test should verify minimisation, access controls and approved troubleshooting procedures. It should also establish how the bank detects and responds to an accidental disclosure, including preservation of evidence and legal escalation.

The learner closes the laboratory with a role-to-information map and a record of tested pathways. Passing the test requires more than screenshots of disabled buttons. It requires evidence that protected data cannot be obtained through the tested alternative routes and that legitimate operational tasks remain possible. The answer should also identify routes not examined and any residual uncertainty. That honest boundary is preferable to a claim that confidentiality is assured because one application view appears restricted.

Laboratory: measure narrative quality without rewarding over-reporting

A fictional quality committee compares two teams. Team A files a high proportion of investigated cases and produces long narratives. Team B files fewer cases and writes shorter reports. Neither fact establishes which team makes better decisions. The laboratory provides a balanced sample of filed and non-filed cases, their relevant evidence and the local decision standard. Learners must assess the reasoning, factual accuracy, clarity, delivery and treatment of contradictory information before comparing aggregate outcomes.

The review criteria should distinguish decision quality from writing quality. A report can be well written but based on a weak identity match. A filing decision can be justified but communicated through an unreadable transaction dump. A non-filing decision can be sound when a legitimate explanation is corroborated, or weak when an analyst closes a case to meet a production target. The committee therefore uses several dimensions and records the specific defect rather than assigning a single unexplained quality score.

Sampling should reflect risk and variation. Include different products, customer types, investigators, channels and outcomes, with additional attention to material defects and possible missed risk. A sample containing only accepted reports cannot test whether the bank should have filed in cases it closed. A sample selected by team managers may exclude difficult examples. The laboratory asks learners to explain the sampling purpose, exclusions and limits before interpreting percentages. Small samples and incomplete external feedback should not be presented as precise measures of criminal detection effectiveness.

The output is a targeted improvement plan. If narrative chronology is weak, coaching and templates may help. If identities are unreliable, source verification and matching controls are needed. If reports are rejected, form validation or delivery ownership may be the issue. If investigators routinely miss contradictory evidence, supervision and quality challenge may require change. The plan should connect each action to the observed defect and define how a later sample will test improvement. Increasing filing volume alone is not an adequate closure criterion.

Laboratory: turn a typology bulletin into a controlled change

A fictional FIU bulletin describes criminals using newly formed companies to collect scam proceeds before rapidly converting them into other assets. The bank already has a generic high-velocity rule. A product owner proposes lowering its threshold for every new business account. The laboratory asks learners to test whether that change addresses the described mechanism, what legitimate activity it may capture and which data is necessary to identify the pattern more accurately.

The first task is to formulate a risk hypothesis. Relevant features may include unrelated payer patterns, beneficiary novelty, unexplained account purpose, rapid movement and evidence linking payments to scams. Company age alone is a weak discriminator because legitimate businesses also start trading and move funds quickly. The learner identifies source systems, missing fields, linkage quality and the period needed for comparison. They also identify products where the bank's visibility is insufficient and where another control or manual review may be more appropriate.

The proposed change should be tested against known examples and legitimate comparison populations, with limitations made explicit. Historical labels are incomplete: a past SAR is not perfect proof of criminality, and a closed case is not proof that no risk existed. The learner therefore evaluates alert usefulness, investigation evidence, false-positive burden, missed-pattern risk and operational capacity. They explain how a rule can improve prioritisation while leaving the local reporting assessment to trained decision makers.

The final change record includes the bulletin, hypothesis, affected population, data assessment, testing results, approval, version and monitoring plan. It also records a decision not to implement a suggested feature when evidence is insufficient or the customer burden is disproportionate. After launch, the bank examines whether investigators can explain the new alerts and whether the expected pattern is actually visible. The bulletin becomes a source for a controlled learning process, not a substitute for accountable requirements and evidence.

Reporting concepts that delivery teams must keep distinct

Review period. This is the period the bank examined, which may differ from the period of activity included in a report. The distinction matters when an investigation reviews several years but identifies material transactions in a shorter interval. State both where relevant so the FIU does not infer that unlisted periods were examined and found unproblematic.

Activity date. This identifies when the relevant conduct or transaction occurred. It should not be replaced by the alert date or the investigation date. Several systems may record different event times, so the report should identify the meaning of the chosen date and explain material timing differences.

Detection or assessment date. This concerns the institution's recognition and analysis of information. The applicable law determines which event starts any reporting deadline. Delivery teams should implement the approved interpretation and preserve its rationale rather than assume that every automated alert immediately starts the same statutory clock.

Report decision. This is the authorised assessment to file or not file under the relevant framework. It is distinct from whether a customer is restricted, a fraud complaint is substantiated or a report reaches the FIU. Record the decision maker, evidence version, reasoning and any subsequent reassessment.

Submitted version. This is the actual payload and attachments transmitted, including the schema and identifiers used. It is not necessarily identical to the investigator's current working draft. Preserving it lets the bank reproduce what the FIU received and explain later corrections without silently changing history.

Acceptance evidence. This is the channel-specific proof that a report reached the required accepted state. A local application status or successful job run may not establish it. The bank should retain acknowledgements, rejection details and reconciled attempts according to its approved reporting and recordkeeping procedures.

Supplementary intelligence. This is additional information supplied after an earlier report, through the relevant permitted process. It should identify what is new, how it relates to the original activity and whether it changes the assessment. It should not disguise a correction as an unrelated report merely to avoid acknowledging an earlier error.

Protected reporting information. This includes the report and information revealing its existence where the applicable law protects them. It is not always identical to every underlying transaction fact. Access and communication decisions should follow the relevant legal distinctions, especially when fraud support and customer contact are also necessary.

Operational feedback. This addresses a particular case, report or delivery issue and may carry restricted handling conditions. It requires an accountable response and preservation of the relevant communication. General distribution is inappropriate unless its content and conditions permit that use.

Strategic feedback. This describes broader methods, risks or patterns. It may inform policy, scenarios, training and product controls, but it does not establish that a particular customer is suspicious. Delivery teams should translate it into testable hypotheses and proportional changes instead of automatic adverse actions.

A management conversation about intelligence usefulness

The head of investigations should be able to explain the reporting programme in terms that management can act on. Useful questions include whether reports describe material concerns clearly, whether the institution files within applicable rules, whether delivery failures are visible and whether investigations test contradictory evidence. A committee can review those questions through risk-sensitive samples, defect trends and operational reconciliation. It should not demand a fixed filing percentage that pressures analysts toward unsupported reports or convenient closures.

Capacity discussion should consider complexity and skill. A team processing simple single-account cases may have different needs from one analysing correspondent chains, trade transactions or multi-party scam networks. Report preparation, quality review, translation, attachments and correction handling also take time. Forecasting only the number of alerts can underestimate workload. Management should identify where delay creates legal or intelligence risk and choose appropriate staffing, specialist support or process changes without reducing the evidence standard to meet a closure target.

Feedback can reveal an organisational problem. Repeated missing-party identifiers may arise because the onboarding system cannot represent an authorised user separately from an owner. Repeated chronology errors may reflect inconsistent time-zone displays. Repeated rejection of attachments may indicate an unstable transformation service. The reporting team should provide those findings to the relevant data and technology owners with enough detail for remediation. The committee's role is to ensure that the underlying defect is addressed rather than repeatedly correcting each individual report.

The final management test is reproducibility with clear limits. Select a report and ask an authorised independent reviewer to explain the concern, identify the evidence, reconstruct the decision, locate the submitted version and confirm delivery. Then select a non-filed case and ask why the local threshold was not met. If both assessments can be reproduced and material uncertainties are visible, the bank has stronger evidence of a functioning reporting capability than a dashboard showing large volumes and green completion rates.

References and further reading

Reviewed 2 October 2026. FATF provides international standards; applicable national law determines binding duties. The operating examples are fictional teaching cases.

• FATF Recommendations, updated June 2026 — relevant anchors: 20, 21, 29 and 34.
• FinCEN joint statement on customer communications, 2 September 2026