Nacha, the governing and enforcement body for United State’s ACH network, recently issued rules requiring organizations to employ a combination of encryption and tokenization when storing bank account information. The rule came into effect on June 30, 2022.
We recently met with Amy Morris, Senior Director of Payments at Nacha, to better understand the rule and how tokenization fits into their larger data security strategy. You can view the conversation recording here, but we wanted to highlight several key points from the discussion and regulations.
As a preferred Nacha partner, we are committed to helping with a successful transition to these new rules for users of the Nacha network.
First, what do you need to know about the new rule?
Nacha now requires ACH originators and third parties services that process more than 2 million ACH payments annually to store deposit account information in an unreadable format. Any system requiring banking account numbers for recurring ACH entries, such as transaction warehousing or client information systems, must use encryption or tokenization.
The requirement is not limited to consumer data. It includes business bank account information, so accounts payables and accounts receivables systems will also be impacted, as well as systems, like claims management for insurance companies. In other words, if you’re not immediately purging or truncating a bank account number, you’ll need to comply with this new mandate.
The new rules are not limited to how data is stored. They also require organizations to track how data is handled, including where it is stored and which systems and people access it.
Highlights from the discussion
Below is a paraphrased transcription of our conversation with Nacha’s Senior Director of ACH Rules, Amy Morris, and Co-Founder of Basis Theory, Brian Billingsley.
What does the new rule entail, and when does it go into effect?
Amy: The new rule is basically closing the loop on what we have had in our ACH Security Framework for many years. These rules have required data protection while it's in transit, but now this applies to data at rest. We've also had ACH rules that say you have to protect access to data. We have determined what protected information is, so this requirement says that if you have an ACH account number, it needs to be protected and rendered unreadable while stored electronically. This rule [went] into effect on June 30th, 2022.
Which parties are subject to the new requirement?
Amy: If you are an Originator, Third Party Service Provider, or a Third-Party Sender, meaning you create ACH transactions or you are a part of the creation of those transactions, this rule applies to you. We started this requirement [in 2021], which was 6,000,000 transactions ACH per year or more, and now we've included transactions of 2,000,000 or more.
What is the scope that the new rule applies to?
Amy: An account number that's been used in an ACH transaction needs to be protected while you're storing it. Not just while it's in transit. If you're part of either creating an ACH transaction or storing those accounts at all. Then you need to comply with this requirement.
This rule includes business accounts. This is not just PII. This is not just protected information. This is any account number that's used in an ACH transaction that includes business-to-business transactions which can go all throughout your Accounts Payable and Accounts Receivable systems.
Does the rule prescribe the specific manner in which data at rest must be rendered unreadable?
Amy: We are very neutral with that. Take an example of a paper document. You can mark it out, you can redact that document, and that'll meet the rule. But, how will that help you if you need to use it or provide that document back to somebody as proof of a transaction? So what we have been talking to folks about is the use of encryption and tokenization to render that data unreadable but still be able to use it for customer service activities.
What is data tokenization, and how can it help meet the requirements?
Brian: At its core, data tokenization is a replacement or a representation of sensitive data. Typically when tokenization comes into play, it's for a specific use case. If you have sensitive data that you're going to need to use more than once, like a monthly ACH billing transaction. In that use case, they need to be able to use that data monthly, and they need to be able to update that account Information. Tokenization is it allows you to replace, secure, and use sensitive data, especially for a recurring use case.
What should organizations consider when choosing between data tokenization and encryption?
Brian: We often get asked the difference between tokenization and encryption. Are they different? Do they go together? We like to say it's really two sides of the same coin, and tokenization makes encryption much more usable and extensible. So encryption is a way to comply with the Nacha rules by making bank accounts or the account information unreadable at rest. But that's just one part of the problem, right? As a business, you can’t just make all of your data unreadable or create a laborious process to decrypt that data to use it and then try telling all of your merchant or biller partners that are sending you files that they need to encrypt it as well. You’ve got to figure out how to do things like key rotation, which is actually pretty intense. It's hard engineering work, and it's risky. If you mess up a key rotation, or you lose your keys, you won't be able to get access to that data. All those stories you see in the news of someone that has $100,000,000 of bitcoin, and they can't get access to that money because they've lost the keys. It’s a similar risk, if you're managing your keys for encryption.
So the beauty of tokenization is that it takes those sensitive accounts, encrypts them, and gives you a token that allows you to continue using your systems seamlessly. So you can even search and query your sensitive data while it's encrypted, allowing your customer service reps or fraud department to do the same exercises and serve your customers, like they were before, but doing it in a safe and compliant way.
How can a tokenization platform help meet the requirement for tracking access to data?
Brian: The beauty of a tokenization platform is the ability to be very clear on what groups inside your technology departments, customer service, compliance departments, etc., can see and interact with your sensitive data. Tokenization can make it very clear who can do what and when, so it not only helps you comply with, in this case the ACH rule that you have to render that data unreadable at rest, but it also allows you to be much more clear on who has access and the ability to change the data. So It will enable you to comply with these rules and be much more compliance and security-minded for future regulations.
How else does data tokenization improve security and compliance?
Brian: In many cases, Financial Institutions (FI) or merchants already use a platform to tokenize card data. Here at Basis Theory, we have a thesis that over the next few years, you'll see more pieces of Personal Identifiable Information (PII) data get pulled in and regulated very similar to PCI or these new ACH rules. Take phishing attacks, for example; look at what attacks someone can do with email addresses, phone numbers, and mailing addresses. We are seeing more and more sets of data being used in attacks and fraud. So if you're an FI or merchant, you're going to start to see regulations around storing not just a credit card or bank account, but name, address, phone number, etc., and so on. By using a tokenization platform, you can put yourself ahead of the curve of these regulations. I think you're also going to see consumers start to demand it more and more. The popularity of encrypted messaging services amongst consumers has been impressive. You're going to see consumers start to expect it, and we haven't even started talking about things like GDPR, CCPA, and other new statewide regulations that will start popping up.
So I think the market will see more top-down regulation and consumer demand driving more data protection requirements soon. There will be more and more aspects of data compliance that FIs and their customers will have to deal with that tokenization can help solve.
About Basis Theory
Basis Theory renders ACH data, like bank account information unreadable via an API tokenization platform and is an approved solution by Nacha to help satisfy this new requirement. Basis Theory was recently named as a Nacha Preferred Partner for ACH data security and is currently working with organizations to meet the latest data security requirements.
In addition to tokenization, Basis Theory can help secure ACH data and adhere to the new data security requirements with:
Compliant environments: Complexity accommodates the nuances of every compliance and security requirement. Tokenization simplifies it by extending our PCI Level 1 and SOC 2 compliant environments to developers, Basis Theory can abstract the compliance burdens faced when trying to store ACH sensitive data.
Encryption management: Abstracting the complexities of encrypting, managing, and rotating keys is important for organizations to consider, but not just for the developer experience: When coupled with tokens, the approach allows Basis Theory to update encryption algorithms over time without disrupting day-to-day operations.
Tools to interact with your data: Developers already know how to write code to solve problems. The Basis Theory platform can also provide the flexibility that development teams need to be able to work with sensitive data.
Contact us to learn how tokenization can help you meet Nacha’s data security requirements for ACH transactions or sign up for a free account to spin up your own secure token vault.
