ACH Network Credit Return Threshold 

Should the Nacha Operating Rules establish a return rate threshold specific to ACH credits? 

The current return rate threshold rules cover ACH debit returns for the following categories of reasons: 

• Unauthorized.
• Administrative. 
• Overall. 

Newer types of fraud often result in the use of credit payments, including ACH credits. 

• Potentially, a rule could establish a return rate threshold for administrative returns of ACH credits, similar to the debit return rate threshold of 3.0%. 
• ACH credits returned for administrative reasons (account closed, account not found) impose similar burdens on RDFIs as administrative debit returns. 
• While some successful credit-push frauds don’t have returns to monitor, the monitoring of credit returns could be helpful in identifying fraud scenarios that result in excess administrative returns. 

• For example, indiscriminate use of Micro-Entries to “phish” for open accounts.   

Define and Apply Rules to “Third-Party Receivers” 

• As ACH processing scenarios have proliferated, so have parties to an ACH payment. 

• On the origination side, a Third-Party Sender is an intermediary between an Originator and ODFI that do not have an ACH agreement with each other. 

• In a similar way, are there “Third-Party Receivers” in ACH payments that act as intermediaries between Receivers and RDFIs that do not have ACH or account agreements with each other? 

Should the Nacha Operating Rules: 

Acknowledge and define a Third-Party Receiver? 

Apply the Rules to Third-Party Receiver relationships, through Rules language and ACH agreements between the parties? 

Place RDFI obligations on Third-Party Receivers, in an analogous way that TPS rules place ODFI obligations on TPs? Such as: 

• Rules compliance audits. 
• ACH risk assessments. 
• ACH data security requirements. 
• Funds availability requirements. 
• Obligation to accept consumer WSUDs. 
• Commercially reasonable fraud detection (if approved) 

Risk-Based Approach to Early Funds Availability 

Should the Nacha Operating Rules incorporate a risk-based approach to early funds availability when RDFIs provide it?

• Providing early funds availability would not be required, but RDFIs that do provide it would need to conduct a risk assessment.

A risk-based approach could identify eligibility and ineligibility for early funds availability based on risk factors, such as:

• Account type- such as consumer vs. non-consumer and other account types.
• Account longevity – limiting or prohibiting early funds availability for new accounts.
• Limits on new transactions – limiting or prohibiting early funds availability for a new transaction purpose (e.g., first payroll, first account transfer).
• Dollar limits – limiting early funds availability to certain dollar amounts, similar to ATM, RDC, and P2P dollar limits.
• SEC Codes – identifying eligibility for consumers vs. non-consumers; and limiting or prohibiting for a mismatch of SEC Code type and account type, especially a business-to-business code (CCD, CTX) to a consumer account.
• Volume and velocity checks – such as abnormal volume or velocity of credit payments to an account, e.g., multiple new payroll or benefit payments or from multiple new sources.
• Reversal risk – Assessing the risk that a credit will be reversed, and what the RDFI would do in such a case.
• Settlement risk – Assessing the risk that the credit will not settle, and what the RDFI would do in such a case.

A risk-based approach could also encompass the establishment of policies, procedures and systems to assess risk, enforce eligibility/ineligibility, and report anomalies and violations.

NOC for SEC Code/Account Type Mismatch 

Should the Nacha Operating Rules include a new Notification of Change (NOC) to enable an RDFI to communicate to the ODFI that an ACH entry bears an SEC Code that does not match the account type at the RDFI? For example, a CCD credit to a consumer account, or a WEB debit to a non-consumer account. 

Currently, other NOCs enable communication of other types of mismatches: 

• Incorrect transaction code (e.g., deposit account vs. savings account).
• Incorrect SEC Code for outbound international payment. 

Also, return reason code R05 enables the return as unauthorized of a CCD or CTX debit to a consumer account. 

Would a new “SEC Code/Account type” mismatch Change Code, such as C10, be useful in correcting errors, and in alerting ODFIs and Originators to potential cases of fraud? For example:

• A BEC or impersonation fraud in which funds are sent by a CCD credit to a consumer mule account. 
• Fraudulent use of a businesses banking account information, resulting in unauthorized WEB debits to a non-consumer account. 

Currently, NOCs provide corrected information to the Originator for use in future Entries. For an SEC Code/account type mismatch, however, the RDFI would not be in a position to provide a correct SEC Code. As a result, the warranties provided by an RDFI to an ODFI for such a hypothetical NOC would necessarily be different from those attached to existing NOCs.