s WatchlistProvenanceEngine { private readonly storage: Map<string, WatchlistEntity[]>;

constructor() { this.storage = new Map(); }

async ingest(source: string, rawPayload: string, effectiveDate: string): Promise<number> { const docHash = createHash('sha256').update(rawPayload).digest('hex'); const versionTag = ${source}_${effectiveDate}_${docHash.slice(0, 8)};

// Parse and validate using external LLM or deterministic parser
const parsed = await this.parseRegulatoryPayload(source, rawPayload);
const validated = parsed.map(entity => ({
  ...entity,
  source_document_hash: docHash,
  version_tag: versionTag,
  effective_date: effectiveDate
}));

this.storage.set(versionTag, validated);
return validated.length;

}

private async parseRegulatoryPayload(source: string, payload: string): Promise<Partial<WatchlistEntity>[]> { // Delegate to Claude Sonnet 4.5 for flexible format normalization // Returns structured JSON matching WatchlistEntitySchema return []; // Placeholder for LLM integration } }

**Why this design:** Version tags combine source, effective date, and document hash to create immutable snapshots. This allows the system to answer temporal questions precisely: "Was this entity listed on the effective date of the transaction?" Storing entities in a versioned map prevents accidental overwrites and supports point-in-time reconstruction.

### Step 2: Dual-Mode Screening Engine

Real-time screening requires deterministic speed for exact matches and contextual reasoning for fuzzy or complex cases. A single model cannot efficiently handle both. The routing engine applies strict rule-based filters first, then delegates ambiguous cases to an LLM with explicit evidence requirements.

```typescript
import { Anthropic } from '@anthropic-ai/sdk';

const RISK_THRESHOLDS = {
  AUTO_CLEAR: 0.25,
  ANALYST_REVIEW: 0.60,
  BLOCK_ESCALATE: 0.85
} as const;

type ScreeningDecision = 'AUTO_CLEAR' | 'ANALYST_REVIEW' | 'BLOCK_ESCALATE';

export class ComplianceDecisionRouter {
  private readonly llm: Anthropic;

  constructor(apiKey: string) {
    this.llm = new Anthropic({ apiKey });
  }

  async evaluateTransaction(tx: {
    id: string;
    amount: number;
    currency: string;
    counterparty: string;
    country: string;
    risk_tier: string;
    watchlist_matches: Array<{ name: string; similarity: number; version: string }>
  }): Promise<ScreeningDecision> {
    // Deterministic pre-screen
    const exactMatch = tx.watchlist_matches.find(m => m.similarity >= 0.98);
    if (exactMatch) {
      return 'BLOCK_ESCALATE';
    }

    // LLM contextual analysis for fuzzy matches
    const context = tx.watchlist_matches
      .filter(m => m.similarity >= 0.65)
      .map(m => `${m.name} (similarity: ${m.similarity}, version: ${m.version})`)
      .join('\n');

    const prompt = `
      Analyze this transaction for compliance risk.
      Transaction: ${tx.amount} ${tx.currency} to ${tx.counterparty} (${tx.country})
      Account Risk Tier: ${tx.risk_tier}
      Watchlist Context:
      ${context || 'No significant matches'}

      Return JSON:
      {
        "score": number,
        "primary_factors": string[],
        "mitigating_factors": string[],
        "rationale": string,
        "confidence": "HIGH|MEDIUM|LOW"
      }
    `;

    const response = await this.llm.messages.create({
      model: 'claude-sonnet-4-5',
      max_tokens: 1024,
      messages: [{ role: 'user', content: prompt }]
    });

    const analysis = JSON.parse(response.content[0].text);
    
    if (analysis.score >= RISK_THRESHOLDS.BLOCK_ESCALATE) return 'BLOCK_ESCALATE';
    if (analysis.score >= RISK_THRESHOLDS.ANALYST_REVIEW) return 'ANALYST_REVIEW';
    return 'AUTO_CLEAR';
  }
}

Why this design: Exact matches bypass the LLM entirely, preserving sub-100ms latency for high-volume flows. Fuzzy matches trigger contextual analysis only when similarity exceeds a calibrated threshold. The LLM is constrained to return structured JSON with explicit factor weighting, preventing vague outputs. Thresholds are externalized to allow compliance teams to adjust risk appetite without code deployments.

Step 3: Immutable Decision Ledger & Plain-Language Synthesis

Every screening outcome must be recorded with full attribution. The ledger is append-only, cryptographically chained, and includes a synthesized explanation tailored for non-technical auditors.

import { createHash } from 'crypto';

export interface AuditRecord {
  tx_id: string;
  decision: ScreeningDecision;
  risk_score: number;
  watchlist_versions: string[];
  regulatory_basis: string[];
  evidence_summary: string;
  human_explanation: string;
  chain_hash: string;
  timestamp: string;
}

export class ImmutableAuditLedger {
  private readonly chain: AuditRecord[] = [];

  async commit(record: Omit<AuditRecord, 'chain_hash'>): Promise<string> {
    const prevHash = this.chain.length > 0 
      ? this.chain[this.chain.length - 1].chain_hash 
      : '0000000000000000';
    
    const payload = JSON.stringify({ ...record, prev_hash: prevHash });
    const chainHash = createHash('sha256').update(payload).digest('hex');
    
    const finalRecord: AuditRecord = { ...record, chain_hash: chainHash };
    this.chain.push(finalRecord);
    
    return chainHash;
  }

  async generateAuditorSummary(rawRecord: AuditRecord): Promise<string> {
    // Delegate to Claude Sonnet 4.5 for plain-language synthesis
    // Constraints: <150 words, no ML jargon, explicit regulatory citations
    return ''; // Placeholder
  }
}

Why this design: Cryptographic chaining prevents retroactive modification of decision history. The watchlist_versions and regulatory_basis fields directly answer regulator questions about data freshness and legal authority. The plain-language synthesis step is isolated to ensure auditors receive contextual explanations without exposing model internals or confidence calibration details.

Pitfall Guide

Pitfall	Explanation	Fix
Treating Application Logs as Audit Trails	Standard logs rotate, compress, or get overwritten. Regulators require permanent, tamper-evident records.	Use append-only storage with cryptographic hashing. Never allow UPDATE or DELETE operations on decision records.
Ignoring Temporal Watchlist Validity	Screening a transaction against today's list when the entity was added yesterday creates false positives/negatives.	Store watchlist snapshots with effective_date and version_tag. Query point-in-time state during screening.
Over-Reliance on LLM Confidence Scores	Language models output confidence levels that do not correlate with statistical accuracy. They can be confidently wrong.	Calibrate LLM outputs against historical false-positive rates. Use deterministic thresholds for routing, not raw confidence strings.
Missing Regulatory Basis Mapping	Failing to cite which specific rule triggered a flag (e.g., OFAC SDN vs. FATF advisory) leaves auditors unable to verify legal compliance.	Add a regulatory_basis array to every decision record. Map watchlist sources to explicit regulatory frameworks during ingestion.
Jargon-Heavy Audit Summaries	Exposing model architecture, token limits, or embedding distances to compliance officers creates confusion and delays examinations.	Implement a dedicated synthesis step with strict constraints: plain language, explicit data citations, <150 words, zero model internals.
Latency Neglect in Real-Time Flows	Blocking payment rails for 2-3 seconds while waiting for LLM responses violates SLAs and degrades user experience.	Use async pre-screening, cache deterministic rule results, and implement fallback routing to manual queues when latency exceeds thresholds.
Treating Fuzzy Matches as Exact	Similarity scores above 0.85 are often treated as definitive matches, triggering unnecessary blocks and customer friction.	Implement explicit ambiguity flags. Route all fuzzy matches to analyst review regardless of score until human validation occurs.

Production Bundle

Action Checklist

• Define decision schema: Include tx_id, decision, risk_score, watchlist_versions, regulatory_basis, evidence_summary, human_explanation, chain_hash, timestamp
• Select append-only storage: Use immutable databases (e.g., Amazon QLDB, Azure Cosmos DB with immutable policy, or cryptographic Merkle trees)
• Externalize risk thresholds: Store AUTO_CLEAR, ANALYST_REVIEW, and BLOCK_ESCALATE values in configuration, not code
• Implement temporal versioning: Hash watchlist payloads, tag with effective dates, and query point-in-time state during screening
• Constrain LLM outputs: Enforce JSON schema validation, cap token limits, and require explicit factor citation in prompts
• Add latency guards: Implement async fallback queues and deterministic rule pre-filters to maintain sub-200ms routing for exact matches
• Run audit simulation: Generate 500 synthetic decisions, export reports, and verify reconstruction accuracy against regulatory checklists

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
High-volume retail payments (>10k TPS)	Deterministic rule engine + async LLM review	Latency constraints prevent synchronous LLM calls; exact matches clear instantly	Low compute, moderate storage
Cross-border corporate transfers	Synchronous dual-mode screening	Higher transaction value justifies 1-2s latency for contextual analysis	Moderate compute, high storage
Crypto onboarding & wallet screening	Fuzzy-match heavy + analyst queue	Pseudonymous entities require nuanced context; exact matches are rare	High analyst cost, moderate compute
Legacy system migration	Parallel run + shadow mode	Validates new pipeline against existing rules without disrupting production	High engineering overhead, low risk

Configuration Template

compliance_pipeline:
  version: "2.1.0"
  risk_thresholds:
    auto_clear: 0.25
    analyst_review: 0.60
    block_escalate: 0.85
  watchlist_sources:
    - name: "OFAC_SDN"
      update_frequency: "weekly"
      temporal_validity: true
    - name: "FATF_GREY_LIST"
      update_frequency: "quarterly"
      temporal_validity: true
  llm_routing:
    model: "claude-sonnet-4-5"
    max_tokens: 1024
    temperature: 0.1
    json_schema_validation: true
  audit_ledger:
    storage_backend: "append_only_sql"
    chain_hashing: "sha256"
    retention_days: 2555
    plain_language_constraints:
      max_words: 150
      exclude_jargon: true
      require_citations: true
  latency_budgets:
    exact_match_ms: 50
    fuzzy_analysis_ms: 1500
    fallback_queue_ms: 3000

Quick Start Guide

1. Initialize the ledger: Deploy an append-only database instance. Configure cryptographic hashing on write operations. Verify that UPDATE and DELETE permissions are revoked for the application service account.
2. Load watchlist snapshots: Ingest OFAC and FATF datasets using the provenance engine. Validate that each entity carries a version_tag and effective_date. Run a point-in-time query to confirm temporal accuracy.
3. Deploy the screening router: Configure risk thresholds in the YAML template. Run a test suite with 50 synthetic transactions covering exact matches, fuzzy matches, and clean counterparties. Verify routing decisions align with thresholds.
4. Enable audit synthesis: Connect the ledger to the plain-language generation step. Export a sample report and validate that explanations cite specific data points, avoid model internals, and remain under 150 words.
5. Shadow mode validation: Route production traffic through the new pipeline in read-only mode for 7 days. Compare decision records against legacy system outputs. Resolve discrepancies before cutover.