AI Agents for payments: How to Automate fraud detection (multi-agent with LangGraph)

Fraud teams in payments are drowning in alerts, false positives, and manual review queues. The real problem is not just detecting bad transactions; it is doing it fast enough to stop loss without freezing legitimate card-not-present traffic, ACH transfers, or wallet payments.

Multi-agent systems with LangGraph fit well here because fraud detection is not one decision. You need separate agents for transaction risk scoring, customer history lookup, sanctions screening, case summarization, and policy enforcement, then a controlled workflow that decides whether to approve, step-up authenticate, hold for review, or decline.

The Business Case

• •

  Reduce manual review volume by 30-50%

  • •In a mid-size payments company processing 5-10 million monthly transactions, rule-only systems often push 15-25k alerts into analyst queues.
  • •A multi-agent layer can pre-triage low-risk cases and summarize evidence, cutting analyst workload by 1,500-3,000 hours per month.
• •

  Lower false positives by 10-20%

  • •Payments teams usually see false-positive rates around 3-8% depending on segment and geography.
  • •Better context retrieval from customer behavior, device fingerprinting, velocity patterns, and merchant history reduces good-customer declines and chargeback friction.
• •

  Cut fraud investigation time from minutes to seconds

  • •A manual case review can take 8-15 minutes when analysts jump across transaction logs, CRM notes, KYC data, and prior disputes.
  • •An agentic workflow can assemble the same evidence in under 5 seconds and hand the analyst a structured summary.
• •

  Reduce fraud loss and ops cost together

  • •For a processor losing $2M-$10M annually to first-party fraud, account takeover, and card testing attacks, even a 5-10% reduction in net fraud loss matters.
  • •At the same time, you can avoid adding headcount as payment volume grows. One fraud ops team of 6-10 people can often support materially more throughput with automation.

Architecture

A production setup should be boring in the right places: deterministic routing, auditable outputs, and clear human override points. I would build it as four components:

• •

  Event ingestion and feature assembly

  • •Stream auth events, chargebacks, dispute signals, device data, IP reputation, merchant metadata, and KYC/KYB attributes into Kafka or Kinesis.
  • •Normalize features in a warehouse or feature store so agents do not query raw systems directly for every decision.
• •

  Agent orchestration with LangGraph

  • •Use LangGraph to model the fraud workflow as a state machine:
    • •Risk scoring agent
    • •Retrieval agent
    • •Policy/compliance agent
    • •Case summarization agent
    • •Decision router
  • •LangChain handles tool calling and model integration; LangGraph controls branching logic and retries.
• •

  Retrieval layer for evidence

  • •Store prior cases, SAR-style internal notes where applicable, policy docs, merchant risk playbooks, and typology examples in pgvector or another vector store.
  • •This lets the system retrieve similar fraud patterns like card testing bursts, mule-account behavior, refund abuse, or triangulation fraud.
• •

  Decisioning and audit layer

  • •Write every agent action to an immutable log with inputs, retrieved evidence IDs, model version, prompt version, and final decision.
  • •Expose outputs to your case management system so analysts can approve holds or escalate suspicious activity reports through existing workflows.

For regulated payments environments under PCI DSS and SOC 2 controls, keep PII access tightly scoped. If you operate across the EU or UK market segments involving GDPR data subjects or financial institutions subject to Basel III-aligned risk governance practices internally, your logging strategy must support retention limits, access reviews, and explainability.

What Can Go Wrong

• •

  Regulatory risk

  • •If an agent makes decisions using personal data without proper controls, you can run into GDPR issues around automated decision-making and data minimization.
  • •Mitigation: keep the final decision policy-based where possible; use agents for evidence gathering and recommendation only. Add human review thresholds for high-impact declines or account freezes.
• •

  Reputation risk

  • •False declines hit revenue fast. In payments this shows up as abandoned checkouts, merchant complaints on recurring billing failures, and elevated support tickets.
  • •Mitigation: set strict approval/decline thresholds during pilot mode. Start with “shadow mode” so agents score transactions without affecting production decisions for at least 4-6 weeks.
• •

  Operational risk

  • •Agents that call too many tools or produce inconsistent summaries will slow analysts down instead of helping them.
  • •Mitigation: limit each agent’s scope. One agent retrieves facts; another classifies typology; another drafts the case note. Use deterministic prompts with schema validation so outputs are machine-readable.

Getting Started

1. •

   Pick one narrow use case first

   • •Start with one high-volume fraud pattern: card testing on e-commerce auths, account takeover on wallet top-ups, or refund abuse on merchants with high dispute rates.
   • •Do not try to automate all fraud types at once.
2. •

   Build a shadow pilot in 6-8 weeks

   • •Use a team of 4-6 people:
     • •Fraud product owner
     • •Backend engineer
     • •Data engineer
     • •ML/AI engineer
     • •Compliance reviewer
     • •Analyst SME part-time
   • •Run the agent workflow in parallel with existing rules and compare precision/recall against analyst outcomes.
3. •

   Define hard guardrails before production

   • •Set thresholds for auto-approve, auto-hold, step-up authentication, manual review, decline.
   • •Encode these policies outside the model so business rules do not drift when prompts change.
4. •

   Measure what finance cares about

   • •Track:
     • •False positive rate
     • •Fraud loss rate per $1M processed
     • •Average handle time per case
     • •Review queue size
     • •Chargeback ratio
   • •If you cannot show improvement after one quarter of live traffic on a limited segment like SMB merchants or one geography such as EMEA cards-not-present traffic,

stop expanding scope until you can.

The pattern works when you treat agents as investigators inside a controlled workflow, not autonomous decision-makers. In payments fraud detection that distinction matters: you want faster evidence collection and better triage without giving up auditability under SOC 2 expectations or regulatory scrutiny.

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.