Automated Clearing House (ACH) is the dominant low-value transfer mechanism in the US. ACH typically refers to the Federal Reserve’s FedACH network which implements the rules maintained by Nacha (formerly stylized as the National Automated Clearing House Association, NACHA).
ACH is an asynchronous network; files containing batches of transfers are sent from originating financial institutions to the Federal Reserve which re-batches the files for onward transmission to receiving financial institutions. FedACH settles within the financial institutions’ Federal Reserve accounts.
ACH supports both credit and debit origination; you can pull and push money. The timeframes have been shortening in the last ten years. FedACH now operates three same-day windows. FedACH also operates six non same-day windows.
An ACH transfer includes mandatory details of the account number, routing number, and amount. There are optional parameters of the recipient’s name and identifying number. Explicitly, most financial institutions don’t enforce that the recipient name on the transfer matches the account holder name.
ACH transfers can be returned. Common return reasons are that the account number isn’t recognized, the account has insufficient funds, and that the account holder states the transfer is unauthorized. Transfer returns can roughly be divided into administrative return (the account number isn't recognized, for example) and unauthorized returns (the account holder stated the transfer wasn’t authorized). Nacha mandates that administrative returns must be limited to 15% and unauthorized returns must be limited to 0.5%. Both are calculated on monthly count.
Returns can be correlated with originating transfers by using the date, amount, account number, routing number, and the trace number. Trace numbers are 15 digits but with only eight digits of entropy (as the leading eight identify the original financial institution). Trace numbers need to be unique in a Nacha file and monotonically increase. For any reasonably large institution, it’s usually not possible to uniquely rely on trace numbers for reconciling returns.
Explicitly, FedACH doesn’t intermediate disputes. This is different to the card networks. A transfer recipient can state a transfer is unauthorized and the receiving bank will return it. For corporate accounts this period is two business days. For consumer accounts, this is sixty days. Nacha recommends using non-ACH related dispute resolution mechanisms like contacting the account holder, collections agencies, or courts.
To reduce unauthorized returns, Nacha recommends (and in some cases requires) validation of account and routing number details.
To validation account details you have two options:
Use a service like Plaid or Finicity, where an account holder provides their bank login details and the platform ~synchronously scrapes the bank’s website.
Send the account holder micro-deposits and have them confirm the amounts.
There are older methods like collecting an image of a voided check or using confirmation notes but they’re less used in modern integrations.
Reversals and other conventions
Nacha also has a number of conventions that have reached varying degrees of codification. One is reversals — reclaiming funds from an erroneous transfer. For reversals, Nacha requires all fields are the same except for the
company_entry_description which must be
REVERSAL. Importantly, reversals aren’t a network primitive; they’re regular transfers and therefore can be returned.
Other Nacha conventions with varying degrees of formality are child support payments, tax payments, and corporate trade exchange data.
ACH supports some non-financial messages. One is the confirmation note used for accounting and routing number validation. Another is a Notification of Change. Notifications of Change are optionally sent by receiving depository institutions to communicate that although a transfer has been accepted, in the future, updated details should be used.
The Federal Reserve’s FedACH schedule is here:
Increase submits for every window and we can accept transfers up to an hour before the cut-offs.
Nacha’s message format is a fixed-width flat file containing batches of transfer entries. Nacha’s specification is here:
Many financial institutions implement ACH by allowing clients submit Nacha’s file format through SFTP servers. Submission to the Federal Reserve runs similarly but uses an IBM product, Connect:Direct. FedACH responds with a custom-formatted acknowledgement file within 15 minutes. (There are escalation channels if a file hasn’t been acknowledged in that timeframe.) Most financial institutions similarly operate an acknowledgement mechanism.
Operating an ACH integration
A common frustration with ACH is that there’s no transfer receipt notification method. As a transfer originator, you have no way to definitely know if or when a transfer has arrived to a recipient’s account.
Some depository institutions allow account holders to maintain an allowlist of companies that can debit their account. This is done by referencing the Company ID. In particular, if you’ll be debiting businesses, you’ll likely want them to register your Company ID with their financial institution.
ACH transfers have many structured parameters like the
individual_id. The specifics of how these are serialized to a transaction description shown to a recipient vary by bank.
Typical operational issues you’ll run into are that Nacha’s file form is ASCII. If you’re allowing UTF-8 data submission you’ll want to flatten it. You’ll also want to exclude client entered data containing things like newline characters.
Not all financial institutions preserve the trace numbers you submit. You’ll want to understand if yours does as it makes a difference to how you’ll correlate returns.
Many financial institutions will fund your ACH transactions by aggregating your daily files and batches possible by transfer effective date. Understanding your bank’s aggregation method is necessary for you to reconcile the transfer instructions you’ve submitted to the cash in your bank account.
While not common, there are data quality issues with FedACH. In particular, the network itself doesn’t store the state of a transfer. Therefore it’s possible for a receiving depository institution to return a transfer multiple times, for example. It’s also possible for them to include the incorrect details on a return.