Str Report

STR Report

When to Use

• Draft or restructure a suspicious transaction report (STR) or suspicious activity report (SAR) narrative for AML compliance filing or internal MLRO review
• Build the who / what / when / where / why suspicion story with clear chronology and aggregated transaction facts
• Map red flags and typologies (structuring, layering, trade-based ML, etc.) to observable facts—not conclusions without evidence
• Compile subject and customer identification fields, related parties, accounts, and product/channel context for filing templates
• Produce a supporting documentation checklist and exhibit index aligned to the narrative
• Run quality review (completeness, consistency, tone, PII handling) before submission to MLRO or regulator-facing systems
• Compare jurisdiction-agnostic structure with high-level US (FinCEN SAR), EU, and goAML field concepts (not legal filing advice)
• Distinguish STR/SAR from internal case notes, management summaries, or law enforcement referral packages
• Escalate and hand off to MLRO/compliance with a structured fact pack and open questions

When NOT to Use

• Design transaction monitoring rules, thresholds, alert tuning, or TM scenario libraries → aml-compliance
• Build a full AML/CFT program, KYC/CDD policy, or enterprise risk assessment → aml-compliance, aml-cft
• Determine legal obligation to file, statute of limitations, or regulator-specific filing deadlines as counsel → commercial-counsel
• Conduct internal or IT audit workpapers, SOC 2 testing, or control effectiveness sampling → auditor
• Implement technical controls, evidence automation, or screening system engineering → compliance-engineer
• Perform on-chain investigation, wallet tracing, or blockchain intelligence reports → on-chain-investigator-agent, solana-tracing-specialist, blockint skills
• Draft law enforcement tactical packages, subpoena responses, or victim tracing narratives → route to investigation skills; keep STR factual and filing-oriented
• CFT/TF-only typologies without broader STR narrative needs → aml-cft (then return here for unified STR assembly)

Related skills

Core Workflows

1. Intake and scope

1. Confirm jurisdiction, entity, filing type (STR vs SAR vs internal referral), and case ID 2. Collect alert source, investigation notes, and already-reviewed transactions (do not re-investigate beyond narrative needs) 3. Identify subjects (customer, beneficial owners, counterparties, unknown parties) and reporting institution role 4. Flag gaps requiring analyst follow-up before MLRO sign-off

See `references/str_report_scope.md`.

2. Facts, aggregation, and chronology

1. Normalize amounts, currencies, dates (UTC vs local—state assumption) 2. Aggregate related transactions (account, counterparty, corridor, instrument) 3. Build a chronological timeline with anchors (onboarding, profile change, alert, key txs) 4. Separate verified facts from inference; label each suspicion element

See `references/subject_and_transaction_detail.md`.

3. Narrative and typologies

1. Open with summary suspicion in plain language (one short paragraph) 2. Develop who / what / when / where / why sections with cross-references to exhibits 3. Tie red flags to typologies and observable indicators—avoid legal conclusions 4. Address innocent explanations considered and why rejected or unresolved

See `references/narrative_structure_and_quality.md` and `references/red_flags_and_typologies.md`.

4. Format, review, and handoff

1. Map narrative blocks to jurisdiction template fields at a high level (FinCEN SAR, goAML, etc.) 2. Complete supporting documentation checklist and quality gates 3. Run MLRO/compliance escalation pack: decision requested, risks, open items 4. Record version, reviewers, and not legal advice disclaimer where appropriate

See `references/jurisdiction_formats_and_filing.md` and `references/review_escalation_and_handoff.md`.

Output Standards

• Use past tense for facts, present tense for ongoing risk where helpful; avoid sensational language
• Every suspicion statement should cite specific transactions, dates, amounts, or documents
• Minimize PII in drafts shared broadly; full detail in MLRO/regulator packages per policy
• Include disclaimer: output supports compliance drafting—not legal advice on whether or when to file
• Deliver: executive summary, full narrative, chronology table, subject/account appendix, exhibit checklist, open questions

Reference Files

Jurisdiction formats and filing

Table of contents

1. Disclaimer 2. Jurisdiction-agnostic core 3. United States — FinCEN SAR 4. European Union — STR concepts 5. United Kingdom — SAR to NCA 6. goAML and FIU platforms 7. Continuing activity and amendments 8. Cross-border and group filing 9. Mapping narrative to form fields

Disclaimer

This reference provides high-level structural orientation only. Filing obligations, deadlines, thresholds, and legal interpretations are for MLRO and counsel—see `commercial-counsel` and local counsel. Do not treat this document as legal advice.

Jurisdiction-agnostic core

Most STR/SAR regimes expect:

Draft in modular sections so compliance can paste into national XML/PDF portals.

United States — FinCEN SAR

Form: FinCEN SAR (e-file via BSA E-Filing). Commonly called SAR, not STR.

US-specific reminders (non-exhaustive):

• Distinguish BSA AML SAR from other reports (e.g., fraud-only channels) per policy
• 314(b) information sharing is separate from SAR narrative—follow legal process
• Do not include Grand Jury or sealed LE material without counsel

European Union — STR concepts

EU framework (AMLD) generally requires reporting suspicious transactions to FIU without tipping off. Member states implement via national law.

Field names vary by member state portal—maintain master narrative plus country-specific field mapping table maintained by compliance.

United Kingdom — SAR to NCA

UK uses SAR to NCA (not FinCEN form). Consider:

Narrative should still follow who/what/when/where/why with UK terminology (e.g., sort code, account number).

goAML and FIU platforms

Many FIUs use goAML or compatible XML schemas.

Build structured data first (transactions), then attach narrative PDF if workflow requires both.

Continuing activity and amendments

Narrative must state relationship to prior report: “Institution filed SAR ID [internal ref] on [date] regarding [summary]; activity continued as follows…”

Cross-border and group filing

Group compliance often maintains filing matrix—reference it before finalizing narrative voice (“on behalf of [Entity X]”).

Mapping narrative to form fields

Use a two-column worksheet for MLRO:

Keeps e-filing accurate when narrative is drafted in Word/Markdown first.

Narrative structure and quality

Table of contents

1. Standard narrative arc 2. Who what when where why 3. Opening and closing paragraphs 4. Fact vs inference vs opinion 5. Tone and language 6. Common defects 7. Quality review checklist

Standard narrative arc

Use a pyramid + chronology hybrid:

1. Lead — one paragraph stating suspicion in plain language 2. Subject context — who the customer is, relationship, risk rating, KYC highlights 3. Chronological facts — what happened, in order 4. Suspicion synthesis — why the pattern is unusual vs expected profile 5. Actions taken — holds, EDD, account restrictions (factual) 6. Closing — ongoing monitoring, continuing activity flag, request for MLRO decision

Regulators often skim the first and last paragraphs first—make them precise.

Who what when where why

Who

• Legal name, aliases, customer type (individual, corporate, trust, VASP)
• Identifiers: national ID, tax ID, LEI, registration number (as available)
• Beneficial owners and control persons when relevant
• Related parties: joint account holders, authorized signers, nested counterparties
• Role of reporting institution (account holder, intermediary, correspondent)

What

• Products: accounts, wires, cards, crypto, trade finance, lending
• Instruments and channels: online, branch, ATM, API, DeFi interface (describe factually)
• Transaction types: deposits, withdrawals, internal transfers, FX, trade settlements
• Volumes: counts, totals, velocity—aggregated where helpful

When

• Anchor dates: account opening, profile changes, alert generation, key transactions
• State timezone assumption (UTC vs local)
• Note gaps in data (missing statements, delayed feed)

Where

• Countries of customer, counterparty, and transaction endpoints
• High-risk geography references only when tied to facts (not generic lists)
• IP or device geolocation only if verified and policy-allowed

Why (suspicious)

• Link each red flag to specific facts (see references/red_flags_and_typologies.md)
• Compare activity to stated purpose, KYC occupation/source of funds, and peer group
• Document benign hypotheses considered and why insufficient

Opening and closing paragraphs

Opening (example structure—not boilerplate to copy)

[Institution] reports suspicion regarding [subject], account(s) [IDs], for the period [dates]. Activity is inconsistent with the customer’s known profile because [2–3 fact-based reasons]. Total in-scope volume is [amount] across [n] transactions.

Closing (example structure)

Based on the above, [institution] requests MLRO review for [STR/SAR filing / internal escalation]. Continuing activity [is / is not] expected. Open items: [list].

Avoid legal conclusions (“money laundering occurred”) unless institution policy and counsel direct specific phrasing.

Fact vs inference vs opinion

Use footnotes or exhibit IDs for document-derived facts: “(Exhibit 4 — March statement).”

Tone and language

• Objective, professional, active voice where clarity helps
• Avoid jargon unless standard in your jurisdiction (define once)
• Do not include alert rule names unless policy requires—describe behavior
• Redact unnecessary PII in wide-distribution drafts
• No marketing language or customer praise/discount narratives unrelated to suspicion

Sensitive topics

• Tipping-off: do not inform customer of STR preparation in narrative drafts circulated broadly
• Sanctions/PEP: factual status only; disposition per policy
• Crypto: describe on-chain facts at summary level unless MLRO wants annex; deep traces → blockint skills

Common defects

Quality review checklist

Before MLRO submission, confirm:

• [ ] Lead paragraph states suspicion and scope
• [ ] All five W dimensions addressed
• [ ] Chronology matches source systems
• [ ] Amounts and currencies consistent throughout
• [ ] Red flags explicitly tied to facts
• [ ] Benign explanations addressed
• [ ] PII minimized per distribution policy
• [ ] Exhibits referenced and listed
• [ ] Prior STR/SAR noted if relevant
• [ ] Open questions listed for MLRO
• [ ] Disclaimer: draft for compliance—not legal filing advice

Red flags and typologies

Table of contents

1. How to use this reference 2. Mapping facts to suspicion 3. General red flags 4. Typology catalog 5. Sector-specific indicators 6. Crypto and virtual assets 7. Narrative phrasing examples 8. Anti-patterns

How to use this reference

Red flags are prompts for explanation, not automatic suspicion. For each flag used in an STR narrative:

1. Cite the observable fact (transaction, document, statement) 2. State why it is inconsistent with customer profile or policy 3. Note alternative explanations if investigated

For enterprise TM scenario design, route to `aml-compliance`. For TF/PF-specific angles, cross-check `aml-cft`.

Mapping facts to suspicion

Cumulative suspicion: multiple weak indicators may combine; document the pattern, not isolated trivia.

General red flags

Typology catalog

Structuring (smurfing)

• Pattern: multiple cash or electronic deposits/withdrawals sized to avoid internal or regulatory attention
• Facts to include: dates, amounts, branches/channels, cumulative totals, known thresholds only as context
• Avoid: asserting intent to evade reporting unless institution counsel approves phrasing

Layering

• Pattern: complex chains obscuring origin—multiple accounts, FX, intermediaries
• Facts: path of funds, account hops, timing, related parties

Integration

• Pattern: introducing illicit funds into legitimate economy—property, business revenue disguise
• Facts: purchases, invoices, commingling with payroll/revenue

Trade-based money laundering (TBML)

• Pattern: mispriced goods, phantom shipments, over/under invoicing
• Facts: trade documents, invoice values vs market, shipping anomalies

Correspondent / nested accounts

• Pattern: downstream banks or PSPs unable to identify underlying customers
• Facts: respondent relationship, wire messages, missing originator/beneficiary info

Identity fraud / shell entities

• Pattern: synthetic IDs, nominee directors, no physical presence
• Facts: KYC anomalies, registry checks, address verification results

Terrorist financing (TF)

• Pattern: small repeatable flows, charitable fronts, high-risk corridors
• Cross-reference: aml-cft for TF-specific narrative supplements

Proliferation financing (PF)

• Pattern: dual-use goods, sanctioned end-users, trade route anomalies
• Cross-reference: aml-cft

Sector-specific indicators

Crypto and virtual assets

Summarize on-chain analytics in STR narratives at institution-approved depth:

Deep tracing, attribution claims, or victim recovery → blockint skills, not STR drafting alone.

Narrative phrasing examples

Weak: “Customer is laundering money.”

Strong: “Between 2024-01-10 and 2024-01-20, account 456 received twelve incoming wires totaling USD 118,400 from nine unrelated individuals. This activity is inconsistent with the customer’s declared employment income (USD 42,000 annually) and prior 12-month average inflow of USD 1,200 per month.”

Weak: “Blockchain proves criminal wallet.”

Strong: “Blockchain analytics (Exhibit 7) show that deposit address [redacted] received funds from an entity categorized as [high-risk category] on [date]; the customer did not disclose crypto activity during onboarding.”

Anti-patterns

• Listing every alert rule fired without synthesis
• Using industry buzzwords without facts
• Importing unverified social media as fact
• Stating sanctions violations without official list match disposition
• Confusing fraud loss with ML suspicion without explaining ML nexus

Review escalation and handoff

Table of contents

1. Review stages 2. Analyst self-QA 3. Second-line MLRO review 4. Legal and tipping-off 5. MLRO handoff package 6. Escalation triggers 7. Post-filing actions 8. Distinguishing handoff types

Review stages

Document version, reviewer, and date on each circulation.

Analyst self-QA

Before escalating, confirm:

• [ ] Scope and date range stated in opening
• [ ] Subject identifiers match KYC system
• [ ] Transaction totals reconcile to source export
• [ ] Chronology ordered and timezone noted
• [ ] Each red flag tied to cited facts
• [ ] Benign explanations documented
• [ ] Exhibits numbered and referenced
• [ ] No customer notification / tipping-off language in external drafts
• [ ] Prior STR/SAR checked
• [ ] Spell-check and remove alert boilerplate

Second-line MLRO review

MLRO typically assesses:

MLRO may edit narrative tone, shorten, or request legal review—analyst provides clean track-changes version.

Legal and tipping-off

Engage `commercial-counsel` when:

• Filing vs no-file decision has legal ambiguity
• DAML / moratorium (UK) or similar freeze regimes
• Subpoena or LE request overlaps with STR
• Privilege concerns (audit, investigation by counsel)
• Cross-border sharing restrictions

Tipping-off: restrict distribution to need-to-know; watermark drafts “CONFIDENTIAL — AML INVESTIGATION”.

MLRO handoff package

Deliver a single package (folder or case system bundle):

1. Cover memo (1 page): case ID, recommendation (file / do not file / hold), deadline, risks 2. STR narrative (final draft) 3. Chronology & aggregation tables 4. Subject / account appendix 5. Exhibit index with files attached 6. Alert & investigation notes (fact extracts) 7. Prior filings copies if continuing 8. Open questions list 9. Filing form worksheet (field mapping)

Cover memo template (structure)

Escalation triggers

Escalate immediately to MLRO (and legal if policy requires) when:

• Sanctions true match or blocked transaction attempted
• TF/PF indicators (aml-cft supplement)
• Insider or employee involvement suspected
• Material customer (PEP, government, large commercial relationship)
• Media / regulatory inquiry linked to case
• Law enforcement already engaged
• Group-wide or multi-entity exposure
• Crypto high-risk exposure beyond institution appetite
• Data breach affecting investigation integrity

Post-filing actions

After MLRO files (operational—not narrative drafting):

Do not reference STR filing in customer-facing messages unless counsel approves specific script.

Distinguishing handoff types

Internal case notes may contain speculative content; strip before MLRO package unless explicitly included and approved.

For audit of AML process (not STR drafting), route to `auditor`. For TM governance, route to `aml-compliance`.

STR report scope

Table of contents

1. Purpose and boundaries 2. Definitions 3. STR vs SAR vs internal artifacts 4. Roles and responsibilities 5. Inputs and outputs 6. What this skill does not cover 7. Quality principles

Purpose and boundaries

This reference defines the operational scope of suspicious transaction / suspicious activity reporting narrative work. The goal is a regulator-ready or MLRO-ready fact narrative that explains why activity is suspicious—not to replace investigation, legal advice, or transaction monitoring engineering.

Always align drafts to the institution’s approved STR/SAR policy, retention schedule, and MLRO authority matrix.

Definitions

Use `fatf-glossary-reference` for authoritative FATF terms when precision matters.

STR vs SAR vs internal artifacts

Do not paste internal speculation, unverified OSINT, or privileged counsel advice into STR narratives without MLRO review.

When narratives diverge

• STR/SAR: stick to verified or reasonably believed facts; label gaps
• Internal: capture alternative explanations under investigation
• LE package: coordinate through legal/compliance; avoid duplicate contradictory stories

Roles and responsibilities

Escalate when: PEP/sanctions nexus, terrorist financing indicators, reputational crisis, cross-border complexity, or tipping-off risk in communications.

Inputs and outputs

Minimum inputs

• Case / alert ID and source system
• Customer master data (legal name, IDs, addresses, BO where known)
• Account and product list in scope
• Transaction export with timestamps, amounts, currencies, channels, counterparties
• Prior STR/SAR history (if any) and EDD/KYC summary
• Analyst investigation memo (facts only for narrative extraction)
• List of documents reviewed (statements, KYC files, contracts, blockchain analytics summary)

Standard outputs

1. Executive summary (3–6 sentences) 2. Full narrative (who / what / when / where / why) 3. Chronology table (date, event, amount, account, reference) 4. Subject and account appendix 5. Red-flag index linked to facts 6. Exhibit / documentation checklist 7. Open questions for MLRO

What this skill does not cover

Quality principles

1. Traceability — each suspicious assertion maps to a transaction, document, or verified statement 2. Neutrality — describe behavior; avoid labeling customers as criminals 3. Completeness — identifiers sufficient for FIU to act (within policy) 4. Concision — regulators read volume; avoid duplicate tables 5. Consistency — amounts and dates match across narrative, tables, and exhibits 6. Confidentiality — respect tipping-off and need-to-know distribution

Subject and transaction detail

Table of contents

1. Subject identification fields 2. Related parties and counterparties 3. Account and product appendix 4. Transaction selection rules 5. Aggregation methods 6. Chronology table template 7. Currency and rounding 8. Exhibits and data lineage

Subject identification fields

Capture fields required by local filing system—below is a jurisdiction-agnostic superset. Map to FinCEN SAR, goAML, or national forms during formatting (see references/jurisdiction_formats_and_filing.md).

Primary subject (customer)

When subject is unknown or partial

Document unknown counterparty fields explicitly: “Beneficiary name per wire message: [X]; KYC not available to reporting institution.”

Related parties and counterparties

For each counterparty: name (as received), account/IBAN/wallet, institution, country, relationship to customer if known.

Account and product appendix

Transaction selection rules

Define in-scope transactions explicitly in the narrative opening:

1. Alert-driven: all transactions in alert window 2. Lookback: standard 90/180-day policy from institution 3. Counterparty cluster: all txs with same originator 4. Materiality threshold: exclude below X unless part of pattern

Include:

• Transactions that triggered or explain suspicion
• Bookends (first/last in pattern)
• Offsetting txs that show layering

Exclude (with note): routine payroll if clearly unrelated—explain exclusion to avoid MLRO challenge

Aggregation methods

Present summary in narrative, detail in appendix table.

Example summary line:

“In March 2024, the customer conducted 47 incoming wires totaling USD 892,100 from 31 unique senders, compared with 2 incoming wires totaling USD 3,400 in March 2023.”

Chronology table template

Attach as Exhibit A; narrative references row numbers or dates—not “see spreadsheet” without exhibit ID.

Currency and rounding

• State FX rates source if converting to reporting currency
• Round consistently (e.g., two decimals fiat); do not round per row then sum differently
• For crypto, note valuation timestamp and unit (BTC vs satoshis)

Exhibits and data lineage

Document data extract date, system source, and analyst who validated totals.