ACH Payment Tokenization replaces sensitive account and routing number data with a random string of alpha-numeric data. This data is called a reference token and is stored in lieu of full sensitive data.
When the bank account is future billed, the token is sent. The ACH processor has the full account and routing number securely stored and using the matching token, processes the ACH transaction.
In contrast to the credit card processing world, ACH payment transactions were not mandated to be tokenized, rendering the sensitive data unreadable.
While it’s definitely a best practice to protect sensitive data, it has only recently become a mandate from NACHA that security measures be put in place.
ACH datapoints consist of a bank account number and routing #. The routing # identifies the consumer or businesses bank.
The new NACHA mandate requires that these numbers be replaced with a reference token. The token is then stored with the customer data and when payment is collected or disbursed the reference token is sent as part of the transaction string. The ACH tokenization gateway has the full account and routing #’s vaulted.
NACHA, the governing board that regulates the ACH network, came down with some new data security requirements. Those requirements are spread-out over two phases:
Phase one covers originators and third parties with volumes greater than 6,000,000 transactions over year 2019. The effective date for phase one is June 30, 2021*.
Phase two covers originators and third parties with volumes greater than 2,000,000 transactions over the year 2020. The effective date for phase one is June 30, 2022*.
*The effective dates were extended by one year, essentially due to Covid.
As part of NACHA’s governing authority, they regulate how transactional data must be safeguarded. The actual NACHA security requirement is neutral, meaning methods employed are not restricted to tokenization alone. However, given that tokenization is a commonplace best practice in the credit card world, and is what we provide to our clients, that is what our focus is on for NACHA data security requirements solution.
Aside from the NACHA security requirement and having to comply, your organization should consider tokenizing sensitive bank account data simply because it’s the right thing to do.
Would you want your checking account routing and account number being stored in a readable fashion on any company’s or organization’s computer system? Of course not.
It only takes one breach – or a disgruntled employee with database access – to acquire and distribute that sensitive data.
Taking proactive measures and complying with rules are your best options.
Agile Payments can provide to companies needing to render sensitive data unreadable is Tokenization.
While any company that has been provided with an ACH processing solution from Agile Payments already has their ACH transactions tokenized, it’s the organizations and companies who typically have a direct ODFI relationship, which in turn usually places them in one of the top tiers of the NACHA mandate, that re those who require some kind of tokenization solution.
Those organizations are usually accustomed to sending a NACHA formatted file to their ODFI for origination and subsequently are returned a similar file for rejected items. Those files contain sensitive data that needs to be rendered unreadable.
We accomplish that via a tokenization solution, and the solution can communicate with your ODFI via system integration with that ODFI. Essentially the ACH tokenization gateway is connected with your bank, making it possible to use not only the tokenization solution, but a number of other tools that can assist with communication channels, reporting advantages, data collection methods and software API integration to name a few.
ODFI Integration: Assuming your organization has decided to move forward with one of the Agile Payments tokenization solutions, we would have our integration team meet with your ODFI for integration specification details. We would then return you the details on the timing and the cost of the ODFI ACH gateway integration.
Communication Methods: When you utilize an Agile Payments ACH gateway solution, you then have the ability to communicate your ACH transactions a number of different ways.
We’re confident that we can provide your organization with an ACH tokenization solutions that exceed your requirements. The best ACH tokenization solutions should all start by understanding your specific needs.
Need more information on how ACH tokenization can assist you?
The security requirement is relevant to originators that are not RDFI’s (banks), Third party senders and service providers who perform ACH processing functionality on behalf of an originator.
All clients who have been provided ACH processing via Agile Payments are compliant because all modern tools and integration methods utilize tokenization. the focus of this particular page is geared more so for organizations who might have a direct ODFI relationship and are used to transmitting a NACHA file format, whereby they are likely storing sensitive bank account data.
Further, it’s geared directly at those organizations who have ACH transaction volumes greater than 2 million annually, as mentioned above in the teo phases of the security requirement roll-out.
if your organization is below the 2 million annual ACH origination volume number, NACHA doe not mandate that you comply with the new security requirement to render sensitive bank account data unreadable.
However, they strongly suggest that you take a proactive approach and adopt the security requirement as a best practice.
Restricting access to storage systems that house sensitive data does not meet the NACHA security requirement. The data that is stored must still be rendered unreadable, and tokenizing that data is an acceptable solution.
Any organization that employs PCI data security standards to all platforms and storage systems are compliant for the new NACHA mandate. As with Agile Payments solutions, both credit card and ACH systems run on a PCI level one system and all sensitive data is rendered unreadable.
ACH Tokenization is the process whereby a full bank routing number and account number are replaced by a token. The token is typically an alpha-numeric string that replaces full (sensitive) data. Instead of sending a full bank account # and potentially revealing that account # to employees, vendors etc, the token is sent. In and of itself the token has no value. This process removes account theft/takeover worries that using full data can engender
Any organization that processes ACH payments by sending full account and routing data is a candidate
Typically there is a nominal per transaction gateway fee