The three questions to ask when securing ACH bank account numbers

In our last post, we gave a high-level explanation of ACH’s requirements for electronically storing financial deposit information (i.e., bank account numbers) and who they impacted. While Nacha, the governing and enforcement body ruling over the United State’s ACH network, addressed many questions regarding its Supplementing Data Security Rule, it did not dive deep or prescribe technical requirements or solutions.

This blog aims to:

• highlight the inspiration behind Nacha’s technical requirements for securing bank account numbers at-rest.
• provide questions to help guide which solution is best for your organization.

What are Nacha’s technical requirements for data at rest?

Nacha has drawn a lot of inspiration for its ACH Specification from the PCI DSS Specification. Their FAQ calls out PCI DSS, specifically 3.2.1 (protecting stored cardholder data) and 8.2.1 (identifying and authenticating access to system components) as best practices when dealing with data at rest. Nacha does not require ACH solution providers to be PCI compliant, but analyzing these two sections offers the best insight into understanding Nacha’s potentially future ruling on technical requirements around handling ACH Data. 

3.2.1 Protecting stored cardholder data 

• Encrypt the data at rest with an industry-standard method. 
• Encrypt data in transit end-to-end with an industry-standard method. 
• Store only the specific data your business needs to retain.
• Only retain data as long as is necessary by the business. 

Check out the PCI’s website to learn more about the card networks’ security standards.

8.2.1 Identifying and authenticating access to system components

Nacha defines bank account numbers as “active” when being used to support an operational or business function (e.g., for customer support or fraud investigation). However, Nacha’s reference to PCI DSS 8.2.1 strengthens its current expectations around access controls. Specifically:

• All access is logged. 
• All access is authenticated.
• Employee/system access is limited to the least privileged.
• Logs are retained for one year or more. 

What options do I have to secure bank account numbers?

Nacha did not prescribe how to render bank account numbers unreadable, but it did endorse a couple of concepts: 

Truncation: Shortening the original value only to store or display a partial segment (typically the last four characters). For example, a bank account number “123456789” might turn into “6789.”

Destruction: Permanently removing bank account numbers from a system. Also known as Deletion, this includes erasing data at rest and in memory and cold storage.

Encryption: Encryption uses mathematical algorithms to take data, like a bank account number, and convert it into something incomprehensible by comparison. Encrypted data is decrypted using keys managed by the organization securing the data.

Tokenization: Tokens substitute data, like a bank account number, with a worthless unique reference string. For example, bank account 1234567890 could be turned into g675Dh3eFd6is. The organization stores the token instead of the sensitive data. Later, the organization may use the token to access all or part of the sensitive data when needed. 

How to determine which option to secure bank account numbers is best for you?

Every company is different, but here are some questions we typically like to ask our customers.

How often are you using the data? 

Getting bank data from end users can feel like pulling teeth, significantly impacting conversion events related to payments. If you intend to reuse the bank account number for future debits or credits on even a semi-regular basis, we’d advise organizations to strike Destruction and Truncation off your “options to comply” list. Alternatively, if you need to use the bank account number, say, only once per year, Destruction may offer a cost-effective way to comply. 

How many systems store and use the data?

If you plan to reuse bank account numbers, you will need to store and reference them yourself or with a third-party provider. If you decide to go it alone, audit the number of places housing this data and understand the different systems interfacing with those locations. This will help scope the initial integration effort and uncover possible risks and costs to maintain after implementation. 

What’s your timeline, and is securing and complying with these requirements a core competency?

For companies thinking about building an in-house solution, ask whether or not you have the engineers and subject matter experts needed to comply in the timeframe required (i.e., June 30, 2022) and maintain it after the implementation is complete. The best place to start grounding this conversation in reality is your roadmap.

Why? Reflect on your most recent roadmap discussion involving security and compliance work. How long did it take to get the solution on the roadmap? How did the final scope compare to the original? How hard is it to return to that work and “do it right” for scale? What value-adding product or service was deprioritized? Think of these questions as Ibuprofen for future you.

Combining encryption and tokenization

Let’s assume, once again, you plan to reuse bank account numbers and need to store them. 

Encryption, by itself, is an excellent option for smaller companies with limited product offerings, usage, and marginal user growth. Many frameworks offer free encryption libraries. However, simple encryption will prove difficult and costly at scale. Rotating keys, updating encryption standards, and maintaining a compliant infrastructure can clutter roadmaps, cause ongoing performance issues, and complicate your system architecture. These all have actual costs, but this is where encryption coupled with tokenization can help. 

Using tokens to reference encrypted data allows applications to pass back and forth (i.e., use) bank account numbers without storing data within their apps. This abstraction layer consolidates a significant source of risk, complexity, and work, as well as enables a variety of use cases, including sharing bank account numbers with internal systems and external partners. 

Watch our pre-recorded webinar to learn more about why tokenization is becoming a popular approach to secure ACH data.

Build vs. buy: encryption and tokenization

For most companies, security and compliance are seen as a cost of business at best and, at worst, an ongoing burden distracting their teams from the problems they’re meant to solve. This position doesn’t make a company bad—just a good candidate for implementing the infrastructure and management of a Nacha preferred partner, like Basis Theory.

Companies that want compliance and growth choose Basis Theory because security, compliance, and scale are the problems we’re here to solve. It’s our core competency—that, and building APIs and SDKs that allow developers to seamlessly collect and secure data in minutes. 

If you’re serious about growth, don’t let compliance and security plague and shape your roadmap discussions. Instead, contact us if you’re interested in learning more about our services or, better yet, use our developer guide, “Securing Bank Accounts,” to see how you can collect bank account numbers in minutes.