ACH (stands for Automated Clearing House) is one of the most common methods of payment in the US. It is an open loop payment network, that connects several financial institutions through a centralized "clearing house". The network is governed by a body (NACHA) that defines the rules and guidelines for participation in the network.
ACH credit is a payment type used to push funds from one account to another.
Example: Alice has an account with Chase, and bob has an account with Bank of America. Alice wants to pay Bob $50 for walking her dog.
|Alice||Originator||The originator defines the amount, description, and provides Bob's bank information (account and routing numbers). Alice must have Bob's banking details in order to make the payment. The funds will be debited from Alice’s account as soon as she creates the payment.|
|Bob||Recipient (Beneficiary)||Once the payment is processed, the funds will be credited to Bob’s account.|
|Chase||ODFI||The ODFI (originating depository financial institutions) is connected to the payment network, and is in charge of verifying Alice's information, as well as the payment details. It then transmits the payment details to the network, and ultimately moves the funds to the RDFI through the network.|
|Bank of America||RDFI||The RDFI (receiving depository financial institutions), will get the message from the network that a payment has been created, and will be in charge of verifying the validity of the beneficiary's information and routing the funds to their account (or returning the payment if the details are Invalid)|
ACH debit is a payment type used to pull funds from an account at a different financial institution.
Example: Alice has an account on Chase and Bob has an account on Bank of America. Bob rents an apartment from Alice and Alice wants to collect $1,000 in rent from Bob.
|Alice||Originator||The originator defines the amount and description, and provides Bob's bank information (account and routing numbers). Alice has to have Bob's details in order to originate the payment. After the payment has been processed, the funds will be credited to her account.|
|Bob||Recipient||Once the payment is processed, the funds will be debited from his account (funds are pulled from Bob’s account and sent to Alice’s account).|
|Chase||ODFI||The ODFI (originating depository financial institutions) is connected to the payment network, and is in charge of verifying Alice's information, as well as the payment details. The ODFI is also responsible for verifying that Alice has received Bob's permission to pull funds from his account.. It then transmits the payment details to the network, and ultimately routes the funds to Alice's account.|
|Bank of America||RDFI||The RDFI (receiving depository financial institutions), will get the message from the network that a payment has been created, and will be in charge of verifying the validity of the beneficiary's information, checking that there are sufficient funds in the recipient's account, debiting it, and sending the funds to the ODFI through the ACH network.|
The originating side of the payment assumes responsibility for the payment - this means they are in charge of verifying that the payment complies with NACHA rules, and is liable in case of any infractions or fraud.
ACH payments can be used to pull and push funds.
In order to move funds from Alice to Bob Using ACH:
- Alice may Originate an ACH credit to Bob's account. Alice must know Bob's account details.
- Bob may Originate an ACH debit from Alice's account. Bob must know Alice's account details, and must obtain Alice's permission to debit her account. Bob is responsible for obtaining and maintaining evidence of Alice's approval to be debited - this is typically done by Micro deposits, or by Alice authenticating against her bank account using providers like Plaid. Bob's bank, the ODFI, warrants the payment, and can ask Bob for proof of authorization at any time.
Unit may receive ACH files from the network multiple times during the day and posts them as soon as it does. Unit processes those files immediately, and each received payment is either successfully processed, returned, or pending. Note that unlike originated ACH payments which are subjected to internal limits, received ACH payments are only subjected to limits imposed by the originating financial institution.
When a received ACH is successfully processed, a transaction.created event is fired immediately, with transaction type: ReceivedAchTransaction, and the funds are deposited into (or taken from) the end-customer's account.
Some received ACH credits have a settlement date that is set in the future - this means that Unit is told by the ACH network that the funds will arrive at a certain date in the future. This typically happens with direct deposits (wage payments). When the settlement date arrives, the funds will be received by Unit, and appear on the end customer's account.
You may be able to provide your customers with early / immediate access to funds that are in pending status. Additional details are available in the Early Payment Access guide.
Direct deposits are electronic deposits of funds into a bank account rather than through a physical, paper check. The term direct deposit is typically used to describe payments being made by an employer to an employee's bank account (payroll).
The way to identify direct deposits is by:
- Looking at the
secCodefield of the ReceivedACHPayment and/or ReceivedACHTransaction. Direct deposits should have
PPDas their SEC code.
- Not all received payments with the
PPDcode are necessarily direct deposits. To verify that this is in fact a direct deposit, it is recommended to search for the words "Direct Dep", "Direct Deposit" or "Payroll" in the ACH description.
There are a few reasons that may cause Unit to return a received ACH transaction, either automatically or manually. Those reasons include:
Name mismatch: The beneficiary name on the received ACH does not match the name of the owner of the receiving account. When that happens, no transactions will be created.
Account not found: The account number does not exist on the Unit platform. When that happens, no transactions will be created.
Insufficient funds: The account does not have a high enough balance to allow the transaction to go through (specific to received ACH debit). When that happens, 2 transactions will be created on the end customer's account:
There has to be a justifiable reason for an ACH return, that has been disclosed to (and agreed upon) by the end customer. By default, you are not supposed to initiate returns, since Unit handles these on your behalf. There are specific use cases in which Unit would allow you to initiate returns - if this is something you would like to explore, contact Unit.
Unit allows you to originate ACH credits and debits:
You may originate ad-hoc ACH credits using a counterparty's account and routing number.
Originated ACH payments are posted once a day at 3 p.m. EST.
You may originate ACH payments, credits or debits, by using saved counterparties.
- You may add a saved counterparty by using an account and rounting number. These counterparties are created with a "Credit Only" permission.
- Unit's strong recommendation is that you use Plaid to obtain a plaid processor token and create a counterparty using that token. You can read about the benefits of using the Unit/Plaid partnership here.
In order to originate ACH debits you must obtain and store the counterparty's authorization to debit their account.
- On Unit, this is typically done by having the counterparty authenticate against their bank account using Plaid, using their bank account's username and password. You would then create the counterparty using the plaid processor token that was obtained. Counterparties created with a Plaid token, are created, by default, with a "Credit and Debit" permission.
- Another way to authenticate the counterparty is by taking the counterparty account holder through a micro-deposit flow. While this is compliant with the network regulation, it loses the many benefits of using Plaid - Plaid's processor token allows Unit to access the counterparty account data on your behalf at any point, whereas micro-deposits provides no information other than that the person authenticating had access to the account at the point of authentication.
Unit may flag a debit ACH payment for manual review if it is considered risky according to our risk models or the monthly\daily soft limits were met due to this payment. Generally, when a a suspicious or fraudulent activity is detected, Unit will not close or freeze an account without reaching out to you first with a recommended course of action.
When originating an ACH Debit, the funds are not immediately deposited into the originator’s account, but rather wait a clearing period. This is done in order to minimize the risk of ACH debit fraud.
Originated ACH payments may be returned by the receiving financial institution for a variety of reasons.
Clients originating ACH debits must adhere to NACHA regulations of return limits. If you exceed these thresholds in any 30 day period, Unit will contact you and work with you to ensure you lower the return rates. Violation of these thresholds can result in the loss of the ability to originate ACH debits.
|Return type||Return codes||Maximum allowable threshold|
|Unauthorized returns||0.5% of total ACH debit originations in the preceding 60 days|
|Administrative Returns||3% of total ACH debit originations in the preceding 60 days|
|All returns (see this list)||15% of total ACH debit originations in the preceding 60 days|
|Reason for Return||Description||Return Time Frame|
|Insufficient funds||Available balance is not sufficient to cover the dollar value of the debit entry.||2 Business Days|
|Account closed||Previously active account has been closed.||2 Business Days|
|No Account/Not able to locate account||Account number structure is valid, but doesn’t match individual identified in entry or is not an open account.||2 Business Days|
|Invalid Account number||Account number structure is not valid.||2 Business Days|
|Account Frozen||Funds unavailable due to action by the RDFI or legal action.||2 Business Days|
|Unauthorized Debit||A debit entry was transmitted to a consumer account that was not authorized by the Receiver. Written Statement is required.||60 calendar days|
|Authorization Revoked by Customer||Consumer who previously authorized entries has revoked authorization with the Originator. Written Statement is required.||60 calendar days|
|Payment Stopped||The Receiver has requested the stop payment of a specific ACH debit entry.||2 Business Days|
|Uncollected Funds||Sufficient balance exists, but value of uncollected items brings available balance below amount of debit entry.||2 Business Days|
When originating an ACH debit, there is a risk that the RDFI (or their customer) will dispute the debit, and the funds will be pulled back to the receiving bank account (“ACH return”). By law, the receiving bank has 60 days to pull the funds back (initiate an ACH return) for ACH’s involving consumer accounts. Most returns happen in the two days after the transaction is originated.
Unlike consumer purpose account returns, a business purpose account has a 24 hour window from when the ACH posts to send a Return ACH file. This only applies when both parties of the ACH are business accounts. If one of the accounts is a consumer account then the ACH return rules will follow the ACH Return rules for a Consumer Purpose Account.
ACH Debit fraud is one of the most common forms of fraud in the payments industry.
In this scenario, a fraudster has access to two bank accounts:
- Account A on bank X - Typically an account that the fraudster has created, using seemingly legitimate information (most often, stolen identity information).
- Account B on bank Y - Typically an account that the fraudster has gained access to illegitimately.
- The fraudster originates an ACH debit from Account A on bank X, pulling funds from account B on Bank Y.
- Once the funds have been released to account A, the fraudster withdraws or spends them.
- Sometime in the next 60 days, the real owner of account B, reaches out to bank Y and reports that the payment was unauthorized. Bank Y returns the payment due to unauthorized debit. Bank X is forced to return the funds according to NACHA rules, but since account A no longer has the funds, and the fraudster has no intention of returning them, Bank X ends up taking the loss.
There is a scenario where a fraudster may use their own (or stolen) identity information to create both account A and Account B. They will then fund Account A, run the fraud "script" described above, they would reach out to bank Y and say that the transaction was unauthorized, and once the funds have been returned to account A, they would withdraw or spend them. The downside of this, is these details are now "burnt" and cannot be reused.
- Clearing: If the owner of account B notices the unauthorized transaction while the funds are "clearing", Bank X can return the funds to Bank Y. Longer clearing times reduce the risk of a return happening after the funds have been spent. The trade-off is, longer clearing times typically result in inferior customer experience.
- Name match: Using Unit and our Plaid Identity integration, you can enforce a restriction that will only allow a client to pull funds from external accounts that they own. This will significantly reduce the risk of ACH debit fraud.
- ACH debit returns are indicative of fraud. Even one ACH debit return should raise a red flag and warrants close review. The top return reasons to indicate fraud are:
Account Frozen(R16) and
When you freeze an account to conduct a review, you are giving yourself a short time for your investigation, in which you may ask the customer for more details on their activity. Ultimately, you will need to either unfreeze or close the account within five business days.