Note: This is the first post of a 4-part series. Afterwards, read part 2, part 3, and part 4.
The Automatic Clearing House (ACH) network is the primary way money moves electronically through the banking system today.
At Gusto, we rely heavily on the ACH network. For example, when a company runs payroll, we’ll use the ACH network to debit the company’s account to fund their employee’s pay. Once we’ve received these funds from the company, we’ll again use the ACH network to initiate credits into each of the employee’s accounts to pay them for their hard work. Today, our systems seamlessly move millions of dollars through the ACH system on a daily basis.
But it wasn’t always that way. I remember when we first started building Gusto, we spent a many weeks struggling to understand how the ACH system works and learning how we can write software to tap into it. Part of the reason it was so hard to comprehend is that much of the documentation explaining the ACH system is targeted towards bankers, not software developers. To guide and encourage the next creators of modern financial software, this article will explain how ACH works from the software developer’s perspective.
In order to initiate an ACH credit or debit on someone’s bank account, you first need to find a bank who is willing to proxy these transactions on your behalf. Only banks are allowed to initiate ACH transaction directly. You’ll need to open a business account with a bank and request the ability to originate — the technical term for send — ACH transactions through them. If they agree, they’ll become your ODFI, which stands for “Originating Depository Financial Institution,” but really it’s just a fancy term for “bank”.
Your ODFI will set you up with a secure FTP server onto which you’ll upload ACH files. I won’t get into the actual format of these text files, but they basically contain information about who you want to debit from or credit to (identified by bank routing number and bank account number), and the amount of the transaction.
When the ODFI receives your ACH file, they will forward it that evening to the Federal Reserve.
At this point your ODFI will usually assume the ACH transaction you originated will go through and credit or debit your bank account for the ACH transaction that you originated. For example, if you initiated an ACH debit on Alice’s bank account for $100, your ODFI will increment your bank balance by $100. If instead you initiated an ACH credit on Alice’s bank account for $100, your ODFI will decrement your bank balance by $100.
Early next morning, the Federal Reserve will tell Alice’s bank that an ACH transaction was originated on Alice’s account, and Alice’s bank will debit or credit her account accordingly. For example, if you initiated an ACH debit on Alice’s bank account, her bank will decrement Alice’s balance by $100. If you initiated an ACH credit on Alice’s bank account, her bank will increment Alice’s balance by $100. Alice’s bank received the ACH file from the Federal Reserve, and is therefore called the “Receiving Depository Financial Institution” (RDFI.)
That’s pretty much it! If you FTP an ACH debit file on Alice’s bank account, the same process will happen with inverse amounts. Your account will credited with $100 and Alice’s account will be debited by $100, and all is balanced with the financial world. If you FTP an ACH credit file on Alice’s bank account, your account will be debited by $100 and Alice’s account will be credit with $100, and all is still balanced with the world.
But what happens if you originate an ACH debit on Alice’s account and it turns out that Alice doesn’t have $100 in her account? Or, worse, what if your ACH debit file mistakenly contained the account number for Bob’s bank account? These are some of the edge cases that make using ACH a little more tricky and will be the subject of part 2!
Comments on Hacker News