Introduction
Welcome to our ACH Platform Guide, in which we detail how our system interacts with the ACH payment rail, as well as key considerations around payment behaviors, platform actions, and operational considerations that you should be aware of as you dive into your integration. ACH (Automated Clearing House) is an electronic bank payment system that enables consumers and businesses in the United States to make payments between bank accounts. ACH transactions are processed several times in batch windows set by the Federal Reserve and according to regulations set by the National Automated Clearing House Association (NACHA).What’s Included
- Key Definitions
- User Onboarding
- Payment Behavior
- Payment Speeds
- Additional Payment Scenarios
- Operations
Key Definitions
Start here to understand terms important to an ACH transaction.Entities
Federal Reserve Serves as the backbone of the ACH network, acting as the central clearing facility for most ACH transactions. The Fed dictates the processing windows in which transfers are processed, sets the bank holiday schedule that ACH payments abide by, and manages regulations that determine underlying processing requirements and best practices. National Automated Clearing House Association (NACHA) The governing body of ACH, NACHA is the regulatory entity managing the administration, development, and governance of the network. It works closely with the Federal Reserve. Originating Depository Financial Institution (ODFI) The financial institution that initiates ACH entries at the request of its clients. ODFIs assume the risk and regulatory responsibility for ACH entries they originate and may set category restrictions, transaction limits, monitoring thresholds, and reserve requirements on clients, in addition to maintaining certain standards for visibility into participating businesses and their transaction data. Payee The business or individual receiving an ACH payment. Payer The consumer or business authorizing a payment and sending funds for an ACH payment. Processor Organizations that handle the technical aspects of routing ACH files. GrailPay is an ACH processor. Receiving Depository Financial Institution (RDFI) The financial institution that receives ACH payments and posts them to the accounts of its clients. RDFIs may have their own return rate thresholds and monitoring practices.For a larger list of ACH-relevant definitions, visit our Key Terms page in the Resources section.
ACH Entry Types
GrailPay offers three ACH entry types: WEB, CCD, and PPD. These different types of ACH have different rulesets applied by regulators, and require different handling. WEB Used to debit funds from a consumer bank account and requires explicit documented authorization. It is commonly used for online bill payments, subscription services, and e-commerce purchases. CCD Used for the transfer of funds between business accounts (B2B payments). It is often used for vendor invoice payments, corporate disbursements, and rent and utility payments. PPD Used for consumer push payments, commonly for direct deposit of payroll. Summary of ACH Entry Types| Consideration | WEB | CCD | PPD |
|---|---|---|---|
| Fraud risk | High | Medium | Medium |
| Applicable return timeframes | Most returns come in 2 banking days, with some returns having a 60 day allowable window | 2 banking days, some rare exceptions | Most returns come in 2 banking days, with some returns having a 60 day allowable window |
| Bank account validation requirements | Required | Recommended | Recommended |
User Onboarding
GrailPay support three user types for participation in payments on our platform: Merchants, Businesses, and People. Each have a dedicated API endpoint for onboarding, and require slightly different treatment for successful onboarding and management. Merchants These are companies that undergo our KYB verification, requiring specific information on the underlying business and its owners. GrailPay requires that at least one side of every payment be KYB’d, meaning that a merchant can be thought of as the anchor of an ACH payment on our platform.KYB (Know Your Business)This is the process of identifying and verifying the identity of a corporate customer to assess risk and ensure compliance with applicable regulations. This involves collecting and verifying documents related to a business’s legal structure and ownership, as well as checking for adverse media, sanctions, or high-risk affiliations. The goal is to prevent financial crimes, by ensuring we do not process payments for illegitimate or high-risk entities.
Bank account validationGrailPay supports verification of bank accounts at the time you onboard users. This is a critical step in reducing the risk of ACH payment failures due to preventable operational causes like typos during entry or outdated routing numbers. Our Account Intelligence offering, a foundational tool within our Risk Intelligence suite, provides a risk score assessing the validity of a bank account and its ability to successfuly transact ACH payments.
Payment Behavior
ACH follows consistent behavioral pathways from payer to payee. GrailPay defines the movement of funds with an ACH payment as a Transaction. Every Transaction has two legs, or, in ACH terms, originations. The first leg is the Transaction Capture, sometimes known as the debit, or pay-in, and the second leg is the payout, or credit.Payment = Transaction Capture + Payout
- Transaction Capture = first origination or debit
- Payout = second origination or credit
Transaction Capture
This is the initiation of the funds’ movement and tracks the related information regarding the debit side of the transfer, taking the funds from the payer. GrailPay’s webhooks provide numerous real-time status updates on the debit as it experiences event updates through the processing lifecycle. Transaction Started This event is fired when the Transaction is created within our system, but the ACH has not begun to process yet. This should occur in a short time following the call to our API to create the transfer of funds. Transaction Capture Started This event is fired when an ACH debit has been successfully initiated on the related transaction. It indicates the funds capture process has begun from the payer’s bank account. Transaction Failed This event is fired if the transaction fails during any stage of processing, whether due to account issues, validation errors, or ACH Return Codes. Most of these will be due to ACH Return Codes as most of our validation checks occur prior to the transaction being created. Transaction Completed This event is fired when the debit side of the transfer has completed. This means that the debit from the payer has successfully settled and we are initiating the transfer of those funds to the payee. Transaction Canceled This event is fired when a transaction is canceled and confirms that no funds will be captured or disbursed. There are limitations on the allowable time frame to cancel a transaction. Once we have processed a debit, indicating that the bank has received and accepted the ACH entry, a cancellation will not be accepted by the system.Transaction monitoringGrailPay supports active monitoring of individual transactions with Transaction Intelligence. This functionality allows you to assess the likelihood that a specific ACH transaction from a payer will successfully settle, and uses forensic analysis to predict a transaction’s risk at that moment in time.
Payout
Once the debit of the ACH has completed, the payout is created, representing the credit side of the transfer, which is us moving the funds to the payee.When processing ACH payments, the participating financial institutions ultimately dictate the exact timing at which funds are moved from and into accounts. This means that while an ACH entry may have been processed successfully by GrailPay and indicate settlement (meaning the bank has recevied the file), the action may not yet have triggered actual funds availability.
Refunds
In the event that either the payer or payee determines that the intentional reversal of a successful ACH payment is desired, a refund may be issued. If a refund is decided upon before a payout is complete, the refund can be created, and will be processed as soon as the payout is settled.Payment Speeds
GrailPay offers multiple options for the speed at which payments can move. The processing of ACH payments are dictated by pre-determined processing windows set by the Federal Reserve. This system allows for payments to be initiated throughout the day before being processed in the next window.Standard ACH
GrailPay processes Standard ACH on a four day settlement schedule, meaning the payout occurs four banking days after the payment initiation. Actual funds availability to the payee will ultimately be determined by their financial institutions internal policies.Fast ACH
GrailPay processes Fast ACH on a same or next day settlement schedule, depending on what time the payment is initiated. Actual funds availability to the payee will ultimately be determined by their financial institutions internal policies.Additional Payment Scenarios
ACH Returns
ACH payments can fail for a variety of reasons including things like a closed bank account, a debit-blocked bank account, insufficient funds in the payer’s bank account, and even sanctions freezes on bank accounts. ACH returns are unique in that they occur after the initial payment initiation. The overwhelming majority of returns occur within two banking days of the initial payment initiation, and for B2B ACHs (CCD), are generally limited to this timeframe. Returns on consumer, or WEB ACHs, also typically occur within two days, but do have a 60 day allowable time frame from payment initiation for payer disputes. When doing Standard ACH (four day settlement), returns are typically triggered before a payout has occurred, in which case the funds from the credit are seamlessly returned to the payer. When doing Fast ACH (same/next-day settlement), it is more common to see returns triggered after the payout has occurred. In this scenario, GrailPay’s system automatically initiates a clawback, which debits the payee bank account to offset the funds that went back to the payer due to the return.You can find additional information on possible ACH returns in our Resources.
Notice of Change (NOC)
Occasionally in the course of processing ACH, a Receiving Depository Financial Institution (RDFI) will issue a Notice of Change, or NOC. These communicate when an ACH entry is outdated or incorrect. The RDFI sends the NOC to the Originating Depository Financial Institution (ODFI) to notify them of the erroneous account information, in which case we are allowed six days to update the bank account information. In most cases when a NOC is issued, an ACH payment will still process successfully. GrailPay will communicate the receipt of NOCs when they are received, and update the relevant bank account information as is required.Clawback
A clawback is triggered automatically when an ACH return occurs after the payout has been processed. In this scenario, the return has already reversed the funds back to the payer, and the clawback is debiting the merchant bank account to zero out the difference.Reverse Payout
These occur when the payee bank account is not active, or in some rare scenarios, cannot be credited. In such instances, the funds are sent back to the payer.For a full list of possible ACH payment behaviors and their associated GrailPay events and statuses, reveiw our dedicated Resource page.