How to Build a claims processing Agent Using LlamaIndex in TypeScript for investment banking

A claims processing agent for investment banking ingests claim documents, extracts the relevant facts, checks them against policy and trade data, and routes the case for approval, rejection, or manual review. It matters because claims in this domain are not just operational tickets — they can trigger financial loss, regulatory exposure, and audit scrutiny if the decision trail is weak.

Architecture

• •

  Document ingestion layer

  • •Pulls PDFs, emails, confirmations, and internal notes from approved storage.
  • •Normalizes content into text chunks with metadata like client ID, trade ID, jurisdiction, and timestamp.
• •

  Indexing layer

  • •Uses LlamaIndex to build a searchable knowledge base over claims history, policy docs, product terms, and exception playbooks.
  • •Keeps retrieval scoped by business unit and region to avoid cross-client leakage.
• •

  Claim extraction layer

  • •Converts unstructured claim text into structured fields:
    • •claimant
    • •instrument
    • •event date
    • •alleged loss
    • •supporting evidence
    • •policy reference
• •

  Decisioning layer

  • •Applies retrieval-augmented reasoning to compare the claim against policy language and prior adjudications.
  • •Produces a recommendation plus citations for audit.
• •

  Human review and escalation layer

  • •Flags low-confidence or high-risk cases for operations or legal review.
  • •Preserves every prompt, retrieved chunk, and output for traceability.
• •

  Governance layer

  • •Enforces redaction, access control, retention rules, and data residency constraints.
  • •Prevents the agent from answering outside approved sources.

Implementation

1) Install LlamaIndex and define your claim schema

For TypeScript, use the llamaindex package. Start by defining the shape of a claim so your agent returns structured output instead of a free-form paragraph.

npm install llamaindex zod dotenv

import "dotenv/config";
import { z } from "zod";

export const ClaimSchema = z.object({
  claimId: z.string(),
  clientName: z.string(),
  instrument: z.string(),
  eventDate: z.string(),
  claimedAmount: z.number(),
  policyReference: z.string(),
  decision: z.enum(["approve", "reject", "manual_review"]),
  rationale: z.string(),
});

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

This is the minimum viable control surface. In investment banking you want deterministic fields because downstream systems need to reconcile claims against books, records, and case management tools.

2) Build an index over policy documents and prior cases

Use VectorStoreIndex to index approved internal documents. In production this should point at a governed document store with row-level permissions and region-specific storage.

import {
  Document,
  VectorStoreIndex,
} from "llamaindex";

const docs = [
  new Document({
    text: `
      FX settlement claims must be submitted within 5 business days.
      Missing SWIFT confirmation requires manual review.
      Claims exceeding $250,000 need legal approval.
    `,
    metadata: { source: "policy_fx_settlement_v3", region: "US" },
  }),
  new Document({
    text: `
      Prior case CLS-1042 was approved because the counterparty failure
      was confirmed by matching trade confirmation and settlement notice.
    `,
    metadata: { source: "case_history", caseId: "CLS-1042", region: "US" },
  }),
];

const index = await VectorStoreIndex.fromDocuments(docs);
const retriever = index.asRetriever({ similarityTopK: 3 });

The key pattern here is that the index only contains approved content. Do not let raw inboxes or chat logs become your retrieval corpus without filtering and classification first.

3) Create an agent that extracts facts and decides with citations

Use QueryEngineTool plus FunctionCallingAgentWorker when you want tool-based reasoning with controlled access to retrieval. The agent can inspect claim text, retrieve policy snippets, then produce a recommendation.

import {
  OpenAI,
  QueryEngineTool,
  FunctionCallingAgentWorker,
} from "llamaindex";

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

const queryEngine = index.asQueryEngine();

const policyTool = QueryEngineTool.fromDefaults({
  queryEngine,
  name: "policy_lookup",
  description:
    "Search approved claims policy documents and prior adjudicated cases.",
});

const worker = await FunctionCallingAgentWorker.fromTools({
  tools: [policyTool],
  llm,
});

const agent = worker.toAgent();

const claimText = `
Client ACME Capital submitted a claim for $310000 on an FX settlement failure.
They attached a trade confirmation but no SWIFT settlement notice.
The event date is within the last week.
`;

const response = await agent.chat({
  message: `
Analyze this claim:
${claimText}

Return:
- decision
- rationale
- cited policy basis
- whether manual review is required
`,
});

console.log(response.toString());

This pattern keeps the model grounded in your indexed policy content instead of improvising from general knowledge. For banking workflows that’s non-negotiable because every recommendation needs a defensible source trail.

4) Add structured extraction before decisioning

Before you ask the agent to decide anything, extract fields into a typed object. That lets you validate thresholds like amount limits or timeliness before invoking broader reasoning.

import { StructuredOutputParser } from "llamaindex";
import { ClaimSchema } from "./claim-schema";

const parser = StructuredOutputParser.fromZodSchema(ClaimSchema);

const extractionPrompt = `
Extract claim fields from this text:

Client ACME Capital submitted a claim for $310000 on an FX settlement failure.
They attached a trade confirmation but no SWIFT settlement notice.
The event date is within the last week.

${parser.getFormatInstructions()}
`;

const extracted = await llm.complete(extractionPrompt);
const parsedClaim = ClaimSchema.parse(JSON.parse(extracted.text));

console.log(parsedClaim);

Once you have structured data, you can apply deterministic controls:

• •amount > threshold => manual review
• •missing evidence => manual review
• •late submission => reject unless exception exists

That separation between extraction and adjudication makes audits much easier.

Production Considerations

• •

  Auditability

  • •Persist every input document ID, retrieved chunk ID, prompt version, model version, and final decision.
  • •If compliance asks why a claim was approved, you need exact citations not “the model said so.”
• •

  Data residency

  • •Keep US client claims in US-hosted infrastructure and EU claims in EU-hosted infrastructure.
  • •Do not send regulated content to external services unless your legal team has cleared the processor and region controls.
• •

  Guardrails

  • •Block responses that reference sources outside the approved index.
  • •Redact account numbers, personal identifiers, and trade secrets before indexing or logging.
  • •Force manual review when confidence is low or when exceptions exceed predefined thresholds.
• •

  Monitoring

  • •Track retrieval quality, manual override rates, false approvals, false rejections, and latency per case type.
  • •Alert on spikes in “manual_review” outcomes; that usually means your policy corpus is stale or your ingestion pipeline broke.

Common Pitfalls

1. •

   Indexing raw operational data without governance

   • •Problem: You accidentally expose one client’s records to another client’s workflow.
   • •Fix: Partition indexes by tenant, region, desk, or legal entity. Apply metadata filters at retrieval time.
2. •

   Letting the model make final decisions without rules

   • •Problem: The agent approves claims above internal thresholds because it sounds confident.
   • •Fix: Put hard business rules outside the LLM. Use the model for extraction and recommendation; use code for thresholds and eligibility checks.
3. •

   Skipping citation capture

   • •Problem: The output looks correct but cannot survive audit review.
   • •Fix: Require retrieved source snippets in every response. Store them alongside case records so compliance can replay the decision path later.

If you build it this way, LlamaIndex gives you the retrieval backbone while TypeScript keeps the workflow typed and testable. For investment banking claims processing, that combination is what keeps automation useful without making it reckless.

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.