COMPLIANCE & EXPLAINABILITY // DEEP DIVE[ TECHNICAL ]

The Regulatory Requirement

FinCEN requires that financial institutions file SARs (Suspicious Activity Reports) for transactions they know or suspect involve illicit funds. The report must explain why the transaction was flagged — 'the ML model said so' is not sufficient. Every flagging decision needs a human-readable justification backed by specific evidence.

SHAP: Per-Prediction Feature Attribution

SHAP (SHapley Additive exPlanations) decomposes each prediction into feature contributions. For a flagged transaction, it might show: neighbor aggregate volume contributed +0.35 to the risk score, unusual output count contributed +0.22, while normal fee rate contributed -0.08. This is exact — the contributions sum to the prediction. TreeExplainer runs in ~2ms for XGBoost, fast enough for real-time use.

SHAP -> Claude -> SAR Narrative

Raw SHAP values are numbers. Compliance analysts need prose. The narrator module sends the top SHAP features to Claude Haiku, which generates a 2-3 sentence narrative: 'This transaction was flagged primarily due to aggregated neighbor transaction volume 3.2 SD above mean, combined with output patterns consistent with fund splitting.' This reduces per-alert review time from ~5 minutes to ~1 minute.

SHAP features:
  neighbor_agg_volume: +0.35
  output_count: +0.22
  fee_rate: -0.08
        |
        v
Claude Haiku API (with compliance prompt)
        |
        v
"Flagged due to elevated neighbor volume
 and output patterns suggesting fund splitting.
 Fee behavior within normal range." 

Investigation Agent

For high-risk alerts, the system can launch an autonomous investigation using Claude with tool_use. The agent has access to tools: look up alert details, check on-chain data, review transaction history, and record analyst verdicts. It produces a structured report with SUMMARY, RISK_ASSESSMENT, EVIDENCE, and RECOMMENDATION sections — a first draft for the compliance officer.

The Analyst Workflow

An alert lands in the compliance queue. The analyst clicks to expand it and sees: transaction details, the risk score, the model that scored it (ML or heuristic), SHAP feature breakdown, and the AI-generated narrative. They review and submit a verdict: true positive (genuinely suspicious), false positive (safe), or escalate. That verdict feeds back into online learning.

Alert arrives (risk > threshold)
  -> Analyst opens alert
    -> Sees: SHAP breakdown + AI narrative
      -> Submits verdict: TP / FP / ESCALATE
        -> Verdict -> online model (immediate)
        -> Verdict -> batch retrain (scheduled)

Full Audit Trail

Every prediction is logged to the prediction_audit table: model name, model version, risk score, threshold at time of scoring, top SHAP features, LLM narrative, inference time in ms. Regulators can reconstruct any flagging decision months later by prediction ID. This is the difference between 'we use ML' and 'we can prove exactly why ML flagged this transaction.'

Cost-Sensitive Decision Making

The alert threshold isn't arbitrary. A missed illicit transaction (false negative) carries ~$50K in regulatory risk. A false alarm (false positive) costs ~$50 in analyst review time. The system optimizes the classification threshold for minimum total business cost, not for maximum accuracy. The threshold is adjustable from the dashboard as business conditions change.