How to Build a claims processing Agent Using LangGraph in TypeScript for retail banking

A claims processing agent for retail banking takes a customer claim, classifies it, pulls the right account and transaction context, checks policy and compliance rules, and routes the case to auto-approval, manual review, or rejection with an audit trail. It matters because claims are high-volume, time-sensitive, and heavily regulated; if your workflow is slow or inconsistent, you create customer churn, operational risk, and audit pain.

Architecture

A production claims agent in retail banking usually needs these components:

• •

  Ingress and validation layer

  • •Accepts claim payloads from a web app, branch system, or CRM.
  • •Validates required fields like customer ID, account number, transaction date, claim type, and consent flags.
• •

  State model

  • •Holds the claim context across steps: raw input, extracted entities, retrieved transactions, policy checks, decision, and audit metadata.
  • •This is where LangGraph shines because state moves through explicit nodes.
• •

  Retrieval and enrichment node

  • •Pulls account history, card transactions, dispute history, KYC status, and product policy data.
  • •For banking workflows, this must be deterministic and logged.
• •

  Decisioning node

  • •Applies business rules such as eligibility windows, fraud thresholds, duplicate detection, and SLA routing.
  • •Returns approve, reject, or manual_review.
• •

  Human review handoff

  • •Escalates borderline cases to an operations queue with all evidence attached.
  • •Needed for exceptions that should not be auto-decided by an LLM.
• •

  Audit and persistence layer

  • •Writes every step to an immutable log store.
  • •Required for compliance review, internal controls, and post-incident analysis.

Implementation

1. Define the claim state and graph nodes

Use a typed state so every step has a contract. In banking systems I prefer explicit fields over free-form blobs because auditors will ask what changed and when.

import { Annotation, StateGraph } from "@langchain/langgraph";

type ClaimDecision = "approve" | "reject" | "manual_review";

const ClaimState = Annotation.Root({
  claimId: Annotation<string>(),
  customerId: Annotation<string>(),
  accountId: Annotation<string>(),
  claimType: Annotation<string>(),
  amount: Annotation<number>(),
  rawDescription: Annotation<string>(),

  transactions: Annotation<Array<{ id: string; amount: number; date: string; merchant?: string }>>(),
  policyChecks: Annotation<Record<string, boolean>>(),
  decision: Annotation<ClaimDecision>(),
  reason: Annotation<string>(),
});

type ClaimStateType = typeof ClaimState.State;

The key pattern here is that each node returns only the fields it owns. That keeps the graph traceable and makes unit testing much easier.

2. Add deterministic retrieval and policy checks

For retail banking claims you usually want hard rules before any model call. That means checking time windows, duplicate claims, card-present vs card-not-present logic, and whether the customer is even eligible.

const fetchTransactions = async (state: ClaimStateType) => {
  // Replace with your core banking / ledger integration
  const transactions = [
    { id: "tx_1", amount: 49.99, date: "2026-04-10", merchant: "GROCERY MART" },
    { id: "tx_2", amount: 120.0, date: "2026-04-11", merchant: "ONLINE STORE" },
  ];

  return { transactions };
};

const runPolicyChecks = async (state: ClaimStateType) => {
  const withinWindow = true; // e.g. dispute filed within policy window
  const underThreshold = state.amount <= 500;
  const hasMatchingTransaction = state.transactions?.some((tx) => tx.amount === state.amount) ?? false;

  return {
    policyChecks: {
      withinWindow,
      underThreshold,
      hasMatchingTransaction,
    },
  };
};

In production this node should call internal services only. Do not let the model invent transaction data or infer eligibility from untrusted text alone.

3. Add a decision node with explicit routing

LangGraph’s addConditionalEdges gives you clean branching without hiding control flow inside prompt logic. That is the right shape for regulated workflows.

const decideClaim = async (state: ClaimStateType) => {
  const checks = state.policyChecks ?? {};
  const approved =
    checks.withinWindow &&
    checks.hasMatchingTransaction &&
    checks.underThreshold;

  if (approved) {
    return {
      decision: "approve" as const,
      reason: "Policy checks passed and matching transaction found.",
    };
    }

  if (!checks.withinWindow) {
    return {
      decision: "reject" as const,
      reason: "Claim filed outside allowed dispute window.",
    };
  }

  return {
    decision: "manual_review" as const,
    reason: "Insufficient deterministic evidence for auto-decision.",
  };
};

const routeByDecision = (state: ClaimStateType) => state.decision;

4. Wire the graph and execute it

This is the actual LangGraph pattern you want in TypeScript. The graph starts at retrieval, moves through policy evaluation, then branches based on the final decision.

const graph = new StateGraph(ClaimState)
  .addNode("fetchTransactions", fetchTransactions)
  .addNode("runPolicyChecks", runPolicyChecks)
  .addNode("decideClaim", decideClaim)
  
graph.addEdge("__start__", "fetchTransactions");
graph.addEdge("fetchTransactions", "runPolicyChecks");
graph.addEdge("runPolicyChecks", "decideClaim");

graph.addConditionalEdges("decideClaim", routeByDecision, {
  approve: "__end__",
  reject: "__end__",
});

const app = graph.compile();

const result = await app.invoke({
  claimId: "clm_10001",
});

For a real claims system you would usually add a manual_review node instead of ending immediately. That node can create a case in your operations queue with evidence attached.

Production Considerations

• •

  Auditability

  • •Persist every node input/output with timestamps.
  • •Store the final decision reason separately from the raw customer narrative so compliance can reconstruct why a claim was approved or rejected.
• •

  Data residency

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.