The SAR narrative is the most labor-intensive part of the filing process and, from an examiner's standpoint, the most telling indicator of program quality. A technically accurate SAR with a thin, vague narrative is a weaker piece of evidence than one that tells a coherent, specific story. Automated narrative drafting changes the economics of SAR production — but only if the automation output maps cleanly to the five structural elements FinCEN evaluates. Getting this right matters because a poorly structured narrative that an analyst sends through without review creates a different kind of problem than the one the automation was meant to solve.
The Five Structural Elements FinCEN Evaluates
FinCEN's SAR filing guidance and the FFIEC BSA/AML Examination Manual both describe what a complete SAR narrative must cover. The shorthand is the "5 Ws":
- Who — identity of the subject(s): name, date of birth, account number, address, SSN/EIN where available, occupation, and any business entity relationships
- What — a specific description of the suspicious activity: transaction types, dollar amounts, dates, and account numbers involved
- When — the timeframe of the suspicious activity, including first observed date and the date of most recent suspicious transaction
- Where — where the transactions occurred (financial institution, branch, access channel — particularly relevant for multi-channel institutions) and the geographic flow of funds
- Why — why the activity is considered suspicious: the specific facts that triggered suspicion, including how the activity deviates from expected behavior, any known account purpose, and any customer explanations provided during the investigation
Of the five, "why" is consistently the weakest element in SAR narratives that examiners flag. A narrative that describes what happened in detail — amounts, dates, account numbers — but does not articulate why the described activity is suspicious reads to an examiner as incomplete case development.
What Automation Can Do and What It Can't
Automated narrative drafting works from structured case data: the alert that triggered the investigation, the transaction records pulled into the case, account profile information, prior SAR history if applicable, and any investigative notes the analyst added during case review. From those inputs, a well-designed system can produce a first-draft narrative that populates the who, what, when, and where elements with accuracy and completeness.
Where automation runs into limits is the "why" element. The system can note that the transaction activity deviated from the account's established baseline and state the specific deviation — for example, "the account, which had averaged $1,200 in monthly outflows over the prior six months, sent $14,800 in six separate transfers over a 72-hour period." That is a mechanically accurate statement. But the full articulation of why that pattern is suspicious in the context of this customer's profile, account purpose, and risk tier requires the analyst's judgment about the case.
We're not saying automation can't contribute to the "why" element. It can surface relevant signals — prior SAR history, EDD flags, adverse media hits, counterparty risk assessments — that an analyst should incorporate. What it can't do is replace the analyst's synthesis of those signals into a narrative that constitutes a defensible explanation of suspicious activity. That synthesis is what separates a SAR narrative from a transaction log.
The Quality Problem Automation Introduces
The risk of automated narrative drafting is not that the automation produces bad narratives. The risk is that analysts stop reading what the automation produces before filing. A digitally-native team working through a 200-alert queue at end of quarter, with a draft narrative auto-populated for each case, faces a powerful incentive to review the case at speed and hit file without deeply engaging with the narrative content.
When that happens, the automation has not improved SAR quality — it has created a new failure mode where the analyst's review step has been effectively eliminated. The examiner reviewing the filed SAR will see a narrative that is structurally complete but may not accurately reflect the case facts, may not include the investigative findings the analyst actually documented in the case notes, and may not address unusual elements of the specific case that a generic template missed.
Building a QA checkpoint into the filing workflow is not optional infrastructure. Specifically: a requirement that the analyst review the drafted narrative against the case notes and document that they've done so, and a supervisor review step for any SAR above a defined dollar threshold or involving certain typologies. The automation produces the draft; the analyst owns the final content.
What Examiners Actually Check in a Narrative Review
During a BSA examination, examiners will typically pull a sample of filed SARs and evaluate narrative quality against specific criteria. In our experience reviewing programs that have been through examinations, the checks that generate the most findings are:
- Specificity of amounts and dates: Narratives that say "multiple large transactions" rather than citing specific dollar amounts and dates are flagged as inadequate. The narrative should be specific enough that law enforcement could use it to identify the activity without pulling additional records.
- Explanation of deviation: The narrative must explain how the described activity differs from the customer's expected transaction behavior or account purpose. "Account opened for payroll transactions" + description of outflows to unrelated parties is a meaningful deviation worth stating explicitly. A narrative that lists the transactions without noting the deviation misses the point.
- Prior SAR history: If this is a continuing-activity SAR, the narrative must reference the prior filing date and SAR reference number and describe what has changed or continued since the prior filing.
- Subject contact notes: If the customer was contacted during the investigation — a phone inquiry, a document request — the outcome of that contact should be reflected in the narrative. "Customer provided the following explanation, which did not resolve the suspicion" is informative. Silence on the contact history leaves a gap.
Building a Defensible Automation Program
A SAR narrative automation program that passes examination has three design requirements. First, the automation output must be structured to address all five narrative elements — not just the transaction data elements. System design that auto-populates who, what, when, and where from case data, and flags the "why" section as analyst-required rather than auto-filling it with generic language, is more defensible than a system that fills all five sections with templates.
Second, the workflow must require analyst attestation before filing — a documented step where the analyst confirms they have reviewed the narrative, verified accuracy against the case record, and are responsible for the content. That attestation creates the audit trail that examiners expect.
Third, a periodic QA review process should sample filed SAR narratives and evaluate them against the FinCEN five-element standard on a defined schedule. The QA output should feed back into system improvement and analyst training. Without that feedback loop, narrative quality tends to drift over time as analysts habituate to the automation output and stop engaging with it critically.
Automation changes who writes the first draft, not who is accountable for the filed SAR. The analyst who attests to the narrative owns it — and so does your program.
