ACH Security Requirements for Merchants

Stay Compliant with NACHA PCI DSS Standards

As a merchant, you’ve probably heard about the PCI DSS (Payment Card Industry Data Security Standard), to which all companies that process credit card transactions must not only adhere, but with which they also need to annually certify compliance. However, you have likely not heard as much talk about NACHA (National Automated Clearinghouse Association) ACH security requirements because there is no official certification process for merchants associated with them.

In fact, there are a number of security requirements included in the NACHA rules for ACH processing that apply to for all businesses initiating ACH transactions (Originators in ACH parlance). These rules apply to any business that processes ACH transactions using a system that creates “entries” into the ACH network, either by converting a paper check document into an ACH transaction or by entering a customer’s bank account information to process a direct payment or direct deposit transaction. It does not include businesses that only use paper checks, or businesses that use imaging (such as snapping a picture of a paper check) applications to deposit checks with their banks.

As a small business owner, you’ll probably have an ACH merchant account if you process ACH transactions, and you’ll probably use some type of software system, provided by a third party such as PaySimple or provided directly by your bank, to process your ACH transactions (which are also referred to as “direct payments” or “e-checks”).

If you do, then the rules discussed below apply to you.

NACHA ACH Security Requirement

NACHA requires that all participants in the ACH process (including merchants initiating ACH transactions via a third party processor like PaySimple) implement processes, procedures and controls to protect sensitive ACH data (Protected Information), and to put access controls in place to safeguard Protected Information.

Secure Protected Information

The ACH Rules define “Protected Information” as, “the non-public personal information, including financial information of a natural person used to create, or contained within, an entry and any related addenda record. The definition…not only covers financial information, but also includes sensitive non-financial information (such as non-financial account information contained in addenda records for bill payments).” It also encompasses common PII information such as social security number, driver’s license number, and other personal information that might be collected in conjunction with an ACH transaction.

While the rule is primarily designed to cover information in an ACH file submitted into the system for processing, it also applies to data used to create those entries. Thus it extends to bank account and other PII information stored by merchants in third-party payment processing systems like PaySimple that are used to create new transactions, as well as any Protected Information that merchants may store on their own systems, or in paper format.

Secure Transmission

The ACH Rules require that any transmission of banking information, such as a customer’s bank account and routing number, be encrypted using “commercially reasonable” encryption technology if transmitted via an unsecured network, like the Internet. (This is similar to the PCI Requirement to use “Strong Cryptography” for transmission of cardholder data.)

This means you can’t send bank account information via regular email and you can’t enter bank account information on an insecure web form or enter it via an insecure system. Thus if you want to collect (or send) bank account information or other Protected Information from your customers via email, you should only use encrypted email. (There are a number of companies offering email encryption. A common choice is Microsoft Office 365 Message Encryption, as an add-on to an Outlook subscription. For Gmail, check out the free third-party SecureGmail application.) If you want to collect Protected Information on your website, make sure you have a security certificate in place and host your forms on secure (https) pages.

If you use a third-party software solution for transmitting ACH transactions, ensure that the company you choose has implemented their systems with the most robust and up-to-date encryption available. For example, PaySimple fully supports the most current TLS 1.2 protocol for secure browser communication and PaySimple currently uses 256-bit encryption for our web security certificates and database encryption algorithm for storing bank account and credit card numbers. This meets the NACHA requirements (as well as PCI requirements).

For additional information and guidance on ACH encryption requirements, see the NACHA publication: Understanding the Value of Encryption in the ACH Network

Routing Number Validation

As part of efforts to prevent fraudulent transactions, as well as efforts to prevent errors, NACHA requires that all Originators take “commercially reasonable” steps to ensure the validity of the routing numbers they enter into the ACH network.

This can be accomplished by using a simple algorithmic check that determines whether the routing number provided as part of a transaction uses a valid format. Another approach is to check the routing number against a database of all valid routing numbers. Typically, a small business will not need to implement this type of solution itself, as any reputable ACH processing system should include this type of validation functionality.

Identity Verification

For TEL transactions where authorization is provided verbally over the phone, and WEB transactions which are authorized by the consumer over the Internet (either on a traditional computer or a mobile device), the ACH rules require that the Originator use “commercially reasonable” methods to verify the identity of the customer prior to processing the transaction.

The reason for this added security requirement is that the only information needed to process a phone or online ACH transaction (name, address, routing #, account #) is readily available on every paper check. Unlike credit cards, there is no CVV2 code to verify that the cardholder has the card in their possession, there is no mechanism for mailing address validation like AVS used with credit card transactions, and unlike credit cards there is no database of account numbers reported stolen against which the transaction can be checked. That’s why this requirement is the one area where ACH Rules are MORE restrictive than PCI Rules.

While there is no hard definition for what is meant by a “commercially reasonable” method, it is typically understood to mean doing things similarly to others that offer similar products and services. And, doing nothing is not understood be “commercially reasonable.”

NACHA guidance suggests many robust ways to verify customer identity, such as collecting and verifying driver’s licenses and/or social security numbers, using third-party identity verification services, or having customers confirm the amount of test deposits to their accounts. Other less onerous approaches that are particularly useful for online transactions, such as documenting a successful authentication via a User ID, password, and known IP address, are also acceptable.

When selecting a payment processing system for ACH Transactions, it is important to look carefully at your options for identity validation if you are going to use it for processing WEB and TEL transactions. It is also important to ensure that if identity validation is not included, that you take independent steps to ensure that you are adhering to the ACH Rules when you accept transactions—regardless of what a software system permits you to do.

For example, a system may enable you to enter a TEL transaction even if it does not include an identity validation feature. The system assumes that you have validated identity prior to submitting the ACH transaction for processing.

Online “Guest” credit card transactions, where customers enter orders without registering for an account or completing any other type of identity validation, are quite common. However, most systems will not permit processing of “guest” ACH transactions where there is no identity validation mechanism. (See WEB Proof of Authorization Industry Practices from NACHA for more information.)

While the identity validation requirements may seem onerous, they are in place to protect both businesses and consumers. A strong “know your customer” policy is not only essential to preventing becoming a victim of fraud, it is also just good business all around.

Fraud Detection

For WEB transactions which are authorized by the consumer over the Internet (either on a traditional computer or a mobile device), the ACH rules require that the Originator use “commercially reasonable” methods to identify fraudulent transactions so that they are not submitted into the ACH network for processing.

This is another place where it is important to choose a payment processing system that includes robust fraud detection functionality. It should hit the basics like monitoring all payment pages for duplicate transactions and suspicious activity such as a hacker trying to use a payment form to test multiple stolen account numbers in order to identify valid ones. More complex systems also implement monitoring algorithms designed specifically to identify fraudulent transaction processing patterns.

Implement a Strong Security Policy

The ACH Rules require that each Originator implement a written security policy that governs processes, procedures, and systems related to the “initiation, processing and storage” of Protected Information. These policies must:

• Protect the confidentiality and integrity of Protected Information.
• Protect against anticipated threats or hazards to the security or integrity of Protected Information.
• Protect against unauthorized use of Protected Information that could result in substantial harm to a natural person (a consumer).

The policies and procedures required to secure Protected Information are similar to those required under the PCI DSS to secure and protect cardholder data. If your small business is currently PCI Compliant, you likely have most of the right policies in place already. Simply update your policy to state that bank account information is to be secured in the exact same manner as credit card account information, and include a section on identity validation for TEL and WEB transactions.

If your company processes only ACH transactions, you should create a set of policies and procedures that meet all of the above security requirements, as well as address access controls and secure storage of all Protected Information. Key components of this policy should be:

• Ensuring that the third party payment processing system you use is compliant with all the ACH security rules. (PaySimple is!)
• A requirement to encrypt ANY electronic storage of full bank account numbers, or bank account numbers in conjunction with routing numbers.
• A requirement that any paper document containing Protected Information (including bank account numbers) must be kept in a secure location (locked file drawer/safe) when not in use.
• A requirement that only employees with a business need should have access to Protected Information.
• Documented “know your customer” procedures for identity validation of all customers authorizing one-time transactions or recurring payment schedules over the phone (TEL) or online (WEB).

While designed specifically for PaySimple merchants tackling PCI Compliance, this sample security policy is a great starting place for any small business implementing their first security policy for NACHA ACH Security Compliance, PCI DSS Compliance, or both.

Visit PaySimple.com to learn more or start your free trial today:
Start My Free Trial