Sending a payment over the ACH Network provides users with a fast and easy payment option for bank-to-bank money transfers.
Since an ACH transaction involves the sharing of sensitive information, typically through an online network, it’s important that the ACH Network is highly secure and that those who incorporate ACH transfers into their operations and payment systems store this private data securely.
While ACH fraud is not uncommon, a study by the Federal Reserve based on payment fraud data from 2012-2016, showed the total number of fraudulent ACH transactions decreased and fraudulent card activity increased in both volume and activity. According to this report, ACH payments present one of the lowest fraud rates by value, with just a 1.3% rate of fraudulent transactions (2015).
If you are an organization that is interested in providing another option for sending a bank-to-bank transfer and moving away from the expensive wire transfer, then it’s important to consider the security measures that need to be taken in order to avoid fraudulent attacks and the ways to mitigate those attacks should they occur.
This article will provide these security measures as well as layout best practices for securing an ACH transaction and for storing ACH payment data.
What is an ACH API?
An ACH API is the combination of two intuitive technologies: ACH transfers and APIs.
If you’ve never heard of them before, know that it is likely that you’ve interacted with both (often together) without knowing it. This technology allows you to send bank-to-bank money transfers to pay a merchant, to complete a business transaction, or to send money to friends.
ACH, which stands for Automated Clearing House, is a form of sending money between banks by proxy of the Automated Clearing House Network that is set up in the United States (U.S.).
This Network, which has existed since 1974, was established because banks were seeing a high volume of money being moved each day. In order to stay on top of this influx, and to mitigate fraudulent checks or mishandled information, the ACH Network was established.
Now, the Network consists of all the financial institutions that are authorized to send ACH transfers, the Federal Reserve, the Clearing House, and everyone who uses ACH transfers—that’s us!
Lastly, ACH transfers can exist as an ACH debit (a withdrawal) and an ACH credit (deposit). Direct deposit is an example of an ACH credit, and bill payment is an example of an ACH debit.
This may sound complex, and that’s because, well, it is. The ACH rules are extensive and every ACH Operator must abide by these rules in order to process ACH transfers.
The more we as a society develop useful technologies for faster interactions and money transfers, the more that APIs are recognized as a key roleplayer in facilitating this trend.
An API, which stands for an Automated Programming Interface, is a robust yet concise set of code that can facilitate a solitary set of requests. These requests are all programmed into the code. By only allowing a limited and specific number of requests, APIs can securely access sensitive data from specific endpoints and operate faster.
Nowadays, more and more companies are adopting an ACH API for payment processing because it is fast and it makes life a whole lot easier.
Since there are a lot of moving parts in play when it comes to transferring money over the ACH Network, and with APIs, security measures need to be adopted in order to protect this data.
This article will primarily focus on the power that organizations have in protecting ACH transactions, as many DevOps teams are in control of the security measure to protect APIs.
To Avoid Attacks Against ACH Transactions
Every financial institution will have to be approved by the ACH Network in order to be an ACH Operator. This means that security measures, like adding encryption to the transaction, will need to already be in place by the financial institutions seeking to facilitate these transactions.
Luckily, regulations are already in place thanks to the National Automated Clearing House Association (NACHA). NACHA is a not-for-profit organization that regulates, administers, and facilitates the ACH Network. Therefore, every ACH Operator who interacts with the ACH Network must abide by NACHA’s Operating Rules.
Primarily, as an Originator (the one who requests ACH transactions) it is your responsibility to ensure the valid authorization of every ACH debit you process.
Proof of authorization can be tested by verifying ACH return codes. Return codes are the primary way that a financial institution (typically the financial institution who is receiving the request, otherwise known as a Receiving Depository Financial Institution or RDFI) can inform the financial institution who made the request (otherwise known as an Originating Depository Financial Institution or ODFI) that there was an error in the request.
Originating requests need to be checked to ensure that the correct code is being sent back. Since there are hundreds of return codes, these return errors can be quite specific and this gives your company useful information as to what went wrong with the transaction.
Testing for return codes and proper authorization procedures is a requirement for being approved. By testing your ACH return codes in a developer console (or Sandbox), you can be prepared for live interaction with an RDFI.
To Mitigate Attacks on ACH Transactions
To mitigate an attack on an ACH transaction, you will need to continually improve upon your financial cybersecurity literacy.
Do so by seeking an appropriate NIST maturity level. The National Institute of Standards and Technology (NIST) has four tiers for cybersecurity protection, each built on a categorical framework:
Identify: Asset management, business environment, governance, risk assessment, risk management strategy, supply chain management (third parties)
Protect: Access control and identity management, awareness and training, data security, information protection processes and procedures, maintenance, protective technology
Detect: Anomalies and events, security continuous monitoring, detection process
Respond: Response planning, communications, analysis, mitigation, improvements
Recover: Recovery planning, improvements, communications
By achieving a more robust categorical response, you can achieve a higher level of cybersecurity awareness.
- Having partial awareness will grant you a Tier 1 status.
- Tier 2 is risk-informed.
- Tier 3 is Repeatable.
- And Tier 4, the highest, is Adaptive.
Properly mitigating an attack on your ACH transactions will mean that you have done a risk assessment, developed a risk management strategy, configured access control and identity management, provided training, tracked anomalies, recorded response planning, and recorded mitigation techniques.
At any time, your users can be targeted by a malicious attack aiming to seek sensitive banking information.
Organizations need security measures in place to avoid high-risk ACH transactions, to give users peace of mind, and the protect their own assets.
For Secure Transfer of ACH Payment Data
Encryption: This involves the ciphering and deciphering of data by passing the characters through an algorithm locked with a key. Another algorithm and the same key unlocks the data so that anyone with key access can decipher the ciphered text. Encryption can also come through cryptocurrency transfers.
Authentication: This involves the verification of the identity of the receiver of the ACH transfer in congruence with account verification. A risk-based approach to authentification allows organizations to take into account the type of transaction, the type of customer, and the stakeholders involved.
Authorization: This is when the originator and the receiver enter into an agreement that allows the Originator to initiate a debit entry to the receiver’s bank account. This is essential because the Receiver is granting access to the bank account and the Receiver needs to be able to prove that they trust the other party.
For Secure Storage of ACH Payment Data
Providing secure storage of both sensitive financial information and electronic payment data is crucial to your success as an operating financial institution.
Here’s how you can do that:
- Store data on PCI approved hardware and software
- Use only approved service providers, those who undergo extensive testing (done through a QSA, see below) and is marked as a PCI DSS Validated Entity
- Do not store card security number or electronic track data
- Encrypt the electronic storage of all credit card account information and cardholder data
- Encrypt phone recordings containing credit card account information
You can take the appropriate self-assessment questionnaire to see if your storage of payment data is PCI compliant. To stay PCI compliant, you’ll also need to complete the Attestation of Compliance (AOC) form and maintain yearly PCI compliance with the Quality Security Assessor (QSA) and Approved Scanning Vendor (ASV).
Providing Secure ACH Transactions
ACH processing is usually done so through online payment options. This presents an inherent and elevated risk for malicious attacks against ACH transactions. Current ACH users are threatened by cyberattacks, email phishing, account takeovers, vendor impersonation, and much more.
As each financial institution offers different functionality, there is no one-size-fits-all when it comes to an effective cybersecurity model:
Characteristics vary by maturity level: Your security majority level will be dictated from the top-down. This comes with the budget that is allotted for security, the complexity of the issues needing to be addressed, and how adaptive a risk management profile is. Accountability comes from the top, but responsibilities need to be shared across the board.
Maintain multiple lines of defense: Chief Security Information Officers are well aware that having multiple lines of defense means that the more barriers that are in the way, the more time and protection business has in defending sensitive data.
Distribute cyber risk exposure: Adaptive companies are more likely to have purchased adequate cyber insurance that covers nearly all expected loss scenarios.
Size matters: Allocate an appropriate amount of resources for a variety of risk scenarios. A survey of larger financial institutions allotted 5 to 50 percent of a total IT budget for cybersecurity.
NACHA also provides third-party risk management resources, such as registration for Third-Party Senders, Direct Access registration, Terminated Originator Database, and the Financial Institution Contact Database. By accessing these resources, your organization will be able to identify who is registered as a verified accessible party and which financial institutions or originators are active.
Protecting Your Data with Sila
Offering your users the ability to use the ACH process leads to happier business relationships. However, following all of these steps takes time. Sila is here to help.
With the Sila API, your organization can offer highly-secure and fully compliant ACH transactions. The Sila API is a payment gateway that can process ACH transactions and securely store cardholder data by using the cryptocurrency network.
Investing in the Sila API means that you can move away from traditional payment processing, such as paying with a debit card, credit card, or wire transfer. In addition to other limitations, relying solely on credit card transactions, for example, prove costly and it does not give your user’s much of an option.
See today why Sila is right for you.
While the Federal Reserve’s study shows that fraudulent activity on ACH transactions has decreased in recent years and that sending money via ACH payment is more secure than using a card, it is important that organizations focus on security measures and best practices in order to keep these numbers low and to keep your customers safe.
If you are interested in ACH payment processing, then visit the following references: