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

Payments fraud teams are drowning in volume, not intelligence. The real problem is not “detecting fraud” in the abstract; it is triaging millions of authorization events, chargeback signals, device fingerprints, and merchant patterns fast enough to stop losses without freezing good customers.

Multi-agent systems built with LangChain fit this problem because fraud work is naturally decomposed: one agent scores risk, another pulls historical context, another checks policy and regulatory constraints, and a supervisor agent decides whether to approve, step-up authenticate, hold, or escalate.

The Business Case

• •A mid-size payments processor handling 20M–50M monthly transactions can cut manual fraud review by 30%–50% by automating first-pass triage on low- and medium-risk cases.
• •If your analysts spend 5–10 minutes per suspicious transaction and review 15,000 cases per month, automation can save 1,250–2,500 analyst hours monthly. That is usually 2–4 FTEs worth of capacity.
• •False positives are expensive in payments. Reducing unnecessary declines by just 0.2%–0.5% on legitimate auths can recover meaningful revenue, especially for card-not-present merchants where approval rates are margin-sensitive.
• •Chargeback exposure moves fast. A system that flags suspicious patterns within sub-second to 2-second decision windows can reduce loss leakage on high-risk flows like card testing, account takeover, promo abuse, and synthetic identity attacks.
• •Operationally, a well-scoped pilot can be built with a 4–6 person team over 8–12 weeks: one payments engineer, one ML/AI engineer, one data engineer, one fraud ops lead, plus security/compliance support.

Architecture

A production setup should not be “an LLM decides fraud.” That is how you get compliance incidents and bad approvals. Build a multi-agent workflow with hard controls around data access and decisioning.

• •

  Event ingestion layer

  • •Streams auths, captures, refunds, chargebacks, login events, device telemetry, merchant metadata.
  • •Common stack: Kafka or Kinesis feeding a feature service.
  • •Normalize payment objects: PAN tokens, BIN country, AVS/CVV results, 3DS outcome, velocity counts, merchant category code (MCC), IP geolocation.
• •

  Agent orchestration layer

  • •Use LangGraph for deterministic agent flow instead of free-form agent wandering.
  • •Example agents:
    • •Risk scoring agent: summarizes model scores and rule hits.
    • •Context retrieval agent: fetches prior disputes, linked accounts, merchant history.
    • •Policy agent: checks internal controls and regulatory rules.
    • •Decision agent: recommends approve / step-up / hold / decline / manual review.
  • •Keep the final action behind policy gates; the LLM should recommend, not directly execute high-impact actions.
• •

  Retrieval and memory layer

  • •Store prior fraud cases, playbooks, merchant notes, and investigation outcomes in pgvector or a managed vector store.
  • •Add structured retrieval from Postgres for deterministic facts like velocity thresholds and risk bands.
  • •This matters because fraud analysts rely on precedent: “same device as a prior mule account,” “same BIN as a known card-testing burst,” “merchant has elevated refund ratio.”
• •

  Controls and observability layer

  • •Log every prompt input/output pair with redaction of PANs and PII.
  • •Track precision/recall by segment: CNP vs CP transactions, geo corridors, MCCs.
  • •Add human-in-the-loop queues for edge cases above threshold.
  • •Integrate with SIEM and case management tools so SOC 2 evidence and audit trails are available.

A practical stack looks like this:

What Can Go Wrong

• •

  Regulatory risk

  • •Payments teams often touch PCI DSS data; some also process data covered by GDPR, regional privacy laws, or banking oversight tied to Basel III operational risk expectations.
  • •If your agents ingest customer communications or identity data from adjacent products like lending or healthcare-linked benefits cards, you may also intersect with frameworks such as HIPAA or stricter retention rules.
  • •Mitigation:
    • •Tokenize PANs and redact PII before LLM calls.
    • •Keep the LLM out of raw cardholder data whenever possible.
    • •Maintain data lineage and retention policies aligned to GDPR deletion rights and internal audit requirements.
• •

  Reputation risk

  • •Overblocking legitimate transactions damages approval rates and merchant trust faster than most teams expect.
  • •In payments, bad declines show up immediately as customer complaints and lost volume from merchants who compare auth rates daily.
  • •Mitigation:
    • •Start with recommendation-only mode for 4–6 weeks.
    • •Set guardrails by segment: e.g., never auto-decline above a defined revenue tier without human review.
    • •Measure false positives separately for high-LTV merchants versus long-tail merchants.
• •

  Operational risk

  • •Multi-agent systems can drift into inconsistent decisions if prompts change without version control or if retrieval returns stale cases.
  • •In production that means noisy alerts at best and broken auth flows at worst.
  • •Mitigation:
    • •Version prompts like code.
    • •Use LangGraph state machines with explicit transitions.
    • •Backtest against historical fraud labels before every release.
    • •Put rollback hooks in place so the rules engine can take over instantly if agent latency spikes.

Getting Started

1. •

   Pick one narrow use case

   • •Start with card-not-present fraud triage for e-commerce auths or account takeover on wallet logins.
   • •Avoid trying to solve chargebacks, AML alerts, merchant underwriting, and promo abuse in the same pilot.
2. •

   Define the decision boundary

   • •Decide exactly what the agents can do:
     • •Recommend manual review
     • •Trigger step-up authentication
     • •Surface evidence to an analyst
   • •Do not let the first version directly decline high-value transactions without human approval.
3. •

   Build a shadow-mode pilot

   • •Run for 6–8 weeks alongside your existing fraud stack.
   • •Compare agent recommendations against analyst decisions and actual outcomes like chargebacks within a rolling window.
   • •Target metrics:
     • •Analyst time saved
     • •False positive reduction
     • •Chargeback rate stability
     • •Latency under your auth SLA
4. •

   Staff it lean

   Core team:

   One payments domain lead
   One AI/ML engineer
   One backend engineer
   One data engineer
   One fraud operations SME
   

   - Add security/compliance reviewers part-time for PCI DSS/GDPR/SOC 2 signoff

   If the pilot works, expand into merchant-level anomaly detection, refund abuse, synthetic identity, then cross-channel risk scoring

The right target is not “replace the fraud team.” It is to turn analysts into exception handlers while agents do the repetitive correlation work at machine speed. In payments, that is where the ROI lives: faster decisions, fewer false declines, and better containment of real fraud before it turns into chargebacks.

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.