In our previous two blogs, we’ve done a deep-dive into ACH transactions and returns in keeping with Direct Deposit and Direct Payment via ACH Month observed each May by NACHA—The Electronic Payments Association®. Some of the information we’ve covered centers on ACH transaction security—for example, how to minimize ACH returns fraud. But NACHA also has security rules you need to know about—rules that apply to merchants that process ACH transactions using Web and phone-based solutions. These solutions create entries into the ACH network or convert paper checks into ACH transactions.
According to ACH rules, “originators” of ACH transactions (i.e., merchants) must have in place a written security policy that governs the policies, procedures, and systems related to the initiation, processing, and storage of “protected information.” The rules define “protected information” as “the non-public personal information of a natural person, used to create, or contained within, an (ACH) entry and any related addenda record.” This includes financial information, as well as sensitive non-financial information (e.g., non-financial account information contained in addenda records for bill payments) and common PII data (social security number, driver’s license number, and other information that may be collected for the purpose of completing an ACH transaction).
An ACH security policy must protect the confidentiality and integrity of the protected information, as well as guard against anticipated threats or hazards to the security or integrity of the information. It must also guard against unauthorized use of protected data that could lead to “substantial harm” to an individual consumer.
The policy should also require that any full bank account numbers and bank account numbers with corresponding bank routing numbers be encrypted when stored electronically, that any paper document containing protected account data (including bank account numbers) be securely locked up when not in use; and that only employees whose job necessitates access to protected information be permitted such access. Finally, lay out procedures for validating the identity of all customers who authorize a one-time transaction or recurring payment schedule online or by telephone.
Here’s some good news: If your business is currently compliant with the PCI DSS, a hefty portion of the policy we’ve just described already exists at your organization. However, you do need to tweak it to state that customers’ bank account information is to be secured in the same way as customers’ credit card information. Additionally, incorporate a section on identity validation for telephone and Web-based ACH transactions (more on that later in this blog).
Beyond mandating the creation of an ACH transaction security policy, ACH security rules for merchants mandate that “commercially reasonable” encryption technology be used when any banking information—like customers’ bank account and bank routing numbers—is transmitted via the Internet or any other unsecured network. Tip: Use encrypted email when collecting or sending customers’ bank account or other protected information via email. Collecting protected information on your website? Implement a security certificate, and host any forms on secure (https) pages.
But there’s more. NACHA is intent on preventing fraudulent transactions and errors. Consequently, security rules dictate taking “commercially reasonable” steps to ensure the validity of routing numbers entered into the ACH network. Some merchants utilize an algorithm to see if the routing number provided for a given ACH transaction uses a valid format—and others compare the routing number against a database of all valid routing numbers. However, you may not need to worry about this particular aspect of the rules, because reputable ACH processing systems usually incorporate such validation functionality.
“Commercially reasonable” methods must be employed to verify customers’ identity before processing ACH transactions. The rules do not offer a definition of “commercially reasonable.” However, the general understanding is that it following this directive entails verifying customers’ identity as similar merchants do—but not if those merchants do nothing in this regard. NACHA guidance proposes several options here, including collecting and verifying customers’ driver’s license and/or social security numbers, engaging third-party identity verification services, or making a test deposit into customers’ accounts and asking them to confirm the amount deposited. Documenting successful authentications via user IDs, passwords, and known IP addresses also works, especially for online ACH transactions.
Additionally, there are security rules centered on Web-based ACH transactions authorized via the Internet from a traditional computer or mobile device. The rules stipulate that “commercially reasonable” methods be in place to identify fraudulent transactions and keep them from being submitted into the ACH network for processing. A reputable payment processing system will feature fraud detection functionality, including monitoring all payment pages for duplicate transactions and suspicious hacker activity.