ACH Credit Risk Management Topics:

Expand Commercially Reasonable Fraud Detection
This proposal would require each non-Consumer Originator, ODFI, Third-Party Service Provider, and Third-Party Sender to establish and implement a commercially reasonable fraudulent transaction detection system with respect to its ACH Entries.

• The proposal is intended to reduce the incidence of successful fraud attempts.
• Regular fraud detection monitoring can establish baselines of typical activity, making atypical activity easier to identify

RDFI Credit Transaction Monitoring
The proposal would require RDFIs to establish Commercially Reasonable Fraud Detection Systems that monitor their received ACH credit transactions.

• RDFIs have a view of incoming transactions as well as account profile information and historic activity on Receivers’ accounts. 
• A commercially reasonable, risk-based approach to monitoring can consider factors such as transactional velocity, anomalies (e.g., SEC Code mismatch with account type), and account characteristics (e.g., age of account, average balance, etc.). This aligns with AML monitoring practices in place today. 
• Based on its monitoring of incoming credits, an RDFI may decide to post a transaction, return an entry, or contact the ODFI to determine the validity of a transaction.

This proposal is intended to reduce the incidence of successful fraud and better enable the recovery of funds when fraud has occurred.

• The proposal aligns with an institution’s regulatory obligation to monitor for suspicious transactions.

Expand Use of Return Reason Code R17
This proposal would explicitly allow, but not require, an RDFI to use R17 to return an entry that it thinks is fraudulent.

• Such use is optional and at the discretion of the RDFI.
• The proposal retains the current requirement to include the descriptor QUESTIONABLE in the return addenda record for such use.
• The proposal is intended to improve the recovery of funds originated due to fraud.

Expand Use of Reversals for Fraud Recovery
The proposal would explicitly allow reversals for use with fraudulently-originated credits and credits transmitted without the authorization of the Originator

• It is likely that some reversals are being used in this manner already.

The proposal is intended to improve the recovery of funds when a fraud has occurred.

This proposal would not change other permissible reasons for a reversal, nor the language that reasons other than those excplicitly listed are not permitted.

The proposal would also require that a reversal used to attempt to recover from fraud use a distinct Company Entry Description to differentiate it from standard reversals for errors. 

Reversals for fraud would use the standard description “REVERSALFR.” 

• Adding “FR” to the end of the description “REVERSAL” differentiates reversals for fraud from reversals for errors.  
• The description is similar in intent to messages in instant payment systems requesting the return of funds that use a reason code of “FRAD.” 
• Providing this indicator in a Batch Header Record field would enable reporting on these transactions. 

In addition, this proposal also includes an expansion to the ability of an ODFI to request a return from the RDFI. 

• Historically, the permissible reasons that an ODFI can request a return tracked closely to the reasons allowed for a reversal (i.e., to correct errors). One existing distinction between reversal and ODFI requests for return occurs when a request for return attempts to recover for credits transmitted without the Originator’s authorization. 
• It is likely that in practice, ODFI requests for return encompass other reasons. 

The proposal would expand the ODFI request for a return so that an ODFI could request a return from an RDFI for any reason. 

• The ODFI would still indemnify the RDFI for compliance with the request.
• Compliance by the RDFI would remain optional.
• An RDFI’s only obligation to the ODFI would be to promptly respond to the ODFI’s request. 
• This proposal is intended to improve the recovery of funds when fraud has occurred. 

Additional Exemption to Funds Availability Requirements
This proposal would provide RDFIs with an additional exemption to include credit entries that the RDFI suspects are originated as a part of a fraud scheme or fraud event.

• The additional exemption provides RDFIs with a tool under the Rules regarding entries identified as questionable.
• RDFIs are still subject to requirements under Regulation CC for funds availability.
• The proposal is intended to improve the recovery of funds when fraud has occurred.
• The proposal is not intended to otherwise alter an RDFI’s obligation to promptly make funds available as required by the Rules.

Standard Company Entry Descriptions
This proposal would establish two new standard descriptions for specific payment purposes. 

1. For PPD Credits for payment of wages, salaries and similar types of compensation, the Company Entry Description field must contain the description PAYROLL.

• RDFIs that monitor inbound ACH credits would have better information regarding new or multiple payroll payments to an account.
• A standard description for payroll payments can help support RDFI logic to provide or suppress early funds availability.
• The proposal is intended to reduce the incidence of fraud involving payroll redirections.

2. For e-commerce purchases, the Company Entry Description field must contain the description PURCHASE.

• For this purpose, an e-commerce purchase is a debit Entry authorized by a consumer Receiver for the online purchase of goods or services.  An e-commerce purchase uses the WEB debit SEC Code, except as permitted by the rule on Standing Authorization to use the PPD or TEL debit SEC Code.
  • ACH purchases at the point-of-sale would continue to use the POS SEC Code which carries terminal information.
• A standard description for e-commerce purchases would enable ODFIs and RDFIs to track volume and other metrics related to transaction quality for this payment purpose (e.g., disputes, returns) and potentially apply additional processing logic
• The proposal is intended to improve ACH transaction quality.

Standard Use of Individual Name Field
This proposal would standardize the formatting for the Individual Name field for consumer names.

• Generally, the standard format would be: last name, first name, middle name or initial.
• Examples are shown on slide slide #36 within the full slide deck. 
• The proposal is intended to reduce the incidence of fraud and to improve the recovery of funds.

This proposal does not seek to require RDFIs to perform name matching when handling received ACH Entries and does not seek to require name matching for the origination of ACH payments.

• Standard formatting, however, can support logic to identify the individual by RDFIs choosing to reconcile against the name of the account owner, and can otherwise help improve name-matching capabilities.
• A standardized format may also permit RDFIs to better identify when an account is receiving entries for multiple receivers who may not be named on the account.
  • This activity may be indicative of a party acting as a “mule” in a fraud scheme.

ACH Debit Risk Management Topics

Timing of Written Statement of Unauthorized Debit
This proposal would allow a WSUD to be signed and dated by the Receiver on or after the date on which the Entry is presented to the Receiver (either by posting to the account or by notice of a pending transaction), even if the debit has not yet been posted to the account.

• Through digital notifications and alerts, a consumer may be able to report an unauthorized debit prior to the debit posting to his or her account.
• Allowing such a debit to post after being reported may cause harm to the Receiver.

This proposal is intended to improve the process and experience when debits are claimed to be unauthorized.

The proposal does not otherwise change the requirement for an RDFI to obtain a consumer’s WSUD.

RDFI Must Promptly Return Unauthorized Debit
This proposal would require that when returning a debit as unauthorized, the RDFI must do so promptly upon receiving a consumer’s completed WSUD.

• The proposal is intended to improve the recovery of funds and reduce the incidence of future fraud.
• The prompt return of an unauthorized debit alerts an ODFI and an Originator to a potential problem.
• This is also true in first-party fraud schemes in which the party who disputes the debit Entry is the same party who benefits from the original entry.
• A prompt return supports controls that an Originator may have enabled, such as a hold on funds or delayed shipment of merchandise.
• This proposal would not change reasons or requirements for obtaining a Written Statement of Unauthorized Debit.