What questions should I ask when securing bank account numbers?

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 do just that. We want 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. 

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. 

Return to Top

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. 

Return to Top

How to determine which option is best? 

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

How often will you need to use 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.

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 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.

Return to Top

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. 

Return to Top

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. 

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.

Return to Top