Investigations, reporting, and confidentiality

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.

Build the case from facts — the flow

1. 01FactsCollect referenced observations
2. 02AnalysisTest explanations and inconsistencies
3. 03ConclusionState the supported disposition

Build the case from facts — the distinction

Observation

• What a record directly shows

Inference

• Interpretation drawn from several facts

Case note structure

Fictional educational excerpt / Not for execution

Case note structure

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Observedthree linked transfers

   Direct transaction evidence

2. 2

   Claimcustomer supplier payments

   Customer explanation

3. 3

   Inferencepurpose unresolved

   Analyst conclusion with limits

The reader must know their evidentiary status

Build the case from facts — control and failure modes

Control design

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.

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.

Manage legal clocks explicitly — the flow

1. 01TriggerIdentify the rule-relevant event
2. 02CalculateApply the approved clock conditions
3. 03EscalateMake deadlines and ownership visible

Manage legal clocks explicitly — the distinction

Internal service target

• Operational handling objective

Legal deadline

• Requirement under the applicable rule

Clock record

Fictional educational excerpt / Not for execution

Clock record

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Activity daterecorded

   Underlying event

2. 2

   Rule triggerseparately established

   Not assumed from queue creation

3. 3

   Ownerreporting officer

   Accountable deadline decision

The start event matters as much as the duration

Manage legal clocks explicitly — control and failure modes

Control design

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.

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.

Separate the reporting decision — the flow

1. 01InvestigateDevelop the supported case
2. 02DecideApply the relevant reporting criteria
3. 03ConfirmRecord submission and receipt evidence

Separate the reporting decision — the distinction

Draft report

• Prepared content awaiting the process

Filed report

• Submission has the required receipt evidence

Reporting lifecycle

Fictional educational excerpt / Not for execution

Reporting lifecycle

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Narrativedraft-v3

   Prepared text

2. 2

   Approvalcomplete

   Internal authorization

3. 3

   Receiptpending

   Filing completion unproven

Approval and filing receipt are different states

Separate the reporting decision — control and failure modes

Control design

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.

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.

Protect confidential reporting information — the flow

1. 01RestrictSeparate protected reporting records
2. 02ReviewControl searches exports and messages
3. 03AuditMonitor access and permitted disclosure

Protect confidential reporting information — the distinction

Underlying transaction facts

• May have a separate lawful sharing basis

SAR existence

• Protected information with specific disclosure limits

Access design

Fictional educational excerpt / Not for execution

Access design

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   General supporttransaction status

   Limited operational view

2. 2

   Reporting teamrestricted case

   Authorized purpose

3. 3

   Customer messageno SAR flag

   Approved wording only

Copies and search indexes can leak the same fact

Protect confidential reporting information — control and failure modes

Control design

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.

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.

Use quality review and feedback — the flow

1. 01SampleInclude different outcomes and reviewers
2. 02DiagnoseFind recurring quality defects
3. 03RepairUpdate controls and verify later cases

Use quality review and feedback — the distinction

Case throughput

• How many cases were processed

Case quality

• Whether the work supports its conclusions

Quality finding

Fictional educational excerpt / Not for execution

Quality finding

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Defectmissing counterparty evidence

   Repeated across cases

2. 2

   Causesource field not collected

   Upstream issue

3. 3

   Fixrepair data capture

   More training alone is insufficient

The defect may begin before the analyst sees it

Use quality review and feedback — control and failure modes

Control design

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.

This chapter builds on Transaction monitoring and alert quality. Use the glossary for terminology and risk mathematics for formulas and worked calculations.