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

A claims processing agent for investment banking takes in claim-related documents, extracts the relevant facts, validates them against internal policy and trade data, and routes the case for decision or escalation. It matters because claims in this domain are not just operational tickets; they can trigger financial exposure, regulatory reporting, audit requests, and client disputes if handled incorrectly.

Architecture

• •

  Document ingestion layer

  • •Pulls PDFs, emails, scanned attachments, and structured claim forms from approved internal sources.
  • •Normalizes text before it reaches the model.
• •

  Claim extraction chain

  • •Uses LangChain to turn unstructured content into structured fields like claimant, trade ID, product type, loss amount, date, and jurisdiction.
  • •Returns typed output instead of free-form text.
• •

  Policy and controls checker

  • •Validates extracted fields against bank policy, KYC/AML flags, product rules, and jurisdiction constraints.
  • •Rejects or escalates cases that violate thresholds.
• •

  Decision routing layer

  • •Sends low-risk claims to auto-resolution.
  • •Routes ambiguous or high-value claims to a human analyst with a full trace.
• •

  Audit logging store

  • •Persists prompts, model outputs, tool calls, and final decisions.
  • •Supports regulatory review and internal model governance.
• •

  Data residency boundary

  • •Ensures sensitive claim data stays in the approved region and approved model endpoint.
  • •Prevents accidental leakage to non-compliant providers.

Implementation

1. •Define the structured claim schema

Use zod with LangChain’s StructuredOutputParser so the model returns predictable fields. In investment banking, you want typed output because downstream rules engines should never parse prose.

import { z } from "zod";
import { ChatOpenAI } from "@langchain/openai";
import { PromptTemplate } from "@langchain/core/prompts";
import { StructuredOutputParser } from "langchain/output_parsers";

const ClaimSchema = z.object({
  claimantName: z.string(),
  tradeId: z.string(),
  productType: z.enum(["equity", "fixed_income", "derivatives", "fx", "other"]),
  claimAmount: z.number(),
  currency: z.string(),
  jurisdiction: z.string(),
  summary: z.string(),
  riskFlag: z.enum(["low", "medium", "high"]),
});

const parser = StructuredOutputParser.fromZodSchema(ClaimSchema);

const prompt = PromptTemplate.fromTemplate(`
Extract the claim details from the document below.
Return only valid JSON matching these instructions:
{format_instructions}

Document:
{document}
`);

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

export async function extractClaim(document: string) {
  const formattedPrompt = await prompt.format({
    document,
    format_instructions: parser.getFormatInstructions(),
  });

  const response = await llm.invoke(formattedPrompt);
  return parser.parse(response.content.toString());
}

2. •Add policy checks after extraction

Keep policy logic outside the model. The model extracts facts; your code decides whether the claim can proceed. That separation is important for auditability.

type Claim = z.infer<typeof ClaimSchema>;

export function evaluateClaimPolicy(claim: Claim) {
  const reasons: string[] = [];

  if (claim.claimAmount > 1000000) {
    reasons.push("amount_above_auto_approval_threshold");
  }

  if (claim.jurisdiction === "US" && claim.productType === "derivatives") {
    reasons.push("us_derivatives_requires_manual_review");
  }

  if (claim.riskFlag === "high") {
    reasons.push("model_marked_high_risk");
  }

  return {
    approvedForAutoProcessing: reasons.length === 0,
    reasons,
    routeTo: reasons.length === 0 ? "auto_resolution" : "human_review",
  };
}

3. •Build a small LangChain pipeline for end-to-end processing

Use RunnableSequence to wire extraction into decisioning. This keeps the flow explicit and easy to trace during audits.

import { RunnableSequence } from "@langchain/core/runnables";

const pipeline = RunnableSequence.from([
  async (input: { document: string }) => extractClaim(input.document),
]);

export async function processClaim(document: string) {
  const claim = await pipeline.invoke({ document });
  const decision = evaluateClaimPolicy(claim);

  return {
    claim,
    decision,
    auditTimestamp: new Date().toISOString(),
    complianceNotes:
      decision.routeTo === "human_review"
        ? "Escalated under investment banking controls"
        : "Eligible for automated handling",
  };
}

4. •Attach retrieval for policy grounding

For production use, don’t hardcode policy text in prompts. Put internal claims policy into a retriever-backed store so the agent can cite current rules without embedding sensitive documents directly in code. Use VectorStoreRetriever or a retriever built on your approved vector database, then pass retrieved snippets into the extraction or review prompt.

Production Considerations

• •

  Audit every hop

  • •Persist input document hashes, prompt templates, retrieved policy chunks, model version, and final routing decision.
  • •Regulators care about reproducibility more than clever prompts.
• •

  Enforce data residency

  • •Pin inference to an approved region and an approved provider endpoint.
  • •Never send client claims data to a general-purpose SaaS endpoint without legal review.
• •

  Add deterministic guardrails

  • •Use strict schemas, thresholds, and allowlists for auto-resolution.
  • •For anything above risk tolerance or monetary threshold, force human approval.
• •

  Monitor drift and exception rates

  • •Track extraction accuracy by product type and jurisdiction.
    • •Watch for rising manual-review rates; that usually means upstream document quality or policy drift is changing.

Common Pitfalls

• •

  Letting the LLM make final decisions

  The model should extract and summarize; your rules engine should approve or reject. If you let the model decide directly, you lose control over consistency and auditability.

• •

  Skipping schema validation

  Free-text output will break downstream systems eventually. Always validate with zod or another strict schema before any business logic runs.

• •

  Ignoring jurisdiction-specific controls

  Claims handling in investment banking changes by region, product class, and client type. Build those rules into code and retrieval sources instead of assuming one global workflow fits all cases.

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.