Making NACHAs: Part I
In 2018, the ACH (Automated Clearing House) network processed nearly 23 billion payments, according to www.nacha.org . Note this isn't payment AMOUNTS, but rather payment COUNTS. The amounts of these transactions, in a single year, exceed $50 trillion. Ponder that for a moment… $50 trillion of money moved in one year — over a million per second!
What started as the backbone of the U.S. banking industry, the ACH network — also commonly referred to as Electronic Funds Transfer (EFT) — is now integrated into most industries, providing a service to move money from one entity to another securely. Whether it's receiving or sending money, direct deposit of payroll, or just about anything involving the movement of money, you can bet the ACH network is probably in play somewhere.
One of the most common ways to communicate with the ACH network is through a text file known as a NACHA (National Automated Clearing House Association) file. The format is ridiculously simple, in theory. But, because it supports all sorts of different types of electronic transactions, building a program to generate a NACHA file can be an especially onerous task. That's the point of our discussion today; let's try to demystify some of the weird NACHA-isms.
The first thing to understand about the NACHA file format is that even though it's an established standard, each receiver implements things just a little bit differently. You'll need to work with your trading partner (the party sending or receiving the file) to make sure what is sent is properly interpreted on the other end.
In this series, we're going to build a file that is used to send money to people while at the same time receiving money from people. For this reason, it can be useful to think of the NACHA file like a checkbook; you're going to write checks to give money to people, and you're going to have deposits of money coming into your account(s). The NACHA file standardizes this into a transmittable format.
Let's take a peek at a sample NACHA file[Figure 1].
Figure 1
That's clear, right? I'm sure that if you've never seen a NACHA file before, this is just a wall of text. Let's break it down, brick by brick.
The key to understanding any of it is to know that each line is 94 characters. A line is not necessarily a complete record as we think of records.
The first character of each line is a line type. Here's a translation guide:
- File header
- Batch header
- Detail
- Addenda (not shown)
- Batch footer
- File footer
Pretty simple, right? Well, that's the theory. As you can see from the example, there are a lot of different fields stuffed into each 94-byte record. To better understand what's inside of them, we first need to review a few NACHA terms. From my own experience, having done several NACHA extracts, the terminology is typically one of the biggest tripping points.
If you look up the terms originator and receiver on the various websites which explain NACHA, the vague descriptions will not be helpful. Instead, returning to our analogy, think of the originator as the person with the checkbook. If you're sending the file, you are the originator. Or more accurately, your bank is.
However, if you're receiving the file, you are the receiver. Keep this in mind, because it has nothing to do with whether you're the one sending or the one receiving money , it is about who is sending and who is receiving the file .
If you build the file, you're the originator. The accepted synonyms are source and company identifier. Starting to see how this can get confusing?
That's why I wrote this. I've already stubbed my toe on these issues. I want to save you from the same pain.
The term ODFI (Originating Depository Financial Institution) is the source of much of the confusion. If you're sending money, your bank is the ODFI. That just makes sense. However, if you're receiving money from someone else, the sender's bank is the originator, right? WRONG. If you're building the file, the ODFI is the ABA ( American Bankers Association) number of your bank. Looking again at our analogy, the ACH network needs to know where our bank account lives. The ODFI provides that value.
The ABA is the 9 digit number on the bottom left of a check — surrounded by funny graphics — is commonly known as a routing number or transit number or routing/transit number. In ACH parlance, however, it's commonly known as an ABA number. It's all the same, but like most things in ACH, there's a bunch of different terms to describe it.
Following ODFI is RDFI (Receiving Depository Financial Institution). Just think of RDFI as the other guy. This can also be known as the destination.
The final term to become familiar with is the Center Name. This describes the ACH endpoint who will receive your file — commonly a bank. Some banks don't care about this value, whereas others are very, very specific about the center name and will reject the file if the center name is not exactly what they want.
Before we get into the details of building each record, there is one more important detail to cover. Once you've built your NACHA formatted file, then what? You'll need some way to transmit this to your assigned center. On Multivalue systems, this is commonly done using SFTP. If you are dealing with a bank which doesn't support SFTP, you'll need to download the file to a workstation and then upload it to a web form provided by the bank. Regardless of how the information gets out the door, it is imperative to always keep in mind that this is the sensitive information and must be protected in every way possible. This is your banking information and the banking information of your customers and vendors, and there are countless nefarious people on the web sniffing the wire for exactly this kind of information to do as much damage as possible.
Believe it or not, I have seen banks that want the NACHA file emailed to them. Don't do it. It would be more secure to copy the file to a flash drive and drive it to the bank. Then again, a flash drive isn't exactly secure either.
In later installments of this series, we'll break down each of the different types of NACHA file records and explain more confusing terminology and how you can easily generate this type of file on any Multivalue system.
