ACH at Galileo

You can enable a product for ACH transactions and specify the types of ACH transactions that customers can originate and receive using your product. This section discusses how ACH works at Galileo and the decisions to make before you set up a product for ACH.

Incoming and outgoing transactions

Galileo uses the terms “incoming” and “outgoing” to indicate whether an ACH transaction originates from an external account or your customer’s account in the Galileo system.

  • An incoming ACH transaction is externally originated. The originator initiates the transaction from an external account and the receiver is your customer in the Galileo system.
  • An outgoing ACH transaction is Galileo-originated using Program API endpoints. Your customer initiates the transaction from an account in the Galileo system and the receiver is an external entity.

ACH credit and ACH debit

An ACH transaction is classified as credit or debit depending on whether the originator moves funds into or out of the receiver’s account. This means that an ACH credit is a credit to the receiver and an ACH debit is a debit to the receiver. The receiver must authorize the request before funds are moved. The originator can make an ACH credit or debit request regardless of whether the transaction is incoming or outgoing.

ACH credit — The originator moves funds into the receiver’s account. For example:

  • An employer makes a direct deposit to your customer’s account via ACH transaction.
  • A cardholder cashes out their Venmo or Paypal account balance and opts to use ACH payment.

📘

Note

An incoming ACH credit is often called a direct deposit. Some examples of incoming ACH credit are: a payroll deposit from an employer, a tax refund, a government stimulus check, and an incoming transfer from the customer’s own external account. Galileo does not make a distinction between a direct deposit and any other incoming ACH credit.

ACH debit — The originator moves funds out of the receiver’s account. For example:

  • Your customer has an external account at another bank and posts an outgoing ACH debit that moves funds out of the external account and into the account under your product.
  • A business bills your consumer customer and removes funds from your customer’s account via ACH transaction (commonly used for utility bills, mortgage payments, other loan payments, etc).
  • Your business customer bills an external business and draws funds from the external business’s account via ACH transaction.

Nacha file

Nacha (National Automated Clearing House Association) is the organization that oversees the ACH system and sets the standards for ACH transactions. A Nacha file contains bulk ACH transaction instructions in a standardized format. The ODFIODFI - Originating Depository Financial Institution. The financial institution that originates an ACH request. sends the transaction in one Nacha file and the RDFIRDFI - Receiving Depository Financial Institution. The financial institution that receives an ACH request. sends the settlement decision in a separate Nacha file. A clearing house in the ACH network transfers Nacha files between banks.

Galileo creates and sends one Nacha file per day for each bank that Galileo is integrated with. Galileo sends each Nacha file via SFTP.

📘

Note

Galileo uses the Nacha file format to process ACH transactions. The Nacha file format is a standardized format that all banks in the ACH network are equipped to process. Nacha files are encrypted.

Decisions to make before setting up ACH

Before setting up a product that is enabled for ACH transactions, you have several decisions to make.

  • Allow incoming ACH credits — Whether to allow incoming ACH credits.
  • Allow incoming ACH debits — Whether to allow incoming ACH debits. By default, incoming ACH debits are not allowed.
  • Use External Trans API for incoming ACH debits — If incoming ACH debits are allowed, you can use the External Trans API to review incoming ACH debits before posting. You can either review all incoming ACH debits, or only incoming ACH debits in which the receiver's account lacks sufficient funds. If you do not use the External Trans API, then incoming ACH debits will post automatically (subject to Galileo's logic).
  • Account statuses for incoming ACH — Acceptable account statuses for accounts to accept incoming ACH transactions. Galileo recommends declining incoming transactions to accounts that are closed or charged-off.
  • Hold days for outgoing ACH debit — Number of hold days for outgoing ACH debit.
  • Early ACH access — Whether account holders have early access to incoming ACH credit.
  • Same-day ACH — Whether to allow same-day outgoing ACH transactions.
  • Approval for direct deposit — Whether direct deposits require manual approval in certain circumstances. For instance, you may want to manually approve a transaction if the amount exceeds a specified limit or if it originates outside of the U.S.

ACH accounts

Before you can originate an ACH transaction, you must provide the receiver’s external bank account and routing number. Galileo stores this information in an ACH account. See Adding an ACH Account for more information on how ACH accounts are structured at Galileo.

Setup for ACH transactions

In an ACH transaction, funds are usually transferred between a settlement account at the RDFI and a settlement account at the ODFI via the ACH network. However, the method used to transfer funds may vary depending on regulations that each DFI is subject to. Work with your DFI to determine how to send and receive funds for ACH transfers.

ACH hold days

When your customer in the Galileo system originates an outgoing ACH debit request to move funds into their account, Galileo recommends setting a waiting period of at least three calendar days before the funds can be transferred to the customer’s account. These hold days give the receiver time to deny the request before the funds are debited from the receiver’s account. Per NachaNacha - National Automated Clearing House Association. This term describes the ACH transaction file that Galileo receives. rules, an ACH transaction can be returned two days after the settlement date (returns past this time are allowed in certain situations).

You can adjust the number of hold days during product setup. The hold days timer starts when Galileo sends the outgoing Nacha file to the ACH operator. Hold days only apply to outgoing ACH debit requests.

See Outgoing ACH debit workflow to see how the hold days are applied.

Recurring ACH transactions

You can set up an ACH account to make recurring outgoing ACH transactions to the linked external account. Use the ACH Loads page in the CSTCST - Customer Service Tool. Software that the Galileo customer service team uses, which is also available to providers, to view customers and their accounts. to create and modify recurring transactions rather than the Program API. To set up a recurring ACH transaction, add the following information to the ACH account using the CST:

  • The start date for recurring ACH transactions.
  • The end date for recurring ACH transactions (if known).
  • The frequency of the recurring transaction (for example, weekly, monthly, yearly).
  • The transaction amount.

Same-day ACH

A standard ACH transaction takes multiple days to settle. NachaNacha - National Automated Clearing House Association. This term describes the ACH transaction file that Galileo receives. rules allow for a same-day ACH credit that is posted to the receiver’s account on the day that the transaction is originated. There is usually a fee for same-day processing.

📘

Note

It is not guaranteed by the ODFIODFI - Originating Depository Financial Institution. The financial institution that originates an ACH request. or the ACH operator that a same-day ACH credit will settle on the same day it is originated. Cutoff times apply (described below), and after settlement, the RDFIRDFI - Receiving Depository Financial Institution. The financial institution that receives an ACH request. has two days to initiate a return.

To post a same-day ACH request, call the Create ACH Transaction endpoint with sameDay set to Y. The ACHSD parameter must also be set to Y to enable same-day processing.

Same-day ACH is only available for ACH credit. International transactions and transactions over $25,000 are not eligible for same-day ACH.

To achieve same-day settlement, the Nacha file must reach the ACH operator before the cutoff time. There are a few deadlines to keep in mind when posting a same-day transaction.

  • Galileo’s cutoff time — The time of day that Galileo generates a Nacha file for outgoing ACH transactions that originate from your program. This is usually about 40 minutes before your own cutoff time.
  • ODFI cutoff time — The time of day that the ODFI retrieves the Nacha file from Galileo and sends it to the ACH operator.
  • ACH operator cutoff time — Send the Nacha file to the ACH operator by the cutoff time shown below to meet your target time for funds availability.

This table shows the ACH operator’s transmit deadline and corresponding time that funds are available to the receiver for same-day ACH. Times are in Eastern Time (but be aware that Galileo’s system time is Mountain Standard Time (UTC-07:00)).

ACH operator cutoff timeFunds available to receiver
(depending on applicable hold days)
10:30 AM1:30 PM
2:45 PM5:00 PM
4:45 PMEnd of processing day

ACH early access

Galileo supports early access to incoming ACH deposits, a process that moves funds into a customer’s account before the settlement date. During product setup, you can request to enable a product for early ACH access and later you can specify when account holders have early access to deposits.

ACH vs. bill pay

Bill pay is a service that is separate from ACH. Account holders can use bill pay to make payments to service providers, either electronically or with a paper check. It is often more convenient for account holders to use the bill pay service than to pay bills via ACH. While an ACH transaction can take a few days to process, funds from an electronic bill payment can be made available to the biller the same day the bill is paid, depending on cutoff times.

The bill pay service also makes it easier to cancel a recurring bill payment. For example, if the customer cancels a gym membership, the gym may not stop the ACH requests and may continue to debit the customer’s account after the membership is terminated. Bill pay allows an account holder to pay service providers without giving them access to bank account information.

📘

Note

Most Galileo programs do not enable incoming ACH debit but use bill pay instead.

To use bill pay instead of ACH, use the bill pay endpoints:

ACH returns and stop payment orders

An ACH return is initiated when an ACH transaction is rejected by the receiver or receiver’s bank. There are three types of ACH returns at Galileo.

  • Outgoing ACH return — An external bank rejects an outgoing ACH transaction originating from your customer.
  • Incoming ACH return — You or Galileo reject an incoming ACH transaction from an external originator.
  • ACH stop payment order — A type of incoming ACH return that blocks an ACH debit before Galileo processes it.

📘

Note

An ACH return can only be sent for specific reasons and must include an ACH return code. Excessive or fraudulent returns can result in fines.

This section describes each type of return in detail.

Outgoing ACH returns

When your customer sends an outgoing ACH request to an external receiver and the external receiver rejects the transaction, the RDFIRDFI - Receiving Depository Financial Institution. The financial institution that receives an ACH request. is responsible for providing an ACH return code. See the Outgoing ACH returns workflow for an overview.

📘

Note

In some cases, there is a problem with an outgoing ACH transaction but the transaction can still be posted. When this happens, the RDFI can post the transaction instead of sending a return, and may send a notice of change that states what the error is and how to correct it.

When an outgoing ACH credit is returned to your customer, the resolution depends on when in the ACH process that the return was sent.

  • If the funds were not posted, the pending transfer is cancelled.
  • If the funds were posted, they are returned and Galileo adjusts the amount for your customer’s account.

Incoming ACH returns

When you or Galileo reject an incoming ACH request, Galileo prepares a Nacha file with the return and sends a return code to the ODFIODFI - Originating Depository Financial Institution. The financial institution that originates an ACH request.. See the Incoming ACH returns workflow for an overview.

You can manage incoming ACH returns using the CSTCST - Customer Service Tool. Software that the Galileo customer service team uses, which is also available to providers, to view customers and their accounts.. This table describes CST controls to review ACH transactions and initiate returns.

CST controlLocationDescription
Payment Posts & ReturnsSystem Administration > Other ToolsReview an ACH transaction and decide how to handle future ACH transactions with matching program settings.
ACH Automation MatchesAccount > ACH InfoUpdate a decision that was made for ACH transactions in Payment Posts & Returns.
ACH ReturnsSystem Administration > Other ToolsQueue for ACH transactions that are in status: i (manual review). A transaction appears in this queue if it violates load limits, if the receiver’s account status does not allow ACH transactions, or if it was sent for review via the External Trans API.
Payment HistoryAccount > Account InfoDisplays the payment history for an account. On this page, you can mark an ACH transaction for return and select a return code.
ACH Debit Block ReviewSystem Administration > Other ToolsShows partial matches for ACH stop payment orders. You can approve the block and start a return. See ACH stop payment orders for more information.

Alternatively, you can use the Modify Pending Deposit Status endpoint to return an incoming ACH credit. See Modifying a pending ACH deposit status for more information.

ACH stop payment orders

When your customer wants to block an incoming ACH debit from a specific originator, you can ask Galileo to set up an ACH stop payment order. This type of return stops an incoming ACH debit before it is processed by Galileo. You provide the following information:

  • Your customer’s account number
  • Name of the business that originated the ACH debit to block
  • Amount or range of amounts to block.
  • Date or range of dates to block.

Galileo compares the business name in incoming ACH debit requests against the business name you provided for the ACH debit block. When there is an exact match, the transaction is blocked. When there is a partial match, you must manually review the transaction to verify the stop payment order. Review ACH stop payment orders in the CSTCST - Customer Service Tool. Software that the Galileo customer service team uses, which is also available to providers, to view customers and their accounts. on the ACH Debit Block Review page.

Federal benefit enrollment

Federal benefit enrollment is a process that informs the U.S. federal government to send federal benefits to a customer via ACH deposit. Use the Create Federal Benefit Enrollment endpoint to enroll a customer. The FBEVA and ENIAN parameters must be set to enable Federal Benefit Enrollment.

Plaid integration

Plaid integration with Galileo is a simple way for customers to move funds between accounts via ACH. You place Plaid’s front-end module on your app or website. When your customer verifies an external bank account using Plaid, Plaid sends you a public token and account ID that you can use to generate a unique processor token for the external account. Galileo can provide you with instructions for Plaid integration.

When you send a call to the Add ACH Account or Create ACH Transaction endpoint, pass the processor token through the endpoint instead of the account number and routing number.

See Plaid's documentation about integration with Galileo at plaid.com/docs/auth/partnerships/galileo/.

Incoming ACH account verification

An external originator can verify your customer’s account information before making an incoming ACH request for the first time. This often occurs for a new recurring ACH transaction. These are common methods for verifying the receiver’s account:

  • Prenotification — The originator posts a non-monetary transaction that indicates the intent to transfer funds. A successful prenotification verifies that the receiver’s account is valid.
  • Microtransactions — The originator makes small test deposits to the receiver’s account, then debits the same amount out of the receiver’s account. A successful series of micro-deposits and micro-debits verifies that the receiver’s account is valid.
  • Bank login verification — Some banks support applications that allow account holders to add and verify their account information. Plaid verification is one example of this.

Galileo setup

These internal parameters must be set at Galileo for ACH, according to your use case.

ParameterLevelDescription
ACCRDProgram or productControls whether to allow incoming ACH credit requests to move funds into the customer account.
ACDBTProgram or productControls whether to allow incoming ACH debit requests to move funds out of the customer account.
ACDBXProgram or productControls whether you participate in the approval of incoming ACH debit requests via the External Trans API.
ACHCAProgram or productControls whether to verify that the receiving account is active before posting an incoming ACH debit request.
ACHCBProgram or productControls whether to check account balance for insufficient funds before posting an incoming ACH debit request. If this parameter is set to N, an incoming debit may drive the balance negative, depending on settings for ACHDN and ACHOD.
ACHDNProgram or productControls whether an incoming ACH debit request to move money out of a customer account is allowed to drive the account balance negative. MBCHS must also be set.
ACHODProductControls whether an incoming ACH debit request to move funds out of the customer account can draw funds from an overdraft account when there are insufficient funds in the primary account.
ACHPTProductSpecifies the time of day to post delayed outgoing ACH debit and delayed incoming ACH credit requests.
ACHRQProgram or productControls whether you participate in the approval of ACH returns. When set, all ACH returns except R01 and R03 are set to status: i (pending approval).
ACHSDProgramControls whether same-day ACH transfers are enabled and processed as same-day transfers.
ACSTSProgramSpecifies the acceptable account statuses to allow an incoming ACH credit request to move funds into the customer account.
BTBEIProgramControls whether to include the account holder’s name and business ID in the Nacha file for business-to-business ACH transactions. BTBPG must also be set.
BTBPGProgramControls whether the program is a business-to-business program.
BTBPIProgramControls whether to include the business ID in the Nacha file for a business-to-business ACH transfer. BTBPG must be set.
EAIAAProductControls whether all accounts have early access to ACH deposits or only accounts with feature type 7 (ACH early access) set to Y have early access. FBEEA must be set to enable early access.
FACHAProductControls whether incoming ACH credit or debit transactions trigger ACHR: ach_debit_fail event alert when the transaction returns status: E (error) or status: R (bad routing number).
FBEEAProductEnables early access to ACH deposits and specifies the number of days before the effective deposit date that the account holder has early access to funds.
FBEVAProductEnables Federal benefits enrollment and specifies product IDs that share a Federal benefits enrollment virtual account balance for incoming ACH credit.
HDACHProductControls whether to calculate hold days for ACH transactions in terms of business days instead of calendar days.
LMACHProductSpecifies the minimum and maximum amounts for an ACH debit request that is set up with the Customer Service Tool.
MBCHSProductControls the minimum amount that must remain in the customer account after an outgoing ACH credit moves funds out of the customer account.
NTSAAProductControls whether to send the ACRT: ach_return event message when an originated ACH transfer is returned.

Did this page help you?