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 guide 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.

Note

Only incoming international transactions are supported. International ACH transactions cannot be originated from the Galileo system.

## Nacha compliance for outgoing ACH

To ensure ACH compliance with Nacha, reduce returns, and provide data points useful to the <<glossary:RDFI>>, the content of the outgoing ACH file that is generated and transferred by Galileo to the sponsor banks will include the relevant <<glossary:SEC code>>s for payments as well as the company name in the batch header (when applicable). The use of SEC codes determine the applicable ACH return rules and can help reduce the risk of ACH returns from a RDFI due to incorrect SEC codes.

## 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 <a href="ref:api-reference-external-trans-api-about-external-trans-api" target="_blank">External Trans API</a> 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 authorize 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 ACH transactions and if any fees apply.

  • **Payment Screening** — Whether all incoming ACH credits or tax-specific credits are screened for name mismatch.

  • **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 posting order at Galileo

In general, Galileo stages ACH transactions for posting when Galileo receives the Nacha files. When transactions are ready to post, Galileo typically posts the credits first, then the debits. However, you may see exceptions to this because there are many factors that affect posting order.

## 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 <a href="doc:ach-endpoints#adding-an-ach-account" target="_blank">Adding an ACH Account</a> 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 <<glossary: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 <<glossary:Nacha>> rules, an ACH transaction can be returned two days after the settlement date (returns past this time are allowed in certain situations).

During product setup, you have the flexibility to customize the number of hold days as needed. The countdown for these hold days start when Galileo transmits the outbound Nacha file to the ACH operator. It's important to note that hold days exclusively apply to outgoing ACH debit requests.

While Galileo's system inherently operates with calendar days for hold day calculations, you can request to have hold days configured to be based on business days instead (by setting HDACH = Y).

The Nacha file contains two dates relevant to an ACH debit transaction. The `effective_date` refers to the day the ACH is scheduled to be processed. For a non-same-day ACH, it is the date the file was created, plus one day. For same-day ACH, it is the file creation date. The `post_date`refers to the date the transaction impacts the account balance (open-to-buy), after the number of hold days have passed.

Note:

The configuration for hold days specifies the number of business days only, so there may be a larger number of calendar days than the value of hold days for particular transactions. This per-transaction increase happens when the time span of file creation date and the `hold_days` after includes weekends and holidays.

See <a href="doc:galileo-ach-workflows#outgoing-ach-debit-workflow" target="_blank">Outgoing ACH debit workflow</a> to see how the hold days are applied.

## Overriding ACH hold days

Galileo offers the flexibility to set hold days at the transaction level for outgoing ACH debits, to provide greater control over defining hold days. While using the <a href="ref:post_createachtransaction" target="_blank">Create ACH Transaction</a> endpoint, you can pass the optional `holdDays` parameter along with an integer value. When you originate an outgoing ACH debit transaction, the value you set for hold days through the API call overrides the value that was set in the product configuration.

If the `holdDays` parameter is empty or null, Galileo uses the default hold day value set at the program level.

### Example scenario

Sally has an account with ABC Bank and another account with XYZ Bank. She wants to add money to her ABC Bank card from her other bank account at XYZ. ABC Bank is powered by Galileo's platform with the program parameters ACOHD enabled and HDACH enabled for business days. Sally initiates a transfer through ABC Bank's mobile application to pull funds from her account with XYZ Bank into her ABC Bank account. ABC Bank sends a <a href="ref:post_createachtransaction" target="_blank">Create ACH Transaction</a> request with the `holdDays` parameter set to `1`.

Banking day EventDescription
MondayAPI request sent to GalileoGalileo sends a success API response and places transactions in a "Queued for transfer" status.
Tuesday (first hold day)Galileo generates Nacha fileGalileo sends Nacha file to issuing bank, triggering the beginning of the hold days period.
WednesdayHold expires at 00:00 MSTFunds are posted at midnight using

This feature requires partner bank approval. Work with Galileo to gain an understanding of the various product and program parameters that affect when hold days begin, and to ensure your program is properly configured to achieve your desired outcome.

<a href="ref:galileo-system-time" target="_blank">Galileo’s system time</a> is Arizona Time (UTC-07:00) and does not honor Daylight Savings.

## Same Day ACH

When you send an outgoing Same Day ACH request, Galileo posts the request in the Nacha file the same day that you originated the request (unless you send the request after Galileo’s cutoff time). For a normal (non-Same Day) ACH request, Galileo posts the request in the next day’s Nacha file. Same Day ACH is a premium service that requires partner bank approval.

See <a href="doc:same-day-ach" target="_blank">Same Day ACH</a> for more information.

## ACH early access

Galileo offers early access to incoming ACH deposits, a process that moves funds into a customer’s account before the settlement date. Thanks to our Early Pay feature, your customers can have early access to paychecks sent via direct deposit.

During product setup, you can request one of these configurations:

  • Enable ACH early access for _all accounts_ within a product

  • Do not enable ACH early access for all accounts, but control access for _individual_ accounts

See <a href="doc:ach-early-access" target="_blank">ACH Early Access</a> for more information.

## 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.

See <a href="doc:about-bill-pay" target="_blank">About Bill Pay</a> for more information.

## 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 <a href="ref:api-reference-events-api-ach-return" target="_blank">ACH returns</a> 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. For suspected fraud, see <a href="doc:about-disputes#ach-disputes" target="_blank">ACH disputes</a> in the _About Disputes_ guide.

### Outgoing ACH returns

When your customer sends an outgoing ACH request to an external receiver and the external receiver rejects the transaction, the <<glossary:RDFI>> is responsible for providing an ACH return code. See the <a href="doc:galileo-ach-workflows#outgoing-ach-returns-workflow" target="_blank">Outgoing ACH returns workflow</a> 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 <<glossary:ODFI>>. See the <a href="doc:galileo-ach-workflows#incoming-ach-returns-workflow" target="_blank">Incoming ACH returns workflow</a> for an overview.

You can manage incoming ACH returns using the <<glossary:CST>>. This table describes CST controls to review ACH transactions and initiate returns.

CST controlLocationDescription
**Payment Posts & Returns**System Administration > Other ToolsReview an ACH transaction and decide how to handle future ACH transactions with matching program settings.
**ACH Automation Matches**Account > ACH InfoUpdate a decision that was made for ACH transactions in Payment Posts & Returns.
**ACH Returns**System 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 History**Account > 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 Review**System 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 <a href="ref:post_modifypendingdepositstatus" target="_blank">Modify Pending Deposit Status</a> endpoint to return an incoming ACH credit. See <a href="doc:ach-endpoints#modifying-a-pending-ach-deposit-status" target="_blank">Modifying a pending ACH deposit status</a> 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 <<glossary:CST>> 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 <a href="ref:post_createfbenrollment" target="_blank">Create Federal Benefit Enrollment</a> endpoint to enroll a customer. The FBEVA and ENIAN parameters must be set to enable Federal Benefit Enrollment.

## Plaid integration

The Plaid integration with Galileo offers a simple way for your cardholders to link their external bank account and move funds between their accounts via ACH. To implement this, incorporate Plaid's front-end module into your app or website. When your cardholder uses the interface to verify an external bank account, Plaid sends you a unique token that corresponds to this account that can be used to create ACH payments via the Galileo API. Simply put, Plaid is responsible for securely linking and verifying the external accounts, and Galileo is responsible for the actual handling of ACH transactions.

When initiating an ACH transaction with the <a href="ref:post_addachaccount" target="_blank">Add ACH Account</a> or <a href="ref:post_createachtransaction" target="_blank">Create ACH Transaction</a> endpoint, pass the processor token instead of the account number and routing number. Reach out to Galileo to request detailed instructions for integrating with Plaid.

Note

Galileo uses Plaid Identity API endpoints to retrieve identity information and compare against the Galileo stored account holder information. We can work with you to customize the match requirements to best meet your business's needs.

See <a href="https://plaid.com/docs/auth/partnerships/galileo/" target="_blank">Plaid's documentation</a> about integrating with 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 number of hours after midnight to post outgoing ACH debit and incoming ACH credit. When this parameter is not set, outgoing ACH debit and incoming ACH credit post at midnight. If Same Day ACH is also enabled, funds may post one day earlier. Hold days go into effect immediately, but when ACHPT is set, it requires a refresh overnight.
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.
ACOHDProductSpecifies whether to override the default hold days, using an optional parameter called `holdDays` in the <a href="ref:post_createachtransaction" target="_blank">Create ACH Transaction</a> endpoint. Sponsor bank approval is required to use this parameter.
ACSDLProgramSpecifies the maximum amount up to 999,999 for a Same Day ACH transaction. ACHSD must also be set. If no value is set, the default value of $1 million per transaction is used.
ACSTSProgramSpecifies the acceptable account statuses to allow an incoming ACH credit request to move funds into the customer account.
BALMCProgramControls whether Galileo checks the balance and assesses fees for outgoing ACH credit transactions. Clients that maintain their own ledger should set this parameter. This affects transactions created with the <a href="ref:post_createachtransaction" target="_blank">Create ACH Transaction</a> endpoint.
BTBEIProgramControls whether to include the business ID in the Nacha file for a business-to-business ACH transfer. BTBPG must also be set. If this parameter is not set, then BTBPI must be set.
BTBPGProgramControls whether the program is a business-to-business program.
BTBPIProgramControls whether to use a custom identification number in the Nacha file. BTBPG must also be set. If this parameter is not set, then BTBEI 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).
FBEEAProductSpecifies the number of days before the effective deposit date that the account holder has early access to ACH deposits. This parameter is required to enable early access to ACH deposits for all accounts, including accounts with feature type `7` set to `Y` (enable early access).
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.