ACH Transfers - Risk and Compliance
    • 16 Jan 2024
    • PDF

    ACH Transfers - Risk and Compliance

    • PDF

    Article summary

    General

    The Automated Clearing House (ACH) is a network for financial transactions in the United States that allows for the electronic movement of money between banks. Managed by NACHA (formerly the National Automated Clearing House Association), the ACH network facilitates direct deposits, bill payments, and other financial transfers. ACH transactions are generally considered to be cost-effective and efficient but can take a few business days to settle. They are widely used for payroll, government benefits, and business-to-business payments, among other things.

    Synctera has an ACH guide here that provides more detail on ACH payments in general.

    In the context of risk and compliance within fintech, it's essential to understand ACH's regulatory landscape, which includes compliance with NACHA Operating Rules and federal laws such as Reg E or the Electronic Fund Transfer Act (EFTA).

    ACH Transfer Types

    ACH transfers can be additionally confusing due to the ability for a customer to 'pull' funds from an external account. This is considered a customer "originating" an ACH debit file, which is ultimately processed by your bank and sent to the receiving bank to pull the funds. Debits come with unique risks and compliance requirements. At the same time, ACH is one of the most common forms of account funding for digital accounts - allowing your customer to "pull" funds from their own external account at another bank via your app or website. Below are the four basic categories of ACH.

    ACH typeACH file directionMoney directionCommon real-world example
    ACH debitOutgoing from your sponsor bank on behalf of the customerThe customer is the beneficiary pulling funds in from an external bank accountCustomer pulls funds from their own external bank account to fund their account with you
    ACH creditOutgoing from your sponsor bank on behalf of the customerThe customer is pushing funds out to a beneficiary with an external bank accountCustomer pushes funds out to make a bill payment or to transfer funds to a friend
    Direct debitIncoming and received by your sponsor bank on behalf of the customerThe customer's funds are being pulled out of their account to a beneficiary with an external bank accountCustomer funds are pulled by their utility company with the customer's authorization to pay their monthly bill
    Direct depositIncoming and received by your sponsor bank on behalf of the customerThe customer's funds are being pushed in their account as a beneficiary from an external bank accountCustomer receives wages from an employer pushing those funds into the customer's account
    Originating vs. Receiving ACH entries
    • In the scenarios above, outgoing ACH files are processed/sent by your partner bank as a designated "Originating Depository Financial Institution" or ODFI.
    • Incoming ACH files are processed/received by your partner bank as a designated "Receiving Depository Financial Institution" or RDFI.
    • As an ODFI and RDFI, your partner bank must meet specific requirements by NACHA and some of these requirements are required of your company as an intermediary.

    Risks and Controls

    When supporting ACH transfers for your customers, there are financial risks to be considered as well as potential controls to mitigate those risks. Below is a breakdown based on the ACH type. Your risk and the bank's risk is primarily concentrated on originating / outgoing entries. Generally speaking, the ODFI / originator are responsible for ensuring proper authorization and controls are in place to mitigate unauthorized entries, insufficient funds, and other administrative errors. Note that operational risks also exist, which relates to broader Operational Resilience topics and controls.

    ACH TypeKey RisksControls and Mitigants
    ACH debit* Fraud Risk - External account did not authorize customer to pull funds
    * Credit Risk - External account did not have sufficient funds to pull from
    * Set max daily transaction limits and velocity limits
    * Require use of Plaid or similar for account linking and credentials
    * Place a 2 business day hold after the ACH is originated so that funds can not be spent immediately
    * Conduct a "balance check" using Plaid or similar on the external account to ensure sufficient funds prior to the debit
    * For account funding use cases, conduct a "name match" using Plaid or similar on the external account to ensure the external account belongs to the customer
    * Receive and record authorization prior to the transaction
    * Freeze account if the transaction results in an ACH return with unauthorized return code
    ACH credit* Fraud risk - Funds being pushed out were unauthorized by the customer; Funds were authorized, but customer was duped from a scam
    * Credit Risk - Customer does not have sufficient funds for the credit
    * Set max daily transaction limits and velocity limits
    * Receive and record authorization prior to the transaction
    * Require 2FA confirmation for large transactions
    * Create customer reminders or alerts regarding scams
    * Synctera operates on a "good funds" model for ACH credits - customers must have sufficient funds to initiate a credit and funds are set aside as soon as the customer initiates the transaction

    ACH Authorization

    ACH origination including ACH debits require the customer to provide authorization. Gathering, recording, and retaining payment authorization is an important component of compliance with NACHA and may be required to protect against unauthorized transaction claims.

    Authorization includes the following:

    • Explicit Consent for Debit Transactions: The language must clearly indicate that the account holder authorizes the company or organization (the originator) to make ACH debits from their account.

      • Example: "I (or we) hereby authorize [Company Name] to initiate debit entries to my (our) [Checking/Savings] account at [Bank Name], Account Number [xxxxxx], for [regular payments, subscription fees, one-time payment, etc.]."
    • Specific Transaction Details: Include details about the transaction, such as the amount, or how the amount will be determined if it's variable, and the timing or frequency of the debit (for recurring transactions).

      • Example: "This authorization is for a recurring charge of [amount] to be debited on the [1st day of each month/next business day]."
    • Bank and Account Identification: Clearly state the bank name and account / routing number for confirmation.

    • Duration of the Agreement: For recurring ACH transactions, specify the duration of the authorization if it is not open-ended. For open-ended authorizations, indicate how they can be terminated.

      • Example: "This authorization will remain in effect until I (we) notify [Company Name] in writing to cancel it in such time as to afford [Company Name] and [Bank Name] a reasonable opportunity to act on it."
    • Revocation Procedure: Detail how the account holder can revoke the authorization, including any terms and conditions related to revocation.

      • Example: "I (or we) understand that I (we) can stop payment of a debit by notifying [company name] by [XYZ] with at least X days prior notice."
    • Signature Requirement: For electronic authorizations, ensure compliance with the Electronic Signatures in Global and National Commerce Act (E-Sign Act).

    Account Validation for ACH Debit

    If you are enabling the ability for customers to initiate ACH WEB Debits (e.g. account funding over an online channel), it is required by NACHA to conduct validation of the account being debited. This helps ensure that your customer is not incorrectly debiting an external account. It can also be a fraud risk mitigant depending on the method.

    Acceptable methods for account validation include the following:

    • Third Party Vendor - Includes Plaid or Finicity via Synctera for account linking and verification of credentials - this is the most common standard for fintechs.
      • It requires that the customer logs in to their external account, which can also be a fraud control.
      • Not all financial institutions may be supported using these vendors.
    • ACH prenotification - Also known as a "pre-note," is a zero-dollar transaction used to verify the accuracy of bank account information such as the account number and routing number before initiating actual ACH transactions.
      • It verifies account number and routing, but does not necessarily mitigate fraud.
    • ACH microtransaction - ACH microtransactions are small, usually random, financial transactions used to verify the ownership and validity of a bank account. They are an alternative to prenotification for account validation.
      • It requires the customer to verify the amounts of the small transactions, which can help verify account ownership and mitigate fraud.

    ACH Return Rates and NACHA Requirements

    ACH returns are transactions that have been rejected or couldn't be processed for various reasons, after initially being accepted by the RDFI. These returns are sent back to the ODFI and ultimately to the originator. Reasons for ACH returns can include insufficient funds, closed accounts, or invalid account information among others.

    Common examples of returns include:

    • Non-sufficient funds (NSF) - Your customer initiated an ACH debit to pull funds from an external account to fund their account with you - the external account does not have sufficient funds resulting in a return
    • Administrative / error - Your customer initiated an ACH credit to send money to an external account - the account and routing number of the external account does not exist resulting in a return
    • Unauthorized transaction - Your customer initiated an ACH debit to pull funds from an external account to fund their account with you - however the owner of the external account disputes the pull as it was not authorized by them resulting in a return - this can often be indicative of fraud

    In the context of risk and compliance, monitoring ACH returns is important as high return rates can be indicative of fraudulent activity or non-compliance with ACH rules. ACH return codes, established by NACHA, specify the reason for the return, aiding in diagnostics and resolution.

    Common return codes and the timeframe associated with them

    NACHA maximum return rates are the following and are calculated based on debits originated for the preceding 60 days or two calendar months:

    Return TypeMax Return RateReturn Codes
    Unauthorized Debit Entries0.5%R05, R07, R10, R29, R51
    Administrative Returns3%R02, R03, R04
    Overall Debit Return Rate15%Applies to all debit entries returned for any reason (except RCK entries)

    Return rate calculation is further described here and is as follows:
    image.png

    Return rates can be tracked via Synctera's Insights tools and includes other metrics helpful for managing returns.

    NACHA Return Rate vs. Dollar Return Rate

    NACHA compliance requires you to fall below the NACHA return rates. However, another measure can be critical from a risk standpoint - dollar return rate. This factors in the actual dollar amount of the return. For example, one return for $100 has a significantly different risk exposure than one return for $100,000.

    If your return rates are near the NACHA maximum, the bank or Synctera may reach out to understand root causes and to identify ways to lower those rates. Consistently high rates may signal issues with your risk management and target customer base.


    Was this article helpful?

    Changing your password will log you out immediately. Use the new password to log back in.
    First name must have atleast 2 characters. Numbers and special characters are not allowed.
    Last name must have atleast 1 characters. Numbers and special characters are not allowed.
    Enter a valid email
    Enter a valid password
    Your profile has been successfully updated.