Skip to content
main
Straddle 101 - Internal
  • Pages
    • main
      straddle
      • TL;DR
      • Embed
        • main
          Regulatory Structure
        • Weave (KYB Decisioning)
      • Strategy
      • Press Release
    • Big ideas '25
      • Manifesto
      • Communication
        • Open doors
      • Engineering @ Straddle
        • Engineering Values
        • Building @ Straddle
          • Discovery->Delivery
          • Linear Guide
            • Projects
            • Issues
            • Workflows
          • Templates
            • Project Template
            • Short PRD
            • Concise Issue
            • Detailed Issue
      • main
        Company Memo
        • 2025 Strategy
          • Ideal Customer Profile
            • Personas
            • Compound Startup
            • Straddle Public Library
              • Payments vs Transfers
              • APIs as ladders
              • How to avoid breaking APIs
                • Breaking changes in JSON APIs
              • How to: Friction Logs
              • Enterprise sales meets product development
            • Payment Systems
              • ACH
                • ACH Basics
                • Flow of Funds
                • ACH Primer
                  • Why do businesses choose ACH?
                  • ACH vs wire transfers: what’s the difference?
                  • What is Nacha and is your business compliant?
                  • What is an ACH debit?
                  • What is direct debit?
                  • What is ACH credit and how does it work?
                  • How does an ACH deposit work? A behind the scenes look
                  • How an ACH transfer works: a complex process explained
                • icon picker
                  Nacha Quick Reference Guide
                  • ACH Returns Quick Reference
          The purpose of the ACH Quick Reference Guide is to provide instruction to financial institution personnel involved in the day-to-day activities associated with receiving commercial ACH transactions. It is ideal for training personnel on ACH procedures and as a quick reference for ACH questions. The Guide contains an appendix with sample reports, Return and Notification of Change codes, and a glossary of ACH terminology.
          This user-friendly guide is based on the 2022 Nacha Operating Rules (referred to as the ACH Rules), Regulation E and the Uniform Commercial Code Article 4A (UCC 4A) and supplements more extensive resource materials. It references various in- depth resource materials and is not intended as a substitute for referencing and complying with the rule requirements published in the ACH Rules. Procedures for handling federal government entries are not covered in this guide. Although many procedures may be similar, federal government entries are also subject to Title 31 Code of Federal Regulations Part 210 (31 CFR Part 210), which are outlined in the Green Book.

          ACH Basics

          What is the ACH Network?

          The Automated Clearing House (ACH) Network is an electronic payments network used by individuals, businesses, financial institutions and government organizations. It allows funds to be electronically debited or credited to a checking account, savings account, financial institution general ledger account or credited to a loan account.
          The ACH Network is the backbone for the electronic movement of money and other related data, providing a safe, secure, reliable network for direct consumer, business and government payments. Large and small financial institutions of all kinds jointly govern and utilize the ACH Network, facilitating billions of payments such as Direct Deposit via ACH and Direct Payment via ACH.
          The ACH Network is a same day, batch processing, store-and- forward system. Transactions are stored by financial institutions throughout the day and processed at specified times in a batch mode.
          The ACH Network exchanges funds and payment-related information throughout the United States, its territories and internationally.

          Who are the ACH Participants?

          There are five key participants that contribute to the successful completion of an ACH transaction. As each participant is discussed, the financial institution should better understand the role it plays in the system.
          The Originator is the company/business that has been authorized by the Receiver to either credit or debit an account. When a company initiates a credit transaction to their employee’s account for payroll or to a business customer’s account for payment of goods and services, it is considered the Originator. Originators may also initiate debit transactions to a consumer or business account for payment of goods or services.
          The Receiver can be either an individual or a company that has authorized the Originator (company) to credit or debit their account. The employee is the Receiver if his/her employer is initiating a Direct Deposit payroll credit. A business partner is the Receiver if the Originator is sending a credit to pay for goods or services. The Originator can also be a Receiver, in situations where another party is initiating credits or debits to their account.
          The authorization is a key component of an ACH transaction, as it gives the Originator the authority to send credit or debit transactions to the Receiver’s account. The manner in which the authorization may be obtained varies based on the type of transaction and is discussed in greater detail in the Authorization section of this Guide.
          The Originating Depository Financial Institution (ODFI) is the financial institution with which the Originator (company) has a contractual relationship for ACH services and is responsible for sending ACH entries into the ACH Network on behalf of the Originator. Through the warranties outlined in the ACH Rules, the ODFI has the greatest liability of all the participants in the ACH Network. The contractual relationship between the Originator and the ODFI outlines the rights and responsibilities of the two parties with respect to the ACH transactions being originated and provides the ODFI with a mechanism to pass some appropriate liabilities to the Originator (company).
          An example of this relates to authorizations. The ODFI warrants to all the other Network participants that transactions are properly authorized; and yet, the Originator obtains and maintains this authorization. Hence, the agreement between the Originator and ODFI must address the Originator’s responsibilities regarding authorizations.
          The ACH Operator is the central clearing facility for ACH transactions. The ACH Operator is responsible for accepting files of ACH entries from ODFIs, which are then sorted, batched and forwarded to the Receiver’s financial institution. The ACH Operator also performs some editing functions, ensuring that mandatory information required in ACH records is included. There are currently two ACH Operators, the Federal Reserve Bank and EPN (Electronic Payments Network).
          The Receiving Depository Financial Institution (RDFI) is a financial institution with which the Receiver has an account relationship. Credit or debit entries sent to a Receiver’s account will be received by the RDFI from the ACH Operator and then posted to the Receiver’s account.
          The RDFI’s primary responsibilities are to:
          Post ACH entries to the Receiver’s account.
          Make funds available to the Receiver for credit entries or debit the Receiver’s account on the Settlement Date.
          Provide information regarding each ACH transaction to the Receiver on their statement.
          Return ACH entries, within the specified timeframes, when the transactions cannot be posted.

          There are two other Network participants that may be involved in the flow of transactions, Third-Party Service Providers and Third-Party Senders.
          A Third-Party Service Provider is a party which performs an ACH processing function on behalf of the Originator, ODFI or RDFI. A payroll processor is a common example of a Third-Party Service Provider used by Originators.
          A Third-Party Sender (TPS) (Straddle) is an entity that has a contractual relationship with an ODFI to transmit debits or credits to the account of a Receiver on behalf of the Originator.
          More specifically, a Third-Party Service Provider is a Third-Party Sender when there is a contractual relationship between the Originator and the Third-Party and there is NOT an agreement between the Originator and the ODFI.
          Again, referencing the payroll processor example, if the Originator has an agreement with an ODFI for ACH origination and they use a payroll processor to create the ACH file on their behalf, the payroll processor is a Third-Party Service Provider. If the Originator has a contractual relationship with the payroll processor and the payroll processor sends the ACH file to the payroll processor’s financial institution for introduction into the ACH Network, the payroll processor is considered a Third-Party Sender.

          How Does the ACH Network Function?

          The Originator obtains authorization to initiate a transaction to the Receiver’s account or provides notice to the Receiver that a transaction will be initiated to the Receiver’s account.
          The Originator initiates a file of ACH transactions and presents the file to its ODFI.
          The ODFI collects ACH files from Originators with which it has contractual relationships, verifies the validity of these files and at specified times, transmits these files to the ACH Operator. The ODFI may consolidate these individual files as batches into a larger file that is then transmitted to the ACH Operator. The ODFI may retain entries within these files that are intended for account holders at its institution. These entries are known as on-us entries.
          The ACH Operator receives ACH files from the ODFI, edits the files to make sure they are formatted properly and distributes files of entries to the RDFI.
          The RDFI receives files of entries from the ACH Operator for its account holders. Entries are posted based upon the Settlement Date and account number. Periodic statements are provided to the Receiver with descriptive information about the ACH transaction, including the date of the transaction, dollar amount, Originator name and transaction description (e.g., payroll, water bill, internet purchase).

          How are ACH Funds Settled?

          Settlement is the actual transfer of funds between financial institutions to complete the payment instructions of an ACH entry. ACH settlement can only occur on banking days. The Federal Reserve Bank provides settlement services for ACH entries, for both the Federal Reserve ACH Operator and any private sector ACH Operator (currently only EPN). The Federal Reserve Bank calculates the net debit and credit positions of financial institutions and applies those debits or credits to the account of the financial institution or to the account of its correspondent financial institution.
          The timing of settlement is based upon the Effective Entry Date indicated by the Originator on the ACH file and the time of its delivery to the ACH Operator. The Effective Entry Date is the date the Originator intends for the entries to post to the accounts of the Receivers (employees or customers).
          When the ACH Operator processes an ACH file, the Effective Entry Date is read and a Settlement Date is assigned. Entries are settled by the ACH Operator on the Settlement Date.
          In most cases, the Settlement Date is the same as the Effective Entry Date, but it is possible that the Settlement Date could be after the Effective Entry Date. For example, if the ACH Operator cannot settle on the Effective Entry Date due to untimely file delivery, a stale date, weekend or holiday, the ACH Operator will apply the next possible Settlement Date.
          Since its inception, the ACH Network’s standard settlement period has been one to two business days after processing (i.e., debit entries are allowed to be sent one day in advance of the Effective Entry Date and credits up to two days in advance). While this processing environment will continue to be available, Originators now have same day processing and settlement of eligible ACH credit and debit payments.

          ACH Network Management

          Operations and compliance are two key aspects in the management of the ACH Network. ACH Operators facilitate the operations for transaction processing, while compliance is the primary focus of financial institutions, Payments Associations (PAs) and Nacha.
          Nacha is a not-for-profit association that represents financial institutions through direct memberships and a network of PAs. Nacha develops operating rules and business practices for the ACH Network and for electronic payments in the areas of Internet commerce, electronic bill and invoice presentment and payment (EBPP, EIPP), electronic check conversions (e-checks), financial electronic data interchange (FEDI), international payments and electronic benefits services (EBS).
          PAs provide access to the ACH Rules and guidelines for the efficient operation of the ACH Network as well as provide education to their members. PA members include financial institutions, companies and other interested parties. With the contributions of their members, PAs help create the ACH Rules.

          ACH Rules and Regulations

          There are many rules and regulations governing the transmission of ACH entries. Details on the rules and regulations having the most impact on the financial institution follow:
          ACH Rules
          Office of Foreign Asset Control (OFAC)
          Regulation E and Electronic Fund Transfer Act (EFTA)
          State law
          Title 31 Code of Federal Regulation Part 210 (31 CFR Part 210)
          Uniform Commercial Code Article 4A (UCC 4A)
          USA PATRIOT Act

          ACH Rules

          The ACH Rules serve as the primary source for rules and regulations for the Commercial ACH Network and are contract law that is made binding by agreements. Commercial ACH entries are originated by the private sector, which includes individuals, companies and state and local governments.
          The ACH Rules define the obligations and liabilities of each financial institution, including a provision to perform an annual audit, and provide a mechanism for a receiving institution to return an entry to the sending institution. The ACH Rules help reduce risk in the Network and protect financial institutions from potential loss.

          Office of Foreign Assets Control (OFAC)

          The U.S. Department of the Treasury, Office of Foreign Assets Control, administers economic sanctions and embargo programs that require assets and transactions involving interests of targeted countries, targeted country nationals and other specifically identified companies and individuals to be frozen. OFAC maintains a list of Specially Designated Nationals and Blocked Persons (SDN List) to assist financial institutions in identifying blocked parties.
          All U.S. participants in the ACH Network need to be aware that they may be held accountable for sanction violations and must understand their compliance obligations. As an RDFI, the financial institution should have a process in place to determine whether any of its account holders are identified as a blocked party on a current SDN List. Financial institutions are strongly encouraged to obtain a current SDN List and other compliance information directly from OFAC.

          Regulation E and Electronic Fund Transfer Act (EFTA)

          Regulation E carries out the purpose of the EFTA, which establishes the basic rights, liabilities and responsibilities of consumers who use electronic fund transfer services. The primary objective of this act and regulation is the protection of individual consumers engaging in electronic fund transfer services. Regulation E also addresses the responsibilities of financial institutions regarding disclosures, stop payments and unauthorized debit transactions to consumer accounts and defines the process for resolving errors.

          State Law

          Some state laws may impact ACH transactions if the law is more restrictive or provides greater consumer protection than other prevailing rules or regulations. For instance, some states allow companies to mandate employees to be paid by Direct Deposit; however, most state labor codes restrict companies from offering only Direct Deposit. Many states have mandated state taxes paid by businesses and corporations be initiated through the ACH. The states’ Attorneys General Offices can provide specifics.

          Title 31 Code of Federal Regulation Part 210 (31 CFR Part 210)

          31 CFR Part 210 provides the regulatory foundation for the use of the ACH Network for federal government agencies. It defines the rights and liabilities of agencies, Federal Reserve Banks, financial institutions and the public in connection with ACH entries. The Green Book is the procedures manual for financial institutions processing federal government payments. Among the procedures covered by the Green Book are the handling of federal government reclamations and enrollment in federal government benefit payment programs. By accepting a federal government benefit payment, a financial institution agrees to be bound to 31 CFR Part 210, and therefore, must adhere to these procedures.

          Uniform Commercial Code Article 4A (UCC 4A)

          Uniform Commercial Code (UCC) is a series of state laws that govern commercial transactions. Article 4A of the UCC governs corporate ACH transactions that are referred to as “corporate wholesale credit entries.” RDFIs may identify these transactions by Standard Entry Class Codes CCD or CTX. UCC 4A also addresses the ‘commercially reasonable security procedures’ that must be in place for ACH Origination to occur.

          USA PATRIOT Act

          Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism Act of 2001 establishes a wide variety of ways to combat international terrorism. Title III—International Money Laundering Abatement and Anti-Terrorist Financing, which contains provisions relating to money laundering and terrorist access to the financial system in our country is the section of the Act that affects financial institutions with regard to information sharing and customer identification programs (CIPs).
          CIPs require financial institutions to complete the following prior to opening a new account:
          Verify the identity of any person seeking to open an account.
          Maintain records of the information used to verify identity.
          Consult government known or suspected terrorist lists to determine whether the customer appears on any such list.

          RULE OF THUMB: When conflicts are found among these various rules and regulations, the most restrictive rule or regulation applies. In other words, the one that benefits or provides the most protection to the consumer would be applied. Over the years, consumer and corporate customers have become more and more aware of the advantages of the electronic payments network. As a result, customers are more demanding and financially savvy. The ACH Network provides the ability to directly deposit employee payroll, permits automated bill payment services, allows for purchases online and can be used by companies to perform cash concentration and make corporate-to-corporate payments.
          As migration from paper to electronic payment continues, the cost-effective ACH Network will grow and enable innovation that strengthens the industry with creative payment solutions.

          ACH Transactions

          Types of ACH Transactions

          In general, there are two types of ACH transactions sent through the ACH Network:
          Commercial—Entries originated by the private sector, including state and local government entities.
          Government—Entries originated by federal government agencies (i.e., Social Security Administration, Veteran’s Affairs, Civil Service, etc.).
          Commercial ACH entries can further be classified as follows:
          Direct Deposit via ACH—Credit entries deposited into a consumer’s account. Direct Deposit includes payments such as payroll, travel reimbursements, government benefits, tax and other refunds, and annuities and interest payments. The deposits arrive and are made available more quickly than paper checks, and can be automatically divided among different accounts based on the Receiver’s direction.
          The various ACH applications are discussed in greater detail throughout this Guide. For a complete listing of ACH transaction types and their uses, see the Operating Guidelines of the ACH Rules.
          Direct Payment via ACH—Credit or debit entries sent or received by individuals or organizations for making a payment. Basically, any ACH payment that is not a Direct Deposit is known as Direct Payment. Direct Payment includes recurring and single-entry payments such as prearranged ACH payments, Internet-initiated ACH transactions and check conversion into the ACH Network. Direct Payment saves time by eliminating check writing, and since payments are automated, the potential for missing or forgetting payments is reduced.
          Increasingly, companies are realizing the benefits of Direct Payment for business-to-business payments. These payments reduce check preparation and distribution expenses, eliminate postage costs, improve cash flow and cash forecasting, can improve payment discounts and simplify account reconciliation. Additionally, payments can accommodate payment-related information in addenda records in standard electronic data interchange (EDI) formats or in Nacha-endorsed banking conventions.
          The ACH Network can also be used by consumers and businesses to exchange funds and payment-related information internationally. In the international payment environment, a new participant, the Gateway, acts as the contact point for a financial institution. The Gateway assumes responsibility for foreign exchange conversion and settlement, format mapping and translation of data.

          Transaction Codes

          The ACH Network supports a number of different credit and debit applications. A Transaction Code identifies an entry as a debit or credit, and indicates the type of account to which the transaction is intended, i.e. checking, savings, financial institution general ledger or loan account. Only credit entries can be transmitted to loan accounts. Commonly used Transaction Codes are listed:

          Demand Credit Records

          21 Automated Return or NOC for a Demand Credit 22 Demand Credit 23 Prenote for a Demand Credit 24 Zero Dollar Entries w/Remittance Data (for CCD and CTX Entries Only)

          Demand Debit Records

          26 Automated Return or NOC for a Demand Debit 27 Demand Debit 28 Prenote for Demand Debit 29 Zero Dollar Entries w/Remittance Data (for CCD and CTX Entries Only)

          Savings Account Credit Records

          31 Automated Return or NOC for a Savings Credit 32 Savings Credit 33 Prenote for a Savings Credit 34 Zero Dollar Entries w/Remittance Data (for CCD and CTX Entries Only)

          Savings Account Debit Records

          36 Automated Return or NOC for a Savings Debit 37 Savings Debit 38 Prenote for a Savings Debit 39 Zero Dollar Entries w/Remittance Data (for CCD and CTX Entries Only)

          Standard Entry Class (SEC) Codes

          Each application has a unique Standard Entry Class (SEC) code which identifies:
          The nature of the transaction as consumer or corporate/business, as well as whether the transaction is single-entry or recurring.
          The ACH Rules and other regulations governing the transaction, including the method for obtaining authorization or providing notice.
          The specific record format that is used to carry the payment and payment-related information relevant to the entry.
          It is important to know the SEC code of the ACH entry as it will define posting and return procedures. This is of utmost importance to the financial institution as proper handling of entries will mitigate any potential losses associated with human error. Commonly used SEC codes are listed below with their use.
          SEC CODE
          SEC CODE DESCRIPTION
          APPLICATION USE
          ARC
          Accounts Receivable Entry
          The Accounts Receivable (ARC) Entry provides billers the opportunity to initiate single-entry ACH debits to customer accounts by converting checks at the point of receipt through the U.S. mail, ata drop box location or in-person for payment of a bill at a manned location. The biller is required to provide the customer with notice prior to the acceptance of the check that states the receipt of the customer’s check will be deemed as the authorization for an ARC debit entry to the customer’s account. The provision of the notice and the receipt of the check together constitute authorization for the ARC entry. The customer’s check will solely be used as a source document to obtain the routing number, account number and check serial number.
          BOC
          Back Office Conversion
          Back Office Conversion (BOC) allows retailers/billers, and ODFIs acting as Originators, to electronically convert checks received at the point-of-purchase as well as at a manned bill payment location into a single-entry ACH debit. The authorization to convert the check will be obtained through a notice at the checkout or manned bill payment location (e.g., loan payment at financial institution’s teller window) and the receipt of the Receiver’s check. The decision to process the check item as an ACH debit will be made in the “back office” instead of at the point-of-purchase. The customer’s check will solely be used as a source document to obtain the routing number, account number and check serial number.
          CCD
          Corporate Credit or Debit
          The Corporate Credit or Debit (CCD) application provides a way for companies to receive cash rapidly, manage funds and control cash disbursements. Companies that operate several branches or sales outlets may consolidate funds quickly and eliminate the difficulties associated with transferring funds to a central corporate account. This application enhances the ability to predict funds availability and improve a company’s total cash management capability. The CCD applicationcan also be used to transfer funds among corporate entities in payment of goods or services, and can support a limited amount of payment-related data (e.g., invoice number, discounts taken, purchase order number, etc.) with the funds transfer.
          CIE
          Customer-Initiated Entry
          A credit entry initiated by consumers through a bill payment service provider to pay bills, including bill payment services submitted through a telephone, ATM or online.
          CTX
          Corporate Trade Exchange
          The Corporate Trade Exchange (CTX) application provides the ability to collect and disburse funds and information between companies. Generally it is used by businesses paying one another for goods or services. These payments replace checks with an electronic process of debiting and crediting invoices between the financial institutions of participating companies.
          IAT
          International ACH Transaction
          An IAT entry is a credit or debit ACH entry that is part of a payment transaction involving a financial agency’s office (i.e., depository financial institution or business issuing money orders) that is not located in the territorial jurisdiction of the United States. IAT entries can be made to or from a corporate or consumer account and must be accompanied by seven (7) mandatory addenda records identifying the name and physical address of the Originator, name and physical address of the Receiver, Receiver’s account number, Receiver’s bank identity and reason for the payment.
          POP
          Point-of-Purchase Entry
          The Point-of-Purchase (POP) application provides businesses the opportunity to create a debit entry to a Receiver’s account for a purchase made in-person at the point-of-sale or a manned bill payment location. After providing the proper notice, the Originator (merchant/retailer) accepts a source document, a paper check/sharedraft, from the Receiver, which is then inserted into a check-reading device to capture the account information (routing number, account number and check serial number) from the MICR lineof the check. The dollar amount of the transaction is manually key-entered by the sales clerk. The check/ sharedraft is then voided and returned to the Receiver along with an authorization form. The Receiver then authorizes the Originator to convert it into a one-time electronic debit to the Receiver’s account.
          POS
          Point-of-Sale
          Point-of-Sale Entries (POS) are ACH debit entries typically initiated by the use of a merchant-issued plastic card to pay an obligation at the point-of-sale. Much like a financial institution issued debit card, the merchant-issued debit card is swiped at the point-of-sale and approved for use; however, the authorization only verifies the card is open, active and within the card’s limits—it does not verify the Receiver’s account balance or debit the account at the time of the purchase. Settlement of the transaction moves from the card network to the ACH Network through the creation of a POS entry by the card issuer to debit the Receiver’s account.
          PPD
          Prearranged Payment and Deposit
          Prearranged Payments and Deposits (PPDs) can be either credit or debit entries and represent either single or recurring payments. PPD transactions are more widely known as Direct Deposit and Direct Payment. The Direct Deposit application provides the ability to disburse funds to consumer accounts. The Direct Payment application provides the ability to collect funds from consumer accounts. PPD can also be used for Return Fee Entries. If a company is allowed by law to collect a fee for a debit entry (ACH or check) that is returned as NSF or UCF, it would use the PPD Standard Entry Class code to do so as long as proper notice is provided.
          RCK
          Re-presented Check Entry
          The Re-presented Check (RCK) Entry provides businesses the ability to collect funds from paper checks that have been processed through the check collection system and returned NSF or UCF. A consumer’s paper check that has been returned insufficient or uncollected funds may be submitted as an ACH debit entry through the ACH Network, as long as the proper notice is provided.
          TEL
          Telephone-Initiated Entry
          The Telephone-Initiated (TEL) Entry provides businesses the opportunity to initiate ACH debits to consumer accounts for the purchase of goods and services pursuant to an oral authorization obtained over the telephone. TEL entries can be either set up for one specific payment (Single-Entry) or to occur at regular intervals (Recurring). A TEL entry may be transmitted only in circumstances in which (1) there is an existing relationship between the Originator and the consumer, or (2) there is not an existing relationship between the Originator and the consumer, but the consumer has initiated the telephone call to the Originator.
          WEB
          Internet-Initiated/ Mobile Entry
          The Internet-Initiated/Mobile (WEB) Entry can be either a debit or credit entry and represents either single or recurring payments. A WEB debit entry provides companies the opportunity to initiate a debit entry to consumer accounts for the purchase of goods or services pursuant to an authorization obtained over the Internet or a Wireless Network. A WEB credit entry is initiated on behalf of a consumer to pay another person or to transfer monies from a consumer’s account at one financial institution to his/her account at another institution. The payment instructions may be communicated via the Internet, Wireless Network or in-person at the financial institution.
          There are no rows in this table

          Authorization

          Originators must obtain authorization from or provide notification to a Receiver prior to initiating ACH transactions. Authorization requirements differ among the types of ACH transactions, also known as SEC codes. The Originator must keep copies of authorizations for two years from the termination or revocation of the authorization. For example, the Originator of a single-entry TEL must keep the original or copy of the oral authorization for two years from the date of the authorization. The table below identifies the authorization requirements of the more commonly initiated SEC codes.
          Authorizations must be readily identifiable as an ACH credit or debit authorization and must contain terms that are clear and readily understandable. For recurring payments only, revocation language must also be included.
          Authorizations may limit an Originator to debit or credit entries and may specify a fixed or variable amount. ACH authorizations should include language requiring consumers to acknowledge that ACH entries must comply with provisions of the laws of the United States.
          SEC CODE
          ENTRY TYPE
          AUTHORIZATION REQUIREMENT
          Accounts Receivable Entry (ARC)(Corporate to Consumer/Corporate to Corporate)
          Debits
          Notification is required prior to acceptance of the check.
          Back Office Conversion (BOC)(Corporate to Consumer/Corporate to Corporate)
          Debits
          Notification prior to acceptance of the check and written authorization required.
          Corporate Credit or Debit (CCD) (Corporate to Corporate)
          Debits/ Credits
          Agreement required for transfers between companies; written authorization implied.
          Customer-Initiated Entry (CIE) (Consumer to Corporate)
          Credits
          Presumed agreement between consumer and company or paying agent.
          Corporate Trade Exchange (CTX) (Corporate to Corporate)
          Debits/ Credits
          Agreement required for transfers between companies; written authorization implied.
          International ACH Transaction (IAT)(Corporate to Corporate/Corporate to Consumer/ Consumer to Consumer)
          Debits/ Credits
          Agreement required for transfers between companies; credit entries to consumer accounts require authorization be provided orally or by non- written means; debit entries to consumer accounts require a written, signed or Similarly Authenticated* authorization.
          Point-of-Purchase Entry (POP)(Corporate to Consumer/Corporate to Corporate)
          Debits
          Notification prior to acceptance of the check and written or signed or similarly authenticated authorization required.
          Prearranged Payment & Deposit (PPD) (Corporate to Consumer)
          Credits
          Authorization required. Oral or non-written means (i.e., voided check) accepted.
          Prearranged Payment & Deposit (PPD) (Corporate to Consumer)
          Debits
          Authorization required. Written, signed or Similarly Authenticated.* Authorization for Return Fee Entries may be obtained by providing notice to the consumer when the original debit is presented for payment.
          Re-presented Check Entry (RCK) (Corporate to Consumer)
          Debits
          Notification is required prior to acceptance of the check.
          Telephone-Initiated Entry (TEL) (Corporate to Consumer)
          Debits
          For Single Entry, recorded oral authorization or written notice provided to the consumer confirming the oral authorization*. For Recurring, a copy of the authorization must be provided to the consumer.
          Internet-Initiated/Mobile Entry (WEB) (Corporate to Consumer)
          Debits
          Similarly Authenticated authorization required due to the nature of the Internet.*
          Internet-Initiated/Mobile Entry (WEB) (Consumer to Consumer)
          Credits
          No authorization required.
          Point-of-Sale (POS)
          Debit/ Credit
          Written and signed or similarly authenticated
          There are no rows in this table
          *Revised Regulation E (2001) and the Electronic Signatures in Global and National Commerce Act (E-Sign Act) qualify electronic signatures as valid for consumer debit authorizations. This refers to authentication of the authorizing party by digital signature such as a unique PIN number.

          Rules Compliance

          Risk Management and Assessment

          Risk management is every financial institution’s responsibility. There are three key types of risk affecting ACH payment processing that you should be aware of:
          Credit Risk—the risk that a party to a transaction cannot provide funds for settlement
          Operational Risk—the risk of loss due to unintentional error
          Fraud Risk—the risk that a transaction may be initiated or altered in an intentional effort to misdirect or misappropriate funds

          The ACH Rules require all financial institutions to perform a risk assessment of their ACH activities and to implement risk management programs based on the assessment, in accordance with the requirements of their regulator(s).

          ACH Credit Risk

          While credit risk is generally associated with ACH origination activities, RDFIs are also exposed to credit risk when they:
          Post a credit entry prior to the Settlement Date, or
          Do not return a debit entry in a timely manner.
          Controlling Credit Risk
          Credit risk is generally controlled by developing and implementing processing procedures, understanding compliance obligations and ensuring ACH operations staff are properly trained.

          ACH Operational Risk

          Operational risk represents the amount of loss related to unintentional errors, which may occur due to a hardware/software failure or clerical errors, such as untimely returns or the incorrect use of return reason codes. Any disruption in ACH processing can jeopardize the accurate and timely processing of ACH entries.
          Controlling ACH Operational Risk
          The evaluation of ACH operational risk and the determination of procedures to control those risks should include participation of auditors and outside professionals to ensure objectivity. Operational risk may be managed through automated security methods, as well as controlled operational procedures, which include cross-training of staff, dual controls and a contingency plan.

          ACH Fraud Risk

          Fraud risk represents risk that a transaction may be initiated or altered in an intentional effort to misdirect or misappropriate funds. Risks related to fraud are affected by internal as well as external factors. Fraudulent activities may be the work of dishonest employees, third-party processing personnel, originating company personnel or other outside parties.
          Controlling ACH Fraud Risk
          While controls related to ACH operational and credit risk may also be effective in diverting fraud, additional areas may include specific personnel practices and security.

          Personnel Practices

          The following are suggestions regarding practices and procedures that contribute to fraud risk management:
          Limit use of temporary employees
          Screen potential full-time employees
          Segregate duties
          Change or rotate work assignments
          Mandate physical security (i.e., individual passwords, physical locks, etc.)

          Security Practices

          It is up to the financial institution to ensure that its ACH operations are secure. Sensitive operation sites, such as the area that houses the computer and communications equipment, should be kept secure. All portable data, such as CDs, USBs, reports and physical file folders, should be kept in secure areas, as well as protected from hazards such as flood or fire. Computer terminals should automatically logoff after a set period of time.
          ACH processing software should be safeguarded with controls in place to ensure that only authorized changes can be undertaken. Communications software should provide security features, such as encryption or authentication to secure data during the process of transmission. In general, ACH processing security should conform to the organization’s data processing security policy.

          ACH Audit

          Refer to the Operating Guidelines of the ACH Rules for detailed information on the ACH Audit.
          All ACH participating financial institutions and Third-Party Service Providers must conduct an audit of ACH Rules compliance annually, by December 31, in accordance with the ACH Rules. This includes both ODFIs and RDFIs and their Third-Party Service Providers (Third-Party Sender, Sending/Receiving Point). The audit may be performed externally or internally under the direction of an audit committee, audit manager or senior level officer of the participating Depository Financial Institution or the Third-Party Service Provider.

          Data Security Requirements

          The ACH Rules establish data security requirements for all ACH transactions, regardless of Standard Entry Class (SEC) code, transmitted or exchanged via an Unsecured Electronic Network (UEN). An example of a UEN is the Internet. Any banking information, which includes but is not limited to, an entry, entry data, routing number, account number, PIN or other identification symbol, that is transmitted or exchanged via a UEN must be either
          (1) encrypted, or (2) transmitted via a secure session, in either case using commercially reasonable security that complies with applicable regulatory requirements.
          TPS must also have policies, procedures and systems in place designed to protect banking information from being breached. Such policies, procedures and systems will need to ensure banking information is secured throughout the ACH payment cycle, including the initiation, processing and storage of entries until destruction.

          Returns

          You cannot return an entry when your customer/member is not satisfied with or has not received the goods or services to which the ACH entry relates.
          ACH entries can be returned to an Originator for any valid reason just as deposited checks can be returned for any valid reason. A return entry is used when the RDFI is unable to post an ACH transaction or when an entry is being disputed. The ACH Rules allow an RDFI to return any entry for which there is a valid Return Reason Code. This may be due to incorrect information, which prevents the RDFI from identifying the correct account; a change in the account relationship, such as death or closure of an account; insufficient or uncollected funds in the Receiver’s account; or an entry the Receiver did not authorize.
          In general, returns must be transmitted so that the return entry will be made available to the ODFI no later than the opening of business on the second banking day following the Settlement Date of the original entry. This timeframe is referred to as the “24-hour” deadline. Here’s how it works:

          Tuesday
          Wednesday
          Thursday
          Friday
          Column
          Debit entry received by the RDFI, but cannot be posted due to insufficient funds
          Debit entry returned by the RDFI
          Debit entry made available to the ODFI at opening of business
          Settlement Date
          1st banking day following the Settlement Date
          2nd banking day following the Settlement Date
          There are no rows in this table
          In the above example, the RDFI returned the entry on the first banking day following the Settlement Date, or within 24 hours of receipt, in order to meet the required timeframe.
          Extended return entries for disputed transactions (i.e., revoked authorization or unauthorized) may be returned up to 60 calendar days from settlement. These entries require a Written Statement of Unauthorized Debit to be completed prior to the entry being returned.
          Returned entries may be reinitiated if the entry was returned for insufficient funds or uncollected funds and are limited in number to two and must be initiated within 180 days of the original entry. An entry returned for stop payment, or an authorization issue, may only be reinitiated if the Originator has received appropriate authorization from the Receiver to do so. Reinitiated entries contain “RETRY PYMT” in the Company Entry Description field of the Company/Batch Header Record.
          When returning an entry, always select the Return Reason Code that most accurately reflects the reason for the return. In doing so, you will effectively communicate to the ODFI and their Originator the appropriate action to take.

          Written Statement of Unauthorized Debit

          The Receiver must execute a Written Statement of Unauthorized Debit when an ACH entry is claimed as unauthorized, improper, authorization revoked, part of an incomplete transaction or improperly reinitiated. The Receiver must identify the reason that the entry is considered unauthorized, improper, authorization revoked, incomplete, or improperly reinitiated based upon the criteria described in the following section of this guide entitled Return Reasons by ACH Application.
          The Written Statement of Unauthorized Debit Rule reinforces both the Receiver’s direct responsibility to the Originator and the Originator’s right of recourse when conditions of revocation, as clearly indicated on the authorization agreement, are not met. Once the Written Statement of Unauthorized Debit has been signed and the Receiver has been recredited, the institution has satisfied its obligation under the ACH Rules.
          An ODFI may request, in writing, a copy of the Written Statement of Unauthorized Debit up to one year from the date of the extended return. Upon receipt of a timely request, an RDFI must provide a copy of the Written Statement of Unauthorized Debit within 10 banking days. The ACH Rules require the financial institution to retain the original or a reproducible copy of the Written Statement of Unauthorized Debit for one year from the Settlement Date of the extended return entry(ies). It is recommended that the RDFI retain a copy for six years along with the records of ACH activity.
          Refer to the Operating Guidelines of the ACH Rules for a sample Written Statement of Unauthorized Debit or contact your Payments Association to purchase these forms.

          Return Reasons by ACH Application

          As stated before, return entries must generally be transmitted by the institution so that the entry is made available to the ODFI no later than the opening of business on the second banking day following the Settlement Date of the original entry (“24-hour” deadline). Some reasons meeting this return deadline include:
          Insufficient funds (R01)
          Account closed (R02)
          No account/unable to locate account (R03)
          Invalid account number (R04)
          Additionally, a Receiver (consumer) may place a stop payment on an entry by providing either verbal or written stop payment instructions to the institution at least three banking days before the scheduled date of the entry or in such time and manner to allow the RDFI a reasonable opportunity to act upon the stop payment instructions prior to acting on the debit entry. In this case, the RDFI would return the entry within the “24-hour” deadline using Return Reason Code R08—Stop Payment.
          The table below represents the SEC codes that can be returned for the reasons mentioned:
          RETURN REASON
          ARC
          BOC
          IAT
          POP
          PPD
          TEL
          WEB
          R01 Insufficient Funds
          X
          X
          X
          X
          X
          X
          X
          R02 Account Closed
          X
          X
          X
          X
          X
          X
          X
          R03 No Account/Unable to Locate Account*
          X
          X
          X
          X
          R04 Invalid Account Number
          X
          X
          X
          X
          X
          X
          X
          R08 Stop Payment
          X
          X
          X
          X
          X
          X
          X
          There are no rows in this table
          *R03 may not be used to return ARC, BOC or POP entries solely because they do not contain the Receiver’s name in the Individual Name/Receiving Company Name field.
          The institution has an extended return deadline for the following reasons:
          Entry was not authorized by the Receiver (R10)
          Debit amount was in an amount different than authorized or in an amount other than indicated on the source document for check conversion (R11)
          Debit date was earlier than authorized (R11)
          Authorization for recurring payment has been revoked by the Receiver (R07)
          Consumer claims source document used for check conversion was not eligible for conversion (R10)
          Source document was presented for payment in addition to the ACH entry (R37)
          Proper notice was not provided to the Receiver regarding the check conversion (R10)
          Financial institution placed stop payment on paper item instead of document for ACH check conversion (R38)
          The debit was part of an incomplete transaction in which an Originator, Third-Party Sender or ODFI debits a consumer’s account to collect funds, but does not complete the corresponding payment (credit) to the party to which payment is owed. A non-consumer account may also dispute an incomplete ARC, BOC or POP entry (R11)
          A returned debit was improperly reinitiated (R10)
          For a listing of Return Reason Codes, see the Appendix of this guide.
          For the preceding exceptions, the return entry must be transmitted to the ACH Operator by the deposit deadline to be made available to the ODFI no later than the opening of business on the banking day following the sixtieth calendar day following the Settlement Date of the original entry. In all of these circumstances, except for R38—Stop Payment on Source Document, the RDFI would be required to obtain a Written Statement of Unauthorized Debit from its customer/member prior to returning the entry. If the RDFI is returning a check conversion entry using R38, the original stop payment form covers the return process.
          The table below represents the SEC codes that can be returned for the reasons mentioned:

          Corporate Debit Entries to a Consumer Account

          If a debit entry was transmitted to a consumer account using a corporate SEC Code (CCD or CTX) and it was not authorized by the consumer, the entry may be returned using Return Reason Code R05—Unauthorized Debit to Consumer Account Using Corporate SEC Code. The institution has 60 calendar days from the Settlement Date to return the entry and must obtain a Written Statement of Unauthorized Debit.

          Corporate Entries

          Return entries for corporate ACH transactions must be transmitted so that the return entry is made available to the ODFI no later than the opening of business on the second banking day following the Settlement Date of the original entry (“24-hour” deadline).
          The ACH Rules provide for the return of unauthorized corporate debits (CCD and CTX) with a unique Return Reason Code R29— Corporate Customer Advises Not Authorized. These transactions also have the “24-hour” deadline. However, if an RDFI receives notification from its corporate Receiver of an unauthorized corporate transaction beyond the return deadline, it may contact the ODFI and request permission to send a late return. If the ODFI agrees to accept the late return, the RDFI will return the entry using Return Reason Code R31—Permissible Return Entry. When Return Reason Code R31 is used without the ODFI’s permission, the ODFI has the right to dishonor the return using Return Reason Code R70—Permissible Return Not Accepted. The Dishonored Returns section of this Guide provides further details on dishonored returns.
          An RDFI may request, in writing, proof of authorization for corporate entries. If proof of authorization is requested, the ODFI must provide within ten banking days of the RDFI’s request either a copy of the authorization or the Originator’s company name and phone number or email address for inquiries.
          Given the limited and strict timeframes in which corporate entries must be returned, the financial institution may choose to offer services that would block unauthorized ACH debits. These services generally fall into two categories:
          ACH Debit Block—ACH debits destined to a particular account are automatically returned.
          ACH Debit Filter—ACH debits, except for those that are pre- authorized, destined to a particular account are automatically returned. This requires the corporate customer to identify who they will accept entries from.

          ACH Operator Rejects

          TAKE ACTION! If a mistake on a return entry is made and is rejected by the ACH Operator, the return timeframe will not be extended. Ensure that the issue is corrected quickly in order to remain within the established return timeframes.
          The ACH Operator may reject entries that are submitted with errors. A rejected entry can occur from either an origination file or return item file. When a return entry is rejected at the ACH Operator level, the entry does not go any further in the process and is not passed along to the ODFI. Instead, it is returned to the submitting RDFI for corrective action. Once corrected, the entry must be reinitiated. Deadlines for returns can be affected by ACH Operator rejects. For this reason, the RDFI should review an acknowledgment report provided by the ACH Operator to confirm successful transmission and processing of files.

          Dishonored Returns

          A dishonored return is an ACH return transmitted by an ODFI in response to a returned ACH entry that was mishandled by the RDFI for one of the following reasons:
          Untimely return of an ACH entry
          Misrouting of a return to the wrong ODFI
          The return contained incorrect or incomplete information as required by the ACH Rules
          An ODFI dishonors a returned entry in an attempt to either dispute the return for inappropriate handling or to advise the RDFI that an error in information prevents the entry from being identified. Special Return Reason Codes identify the ODFI’s reason for dishonoring a return. The addenda record of a Dishonored Return carries information that identifies the Return Reason Code and details the reason the entry was dishonored. A dishonored return must be transmitted by the ODFI within five banking days from the Settlement Date of the return entry.
          Contested Dishonored Returns
          The proper action required by the financial institution varies, depending on whether the dishonored return was disputed or represents a need for a correction. An RDFI may:
          Contest a dishonored return based on a dispute of timeliness, or
          Correct a dishonored return for the purpose of correcting return information related to the original entry (e.g., account number, transaction code, etc.)
          In either case, the RDFI must respond within two banking days of the Settlement Date of the dishonored return. If the RDFI properly contests a dishonored return (i.e., on time and without error), the ODFI must accept the entry and resolve further disputes outside of the ACH Network.
          Valid Dispute of Return Entry
          If the reason a return was dishonored is valid (e.g., a return disputed as untimely was, in fact, a late return), the institution must accept the entry. The RDFI may be able to collect funds from the customer/member in some cases (e.g., an account now has funds where the original entry was returned insufficient). Questions regarding the financial institution’s right to collect from the customer/member should be referred to legal counsel.

          Notifications of Change (NOC)

          Occasionally, the financial institution will receive an ACH entry that contains incorrect information (i.e., account number, account name, etc.). While it may be able to identify the intended account holder, the error may cause the item to reject. In these instances, the RDFI may send an NOC or return the entry. The NOC application allows the RDFI to send a message requesting the correction of information without returning the value of the entry. However, the institution does warrant that the information contained in an NOC is correct. By initiating an NOC, By initiating an NOC, the RDFI warrants the information sent in the NOC is correct.
          If an RDFI chooses to send an NOC, it must do so within two banking days from the Settlement Date of the original entry. Delayed processing of NOCs may make it difficult for the ODFI to match transaction information, resulting in a lack of response to the NOC. ODFIs must report NOC information to Originators within two banking days from the Settlement Date of the NOC. Originators of Recurring entries must make the specified changes within six banking days of receipt of the NOC information or prior to initiating another entry to the Receiver’s account, whichever is later. Originators of Single- Entry payments are not required to make the specified changes.

          Other Exceptions

          Duplicate Files
          A duplication of file processing can cause a host of problems from account overdrafts and returned items to customer service charges. Duplicated credits may cause improper withdrawals and incorrectly stated balances. Duplications should be suspected when items are received with identical trace numbers or have the same dates and amounts. The following action is suggested:
          Verify that the duplication is not a result of double posting by the financial institution. If so, reverse posting as soon as possible and notify customer assistance staff.
          Contact the ACH Operator or ODFI to determine whether the duplication was a result of their processing, and determine the method to be used in correcting the problem.
          In the case of duplicated debit entries, accounts should be monitored for improper returns and return charges. For duplicated credit entries, place holds on accounts to prevent improper withdrawals.
          The ODFI may ask an RDFI to return duplicated items; the RDFI should consider doing so promptly.
          Reversals
          In the event an erroneous or duplicate transaction or file is originated, the ACH Rules allow the Originator or ODFI to reverse the transaction or file. An erroneous entry or file is one that contains the wrong amount; is directed to the account of an entity not intended to be paid by the Originator; or is a duplicate of a previous transaction or file. The reversing entry or file must be transmitted within five banking days from the Settlement Date of the erroneous or duplicate entry or file. If funds are available in the customer’s/member’s account, the RDFI must accept the transaction. An Originator initiating a reversing debit entry must ensure the Effective Entry Date is not earlier than the Effective Entry Date of the erroneous credit entry to which it relates.
          The ACH Rules require the Originator of a reversing entry to notify the Receiver that a reversing entry has been transmitted to their account, including the reason for the reversal, no later than the Settlement Date of the reversing entry.
          When an ODFI originates a reversal, the transactions are batched separately. In doing so, the word “REVERSAL” must appear in the Company Entry Description field in the Company/Batch Header Record.

          ODFI Request for Return
          The ODFI may request the return of an entry that was duplicated, sent in error or that was not authorized to be originated by the Originator. Although the RDFI does not have to consent to the request, it is encouraged to work with the ODFI. It is reasonable that the RDFI require a written request to document the return prior to returning it using Return Reason Code R06—Returned per ODFI’s Request. The ODFI indemnifies the financial institution against all losses that result from the origination of erroneous entries and reversals.

          APPENDIX

          ACH File Format

          Nacha Batch/File Level Information

          Company Name—entity or individual originating batch of entries (Originator)
          Company ID—number that uniquely identifies the Originator to the ODFI (tax ID number often used)
          Settlement Date—three-digit Julian date which represents the date funds are actually settled by the ACH Operator (i.e., Federal Reserve Bank or The Clearing House)
          Originator Status Code—distinguishes between Commercial and Federal Government Originators (1=Commercial, 2=Federal Government entity or agency)
          Standard Entry Class Code—three-character alpha code which distinguishes application type and identifies which rules apply
          Company Entry Description—describes the entry and should be provided to the account holder
          Effective Entry Date—date Originator intended entries to settle (actual Settlement Date may differ)
           
          Want to print your doc?
          This is not the way.
          Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
          CtrlP
          ) instead.