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.

## 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 <<glossary:ODFI>> sends the transaction in one Nacha file and the <<glossary:RDFI>> 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.

## Nacha compliance for outgoing ACH

To ensure ACH compliance with Nacha, reduce returns, and provide data points useful to the RDFI, the content of the outgoing ACH file that is generated and transferred by Galileo to the sponsor banks will include the relevant standard entry class (SEC) codes for payments as well as the company name in the batch header (when applicable).

SEC codes are payment types used by originators to identify ACH debit and credit entries transmitted to a corporate or consumer account at the RDFI. The use of SEC codes determines the applicable ACH return rules and can help reduce the risk of ACH returns from a RDFI due to incorrect SEC codes.

The most notable difference between business-to-business (B2B) versus business-to-consumer (B2C) money movement models is the party receiving the payment. In B2B commerce, a business sells a product or service directly to another business. In B2C commerce, a business sells a product or service directly to a consumer.

### SEC code support for businesses and consumers

Galileo supports four SEC codes to solidify our commitment to adapt to industry standards and ensure strict compliance for originating ACH transactions. When using the [Create ACH Transaction](🔗) endpoint, the appropriate SEC code is determined based on the account types in the Galileo system for the source and destination accounts.

### File generation based on SEC code

Nacha files are formatted in a digital envelope and contain important instructions. The batch header contains specific information about the payment, such as the SEC code, description, and effective date. The detailed transaction record includes information about the payee (banking information), and the amount to be paid. Below are more details specific to the file format generated by Galileo.

#### Batch header record / Entry details record

The three-character SEC code is indicated in Field 6 of the Company / Batch Header record (type 5), which is populated by Galileo. Additionally, In accordance with Nacha guidelines, Fields 7, 8, 9 in the Entry Detail Records are populated based on the SEC code, respectively:

• **CCD** — Identification Number, Receiving Company Name, and Discretionary Data

• **PPD** — Individual Identification Number, Individual Name, and Discretionary Data

• **CIE** — Individual Name, Individual Identification Number, and Discretionary Data Note: This code is applicable for outgoing credits only. Galileo does not support outgoing ACH debits from consumer to corporate accounts.

• **WEB** — Individual Identification Number, Individual Name, and Payment Type Code

##### Entry details record

Depending on the nature of transactions between business or consumer accounts, the “Individual Identification Number” or “Identification Number” field may be mandatory or may be optional:

• **B2B funds transfer** (CCD) — The Identification Number is optional.

  • Galileo uses the client-provided value passed in the identNumber field in [Create ACH Transaction](🔗). It should contain the account number by which the Receiver is known to the Originator. It is included for further identification and for descriptive purposes.

• **B2C funds transfer** (PPD) — The Individual Identification Number is optional.

  • For a return fee related to an ARC, BOC, POP, or RCK entry, or to an item that was eligible to be converted to a debit entry, but was not converted, this field must contain the Check Serial Number contained within the ARC, BOC, POP, or RCK Entry or item.

• **C2B funds transfer** (CIE) — The Individual Identification Number is mandatory.

  • Galileo uses the -value passed in the identNumber field in [Create ACH Transaction](🔗). It should contain the account number by which the Originator is known to the Receiver, in order to update accounts receivable records. It should be the number shown on an invoice, statement, billhead, notice, or other communication as the reference. Numbers may be policy, customer, invoice, meter, sequence, and/or alphanumeric combinations.

• **C2C funds transfer** (WEB) — The Individual Identification Number is mandatory for credit transactions.

  • For a Person-to-Person (P2P) entry, this field contains the name of the Originator for use by the RDFI on the periodic statement.

#### Company name update

For a B2B transaction, it is important to have a placeholder to pass the payee’s information to the RDFI. For example, “ABC Fintech” operates as a business program within the Galileo platform, specializing in providing business banking services to enterprises. “XYZ Corp” is a business that is a customer of ABC Fintech (the business name on the Galileo account is XYZ Corp). When XYZ Corp initiates an outgoing ACH, the Company Name field in the outgoing ACH file will include the value “XYZ Corp” .

📘

Note

Many of the outgoing payments from business accounts are for supplier/vendor payments, and vendors need to know the actual sender of the transaction for reconciliation purposes.

Business programs need to accurately populate the business name field of the business accounts hosted in the Galileo system with the name by which the Originator is known to and readily recognized by the Receiver of the ACH entry. This ensures the correct value is retrieved during ACH transaction processing:

• **Existing accounts under business programs** — use [Update Account](🔗) to update the businessName field.

• **New business programs** — populate the `businessName` field while using [Create Account](🔗).

Use [Add ACH Account Corporate](🔗) to link an external business account to the account in the Galileo system. This distinguishes whether transactions are CCD or PPD, based on the source and destination account type.

📘

Note

You may need to modify the existing flow in your application to capture this additional information about whether the account being linked is an individual or a business account. Subsequently, you would need to call the appropriate endpoint based on this distinction.

### Testing outgoing ACH

Galileo supports testing in CV using the [ACH Simulation](🔗) endpoints. Follow the step-by-step instructions for consumer programs or for business programs.

#### Consumer Programs (C2C/C2B)

1. Use [Create Account](🔗) to create an account on the Galileo platform.

2. Use [Add ACH Account](🔗) to link an external consumer account to the Galileo-powered account. This can be a fake account for a CV environment.

3. Use [Create ACH Transaction](🔗) to initiate an outgoing debit or a credit.

   1. Provide the test account PRN and a corresponding dollar amount.

   2. Add a value to the `identNumber` field:

      1. **C2B** (CIE) — Enter the account number by which the Originator is known to the Receiver. It is used by the receiver to update accounts receivable records. It should be the number shown on an invoice, statement, bill head, notice, or other communication as the reference. Numbers may be policy, customer, invoice, meter, sequence, and/or alphanumeric combinations. _Mandatory_.

      2. **C2C** (WEB) — This field contains the name of the Originator for use by the RDFI on the periodic statement. _Mandatory_. Galileo then uses the user test account PRN(s) and the corresponding dollar amount(s) to generate a test file, which is sent via secure email by Galileo to the issuing bank for file processing validation and feature signoff.

#### Business Programs (B2C/B2B)

1. Use [Create Account](🔗) to create a corporate account on the Galileo platform. (If an account already exists, skip to step 2.)

   1. Ensure the `businessName` field for this account is configured with a valid value. Use Update Account to update this if needed.

2. Use [Add ACH Account Corporate](🔗) to link an external business account to the Galileo powered account. This can be a fake account for a CV environment.

3. Use Use [Create ACH Transaction](🔗) to initiate an outgoing debit or a credit.

4. Provide the user test account PRN and the corresponding dollar amount.

5. Add a value in the `identNumber` field:

   1. **B2B** (CCD) – Pass the account number by which the Receiver is known to the Originator. Used for further identification and for descriptive purposes. _Optional_.

   2. **B2C** (PPD) – For a Return Fee Entry related to an ARC, BOC, POP, or RCK Entry, or to an item that was eligible to be converted to a debit Entry but was not converted, this field must contain the Check Serial Number contained within the ARC, BOC, POP, or RCK Entry or item. _Optional_.

Galileo then uses the user test account PRN and the corresponding dollar amount to generate a test file. That test file will be sent via secure email by Galileo to the Issuing Bank for file processing validation and feature signoff.

📘

Note

For detailed instructions for how to use the above APIs, please see [ACH Endpoints](🔗).

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

In general, Galileo stages ACH transactions for posting when requests are received. 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 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).

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.

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

## ACH Hold Days Override

We now offer 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 `createAchTransaction` API, you can now pass a new optional parameter: `holdDays` 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.

When the API request is initiated with the new parameter and value, Galileo receives the API request and the transaction is queued in Galileo’s ACH system. Once Galileo’s ACH system processes the transaction, the Nacha file is generated and sent to the partner bank. The different parameters set up for your program determine when the Nacha file is generated by Galileo, which begins the `holdDays` countdown.

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

#### Requirements

1. Get approval from your partner bank to be able to use this feature.

2. Work with your RM to enable the product configuration `ACOHD` to use the optional API parameter.

📘

Note

There are various product parameters that could affect when the `holdDays` countdown begins and ends. To make sure you get the expected results, you may want to review those other configuration settings for your program.

Galileo’s system time 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 available for both ACH credit and debit, with a $1,000,000 per-transaction limit. International transactions are not eligible for Same Day ACH.

For fraud prevention purposes, <a href="doc:ach-at-galileo#ach-hold-days" target="_blank">ACH hold days</a> apply to Same Day ACH. Hold days control when the funds are posted to the receiving account. Cutoff times also apply (described below), and after settlement, the <<glossary:RDFI>> has two days to initiate a return.

To post a Same Day ACH request, send the <a href="ref:post_createachtransaction" target="_blank">Create ACH Transaction</a> endpoint with `sameDay` set to `Y`. The ACHSD parameter must also be set to `Y` to enable Same Day processing.

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 Arizona Time (UTC-07:00)). If the 3:00 PM deadline is missed, the transaction is sent and settled in the first time slot the following business 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. Galileo Early Pay is a feature of ACH early access, where 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

Clients can request the _ACH Early Access_ guide 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 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. For suspected fraud, see <a href="doc:about-disputes#ach-disputes" target="_blank">ACH disputes</a> in the _About Disputes_ guide.

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

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

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 <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 through the endpoint instead of the account number and routing number.

📘

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 Plaid's documentation about integration with Galileo at <a href="https://plaid.com/docs/auth/partnerships/galileo/" target="_blank">plaid.com/docs/auth/partnerships/galileo/</a>.

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