ReviewHigh riskComparison recommended

AI Playbook for ACH Return Fraud Pattern

A community bank's operations team has seen ACH returns spike 340% in 60 days. The returns are concentrated in code R10 (customer advises unauthorized) and R29 (corporate customer advises not authorized). Forty-three business accounts are involved. The bank's per-item return threshold is at risk.

When to use this playbook

  • Use this playbook when the decision looks like the situation above: A community bank's operations team has seen ACH returns spike 340% in 60 days.
  • It is a fit when you have source files in hand and need a structured, reviewable analysis — not a generic chat answer about "ACH Return Fraud Pattern".
  • Do not use it as a substitute for licensed, legal, clinical, or authorized official judgment in the domain.

What you'll need

  • ACH transaction file (90 days, all debits and credits)
  • Return reason code log
  • Business account origination files for the 43 flagged accounts
  • NACHA return rate report
  • Originator company ID list for all debits

Attachments: Documents (Documents)

The Prompt

You are a fraud analyst investigating ACH return fraud at a community bank. I am attaching:

Work only from the attached source files. If a conclusion is not supported, say so.

Produce:
1. Identify the originator company IDs driving the R10 and R29 returns—are returns concentrated among a small number of originators?
2. For the 43 flagged business accounts, identify whether they share origination attributes (same beneficial owner, same registered agent, same IP at account opening).
3. Assess whether the return pattern is consistent with synthetic business identity fraud (accounts opened to receive credits, then dispute the debits).
4. Calculate the bank's current unauthorized return rate and how far it is from the NACHA threshold that would trigger an audit.
5. Tell me which originators to block today and what documentation I need to file a NACHA complaint.

Call out where independent models are likely to disagree, and list follow-up documents a reviewer should request.

What to expect

  • Originator risk ranking by return rate
  • Business account cluster analysis
  • Synthetic identity risk flags
  • Current vs. NACHA threshold return rate
  • Block list and complaint filing checklist

Review before you act

  • Validate this output against source files before relying on it: Identify the originator company IDs driving the R10 and R29 returns—are returns concentrated among a small number of originators?.
  • Validate this output against source files before relying on it: For the 43 flagged business accounts, identify whether they share origination attributes (same beneficial owner, same registered agent, same IP at account opening).
  • Validate this output against source files before relying on it: Assess whether the return pattern is consistent with synthetic business identity fraud (accounts opened to receive credits, then dispute the debits).
  • Validate this output against source files before relying on it: Calculate the bank's current unauthorized return rate and how far it is from the NACHA threshold that would trigger an audit.
  • Confirm every cited figure, date, counterparty, or requirement against the attached originals — models compress and can drop a qualifier.
  • Treat disagreement between models as a review item, especially on classification, materiality, and recommended next action.
  • Do not authorize an operational, clinical, legal, credit, or enforcement action solely because the models agree.

Why compare models on this

For ACH Return Fraud Pattern, running the same attachments across independent models is useful because the hard part is classification and completeness, not fluency. The workflow is already designed to surface originator risk ranking by return rate; business account cluster analysis; synthetic identity risk flags; current vs. nacha threshold return rate. Those are comparison artifacts — they only exist if more than one model runs. Typology labels (bust-out vs. first-party vs. third-party) and ring membership often diverge across models when data is incomplete. Divergence is a reason to hold and verify, not to auto-file a SAR.

Fraud DetectionPayments FraudReviewHighDocuments

See governed multi-model AI on your own prompt

Compare GPT-5, Claude, and Gemini side by side, with human review and a decision record built in.