Request for Comment on ACH Quality and Risk Management Topics
Maribel Bondoc
Manager, Network Rules
NACHA, The Electronic Payments Association
13450 Sunrise Valley Drive
Herndon, VA 20171
Dear Ms. Bondoc:
Thank you for the opportunity to comment on the recent proposal on ACH Quality and Risk Management Topics issued on May 11, 2018. The American Bankers Association appreciates your efforts to improve efficiency and lower risk in the five areas outlined in the proposal. We look forward to working with you to make payments safer for all.
The proposal seeks to improve the quality of the ACH Network by making changes in several areas of the NACHA Operating Rules (Rules). The changes include limiting the length of time allowed to refute an authorization, differentiating between types of unauthorized returns, new fraud detection requirements for WEB debits, new options for identifying suspicious transactions, and increasing the amount of information about Originator and Third-Party security levels.
ABA supports the intent behind all of the proposals. However, there are several instances where the new requirements need clarification in order to determine their effectiveness. ABA recommends that the proposal related to gathering attestations of security from Originators and Third-Parties be reconsidered entirely and re-proposed in another format due to the extreme cost of compliance outlined in the current proposal.
Proposal 1: Limit the length of time that a Receiving Depositary Financial Institution (RDFI) can make a claim against an Originating Depositary Financial Institution’s (ODFI) warranty.
Currently, there is no set time defined for a limit on how long RDFIs can make claims to ODFIs that payments were unauthorized. The ODFI authorization warranty is not defined in the ACH Operating Rules (Rules). Instead, that warranty is governed by varying state laws that can extend this to a ten year statute of limitations period.
The proposal would define the length of time allowed for RDFIs to make claims against ODFIs for unauthorized transactions.
ABA supports making this change and believes that the time periods selected are appropriate. This will remove a lingering risk for ODFIs and allow RDFIs a reasonable amount of time to submit claims.
Proposal 2: Differentiate unauthorized return reasons for Return Reason Codes R10 and R11.
Under the current Rules, Return Reason Code R10 is used for various reasons including wrong dates, wrong amounts, incomplete transactions, improperly reinitiated transactions, Originator not known, and Authorization never given. It is a catch-all for a wide range of reasons to return a transaction. These transactions may be authorized, but returned due to errors in the transmission. But, the Rules now combine unauthorized transactions in with authorized transactions with errors.The proposal would separate out transactions that are authorized with errors from those that are returned because they are unauthorized or when the Originator is not known to the Receiver. Transactions that are authorized with errors would be categorized as R11 and those the others would be categorized as R10.
ABA supports the repurposing of R11 to differentiate between the two types of return reasons. It is helpful to separate returns that are made because of errors and returns made because they are unauthorized. The repurposing of existing R11 is preferable to creating a new Return Reason Code.
This is a significant change. It would be very helpful to have a more robust description of the types of transactions that would fall into R10 and R11 and when to use them. It is important that FIs have a well-developed understanding of which transactions should fall into which category.
ABA recommends that NACHA provide a clear definition of the types of transactions that would fall into each return reason code.Proposal 3: Require account validation be part of a “commercially reasonable” fraud detection system.
Currently, Originators of WEB debit entries are required to use a “commercially reasonable” fraud detection system. The goal is to reduce fraudulent transactions from entering the network and to protect RDFIs and their customers.
The proposal would expand on the current ODFI warranties and Originator requirements by requiring that “account validation” be made part of the “commercially reasonable” fraud detection system requirement. And, it requires Originators to take additional action to screen transactions by validating account numbers when that number is first used. The proposal does not specify how this must be done, but cites ACH prenotification, ACH micro-transaction verification, and other commercially available validation services as possibilities.
The proposal goes even further by instituting a “reasonableness test.” This is intended to screen for fraudulent payments by requiring the Originators to determine if the amount of the payment is related to the purpose of the payment.
ABA supports efforts to reduce fraud of all types. However, the scope of these changes is dramatic and is not justified clearly in the proposal. The proposal states that it is apparent that some Originators are not complying with existing screening requirements. Then, this proposal goes on to add even more requirements. ABA recommends enforcing the current rules to judge their effectiveness before layering on more requirements.
In the proposal, validating accounts on their first use could be done through ACH prenotification or micro-transactions. These types of screening may cause a two to three day delay for the first transaction. This will create significant customer experience problems further associating ACH transactions with slow payments. This proposal may preclude some WEB debits from being processed as Same Day ACH transactions if prenotifications or micro- payments were used to comply with the rule.
The third example, “commercially available validation service” is not defined and will undoubtedly increase costs for ODFIs.
The second part of the proposal would institute a “reasonableness” test for ODFIs to evaluate each entry to decide if the dollar amount aligned with its purpose. This requirement is a bit perplexing. While ODFIs are required to know the business of their Originators, they do not have insight into each relationship an Originator has with their individual customers. If a customer increased their standing widget order from $5.00 to $5,000 would Originators be required to halt the transaction? Would an Originator be liable if it halted a valid transaction? Would the ODFI or the Originator be liable if they didn’t halt a fraudulent transaction?
ABA recommends that the “reasonableness” requirement be removed from consideration entirely.
Proposal 4: Allow a return for questionable activity.
Currently, RDFIs returning transactions because the account number was invalid use an administrative Return Reason Code that would not indicate that the return was “questionable.” The proposal states that this is a problem because RDFIs receiving large numbers of “questionable transactions” are not able to communicate this concern back to the ODFI.
The proposal would allow, but not require, RDFIs to use return reason code R17 when they believe a returned entry was “questionable.”
ABA supports the intent of this proposal, but not this proposal as drafted. ABA recommends that a definition for “questionable activity” be created before a rule like this be issued. ABA appreciates that this is a rule change that would be voluntary for RDFIs, but the risks of more confusion without a definition are too high.
ABA recommends that a more complete definition of “questionable activity” be provided before this is considered for a rule a change.
Proposal 5: Account Information Security
The existing ACH Security Framework established many requirements to safeguard sensitive banking information. Concerns over data breaches are addressed through requiring policies, procedures, and systems be in place to protect sensitive information.
This proposal would extend the security requirements to large non-FI Originators, Third-Party Service Providers (TPSPs) and Third-Party Senders (TPSs) to protect data that is stored electronically. This new requirement would be limited to electronic records related to account numbers used for ACH transactions. The methods for making the data unreadable are not specified but may include encryption, truncation, tokenization, and destruction. This doesn’t apply to paper records.
The proposed rule would apply to the largest Originators, TPSPs, and TSPs in June 2019 then a second phase a year later. These entities would be required to formally attest that they are compliant but ODFIs would not be required to audit or verify compliance.
ABA supports the intent of this rule proposal, but has serious concerns about the attestation requirement placed on ODFIs. ODFIs may have relationships with hundreds or thousands of TPSPs. Those TPSPs may have relationships with other ODFIs, customers, or even other TPSPs who in turn have more relationships with Originators. For example, consider the largest payroll processors that have tens of thousands of clients for whom they process transactions. Would the payroll processor’s ODFI be required to manage attestations from ten thousand businesses across the country? What is the potential penalty to the ODFI if it cannot gather all of the attestations? Must the attestations be updated annually? If so, the problems associated with this proposal are even higher.
Again, ABA supports the intent of this rule but not the proposal itself. Its potential to create an unreasonable administrative burden on ODFIs is too high. ODFIs would not be able to manage the attestation process effectively.
ABA recommends that this proposal not be adopted as drafted due to the considerable administrative burden it would place on ODFIs.
ABA would like to thank NACHA for the opportunity of responding to the Request for Comment on ACH Quality and Risk Management Topics. If you have any questions about these comments, please contact the undersigned at (202) 663-5147.
Sincerely,
Stephen K. Kenneally
