Financial Intelligence Unit

FIU (Financial Intelligence Unit)

When to Use

• Run FIU operations: alert queues, case assignment, triage, and investigation lifecycle
• Perform financial analysis on suspicious activity—flows, networks, counterparties, products, corridors
• Document case files with facts, chronology, hypotheses tested, and disposition rationale
• Prepare MLRO escalation packs—fact summaries, open questions, recommendation options (not filing decisions)
• Apply typology-driven analysis (structuring, layering, mule, trade-based ML, VASP/crypto patterns)
• Coordinate with transaction monitoring, second-line compliance, and investigations (fraud, security)
• Support internal FIU reporting—backlog, SLA, quality metrics, management information (not regulator filing advice)
• Run quality assurance, peer review, and case reconstruction for audits or lessons learned
• Design handover, training, and playbook updates from closed cases and tuning feedback
• Integrate adverse media context at a high level (route deep NLP/sentiment pipelines elsewhere)

When NOT to Use

• Design or mature the full AML/CFT program, policies, KYC tiers, or enterprise risk assessment → aml-compliance
• CFT/PF-only typologies, TFS/asset-freeze programs, or NPO sector controls without general FIU case work → aml-cft
• Draft or finalize STR/SAR narratives for filing templates as the primary deliverable → str-report
• Execute internal/IT audit workpapers, SOC 2 testing, or control effectiveness sampling → auditor
• Implement technical controls, evidence automation, or screening/TM engineering → compliance-engineer
• Legal advice, filing duty, regulatory interpretation, or entity structuring → commercial-counsel
• Per-text sentiment labeling or aggregate sentiment forecasting → sentiment-analysis-engineer, sentiment-forecasting-engineer
• Law enforcement blockchain forensics as primary output → blockint / on-chain-investigator-agent skills

Related skills

Core Workflows

1. Intake and triage

1. Classify source (TM alert, referral, law-enforcement request, ad hoc) 2. Assign priority using risk, amount, SLA, and repeat-subject rules 3. Confirm minimum data before investigation (KYC, alert details, lookback window) 4. Route duplicates, false-positive candidates, and out-of-scope items with coded dispositions

See `references/case_intake_and_triage.md`.

2. Financial analysis and typologies

1. Reconstruct flows (accounts, instruments, corridors, counterparties) 2. Map networks and related parties; separate verified facts from inference 3. Test typology hypotheses against observable indicators; document innocent explanations considered 4. Request blockchain or external intelligence with confidence labels when needed

See `references/financial_analysis_and_typologies.md`.

3. Documentation, QA, and escalation

1. Maintain case chronology, exhibit index, and decision log 2. Run peer review or QA sampling before MLRO handoff 3. Package MLRO escalation: summary facts, suspicion elements, gaps, and options—not legal conclusions 4. Hand off to str-report when narrative drafting for filing is the next step

See `references/escalation_and_mlro_handoff.md` and `references/quality_assurance_and_documentation.md`.

4. Reporting, coordination, and metrics

1. Produce internal MI (volumes, aging, typologies, outcomes)—not filing advice 2. Coordinate with TM on tuning feedback and scenario performance 3. Track backlog, SLA, rework, and quality defect rates 4. Capture training topics and playbook updates from closed cases

See `references/reporting_coordination_and_metrics.md`.

When to load references

Operating principles

• Facts first — chronology and amounts before suspicion narrative
• Typology-led, evidence-bound — hypotheses tied to observable indicators
• Segregation of duties — investigators vs QA vs MLRO; log overrides
• Need-to-know — restrict sensitive case materials; access audited
• No legal filing advice — internal packs and MI only; MLRO/counsel decide filings
• Close the loop — feed TM tuning and training from dispositions and QA findings

Case intake and triage

Table of contents

1. Sources and queues 2. Minimum data checklist 3. Prioritization 4. Routing and assignment 5. Disposition at triage 6. SLA and backlog

Sources and queues

Maintain separate queues where regulations or licensing differ (entity, product, corridor). Do not commingle jurisdictions without explicit analyst training.

Minimum data checklist

Before opening a full investigation, confirm:

• Customer ID, legal entity, and CDD tier snapshot
• Alert or referral reference, date range, and scenario/rule name
• Account(s) and instrument(s) in scope
• Amounts and currencies (normalized to reporting currency where used)
• Prior alerts and dispositions on same subject (lookback per policy)
• Sanctions / PEP status at triage (true match vs false positive disposition)

If gaps exist, set status Pending data with owner and due date—do not investigate on incomplete KYC without documented exception approval.

Prioritization

Use a scoring model aligned to policy, for example:

Document priority override with approver when analysts reprioritize outside the model.

Routing and assignment

• Skill-based routing: complex trade finance, crypto, correspondent, or corporate structures
• Capacity balancing: cap WIP per analyst; supervisor rebalances daily
• Conflict check: analyst must not investigate own onboarding or overrides they performed
• Escalation path: team lead → FIU manager → MLRO for threshold breaches

Disposition at triage

All dispositions require actor, timestamp, and free-text rationale retrievable for audit.

SLA and backlog

• Define SLA by priority tier (e.g., P1 24h, P2 72h, P3 10 business days)—adjust to license and risk appetite
• Report aging buckets (0–3d, 4–7d, 8–14d, 15+d) in daily stand-up
• Escalate breaches with root cause: volume, staffing, data latency, rework
• Cap reopen rate tracking—frequent reopens signal triage or QA issues

Feed false positive closures back to TM with structured fields (scenario, reason code, sample tx IDs) for tuning governance.

Escalation and MLRO handoff

Table of contents

1. Escalation triggers 2. MLRO pack structure 3. Suspicion mapping 4. Options and recommendations 5. Handoff to STR drafting 6. Post-MLRO actions

Escalation triggers

Escalate to MLRO (or designated delegate) when any apply:

• Policy mandatory escalation (amount, typology, PEP, sanctions nexus)
• Unresolved suspicion after investigation steps completed
• Repeat subject with prior STR consideration or open regulatory matter
• Cross-border or multi-entity complexity beyond analyst authority
• Media, law enforcement, or partner bank involvement
• Control failure or systemic issue affecting multiple customers
• Analyst recommends STR/SAR consideration regardless of threshold

Document who escalated, when, and prior reviews (QA sign-off where required).

MLRO pack structure

Restrict distribution per need-to-know; watermark or classify per policy.

Suspicion mapping

Use a matrix:

Avoid legal conclusions (“money laundering proved”). Use suspicious indicators language aligned to internal policy and FATF concepts via fatf-glossary-reference when helpful.

Options and recommendations

Present options, not decisions, for MLRO:

MLRO selects option; do not state “must file” unless user explicitly requests counsel skill.

Handoff to STR drafting

When MLRO directs STR/SAR preparation:

1. Transfer MLRO pack and exhibit index to str-report workflow 2. Avoid duplicating investigation—narrative skill assembles who/what/when/where/why 3. List open questions for narrative author explicitly 4. Maintain case master record in FIU system of record

Post-MLRO actions

• Record MLRO decision, date, and rationale in case system
• If closed: apply closure code and TM feedback
• If STR path: track draft, review, approval statuses (FIU may QA facts, not replace MLRO sign-off)
• Schedule retrospective for systemic issues (tuning, training, policy)
• Retention per jurisdictional schedule; restrict access post-filing

Financial analysis and typologies

Table of contents

1. Analysis framework 2. Flow reconstruction 3. Networks and counterparties 4. Typology catalog 5. Crypto and VASP considerations 6. Innocent explanations 7. External intelligence

Analysis framework

1. Scope — subjects, accounts, date range, products, jurisdictions 2. Baseline — expected activity from KYC, RM notes, and historical profile 3. Deviation — quantify vs baseline (amount, count, velocity, geography) 4. Hypothesis — typology-led; multiple hypotheses allowed 5. Test — gather evidence; reject or support each hypothesis 6. Conclusion — suspicion level for internal use; gaps and next steps

Separate verified data (core banking, TM, KYC) from inference (heuristic blockchain labels, media).

Flow reconstruction

Use tables: date, amount, currency, account, counterparty, type, reference, analyst note.

Networks and counterparties

• Map direct counterparties (name, country, bank, VASP if applicable)
• Identify related parties (UBO, common address, device, IP where policy allows)
• Flag high-risk jurisdictions and sectors per risk assessment
• Document unknown counterparties explicitly—do not invent entity names
• For nested relationships, attach simple diagram or adjacency list in case file

Typology catalog

Tie each indicator to specific transactions or events—avoid generic typology labels without facts.

Crypto and VASP considerations

• Use blockchain analytics as decision support; document label confidence
• Record wallet addresses, chains, and tx hashes in exhibit index
• Note travel rule data completeness where relevant
• Route deep forensic narratives to blockint skills; FIU integrates summary into case file
• Do not treat heuristic clustering as proof of ownership

Innocent explanations

For each material deviation, record:

• Hypothesis (e.g., payroll, tuition, property sale, intra-group transfer)
• Evidence checked (payslip, invoice, public record, RM confirmation)
• Outcome — supported, rejected, or unresolved

Unresolved explanations increase escalation likelihood; do not close solely because a plausible story exists without evidence.

External intelligence

Record date, source, and analyst interpretation for each external pull.

FIU scope

Table of contents

1. Mission 2. In scope 3. Out of scope 4. Handoffs 5. Operating principles 6. Deliverable patterns

Mission

Operate the Financial Intelligence Unit (FIU) as the investigative and analytical arm of an AML/CFT program. Convert alerts and referrals into defensible case files: triage, financial analysis, typology testing, documentation, quality review, and MLRO-ready escalation packs. Optimize for throughput with quality, clear audit trails, and feedback into transaction monitoring—not for substituting enterprise policy design, legal filing decisions, or IT audit fieldwork.

In scope

Out of scope

Handoffs

From transaction monitoring / first line:

• Provide: alert ID, scenario, thresholds, lookback, customer profile snapshot, prior alerts
• Receive: disposition, tuning feedback, and documented rationale for closure or escalation

To MLRO / `str-report`:

• Deliver: verified fact pack, chronology, suspicion mapping, exhibit index, open questions
• Request: STR/SAR narrative drafting when filing preparation is the next step—not duplicate investigation

To `aml-compliance`:

• Escalate: systemic control gaps, policy exceptions, program-level risk changes
• Do not: rewrite enterprise AML policy inside a single case file

To `auditor`:

• Provide: sample cases, QA results, disposition codes, access logs for independent review
• Distinguish: FIU QA (second-line operations) vs third-line audit plan

To blockint / investigation skills:

• Request: on-chain traces and entity labels with confidence; FIU owns case disposition and internal narrative

Operating principles

• Investigate to standard — same minimum steps for like cases; avoid ad hoc shortcuts
• Document as you go — contemporaneous notes; reconstructable by another analyst
• Separate facts and inference — label assumptions and data gaps explicitly
• Escalate early — complex typologies, high amounts, PEP/sanctions touchpoints, media attention
• Protect confidentiality — need-to-know access; no casual sharing of suspicion details
• No legal conclusions — describe suspicious indicators; MLRO/counsel decide filings

Deliverable patterns

Quality assurance and documentation

Table of contents

1. Case file standards 2. Documentation elements 3. Peer review 4. QA sampling program 5. Defect taxonomy 6. Rework and sign-off 7. Audit and exam support

Case file standards

Every investigated case should be reconstructable by a second analyst without oral history.

Documentation elements

Minimum artifacts by stage:

Exhibit index: number, title, source, date obtained, sensitivity.

Decision log: date, actor, decision, rationale (overrides, priority changes, reopen).

Peer review

Use peer review before MLRO escalation when policy requires or case exceeds thresholds.

Reviewer confirms:

• Scope appropriate; no material txs omitted
• Typologies tested against facts
• Innocent explanations documented
• Escalation pack complete and internally consistent
• No prohibited language (legal conclusions, guaranteed filing)

Peer reviewer must not be the primary analyst or the KYC officer who approved exceptions on same customer.

QA sampling program

Score cases with a rubric (see defect taxonomy). Trend scores by team, scenario, and source system.

Defect taxonomy

Critical defects require rework and supervisor sign-off before closure stands.

Rework and sign-off

1. QA issues finding sheet with severity and due date 2. Analyst remediates with tracked changes 3. Reviewer re-checks remediated items only or full file per severity 4. Supervisor signs off on critical/major closure 5. Feed root cause into training and playbooks

Audit and exam support

For auditor or regulator requests:

• Provide sample lists with case ID, disposition, date, analyst (not full narrative in email)
• Redact third-party and LE-sensitive material per policy
• Explain QA methodology and metrics trend
• Distinguish FIU QA from independent AML testing (aml-compliance scope)

Do not alter historical records; attach addenda for corrections with approver.

Reporting, coordination, and metrics

Table of contents

1. Internal management information 2. Metrics catalog 3. Coordination with transaction monitoring 4. Coordination with compliance and investigations 5. Regulatory reporting support 6. Training and handover 7. Dashboard cadence

Internal management information

FIU MI supports MLRO, COO, and risk committees—not external filing.

State limitations: data lag, definition changes, and one-off events affecting trends.

Metrics catalog

Avoid single-metric incentives that encourage premature closure; pair productivity with quality scores.

Coordination with transaction monitoring

Structured feedback loop:

1. Tuning requests — scenario ID, sample case IDs, proposed change, expected impact 2. False positive reviews — monthly joint session with documented outcomes 3. New product / corridor — FIU input on typologies before go-live (aml-compliance owns risk sign-off) 4. Model validation support — labeled outcomes for back-testing where governance requires

Log TM changes with version, approver, and effective date—FIU references version in cases affected.

Coordination with compliance and investigations

Use shared case IDs or links across systems; never parallel undocumented investigations on same subject.

Regulatory reporting support

FIU may assemble factual extracts for MLRO or regulatory requests:

• Aggregate STR counts (internal)
• Trend narratives on typologies (non-legal)
• Population descriptions for statistical reporting

Do not:

• Advise whether a filing is legally required
• Draft final regulator submissions without MLRO/counsel
• Replace str-report for narrative assembly

Coordinate exam requests with aml-compliance and auditor—FIU provides case samples and QA evidence.

Training and handover

Track training completion in HR/LMS where required; link to competency matrix (retail vs corporate vs crypto).

Dashboard cadence

Archive dashboards with definitions so period-over-period comparisons remain valid.