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

Fraud detection in insurance is mostly a document and evidence problem. The agent’s job is to read claims, policy details, adjuster notes, repair invoices, medical reports, and prior claim history, then flag inconsistencies that deserve human review before money goes out.

For insurance teams, that matters because fraud is expensive, but false positives are too. A good agent reduces manual triage time while keeping an audit trail for compliance, claims governance, and downstream dispute handling.

Architecture

• •

  Document ingestion layer

  • •Pulls claim packets from object storage, case management systems, or secure uploads.
  • •Normalizes PDFs, emails, scanned notes, and structured JSON into LlamaIndex Document objects.
• •

  Indexing layer

  • •Builds a vector index over claim evidence using VectorStoreIndex.
  • •Keeps retrieval focused on the current claim file and linked historical cases.
• •

  Fraud reasoning layer

  • •Uses an LLM-backed query engine to compare evidence against fraud patterns.
  • •Produces a structured risk assessment: inconsistencies, missing documents, duplicate signals, and escalation reasons.
• •

  Policy and compliance guardrail layer

  • •Enforces what data can be processed and what outputs are allowed.
  • •Prevents the agent from making final claim decisions; it only recommends review.
• •

  Audit logging layer

  • •Stores inputs, retrieved passages, prompts, and outputs for regulator review.
  • •Supports explainability when a claims handler asks why a case was flagged.

Implementation

1) Install the LlamaIndex TypeScript packages

Use the core package plus an LLM provider. For OpenAI-backed workflows:

npm install llamaindex dotenv

Set your environment variables:

OPENAI_API_KEY=your_key_here

2) Load claim evidence into Document objects

This example uses in-memory documents for clarity. In production, replace this with secure ingestion from your claims platform or document store.

import "dotenv/config";
import { Document } from "llamaindex";

export function buildClaimDocuments() {
  return [
    new Document({
      id_: "claim-1001-policy",
      text: `
Claim ID: CLM-1001
Policy Type: Auto Comprehensive
Insured: J. Ndlovu
Loss Date: 2025-03-11
Reported Loss Time: 02:10 AM
Police Report: Not filed
Notes: Vehicle allegedly stolen from gated parking lot.
`,
    }),
    new Document({
      id_: "claim-1001-invoice",
      text: `
Repair Invoice
Shop: Apex Auto Body
VIN: WDB123456789
Mileage: 18,200
Total Amount: $14,860
Parts replaced include front bumper, headlights, radiator support.
`,
    }),
    new Document({
      id_: "claim-1001-notes",
      text: `
Adjuster Notes:
- Insured submitted photos taken before tow truck arrival.
- Metadata suggests images were captured two days after reported loss date.
- Similar invoice pattern seen in prior claims from same repair shop.
`,
    }),
  ];
}

3) Build a vector index and query it with a fraud-focused prompt

The key pattern is to retrieve evidence first, then ask the model for a grounded assessment. Use VectorStoreIndex.fromDocuments() and index.asQueryEngine().

import "dotenv/config";
import {
  VectorStoreIndex,
  Settings,
  OpenAI,
} from "llamaindex";
import { buildClaimDocuments } from "./documents";

Settings.llm = new OpenAI({
  model: "gpt-4o-mini",
});

async function main() {
  const docs = buildClaimDocuments();

  const index = await VectorStoreIndex.fromDocuments(docs);

  const queryEngine = index.asQueryEngine({
    similarityTopK: 3,
    systemPrompt: `
You are an insurance fraud triage assistant.
Only use the provided claim evidence.
Do not decide coverage or deny claims.
Return:
1. Risk level: low/medium/high
2. Evidence-based reasons
3. Missing information to request
4. Recommended next action for a human adjuster
`,
  });

  const response = await queryEngine.query({
    query:
      "Assess this claim for fraud indicators. Focus on timing inconsistencies, invoice anomalies, missing police report, and suspicious photo metadata.",
  });

  console.log(response.toString());
}

main().catch(console.error);

This works because VectorStoreIndex gives you retrieval over the claim packet, while asQueryEngine() turns it into a grounded reasoning interface. For insurance workflows, that grounding matters more than raw generation quality.

4) Add structured output for downstream case management

Claims systems need predictable fields, not free-form prose. A practical pattern is to have the agent return JSON-like fields that your workflow engine can parse and store.

const queryEngine = index.asQueryEngine({
  similarityTopK: 4,
  systemPrompt: `
Return valid JSON with keys:
risk_level, reasons[], missing_info[], recommended_action
Use only evidence from retrieved context.
`,
});

const result = await queryEngine.query({
  query: "Generate a fraud triage summary for this claim.",
});

const raw = result.toString();
console.log(raw);

If you need stricter schema enforcement later, wrap this with your own validator before writing to the claims database. In production insurance systems I usually validate against Zod or Ajv before anything reaches adjuster queues.

Production Considerations

• •

  Keep data residency explicit

  • •Claims data often cannot leave a jurisdiction.
  • •Pin your vector store and LLM endpoints to approved regions and avoid cross-border processing unless legal has signed off.
• •

  Log every retrieval path

  • •Store the user question, retrieved chunks, model output, timestamp, and claim ID.
  • •This is what you need when a regulator or internal audit team asks why a file was escalated.
• •

  Put hard guardrails around decisions

  • •The agent should recommend review, not approve or deny coverage.
  • •Final decisions stay with licensed claims staff under documented SOPs.
• •

  Monitor false positives by line of business

  • •Fraud signals differ between auto, property, health travel insurance, and life claims.
  • •Track precision by product so one noisy model does not flood adjusters with bad escalations.

Common Pitfalls

• •

  Mixing unrelated claims into one index

  • •This causes cross-case leakage and bad recommendations.
  • •Build per-claim or tightly scoped indexes unless you have explicit permission to search historical cases.
• •

  Letting the model infer facts not in evidence

  • •Fraud agents must stay grounded in retrieved documents.
  • •Use prompts that forbid speculation and require cited evidence snippets in the output.
• •

  Skipping compliance review on PII and PHI

  • •Insurance files contain highly sensitive personal data.
  • •Redact where possible before indexing, minimize retention windows, and confirm vendor contracts cover regulated data handling.

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.