Investigations, reporting, and confidentiality
Build a defensible case without confusing suspicion with proof.
Build one case. Keep decisions separate.
Enlarge to read every label and explore the connections
A defensible investigation separates facts, statements, and inference. Reporting and account actions require their own reasoned decisions.
Keep evidence classes distinct.
Use the case record to explain the reasoning.
Separate reporting access from routine account actions.
A case narrative should read like a clear account of events, not a pile of copied alerts. The reader needs to know what happened, why it matters, what evidence supports it, and what the institution decided.
Build the case from facts
- FactsCollect referenced observations
- AnalysisTest explanations and inconsistencies
- ConclusionState the supported disposition
Start with the triggering activity, relevant customer context, transaction timeline, and source records. Separate observed facts from customer statements and analyst inferences. Record alternative explanations and the evidence used to accept or reject them.
A defensible case can conclude that the activity is explained, remains uncertain, or warrants further action. It does not need dramatic language. Avoid unsupported statements about criminal intent. Preserve the actual references and amounts so another authorized reviewer can reproduce the analysis. Good writing is an operational control because it reduces ambiguity at handoff.
A case narrative should let another trained person distinguish observations from conclusions. “Five payments arrived within ten minutes” is an observation supported by records. “The payments are coordinated” is an inference that needs further evidence. “The account was used for crime” is a stronger conclusion that may exceed the available facts. Precise language improves both the investigation and the quality of downstream decisions.
Build a timeline from retained source records and note gaps explicitly. A case can explain that a counterparty’s identity is unresolved without filling the gap with an assumption. Include facts that weaken the initial suspicion as well as facts that support it. The objective is a defensible assessment of activity, not a persuasive story assembled from only one side of the evidence.
Inside the mechanism. Build a chronology that separates source facts, customer explanations, analyst inferences, and unresolved gaps. Each material claim should point to evidence that another authorized reviewer can inspect. Preserve contradictory facts rather than selecting only those that support the initial alert. The case should explain the relevant activity and decision, not merely paste a long transaction list.
A concrete example. An investigator assembles a timeline from retained source records. Observations, alternative explanations, and conclusions must remain distinguishable. The case identifies 1,288 eligible records from a source population of 1,480. The required workflow completes for 1,249, but 19 completed records miss the illustrative internal target. Another 39 remain incomplete. Communication evidence covers 1,237 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.
When the assumption fails. The narrative states criminal intent where the evidence supports only an unusual pattern. Use precise factual language, cite records, and retain evidence that weakens as well as supports the concern. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
An investigator assembles a timeline from retained source records. Observations, alternative explanations, and conclusions must remain distinguishable.
- Observation
- What a record directly shows
- Inference
- Interpretation drawn from several facts
Case note structure
Illustrative data; not a real customer record or a prescribed policy.
- Observedthree linked transfers
Direct transaction evidence
- Claimcustomer supplier payments
Customer explanation
- Inferencepurpose unresolved
Analyst conclusion with limits
The reader must know their evidentiary status
Label facts claims and inferences. The reader must know their evidentiary status.
- Failure mode 1avoid
- Use accusations without support. That exceeds the available facts.
- Failure mode 2avoid
- Copy alerts without analysis. The case still lacks reasoning.
- Failure mode 3avoid
- Omit alternative explanations. The conclusion becomes harder to assess.
Manage legal clocks explicitly
- TriggerIdentify the rule-relevant event
- CalculateApply the approved clock conditions
- EscalateMake deadlines and ownership visible
Reporting and investigation deadlines depend on the institution, report type, facts, and applicable rule. Distinguish activity date, alert date, discovery or detection events relevant to the rule, decision date, and filing date. An internal queue target does not replace a legal clock.
Implement deadlines through an approved requirements map with source and version. Calculate them using the relevant day convention and conditions. Escalate overdue work without silently changing the start event. This textbook does not supply one universal SAR deadline because the scope and triggering facts must be established for the actual institution.
Operational deadlines and legal deadlines need separate meanings. A team may set an internal target earlier than a legally relevant date to allow review and correction. Store the event that starts each clock, the applicable basis, the owner, and any approved adjustment. A generic age counter cannot represent every obligation. Queue design should make approaching deadlines visible while preserving a reliable record of when information became available and when decisions were made.
Inside the mechanism. A legal clock needs an applicable obligation, a triggering event, a calculation rule, a due date, and evidence of completion. Internal service targets are separate. Do not let a reopened case or assignment change silently reset the original trigger. Calendar handling, exceptions, and escalation need the relevant rule interpretation. A generic queue age cannot substitute for the institution’s actual reporting-deadline logic.
A concrete example. Different duties and internal targets can begin from different facts. One generic case-age field cannot encode all of those starts and deadlines. The case identifies 902 eligible records from a source population of 960. The required workflow completes for 875, but 13 completed records miss the illustrative internal target. Another 27 remain incomplete. Communication evidence covers 866 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.
When the assumption fails. Routing delay silently replaces the institution’s original receipt or detection timestamp. Store each trigger, basis, owner, and actual event time under the applicable process. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
Different duties and internal targets can begin from different facts. One generic case-age field cannot encode all of those starts and deadlines.
- Internal service target
- Operational handling objective
- Legal deadline
- Requirement under the applicable rule
Clock record
Illustrative data; not a real customer record or a prescribed policy.
- Activity daterecorded
Underlying event
- Rule triggerseparately established
Not assumed from queue creation
- Ownerreporting officer
Accountable deadline decision
The start event matters as much as the duration
Version the trigger and deadline logic. The start event matters as much as the duration.
- Failure mode 1avoid
- Use alert creation for every legal clock. The applicable trigger may differ.
- Failure mode 2avoid
- Reset the clock when reassigned. Queue movement does not rewrite the rule.
- Failure mode 3avoid
- Treat an internal target as law. The sources and consequences differ.
Separate the reporting decision
- InvestigateDevelop the supported case
- DecideApply the relevant reporting criteria
- ConfirmRecord submission and receipt evidence
A suspicious activity report is not a criminal conviction. The institution applies the relevant reporting criteria using its investigation and procedures. A decision not to file also needs a documented basis where required by the program.
Keep reporting disposition distinct from account restriction, customer refund, and relationship exit. One action does not automatically dictate the others. The authorized decision maker should review the evidence and unresolved issues. Preserve approvals and the version of the narrative submitted. A draft saved in a case tool is not evidence that a filing was received.
Inside the mechanism. An alert, investigation, reporting decision, filing, and account action are distinct states with different authority. The reporting conclusion should follow the applicable facts and standard, not an automatic conversion from an alert score. Preserve the decision and its supporting rationale even when no report is filed. Account restrictions or closure may require separate consideration and should not be inferred solely from the report state.
A concrete example. An alert, escalation, customer exit, and reporting decision are distinct actions. A case conclusion should identify which action was actually considered and authorized. The case identifies 648 eligible records from a source population of 820. The required workflow completes for 629, but 9 completed records miss the illustrative internal target. Another 19 remain incomplete. Communication evidence covers 623 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.
When the assumption fails. A scenario hit automatically becomes a reportable conclusion. Apply the institution-specific review, rationale, approval, and reporting requirements. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
An alert, escalation, customer exit, and reporting decision are distinct actions. A case conclusion should identify which action was actually considered and authorized.
- Draft report
- Prepared content awaiting the process
- Filed report
- Submission has the required receipt evidence
Reporting lifecycle
Illustrative data; not a real customer record or a prescribed policy.
- Narrativedraft-v3
Prepared text
- Approvalcomplete
Internal authorization
- Receiptpending
Filing completion unproven
Approval and filing receipt are different states
Track reporting as its own lifecycle. Approval and filing receipt are different states.
- Failure mode 1avoid
- Call a draft filed. That overstates completion.
- Failure mode 2avoid
- Treat filing as proof of guilt. Reporting concerns suspicion under the rule.
- Failure mode 3avoid
- Automatically refund or close from filing alone. Those actions require their own basis.
Protect confidential reporting information
- RestrictSeparate protected reporting records
- ReviewControl searches exports and messages
- AuditMonitor access and permitted disclosure
SARs and information that would reveal their existence are subject to strict confidentiality rules, with specific permitted disclosures. Do not expose a SAR flag to general customer support, ordinary exports, or customer-facing explanations. Underlying facts can have a different sharing analysis, but that does not make every disclosure permissible.
Implement separate permissions, audit access, and review exports. Use customer wording approved for the situation without revealing protected reporting information. Test search, notifications, analytics, and backups for accidental disclosure. Confidentiality is a system property; a policy cannot protect a field copied into every event stream.
The September 2, 2026 joint agency statement clarifies that SAR confidentiality does not prevent banks from discussing potentially fraudulent transactions, other suspicious activity, or account closures with customers. Protecting the report does not require silence about every underlying customer problem.
Inside the mechanism. Protect information whose disclosure would reveal confidential reporting while preserving permitted operational communication. Access controls should distinguish source transaction facts from protected reporting material and record the purpose of access. Customer communication needs approved boundaries tied to the actual facts. The existence of a reporting workflow should not cause staff to treat every ordinary factual customer conversation as categorically prohibited.
A concrete example. Customer communication can explain appropriate account or fraud facts without disclosing protected reporting information. The access model needs to separate those materials. The case identifies 1,281 eligible records from a source population of 2,100. The required workflow completes for 1,243, but 19 completed records miss the illustrative internal target. Another 38 remain incomplete. Communication evidence covers 1,231 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.
When the assumption fails. A support export includes confidential reporting status and internal filing discussion. Separate factual customer communications from protected reporting records and restrict access by role. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
Customer communication can explain appropriate account or fraud facts without disclosing protected reporting information. The access model needs to separate those materials.
- Underlying transaction facts
- May have a separate lawful sharing basis
- SAR existence
- Protected information with specific disclosure limits
Access design
Illustrative data; not a real customer record or a prescribed policy.
- General supporttransaction status
Limited operational view
- Reporting teamrestricted case
Authorized purpose
- Customer messageno SAR flag
Approved wording only
Copies and search indexes can leak the same fact
Restrict reporting status across all data paths. Copies and search indexes can leak the same fact.
- Failure mode 1avoid
- Show SAR status in support badges. That broadens access to protected information.
- Failure mode 2avoid
- Assume internal sharing is always unrestricted. Permissions and legal limits still matter.
- Failure mode 3avoid
- Put filing reasons in customer email. That can reveal protected information.
Use quality review and feedback
- SampleInclude different outcomes and reviewers
- DiagnoseFind recurring quality defects
- RepairUpdate controls and verify later cases
Quality review should assess evidence, reasoning, completeness, deadlines, and confidentiality. Sample across reviewers and dispositions. Reviewing only filed cases misses weak closures and missed escalation.
Feed recurring issues back into training, data collection, and monitoring design. A missing counterparty identifier may be an onboarding defect, not an analyst problem. Track rework and root causes separately from raw case speed. The program improves when findings change the process and the change is verified on later work.
Inside the mechanism. Quality review should assess factual support, completeness, clarity, timing, and the appropriateness of the decision within the applicable framework. A returned case needs a specific correction reason and an owner. Aggregate recurring defects into upstream changes, such as better event data or clearer case guidance. Do not use filing volume alone as a measure of investigation quality or program effectiveness.
A concrete example. A quality review can identify weak evidence, missed timing, inconsistent reasoning, and data defects. The feedback should improve the upstream process as well as the individual case. The daily source population is 3,700 items, but 74 are outside the completed monitoring run. The included population creates 399 hits and 327 unique cases. With 60 cases already open and capacity for 330, the queue closes at 57. Coverage, duplicate work, and staffing are separate causes; reducing one number does not prove that the overall control improved.
When the assumption fails. Only case closure volume is measured, so rushed weak decisions appear efficient. Track defect types and corrective actions while preserving a representative review population. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
A quality review can identify weak evidence, missed timing, inconsistent reasoning, and data defects. The feedback should improve the upstream process as well as the individual case.
- Case throughput
- How many cases were processed
- Case quality
- Whether the work supports its conclusions
Quality finding
Illustrative data; not a real customer record or a prescribed policy.
- Defectmissing counterparty evidence
Repeated across cases
- Causesource field not collected
Upstream issue
- Fixrepair data capture
More training alone is insufficient
The defect may begin before the analyst sees it
Link quality findings to their root cause. The defect may begin before the analyst sees it.
- Failure mode 1avoid
- Measure only cases per hour. Speed can hide incomplete work.
- Failure mode 2avoid
- Review only filings. Weak non-filing decisions remain unseen.
- Failure mode 3avoid
- Close findings after training attendance. Effectiveness requires later evidence.
Chapter connections
This chapter builds on Transaction monitoring and alert quality. Use the glossary for terminology and risk mathematics for formulas and worked calculations.