How to Build a fraud detection Agent Using AutoGen in TypeScript for insurance

By Cyprian AaronsUpdated 2026-04-21
fraud-detectionautogentypescriptinsurance

A fraud detection agent for insurance takes a claim, policy, and supporting evidence, then coordinates analysis across rules, document checks, and investigation steps to decide whether the case is clean, suspicious, or needs human review. It matters because false positives slow down legitimate claims, while false negatives leak money through staged accidents, inflated medical bills, duplicate submissions, and identity fraud.

Architecture

Build this agent as a small system of specialized components instead of one giant prompt:

  • Claim intake service
    • Normalizes FNOL data, policy metadata, claimant history, and attachments into a single request object.
  • AutoGen orchestrator
    • Uses AssistantAgent instances to reason over fraud signals and produce structured findings.
  • Evidence extraction tool
    • Pulls OCR text, policy coverage details, prior claims history, and vendor data into the conversation.
  • Risk scoring layer
    • Converts agent output into a numeric fraud score and a decision: auto-approve, refer to SIU, or hold for manual review.
  • Audit logger
    • Persists prompts, tool outputs, model responses, and final decisions for compliance review.
  • Human review handoff
    • Routes borderline cases to an adjuster or SIU analyst with the supporting rationale.

Implementation

1) Install AutoGen and define your claim schema

Use the TypeScript AutoGen package and keep your input contract strict. Insurance workflows break when claim payloads are loose JSON blobs.

npm install @autogen/core zod
import { z } from "zod";

export const ClaimSchema = z.object({
  claimId: z.string(),
  policyId: z.string(),
  lineOfBusiness: z.enum(["auto", "property", "health", "life"]),
  lossDate: z.string(),
  reportedDate: z.string(),
  claimantName: z.string(),
  amountRequested: z.number(),
  incidentSummary: z.string(),
  documents: z.array(z.string()),
});

export type ClaimInput = z.infer<typeof ClaimSchema>;

2) Create an AutoGen assistant that investigates fraud signals

The key pattern is to give the agent a narrow job: inspect the claim for fraud indicators and return structured output. In AutoGen TypeScript, AssistantAgent is the workhorse for this.

import { AssistantAgent } from "@autogen/core";

export const fraudAnalyst = new AssistantAgent({
  name: "fraud_analyst",
  systemMessage: `
You are an insurance fraud investigation assistant.
Your job is to assess claim red flags using only the provided evidence.
Return JSON with:
- riskLevel: low | medium | high
- score: number from 0 to 100
- redFlags: string[]
- rationale: string
- nextAction: approve | refer_to_siu | request_more_info
Do not invent facts. If evidence is missing, say so.
`,
});

That system message matters more than people think. In insurance, hallucinated facts become bad claim decisions and bad audit trails.

3) Run a single-turn assessment with real evidence

If you already have extracted claim data and document text, send it directly to the agent. Keep the prompt deterministic and include only what you want evaluated.

import { ClaimInput } from "./schema";
import { fraudAnalyst } from "./agent";

export async function assessClaim(claim: ClaimInput) {
  const prompt = `
Assess this insurance claim for potential fraud.

Claim:
${JSON.stringify(claim, null, 2)}

Focus on:
- mismatch between loss date and report date
- repeated claimant or policy patterns
- suspiciously high requested amount
- vague incident narrative
- missing or inconsistent documents
`;

  const result = await fraudAnalyst.run(prompt);
  return result;
}

4) Wrap it in an orchestration layer with human escalation

For production insurance systems, don’t let the model make the final call by itself. Use its output as one signal in a controlled workflow.

import { ClaimSchema } from "./schema";
import { assessClaim } from "./assess";

type Decision = {
  score: number;
  action: "approve" | "refer_to_siu" | "request_more_info";
};

export async function triageClaim(rawClaim: unknown): Promise<Decision> {
  const claim = ClaimSchema.parse(rawClaim);
  const analysis = await assessClaim(claim);

  const text = typeof analysis === "string" ? analysis : JSON.stringify(analysis);
  const parsed = JSON.parse(text);

  if (parsed.score >= 80) {
    return { score: parsed.score, action: "refer_to_siu" };
    }
  
    if (parsed.score >= 50) {
    return { score: parsed.score, action: "request_more_info" };
    }

    return { score: parsed.score, action: "approve" };
}

The important part here is that business logic stays outside the model. That gives you predictable routing rules when auditors ask why a claim was held.

Production Considerations

  • Auditability

    • Store the exact input payload, model output, timestamp, model version, and routing decision.
    • For regulated claims handling, you need traceability from decision back to evidence.
  • Data residency

    • Keep PHI/PII inside approved regions and approved vendors only.
    • If your insurer operates across jurisdictions, route EU or state-restricted data through region-bound infrastructure.
  • Guardrails

    • Redact sensitive fields before sending them to the agent when full identifiers are not needed.
    • Block unsupported actions like denial recommendations unless they are backed by explicit rules.
  • Monitoring

    • Track false positive rate by line of business.
    • Watch for drift in score distributions after new policy wording changes or new fraud campaigns.

Common Pitfalls

  1. Letting the model make final adjudication

    • Don’t use agent output as the final denial/approval decision.
    • Use it for triage; keep settlement authority in deterministic code or human review.
  2. Feeding raw documents without normalization

    • OCR noise and duplicated attachments will confuse any agent.
    • Extract structured fields first: dates, amounts, names, VINs, provider IDs, diagnosis codes.
  3. Ignoring compliance boundaries

    • Claims data often includes PII, PHI, and jurisdiction-specific retention rules.
    • Define what can be sent to the model before implementation starts; retrofitting controls later is painful.
  4. No feedback loop from SIU outcomes

    • If investigators close cases as legitimate or fraudulent but you never feed that back into scoring thresholds, performance stalls.
    • Log outcomes and recalibrate your routing rules monthly.

Keep learning

By Cyprian Aarons, AI Consultant at Topiax.

Want the complete 8-step roadmap?

Grab the free AI Agent Starter Kit — architecture templates, compliance checklists, and a 7-email deep-dive course.

Get the Starter Kit

Related Guides