Supplementing Data Security Requirements
This rule supplements previous ACH Security Framework data protection requirements by explicitly requiring large, non-FI Originators, Third-Party Service Providers (TPSPs) and Third-Party Senders (TPSs) to protect deposit account information by rendering it unreadable when it is stored electronically.
Beginning June 30, 2022, this rule applies to those with ACH volume of 2 million transactions or greater annually.
Details
In response to requests from some covered parties in 2020 for additional time to come into compliance with the Rule requirements, Nacha extended each of the two effective dates by one year; Phase 1 of the Rule, which applies to ACH Originators and Third-Parties with more than 6 million ACH payments annually, became effective on June 30, 2021, and Phase 2 of the Rule, which applies to ACH Originators and Third-Parties with more than 2 million ACH payments annually, became effective on June 30, 2022.
This effective date was affirmed in ACH Operations Bulletin #7-2020. Nacha will not enforce this rule for an additional period of one year from the effective date with respect to covered entities that are working in good faith toward compliance, but that require additional time to implement solutions. This applies to both phases of this rule. Nacha strongly encourages all such covered entities to work towards compliance as soon as possible.
Technical
This Rule modifies the following areas of the Nacha Operating Rules:
Article One, Section 1.6 (Security Requirements) to require each Non-Consumer Originator that is not a Participating DFI, each Third-Party Service Provider, and each Third-Party Sender, whose ACH Origination or Transmission volume exceeds 2 million Entries annually to protect DFI Account Numbers used in the initiation of Entries by rendering them unreadable when stored electronically.
The Rules are neutral as to the methods/technologies that may be used to render data unreadable while stored at rest electronically. Encryption, truncation, tokenization, destruction, or having the financial institution store, host, or tokenize the account numbers, are among options for Originators and Third-Parties to consider.
Impact
Effective Date: Phase 2 – June 30, 2022 for Originators and Third-Parties with ACH volume greater than 2 million in 2020.
Parties that reach 2 million or more ACH payments beginning 2022 ad any year thereafter have until June 30 of the following year to come into compliance with the Rule.
Potential Impacts:
- Implementation for those Originators and Third-Parties that currently would not be compliant
- For ODFIs, informing Originators of their direct compliance obligations
FAQs Section
Which parties are subject to the new Data Security Requirement to protect account numbers used for ACH purposes by rendering them unreadable when stored electronically?
The new requirement applies to non-consumer Originators that are not Participating Depository Financial Institutions (as defined by the Nacha Operating Rules), and to Third-Party Senders and Third-Party Service Providers that perform any function of ACH processing on behalf of an Originator, Third-Party Sender, ODFI, RDFI, or ACH Operator.
Financial institutions are not included within the scope of the new requirement to render ACH account numbers unreadable when stored electronically because they are already subject to rigorous data security requirements imposed by their regulators.
The Payment Card Industry Data Security Standard (PCI DSS) and the National Institute of Standards and Technology’s (NIST) Cybersecurity Framework (“the NIST Framework”) both have the shared objective of strengthening data security. The PCI Security Standards Council (PCI SSC) recently updated its document entitled “Mapping PCI DSS v3.2.1 to the NIST Cybersecurity Framework v1.1,” which provides industry users with guidance on data security standards that meet objectives in both PCI DSS and the NIST Framework.
Is a third-party vendor whose function is to operate a financial institution’s core processing system (i.e., DDA and savings posting systems) subject to the new data security requirements?
No. A financial institution’s third-party vendor whose function is to operate the financial institution’s core processing system (i.e., DDA and savings posting system) is not subject to the new rule. However, if that same third-party vendor also performs any function of ACH processing, such as running the FI’s ACH platform, the vendor would meet the definition of a Third-Party Service Provider under the Nacha Operating Rules and therefore would be subject to the requirements of the new rule for that function to render ACH-related account numbers unreadable while stored at rest.
Must all parties subject to the new data security requirements be in compliance by June 30, 2021?
No. This rule focuses initially on large-volume third parties and non-financial-institution Originators, and will be implemented in phases.
Phase One
Any non-financial-institution Originator whose total ACH origination volume exceeds 6 million entries in calendar year 2019 will be required to comply with this rule no later than June 30, 2021. Any Third-Party Sender or Third-Party Service Provider whose total transmission volume (that is, the aggregate volume transmitted on behalf of ALL of its clients) exceeds 6 million entries in calendar year 2019 must comply with this rule no later than June 30, 2021.
Phase Two
Beginning in calendar year 2020, the annual volume threshold will be reduced to 2 million entries. Any non-financial-institution Originator whose total ACH origination volume exceeds 2 million entries in calendar year 2020 will be required to comply with this rule no later than June 30, 2022. Any Third-Party Sender or Third-Party Service Provider whose total transmission volume (that is, the aggregate volume transmitted on behalf of ALL of its clients) exceeds 2 million entries in calendar year 2020 must comply with this rule no later than June 30, 2022.
How does the rule apply once fully implemented?
Any non-financial-institution Originator, Third-Party Sender, or Third-Party Service Provider that meets the 2-million-entry annual origination/transmission volume threshold in calendar year 2020 or beyond will be required to comply with this rule by June 30 of the year following the calendar year in which the 2 million-entry volume threshold was met.
When an Originator initiates entries through multiple accounts at one ODFI, or uses multiple ODFIs, how do the thresholds apply?
A Non-Consumer ACH Originator that originates ACH entries through multiple settlement accounts at one ODFI, or originates ACH entries through multiple ODFIs, should consider its total, combined origination volume when determining whether it meets the 6-million/2-million-entry thresholds.
When a TPSP or TPS initiates entries on behalf of multiple clients, is the 6M/2M-entry threshold based on the TPSP/TPS’s aggregate volume of entries transmitted for all of its clients, or is it based on each Originator’s volume separately?
A Third-Party Service Provider or a Third-Party Sender must consider the combined volume of entries processed for all of its various clients when determining if it meets the annual 6 million/2 million volume thresholds. These thresholds are not client-specific. TPSPs/TPSs who originate and/or transmit ACH entries through multiple settlement accounts and/or multiple financial institutions should take volume from all ACH entries they originate/transmit into consideration when determining if they exceed the thresholds.
How does this rule impact non-financial-institution Originators and Third-Parties with volumes below the threshold?
Non-financial-institution Originators, Third-Party Senders, and Third-Party Service Providers that do not meet these thresholds are currently not mandated by the Rules to render ACH account information stored electronically unreadable while at rest. Nevertheless, NACHA strongly encourages voluntary adoption of this data security standards as a sound business practice.
Does the new rule to render account information unreadable apply to consumer accounts only, non-consumer accounts only, or both?
Both. If an account number is used for ANY ACH payment (consumer or corporate), it must be rendered unreadable while stored electronically.
Does the requirement to render ACH account numbers unreadable apply only to systems where transactions can be created, or does it extend to other systems within the organization?
Any place where account numbers related to ACH entries are stored is in scope. This includes systems on which authorizations are obtained or stored electronically, as well as databases or systems platforms that support ACH entries. As an example, for a Third-Party Service Provider whose client is a financial institution, these can include platforms that service ACH transaction warehousing and posting, and client information reporting systems. For Originators and their Third-Party Service Providers, accounts payables and accounts receivables systems will be impacted, as may be other systems (for example, claims management systems for insurance companies).
We have scanned our paper authorizations and ACH records into our database for easier storage. Does the new rule apply to the scanned documents even though the same documents in paper form would not be covered?
Yes. Although the new rule does not apply to the storage of ACH account information in physical, paper form, the requirement to render the account information unreadable DOES apply if these paper authorizations or other documents containing ACH account numbers are scanned for electronic record retention and storage purposes.
Do the NACHA Operating Rules prescribe the specific manner in which data at rest must be rendered unreadable?
No. The Rules are neutral as to the methods/technologies that may be used to render data unreadable while stored at rest electronically. Encryption, truncation, tokenization, destruction, or having the financial institution store, host, or tokenize the account numbers, are among options for Originators and Third-Parties to consider, but each Originator or TPSP will need to make its own business decision in consultation with its legal counsel and technology providers.
Our electronic documents are stored on platforms that are not encrypted, but access is restricted by access controls– e.g., passwords, etc. Data is not accessible except to those with proper credentials. Does this comply with the new rule requirement?
No. Although access controls such as passwords help to secure ACH-related data at rest, these do not meet the new standard. Even with the use of various physical security controls and restricted access, the electronic data at rest still must be rendered unreadable.
If we apply PCI data security standards to all systems or platforms on which account numbers used in ACH entries reside, are we compliant with the requirements to render the information unreadable while stored electronically at rest?
Yes, PCI DSS includes specific requirements related to protecting data while at rest. Utilizing one of these prescribed methods of data protection for ACH-related account numbers, in such a manner as to be compliant with the standard, should meet the commercially reasonable requirement for this Rule.
Do we need to apply all PCI standards to our ACH-related account numbers to be compliant with the Supplementing Data Security Rule?
No. The ACH Security Framework, first implemented in 2013, includes data security rules beyond data at rest that also utilize the commercially reasonable standard. Utilizing PCI DSS standards may be a best practice when adhering to those Rules. However, the Supplementing Data Security Rule only pertains to securing data at rest, which is currently covered by PCI DSS v3.2.1 3 (all) and 8.2.1.
Is disk encryption considered an acceptable method to protect ACH account numbers stored electronically?
Possibly. PCI considers disk encryption an acceptable protection method if additional, prescribed logical access security steps are taken. Disk encryption will be considered a commercially reasonable method of compliance if it either (i) satisfies the PCI requirements related to disk encryption or (ii) utilizes other commercially reasonable controls to secure DFI Account Numbers.
Is compliance with PCI DSS standards related to protecting data at rest required to comply with the requirement in Rule 1.6 to render DFI Account Numbers unreadable when stored electronically?
No. Full compliance with one of the prescribed methods in the PCI DSS standards related to protecting data at rest would be deemed commercially reasonable in a satisfaction of this requirement. However, this Rules requirement does not incorporate the PCI DSS standards by reference. Compliance may be satisfied by other commercially reasonable methods of rendering the DFI Account Numbers unreadable when stored electronically. If an alternative method of compliance with this requirement is used (other than full compliance with a prescribed PCI DSS standard), an analysis should be conducted to demonstrate that the alternative method is commercially reasonable to render the DFI Account Numbers unreadable when stored electronically. If a prescribed PCI DSS standard is implemented in part, compensating controls should be considered to address the portion of the prescribed PCI DSS standard that has not been implemented to ensure compliance with the unreadability requirement of Rule 1.6.
What if I need access to my customer’s full DFI account number in order to conduct customer service or other job-related functions? How does the new rule apply?
When access to and the ability to view a customer’s full DFI account number is necessary to perform a customer service function or to conduct authorized business, the data is considered “active” and not in an at-rest state, and the requirement that the account number be unreadable does not apply. Nevertheless, even in an “active” state, the account information must be protected from unauthorized use or unauthorized access through the use of appropriate risk controls (such as passwords and other access controls) that limit access to “active” data only to authorized personnel. Once access to the account number is no longer needed to conduct a particular business function and is returned to a passive state, it must be returned to an unreadable state for storage purposes.
2024 Nacha Operating Rules & Guidelines Online Resource
