Explore

Data Security: This is the way
Data Security: This is the way

A simple guide to Nacha requirements

A simple guide to Nacha requirements

Effective 2021 the National Automated Clearing House Association also referred to as NACHA is requiring an annual audit to ensure the security of financial information. This audit will focus on web debit transaction origination and customer bank information security - specifically for ACH (non-card transactions).

What are the Requirements?

Complete an annual audit conducted on your behalf, to ensure the financial information is protected by security practices and procedures. Security practices at a minimum should include an adequate level of:

physical security to protect against theft, tampering, or damage;

personnel and access controls to protect against unauthorized access and use; and

network security to ensure capture, storage, and distribution.

The document attached below outlines the minimum requirements to be NACHA compliant.

What action is required of me?

To complete this audit and provide the necessary information to ACHQ we’ve taken all this and slapped it into a nice, easy web-form for you. Right here:

Click me!⁠

⁠

Don’t rush

This is a once-per-year kind of thing. While it’s important to do it right, you have time to get there.

If you completed the Web Debit Security Audit previously, you must review your responses and visit this form to certify that no changes have been made to your organization's policies and procedures that would affect compliance with Nacha's Operating Rules and Guidelines.

Who in our organization would be best equipped to answer the questions in this audit?

Someone within your IT Department or your IT Vendor would be a great resource in answering the questions in the Web Debit Security Audit.

What if we do not have these policies or processes in place?

If you answer no to any questions in the audit or are unable to supply the document name when needed, your organization will be considered non-compliant. In this instance, ACHQ will need a remediation plan and timeline from your organization. Additionally, you can refer to the Federal Communication Commission (FCC) website for cybersecurity for small businesses. The Cybersecurity Hub was designed for businesses that lack the resources to hire a dedicated staff member to protect their business from cyber threats. FCC Cybersecurity for Small Businesses includes links to free and low-cost security tools (e.g. a Cybersecurity Tip Sheet, and Small Biz Cyber Planner) to assist small businesses to create customized cybersecurity plans.

What if no one in my organization can answer the audit questions?

If you are unable to locate anyone to complete the audit questions, please contact ACHQ compliance via email at

compliance@achq.com⁠

for additional support, a vendor may be necessary to conduct the audit. ACHQ does not endorse any vendor or company; however, Cyber Research Databank provides a resource page to find the latest trends of US Data Security companies and offers a unique an easy to navigate database with more than 5000 US Data Security vendors/companies.

What is Nacha?

Nacha was originally NACHA, an acronym for National Automated Clearing House Association. Though the acronym is no longer in official use (they go by ‘Nacha’ instead), it shows where the organization came from and the role they fill in the ACH ecosystem.

⁠

Back in the early 1970s⁠

, regional banking associations across the US joined forces to standardize processes around the development of “automated” clearing house solutions—the digital replacements for physical clearinghouses where paper checks were once exchanged. By 1974, the American Bankers Association had centralized all of those regional groups under a national sub-division that they named NACHA.

An independent organization since 1985, Nacha is effectively a non-profit consortium tasked with:

Translating federal legislation and executive rules into clear guidance for member banks and ACH network participants

Enforcing those rules for all 10,000+ member banks and network participants

Driving development and adoption of the ACH system

Acting as a trade organization (e.g., education, advocacy, roundtables, etc.)

What’s the difference between Nacha and ACH?

The Automated Clearing House (ACH) network is the American interbank funds-transferring system run by two national operators: The Clearing House and FedACH. Nacha is the governing body that oversees the ACH network. It ensures that member banks are aware of and compliant with related federal legislation, along with promoting development and education around ACH.

As for the operators that run the ACH network:

The Clearing House (also referred to as TCH or PayCo) is itself another banking consortium, with a much smaller subset of the major US banks (

currently 24⁠

). They run a system called Electronic Payments Network (EPN), which is the ACH operator for all private banks in the ACH network.

FedACH is part of the Federal Reserve system, performing the same function as EPN, for government accounts and entities, rather than private ones.

When an ACH transaction involves both a government account and a private account, the two operators work together to pass the corresponding data between themselves accordingly.

Nacha translates mandates from the US government into actionable rules and standards for The Clearing House and FedACH, which then operate their respective parts of the ACH network in accordance with Nacha’s guidance. Nacha also mediates between members and acts as an advocate for the ACH ecosystem to the larger financial industry.

What is the specific Nacha security audit guidance for WEB debits?

The minimum elements required by an annual data security audit are outlined by Section V – Standard Entry Class Codes, Chapter 48 Internet Initiated/Mobile Entries in the 2020 NACHA Operating Guidelines:

Annual Data Security Audits

Data loss or compromise not only hurts the Receiver, but can also damage a business’s reputation. Receiver trust is a key factor in building loyalty. It is in the Originator’s best interest to develop and deploy practices that protect the integrity of Receiver information and the transaction, and to ensure that these practices are audited for their effectiveness.

The Nacha Operating Rules for debit WEB transactions require Originators to conduct an annual data security audit to ensure that Receivers’ financial information is protected by security practices and procedures that ensure the financial information the Originator obtains from Receivers is protected by commercially reasonable security practices that include adequate levels of:

physical security to protect against theft, tampering, or damage,

administrative, technical, and physical access controls to protect against unauthorized access and use,

network security to ensure secure capture, transmission, storage, distribution and destruction of financial information.

While the Nacha Operating Rules only require Originators of debit WEB Entries to conduct an audit of their security practices and procedures once a year, many companies are now opting to audit these practices bi-annually or even quarterly due to the rapid change of technology and security risks. It is therefore highly recommended that Originators of debit WEB entries conduct more frequent audits.

This audit requirement can be met in several ways. It can be a component of a comprehensive internal or external audit, or it can be an independent audit that uses a commercially reasonable generally accepted security compliance program. An Originator that is already conducting an audit of these practices and procedures for another area of its business is not required to have two separate audits. However, the audit should address adequate levels of data security for the Originator’s ACH operations.

The following sections detail the minimum components that need to be audited in order to be in compliance with the audit requirement. (NOTE: In any case where these key components are not specifically required under the Nacha Operating Rules, all are recommended by Nacha as sound business practices.)

Physical security to protect against theft, tampering or damage

Critical network, server, and telecommunications equipment should be placed in physically secure locations that permit access only to authorized personnel.

Firewalls must be fully deployed with secured processes for administering those firewalls.

Firewalls must protect websites from inappropriate and unauthorized access.

Disaster recovery plans must be developed and reviewed periodically.

Personnel and access controls to protect against unauthorized access and use

A formal set of security policies and procedures must be developed that clearly outline the corporate rules governing access to sensitive financial data.

Hiring procedures should be developed that will, at a minimum, verify application information and check references on new employees that will have access to Receiver financial information.

Relevant employees must be educated on information security and company practices and their individual responsibilities.

Access controls should be in place to ensure adequate administrative, technical, and physical controls:

Limit employee access to secure areas and to documents/files that contain Receiver financial information.

Ensure that terminated employees have no access to secure information and areas.

Permit visitors only when absolutely necessary to these areas and information and ensure they are accompanied by an employee at all times.

Authenticate all access to any database containing sensitive ACH information such as financial information (e.g., passwords or passphrase, multifactor authentication such as token devices, smart cards, biometrics, or public keys).

Implement key-management procedures to require split knowledge for dual control of keys (e.g., requiring two or three people (or processes or procedures) to cooperate in gaining authorized access to a system resource (data, files, devices) – a separation of duties).

Establish policies and procedures to monitor and audit all user activity for personnel with access to Receiver information in order to detect exceptions.

Network security to ensure secure capture, transmission, storage, distribution, and destruction.

Install and maintain a firewall configuration to protect all Receiver financial information, including but not limited to the company network and databases, and portable electronic devices (e.g., employee laptops, smartphones, etc.).

Install and update anti-virus software on a regular basis.

Ensure all system components have the latest vendor-supplied security patches installed.

Change vendor-supplied defaults before installing a system on the network.

Minimize retention and/or storage of all Receiver financial information.

Develop a data retention and disposal policy and schedule to include a process (manual or automatic), to remove, at least on a quarterly basis, any unnecessary Receiver financial information. Monitor these retention schedules regularly.

Receiver financial information should only be stored permanently if it is required by law, regulation, rule, or a governing organization.

Limit distribution of Receiver financial and personal information and implement procedures and policies to govern the distribution of sensitive financial information.

Review data distribution policies and procedures periodically.

Encrypt Receiver data and financial information at all points in the transaction lifecycle from transmission to storage via a secure, electronic means that provides a commercially reasonable level of security compliant with current, applicable regulatory guidelines.

Render account numbers used in the origination and transmission of ACH transactions unreadable when stored electronically.

Regularly test security systems and processes (e.g., vulnerability scans, external and internal penetration testing, intrusion detection, file integrity monitoring).

It is important to note that for transactions that involve some use of the Internet but are not defined as WEB transactions, Originators must incorporate the security and risk management principles of the WEB rules, as applicable. For example the Originator is required to authenticate the Receiver and conduct a data security audit to ensure the Receiver’s data is stored securely.