ACH Payments

If you’re building a service that will enable your customers to send and accept payments, issue cards, or transfer money between accounts at different institutions, chances are you’ll need ACH.

Overview

ACH is a one-stop shop for a variety of payment use cases. From recurring payments and payroll deposits to online purchases and bill payment, ACH offers a fast and flexible way to send money.

Originally established in 1970, expanding support and innovation around ACH payments has led it to become one of the most popular online payment rails in the world.

What is an ACH Transaction?

An ACH transaction (often referred to as an ACH transfer) is an electronic, bank-to-bank money transfer processed through the Automated Clearing House (ACH) Network. You can think of the ACH Network as a postal service for ACH files. Each file can contain up to 1000 ACH entries with each entry representing a transaction being sent from one bank to another.

ACH transactions can be used to facilitate Person-to-person (P2P), Business-to-consumer (B2C), and Business-to-business (B2B) payments and is a convenient alternative to card networks, wire transfers, paper checks or cash. In addition to their convenience, ACH transactions are reliable, inexpensive, fast, and most importantly, safe. Most transfers are processed and settled within 1-2 business day with zero cost to the consumer.

What are the 2 types of ACH Transactions?

Each ACH transaction involves 2 primary parties:

1. The Originating Depository Financial Institution (ODFI) which is the bank initiating the transaction; and
2. The Receiving Depository Financial Institution (RDFI), the bank receiving the transaction).

All transactions fall into one of two categories, debit (“pull”) or credit (“push”).

Push (Credit)

Determining if a transaction is a push or pull is always with respect to the receiving account. For example, if Tom, a customer of Bank A wants to send money to John, a customer of Bank B. Tom’s bank can originate an ACH push transaction from his account to John’s account. The term “push” is used interchangeably with “credit”. The result is a credit to John’s (the receiver) account balance and a debit to Tom’s (the sender).

A real life use case for push transactions are the deposits that result from an employee signing up for payroll direct deposit. Whenever payday rolls around, the employer’s bank initiates a push/credit to the employee’s bank account.

Pull (Debit)

Alternatively, if Tom want’s to request money from John, Tom’s bank can originate an ACH pull request from his account to John’s. The term “pull” is used interchangeably with “debit”. The result is a debit to John’s account and a credit to Tom’s. This is what occurs when users of a service sign up for recurring bill payments. The service provider ends up debiting the customer’s account via an ACH pull request.

This is also the case when a banking customer deposits a check made out to him/her by an account holder at another financial institution. Checks are ultimately translated into pull request on the ACH network. The check contains the account holders routing and account number which are the only pieces of information required to initiate a credit or debit from an account at another institution.

There is a difference between the direction of an ACH transaction and the direction of money flow. The direction of the transaction refers to the direction of the ACH message on the network. It always flows from the originator to the receiver while the direction of money flow relates to which account is receiving funds and which account is sending them. This means there are 2 ways to achieve the same direction of money movement.

Scenario

The desired result is to withdraw funds from an account at Bank A and deposit them into an account at Bank B

Option 1 (This is how customers fund their accounts)

Bank B sends an ACH debit / pull transaction requesting funds from the account at Bank A:

Option 2

Bank A sends an ACH credit / push transaction to send funds to the account at Bank B.

How does Synctera support ACH?

From the outside, the ACH workflow may seem simple, but it’s actually quite complex. This is where Synctera comes in. Synctera works with your sponsor bank to serve as your connection to the ACH network and supports sending and accepting ACH transactions from other financial institutions.

In ACH terms, Synctera acts as the ODFI (Originating Depository Financial Institution) when it comes to originating transactions and the RDFI (Receiving Depository Financial Institution) when it comes to receiving them. It means that we take care of all the batch processing and file generation while ensuring that all transactions are reflected in your customer account balances.

FinTech in the Auth Flow

Synctera allows the FinTech to participate in the transaction authorization decision for Inbound ACH Direct Debit.

This capability can only be enabled for linked zero balance accounts and can be used to:

• Restrict payments to certain institutions
• Run your own balance checks against the linked balance carrying account

If the transaction is declined by the FinTech, then an ACH return will be sent to the network.

The FinTech does not have to participate unless there is an additional approval logic. If the FinTech opts not to participate in the Auth Flow, Synctera will use default authorization logic to authorize the transactions.

In order to participate in Auth Flow for Pull (Debit) ACH transactions, the FinTech should support an Authorization Gateway and a corresponding Gateway Endpoint must be configured on the Synctera side.

Authorization Gateway

An authorization Gateway enables a FinTech to optionally take part in the decision of a Pull (Debit) ACH transaction’s authorization cycle. The FinTech receives an authorization request via the configured Gateway to either approve or decline corresponding ACH transactions based on the FinTech’s own business logic.

Request Body

Synctera sends such information as a POST HTTP request to the FinTech about Pull (Debit) ACH transactions that needs to be authorized:

JSON

{
  "customer_id": "2b9cc6f2-d0bd-4d9d-aa20-5e53355f9469",
  "account_id": "0221e0a7-7774-48a4-8521-e678ec09a53a",
  "transaction_id": "9b59fc80-9bf5-4749-8dd2-511f183becf2",
  "settlement_date": "2022-03-25",
  "effective_date":  "2022-03-25",
  "transaction_type": "incoming_debit",
  "dc_sign": "debit",
  "amount": 100,
  "currency": "USD",
  "network": "ACH"
}

Response HTTP code

To signal an authorization request decision, the FinTech must reply with the appropriate HTTP code:

• HTTP code 200: approve the corresponding ACH transaction
• HTTP code 402: decline the corresponding ACH transaction

Receiving any other HTTP code in the response will stop the processing of the corresponding Pull (Debit) ACH transaction. However, in this case the transaction will not be declined, but will be retried within 2 days until the FinTech responds with either 200 or 402 response.

Response timeout

Synctera waits for the authorization response within the timeout window which defaults to 1.5 seconds, but can be configured in the Gateway Endpoint Configuration.

If the response is not received within the defined timeout window, the corresponding Pull (Debit) ACH transaction will stop being processed. But will not be declined and will be retried within 2 days until the FinTech sends the response within the defined timeout window.

Gateway Endpoint Configuration

To configure a Gateway for the FinTech, a valid publicly accessible url must be provided.

Additionally, custom_headers and custom response timeout in milliseconds max_wait_ms can be configured. Also, Gateways may be disabled by setting the disabled field to true.

Shell

curl \
  -X POST \
  -H "Authorization: Bearer $apikey" \
  -H "Content-Type: application/json" \
  $baseurl/v0/ach/gateways \
  --data-binary '
  {
    "url": "https://example-fintech.com/ach/auth",
    "custom_headers": {
      "key1": ["value1", "value2"],
      "key2": ["value"]
    },
    "max_wait_ms: 1500,
    "disabled": false
  }'

How are accounts funded using ACH?

Once your customers have an account setup, they’ll need to fund their account by originating an ACH pull/debit transaction to be sent to their account at another institution. Synctera refers to this as an external account.

If you have just created account B on the Synctera platform and you want to add funds to it from account A at another financial institution, its natural to assume that funding involves pushing funds from account A to account B. Instead, funding your customers account involves originating an ACH debit/pull transaction with your Synctera account in order to withdraw funds from the external account.

How do I get started with sending/receiving ACH payments?

1. Customer Creation

   1.1 Create a Customer

   Any individual wanting to transact on the Synctera platform must be stored as a customer in our system. Part of that includes completing the KYC process. See the Customer guide for details.

2. Account Creation

   2.1 Create an Account

   In order to send and receive ACH payments you will need to create an account and associate it with your customer. Account Guide

   2.2 Create an External Account

   In order for your customers to fund their accounts they’ll need to debit funds from an account at another institution. You’ll need to create an external account on the Synctera platform which serves as the internal representation of the account to be debited. External Account Guide

3. Send/Receive an ACH

   3.1 Send an ACH request

   Once the external account has been verified, ACH transactions (credits and debits) can be originated from your customer’s account. If you’re unsure what values to set in your API request take a look at the documentation here.

   3.2 Receive an ACH transaction

   As long as your customer has an account that is both active and verified, there is no work required by you or your customer to receive ACH transactions. Synctera will process the incoming transaction and debit/credit the account accordingly.

What happens after I send an ACH request?

After you send a request to originate an ACH transaction, the transaction is placed in a batch which, in turn, is placed in an ACH file to be sent out over the network. Depending on the time that you originate the transaction there may be some delay between the time the transaction is created and the time the file is sent. This is done to align with the processing schedule set by the federal reserve. The date the transaction is sent will ultimately determine when funds are settled across accounts and institutions. It will also have a bearing on if and when an ACH transaction can be returned by the recipient.

The responsibilities and guidelines for participants in the ACH system are determined by the National Automated Clearing House Association, better known as NACHA. NACHA operates as the rule making body for all financial institutions wanting to use the ACH system.

What do I need to do to receive an ACH transaction?

Nothing. Unless an incoming transaction needs to be returned (see Why would an ACH transaction be returned?), no action is required. Synctera will process all debit and credits for any ACH transactions that we receive on behalf of you or your customers. Check your Synctera dashboard to view all ACH transaction that have been sent or received. Synctera also supports webhooks to notify you of all ACH transactions.

How long does it take to process an ACH transaction?

The time it takes for the network to completely process an ACH transaction is dependent on a number of variables. The operating schedule of the federal reserve, the operating schedule of each bank, and the time of day the transaction was created are all key factors in determining when a transaction will settle. “Settle”. Integrators can influence the timing of an ACH transaction by setting the is_same_day field to true when posting a request to send a transaction.

However, even when sending “same day” ACH transfers, there are a couple things to keep in mind:

• Transactions can be returned up to 2 business days after the settlement day. This introduces risk for fintech’s who choose to make funds immediately available to account owner who have initiated a pull request. The ACH system operates on a “no news is good news” basis. The absence of a return within the 2-day timeframe typically means that the RDFI has accepted the transaction.
• “Same day” ACH is only available within certain transmission windows set by the federal reserve. Take a look at the Fed processing schedule for more information on cut off times. In general, transactions submitted (Mon-Fri) by 4:45pm are eligible to settle on the same day. “Same day” is not available on non-banking days (weekends and holidays) and will automatically default to the next available “banking day”.
• Submitting incorrect information may cause processing errors that result in delays. Errors may also increase the likelihood of a transaction being returned.

Why would an ACH transaction be returned?

ACH transactions can be returned for a variety of reasons. “Insufficient funds”, “invalid account number”, “account closed” are all fair game but but many of the return reasons are not so obvious. NACHA guidelines specify 85 different codes that may be associated with a returned transaction. The good news is that you and your customers are likely to see only the most common ones. Synctera will take care of processing any returned transaction and notify you of the resolution via webhooks. In the event that a returned transaction requires your immediate attention, you will be able to take action through the Synctera dashboard.

The dashboard is also were you can generate returns from received ACH transactions. While most transaction failures such as insufficient funds, invalid account, etc., will result in automatic returns, you may occasionally identify transactions that were not authorized and choose to manually initiate a return.

ACH same day vs non-same day cut-off times

ACH Type	Cut-off time	Comments
Same day	4:45 pm ET (1:45 pm PT) (Monday - Friday)	Same day ACH payments with effective date of today submitted before 4:45 pm ET will be processed as ‘same day’ ACH
Non-Same day	24:00 pm ET (Monday-Friday)	Non same ACH payments with effective date of tomorrow or 2 days in the future submitted before 24:00 will be processed as ‘non-same day’

ACH (Debit/Credit) - External bank to Synctera account

ACH Type	File processing time	Comments
Same day	10:30 am ET2:45 pm ET4:45 pm ET	ACH Batch files with same day payments (debits/credits/returns) directed to Synctera accounts will be processed at these times
Non same day / future dated ACH	10:30 am ET2:45 pm ET4:45 pm ET8:00 pm ET *2:15 am ET *	ACH Batch files with non-same day payments (debits/credits/returns) directed to the Synctera accounts will be processed at these times

Not all of our sponsor banks support 8:00 pm ET / 2:15 am ET exchange times

ACH Returns - External bank to Synctera account

Return code	Days from original transaction
R01: NSF	2 Banking Days
R02: Account closed	2 Banking Days
R03: No Account - Account number structure is valid, but doesn’t match individual or Open account	2 Banking Days
R04: Invalid Account - Account number structure not valid, ie edit check digit or number failed	2 Banking Days
R05: Unauthorized Debit to Consumer Account Using Corporate SEC Code - A Debit entry that uses a corporate SEC code was transmitted to a consumer but was not authorized by the consumer	60 Calendar Days
R07: Authorization Revoked - Customer who previously authorized an entry claims, authorization has been revoked from the Originator	60 Calendar Days
R08: Payment Stopped: The customer has requested the stop payment of a specific ACH Debit Entry	2 Banking Days
R09: Sufficient ledger balance exists, but value of of uncollected items brings available balance below amount of debit entry	2 Banking Days
R10: Customer Advises Not Authorized, Improper, Ineligible, Part of Incomplete transaction or Improperly reinitiated - Not authorized, wrong amount, debit date before authorized, incomplete transaction, improper source document or exceeds reinitiating attempt	60 Calendar Days
R12: Account sold to another FI	2 Banking Days
R16: Account frozen/Entry Returned Per OFAC Instruction - Access to account is restricted due to action by the bank	2 Banking Days
R20: Non-transaction Account - Policies and regulations restrict activity to account indicated	2 Banking Days
R24: Duplicate Entry - Entry is a duplication. The trace number, date, dollar amount ect.. match another entry	2 Banking Days
R29: Corporate Customer Advises Not Authorized	2 Banking Days
R31: Permissible Return Entry - Sender bank agreed on behalf of the Originator to accept a return after the deadline for an unauthorized corporate entry	Undefined
R37: Source document Presented for Payment - The source document to which an ARC or BOC or POP entry relates has also been presented for payment	60 Calendar Days
R38: Stop Payment of Source Document - A Stop Payment has been placed on the source document to which the ARC or BOC Entry relates.	60 Calendar Days
R39: Improper Source Document/Source Document presented for payment - The RDFI determines the source document for the ARC, BOC or POP entry is not an eligible item or was presented for payments	2 Banking Days
R50: State Law Affecting RCK Acceptance - RDFI is located in a state that has not adopted Revised Article 4 of the UCC or RDFI is located in a state that requires all canceled checks to be returned to the receiver	2 Banking Days
R51: Item is Ineligible, Notice Not Provided, Signatures not Genuine, Item Altered or Amount of RCK Not Accurately Obtained from the Item	60 Calendar Days

Example: Funding a customer account

To fund a customer account from an external bank account the Synctera API:

Shell

curl \
  -X POST \
  -H "Authorization: Bearer $apikey" \
  -H "Content-Type: application/json" \
  https://api.synctera.com/v0/ach \
  --data-binary '
    {
      "risk": {
        "client_ip": "127.0.0.1"
      },
      "customer_id": "{CUSTOMER_ID}",
      "amount": 100,
      "currency": "USD",
      "receiving_account_id": "{EXTERNAL_ACCOUNT_ID}",
      "dc_sign": "debit",
      "originating_account_id": "{ACCOUNT_ID}",
      "reference_info": "Synctera test",
      "memo": "Synctera test"
    }'

It is important to note a few things in this example:

1. The receiving_account_id always refers to an External Account.
2. The originating_account_id always refers to to an Account.
3. The dc_sign is always from the perspective of the receiving account. So a debit to the receiving account results in a credit to the originating account.
4. The amount is always in the smallest denomination of the given currency. In this case, the currency is USD, which means the amount is in cents.
5. The customer_id indicates the person that is making the outgoing ACH request. This customer must be an account holder or authorized signer of originating_account_id