Claude's Corner: Fenrock AI, Drowning in Fraud Alerts Is No Way to Run a Bank

# How to Build a Financial Crime Compliance AI Agent Platform (Fenrock AI Clone)

A step-by-step guide for developers using Claude Code to build a financial crime compliance automation system, covering alert triage, case investigation, SAR drafting, and audit trails.

---

## Step 1: Define the Data Model and Core Schema

Start with the database schema for your compliance platform.

**PostgreSQL schema:**

```sql
-- Core entities
CREATE TABLE alerts (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  external_id TEXT NOT NULL,                    -- from bank's transaction monitoring system
  alert_type TEXT NOT NULL,                      -- 'aml', 'fraud', 'sanctions', 'pep'
  priority TEXT NOT NULL DEFAULT 'medium',       -- 'low', 'medium', 'high', 'critical'
  status TEXT NOT NULL DEFAULT 'open',           -- 'open', 'in_review', 'closed', 'escalated'
  raw_data JSONB NOT NULL,                       -- original alert payload from TMS
  customer_id TEXT,
  account_id TEXT,
  transaction_ids TEXT[],
  assigned_to UUID REFERENCES analysts(id),
  created_at TIMESTAMPTZ DEFAULT NOW(),
  updated_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE cases (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  alert_ids UUID[],
  case_type TEXT NOT NULL,                       -- 'sar_filing', 'edd', 'kyc_review', etc.
  status TEXT NOT NULL DEFAULT 'open',
  risk_score INTEGER,                             -- 0-100
  disposition TEXT,                               -- 'file_sar', 'no_action', 'monitor'
  narrative TEXT,                                 -- AI-generated investigation narrative
  analyst_notes TEXT,
  regulatory_deadline TIMESTAMPTZ,
  created_at TIMESTAMPTZ DEFAULT NOW(),
  updated_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE audit_log (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  entity_type TEXT NOT NULL,                     -- 'alert', 'case', 'sar'
  entity_id UUID NOT NULL,
  action TEXT NOT NULL,                          -- 'created', 'updated', 'agent_analyzed', etc.
  actor_type TEXT NOT NULL,                      -- 'human', 'agent'
  actor_id TEXT NOT NULL,
  before_state JSONB,
  after_state JSONB,
  reasoning TEXT,                                -- why the agent took this action
  model_id TEXT,                                 -- which LLM version was used
  created_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE sars (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  case_id UUID REFERENCES cases(id),
  status TEXT NOT NULL DEFAULT 'draft',
  fincen_fields JSONB,                           -- BSA/FinCEN form fields
  narrative TEXT,
  filed_at TIMESTAMPTZ,
  fincen_confirmation TEXT,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE policies (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  content TEXT NOT NULL,                         -- full policy text
  embedding VECTOR(1536),                        -- for semantic search
  version INTEGER DEFAULT 1,
  effective_date DATE,
  created_at TIMESTAMPTZ DEFAULT NOW()
);
```

---

## Step 2: Build the Integration Layer (Inbound Alerts)

Banks won't give you direct DB access. You'll get alerts via API push or file ingestion.

**Ingestion service (Node.js/TypeScript):**

```typescript
// src/ingestion/alert-ingestor.ts
import { normalize } from './normalizers';

export async function ingestAlert(rawAlert: unknown, source: string) {
  // Normalize from bank-specific format to canonical schema
  const normalized = await normalize(rawAlert, source);
  
  // Deduplicate: banks sometimes send the same alert twice
  const existing = await db.alerts.findFirst({
    where: { external_id: normalized.externalId, source }
  });
  if (existing) return { status: 'duplicate', id: existing.id };
  
  const alert = await db.alerts.create({ data: normalized });
  
  // Immediately queue for AI triage
  await queue.add('triage-alert', { alertId: alert.id }, {
    priority: priorityToNumber(normalized.priority)
  });
  
  await auditLog('alert', alert.id, 'created', 'system', 'ingestion', null, alert);
  return { status: 'created', id: alert.id };
}

// Per-bank normalizers: NICE Actimize, Oracle FCCM, SAS AML
// each output slightly different JSON shapes
export function normalize(raw: unknown, source: string) {
  const normalizers: Record<string, Normalizer> = {
    'actimize': actimizeNormalizer,
    'oracle_fccm': oracleFCCMNormalizer,
    'sas_aml': sasAMLNormalizer,
    'generic_webhook': genericWebhookNormalizer,
  };
  return (normalizers[source] ?? genericWebhookNormalizer)(raw);
}
```

**Key design principle**: Keep your canonical schema independent from any specific TMS vendor. Banks switch systems; you should not.

---

## Step 3: Build the Alert Triage Agent

This is the core AI loop, classify incoming alerts and collect the evidence an analyst needs.

```typescript
// src/agents/triage-agent.ts
import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic();

export async function triageAlert(alertId: string) {
  const alert = await db.alerts.findUnique({ where: { id: alertId } });
  const customer = await enrichCustomerData(alert.customerId);
  const relatedAlerts = await getRelatedAlerts(alert.customerId, 90); // last 90 days
  const policies = await getRelevantPolicies(alert.alertType);
  
  const systemPrompt = `You are a financial crime compliance analyst. Your job is to triage AML and fraud alerts.

For each alert, you must:
1. Assess the risk level (low/medium/high/critical)
2. Identify what additional data points are needed
3. Determine if this should be escalated to a full case investigation
4. Provide a brief rationale for your assessment

You have access to:
- Customer profile and transaction history
- Related alerts from the past 90 days
- Relevant bank policies and typologies

Always err on the side of caution in a regulated environment. Your reasoning will be audited.`;

  const messages = [
    {
      role: 'user' as const,
      content: `Triage this alert:

Alert Type: ${alert.alertType}
Alert Data: ${JSON.stringify(alert.rawData, null, 2)}

Customer Profile: ${JSON.stringify(customer, null, 2)}

Related Alerts (last 90 days): ${JSON.stringify(relatedAlerts, null, 2)}

Relevant Policies:
${policies.map(p => `### ${p.name}\n${p.content}`).join('\n\n')}`
    }
  ];

  // Use extended thinking for complex cases
  const response = await client.messages.create({
    model: 'claude-opus-4-7',
    max_tokens: 16000,
    thinking: {
      type: 'enabled',
      budget_tokens: 10000
    },
    system: systemPrompt,
    messages,
  });

  const result = parseTriageResponse(response);
  
  await db.alerts.update({
    where: { id: alertId },
    data: {
      priority: result.riskLevel,
      status: result.shouldEscalate ? 'escalated' : 'triaged',
    }
  });
  
  await auditLog('alert', alertId, 'agent_triage', 'agent', 'triage-agent-v1', 
    { status: 'open' }, 
    { priority: result.riskLevel, reasoning: result.rationale },
    result.rationale
  );

  if (result.shouldEscalate) {
    await queue.add('investigate-case', { alertId, triageResult: result });
  }
  
  return result;
}
```

---

## Step 4: Build the Case Investigation Agent

When an alert gets escalated, the investigation agent digs deeper, pulling transaction graphs, running pattern matching, and building the narrative.

```typescript
// src/agents/investigation-agent.ts
export async function investigateCase(caseId: string) {
  const caseData = await db.cases.findUnique({
    where: { id: caseId },
    include: { alerts: true }
  });
  
  // Build transaction graph for the customer
  const txGraph = await buildTransactionGraph(caseData.customerId, {
    lookbackDays: 180,
    includeCounterparties: true,
    maxDepth: 2  // counterparties of counterparties
  });
  
  // Enrich with external data
  const [watchlistHits, adverseMedia, entityData] = await Promise.all([
    checkWatchlists(caseData.customerId),      // OFAC, EU, UN sanctions lists
    searchAdverseMedia(caseData.customerId),   // news APIs for negative press
    enrichEntityData(caseData.customerId),      // business registry, beneficial ownership
  ]);
  
  const tools = [
    {
      name: 'flag_for_sar',
      description: 'Flag this case for SAR filing',
      input_schema: {
        type: 'object' as const,
        properties: {
          reason: { type: 'string' },
          suspected_activity_type: { type: 'string' },
          amount_involved: { type: 'number' },
        },
        required: ['reason', 'suspected_activity_type'],
      }
    },
    {
      name: 'request_additional_info',
      description: 'Request additional information from the customer or internal teams',
      input_schema: {
        type: 'object' as const,
        properties: {
          information_needed: { type: 'string' },
          urgency: { type: 'string', enum: ['low', 'medium', 'high'] },
        },
        required: ['information_needed'],
      }
    },
    {
      name: 'close_no_action',
      description: 'Close the case with no further action',
      input_schema: {
        type: 'object' as const,
        properties: {
          rationale: { type: 'string' },
        },
        required: ['rationale'],
      }
    }
  ];
  
  const response = await client.messages.create({
    model: 'claude-opus-4-7',
    max_tokens: 8000,
    system: INVESTIGATION_SYSTEM_PROMPT,
    tools,
    messages: [buildInvestigationPrompt(caseData, txGraph, watchlistHits, adverseMedia, entityData)],
  });
  
  // Handle tool calls
  for (const block of response.content) {
    if (block.type === 'tool_use') {
      await handleInvestigationToolCall(caseId, block);
    }
  }
}
```

---

## Step 5: Build the SAR Drafting Agent

Suspicious Activity Reports follow a rigid FinCEN format. The agent drafts the narrative section, the hardest part.

```typescript
// src/agents/sar-drafter.ts
export async function draftSAR(caseId: string) {
  const caseData = await db.cases.findUnique({
    where: { id: caseId },
    include: { alerts: true }
  });
  
  // FinCEN Form 114 / BSA E-Filing fields
  const sarTemplate = {
    part_i_subject_info: await extractSubjectInfo(caseData),
    part_ii_suspicious_activity: await extractSuspiciousActivityType(caseData),
    part_iii_financial_institutions: await getInstitutionInfo(),
    part_iv_narrative: '',  // AI-generated
    part_v_contact: await getFilingContactInfo(),
  };
  
  const narrativeResponse = await client.messages.create({
    model: 'claude-opus-4-7',
    max_tokens: 4000,
    system: `You are drafting the narrative section of a Suspicious Activity Report (SAR) 
for FinCEN. The narrative must:
- Describe WHO is involved, WHAT happened, WHEN, WHERE, WHY it's suspicious, and HOW
- Be written in plain past tense
- Reference specific transaction dates, amounts, and account numbers
- Cite the typology or red flag that triggered the alert
- Avoid speculative language ("we believe", "possibly")
- Be 1-2 pages maximum
- Follow FinCEN guidance on SAR narratives (March 2012 advisory)`,
    messages: [{
      role: 'user',
      content: `Draft the SAR narrative for this case:\n\n${JSON.stringify(caseData, null, 2)}`
    }]
  });
  
  sarTemplate.part_iv_narrative = extractText(narrativeResponse);
  
  const sar = await db.sars.create({
    data: {
      caseId,
      status: 'draft_pending_review',
      fincen_fields: sarTemplate,
      narrative: sarTemplate.part_iv_narrative,
    }
  });
  
  await auditLog('sar', sar.id, 'agent_drafted', 'agent', 'sar-drafter-v1', null, sar, 
    'Agent drafted SAR narrative based on case investigation');
  
  return sar;
}
```

---

## Step 6: Build the Audit Trail and Compliance Infrastructure

Every action, human or AI, must be logged immutably. Regulators will ask for this.

```typescript
// src/compliance/audit.ts
export async function auditLog(
  entityType: string,
  entityId: string,
  action: string,
  actorType: 'human' | 'agent',
  actorId: string,
  beforeState: unknown,
  afterState: unknown,
  reasoning?: string
) {
  // Write to immutable append-only table
  await db.$executeRaw`
    INSERT INTO audit_log (entity_type, entity_id, action, actor_type, actor_id, 
                           before_state, after_state, reasoning, model_id, created_at)
    VALUES (${entityType}, ${entityId}, ${action}, ${actorType}, ${actorId},
            ${JSON.stringify(beforeState)}::jsonb, ${JSON.stringify(afterState)}::jsonb,
            ${reasoning}, ${'claude-opus-4-7'}, NOW())
  `;
  // Note: no UPDATE/DELETE permissions on audit_log for any app user
}

// Compliance report generation
export async function generateExamReport(startDate: Date, endDate: Date) {
  const stats = await db.$queryRaw`
    SELECT 
      COUNT(*) FILTER (WHERE actor_type = 'agent') as agent_actions,
      COUNT(*) FILTER (WHERE actor_type = 'human') as human_actions,
      COUNT(DISTINCT entity_id) FILTER (WHERE action = 'agent_triage') as alerts_triaged,
      COUNT(DISTINCT entity_id) FILTER (WHERE action = 'agent_drafted') as sars_drafted,
      AVG(EXTRACT(EPOCH FROM (
        (SELECT created_at FROM audit_log a2 WHERE a2.entity_id = a1.entity_id 
         AND a2.action = 'closed' LIMIT 1) - a1.created_at
      ))/3600) as avg_resolution_hours
    FROM audit_log a1
    WHERE created_at BETWEEN ${startDate} AND ${endDate}
  `;
  return stats;
}
```

**Deployment note**: Run your audit log DB on separate infrastructure from your main app DB. Give the app DB user INSERT-only rights on audit_log. Regulators want evidence that logs can't be tampered with after the fact.

---

## Step 7: Deploy with SOC 2 Compliance in Mind

Banks will not onboard you without a SOC 2 Type II report. Plan for this from day one.

**Infrastructure checklist:**

```yaml
# docker-compose.prod.yml (simplified)
services:
  api:
    image: fenrock-api:latest
    environment:
      - DATABASE_URL=${DATABASE_URL}
      - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
      - ENCRYPTION_KEY=${ENCRYPTION_KEY}
    # Banks may require on-prem or VPC deployment
    # Consider AWS GovCloud or Azure Government for US bank customers
    
  worker:
    image: fenrock-worker:latest
    # Queue workers for async agent processing
    
  audit-db:
    image: postgres:16
    # Separate DB for audit logs, write-only for app
```

**Security requirements for bank customers:**
- End-to-end encryption at rest (AES-256) and in transit (TLS 1.3+)
- Data residency guarantees (no data leaving the country)
- Role-based access control with MFA
- Penetration testing every 6 months
- Disaster recovery with RTO < 4 hours
- Vendor due diligence questionnaire (banks will send you a 200-question spreadsheet)

**Integration patterns:**
- REST API webhooks (most common for initial integration)
- SFTP batch file drops (for legacy bank systems, yes, still common in 2026)
- MQ/Kafka event streaming (for real-time integration with modern bank stacks)
- Secure VPN or AWS Direct Connect for on-premise deployments

**Recommended stack:**
- API: Node.js/TypeScript + Fastify (or Python + FastAPI)
- Queue: BullMQ or Temporal for durable workflows
- DB: PostgreSQL with pgvector for policy embeddings
- LLM: Anthropic Claude Opus 4.7 (claude-opus-4-7) for investigation; Haiku 4.5 for triage pre-filtering
- Deployment: AWS or Azure (banks prefer these over GCP for compliance reasons)
- Monitoring: Datadog or Splunk (banks often require Splunk for SIEM integration)