ACH return handling

Why return is a special-case workflow

In ACH operations, “return” is not one single process. What makes it special is that the same end result (entry comes back) can be triggered by different actors, with different evidence, timing windows, and follow-up actions.

Two primary operational paths

1) Customer/Receiver-advised return (customer-triggered)

This path is initiated from the Receiver side (consumer or corporate customer) through the RDFI.

Typical cases:

• Unauthorized/no relationship claims (for example R10 context).
• Authorized relationship exists, but entry is not in accordance with authorization terms (R11 context).
• Revoked authorization and related customer-claim flows (for example R07 context).
• Corporate customer authorization dispute (R29 context).

What is special here:

• Evidence path is customer-claim-driven and often requires WSUD handling on the RDFI side for applicable unauthorized/error claims.
• Time windows can differ materially from standard admin returns (for example, 60-day windows for consumer unauthorized families).
• You must separate “authorization absent” vs “authorized but wrong execution” because remediation paths differ.

2) Operator/Bank-operations return (operator-triggered)

This path is initiated by financial-institution/operations workflows rather than a customer claim.

In practice, teams usually see this via:

• ACH Positive Pay decisioning: customer/treasury team or bank ops reviews exceptions and marks pay/return per configured controls.
• Operator/bank processing returns: returns generated from edit/processing/eligibility failures in ACH processing workflows.

What is special here:

• Trigger is operational control, not customer affidavit.
• SLA is driven by processing windows and operational cutoff controls.
• Return reason selection must align with actual processing condition; misclassification can create downstream dispute escalation.

Where dishonor/contest fits

After an initial return is sent, the flow may continue:

• Dishonored return: ODFI challenges the return itself (for allowed reasons).
• Contested dishonored return: RDFI counters the dishonor.

This is a separate sub-workflow. Keep it out of first-line retry automation until final state is resolved.

Practical samples

Sample A: Customer says “I don’t know this company”

• Trigger type: customer-triggered.
• Flow: Receiver contacts RDFI -> RDFI returns with unauthorized-family reason -> ODFI/originator investigates mandate evidence.
• Control point: do not auto-retry before classifying whether this is “no authorization” vs “execution error.”

Sample B: ACH Positive Pay exception queue

• Trigger type: operator-triggered.
• Flow: inbound debit hits bank exception rule -> reviewer chooses return in Positive Pay -> return is sent through ACH return rails.
• Control point: reviewer decision logs should capture rule hit, decision timestamp, and return reason mapping.

Sample C: Processing-side return from operational failure

• Trigger type: operator-triggered.
• Flow: item fails operational/processing criteria in ACH handling -> bank/operator sends return.
• Control point: reconcile root cause category (data/edit/process) with selected return reason before customer communication.

Sample data (illustrative) and highlight points

Original Entry (for context)
  SEC: WEB
  Transaction Code: 27
  Amount: 0000007500   (=$75.00)
  Trace Number: 081000210555111

Return Addenda (99 / return detail context)
  Return Reason Code: R10
  Original Trace: 081000210555111
  Date of Death/Incorrect Data: blank
  Addenda Information: CUSTOMER ADVISES NOT AUTHORIZED

Operator-triggered decision sample (Positive Pay workflow log)
  Exception ID: PP-2026-05-06-00421
  Rule Hit: Company ID mismatch + amount exceeds limit
  Decision: RETURN
  Selected Reason: R29 (corporate authorization dispute path in this example)
  Reviewer: ops_user_17
  Decision Time: 2026-05-06T14:22:31Z

Highlight

• Customer-triggered 与 operator-triggered 的证据源不同：前者看客户声明链路，后者看规则命中和操作日志。
• Return Reason Code 要和触发事实一致，不能“为了快”随便选码。
• 返回链路里 Original Trace 是后续 dishonor/contest 与审计闭环的核心键。
• Positive Pay 不是新 return code 体系，而是触发“是否走标准 ACH return”的决策层。

Runbook checklist

1. Classify trigger first: customer-triggered vs operator-triggered.
2. Identify whether this is initial return or downstream dishonor/contest.
3. Validate evidence pack: customer claim/WSUD path vs operational decision log path.
4. Confirm reason-code selection is consistent with trigger type and rule basis.
5. Gate retries or re-origination only after final accepted state is known.
6. Store trace-linked audit chain across original entry, return, and any follow-on entries.