Quick Guide for ACH Originators
The following ACH Operating Rules and Guidelines outline essential information for ACH Originators while utilizing Grand Savings Bank’s Cash Management ACH services. The Rules noted below do not cover the full scope of the Rules as governed by the National Automated Clearinghouse Association (NACHA) but do highlight what we as the Originating Depository Financial Institution (ODFI) want ACH Originators to be educated on.
“NACHA governs the ACH Network, the payment system that drives Direct Deposits and Direct Payments with the capability to reach all U.S. bank and credit union accounts. We advance the nation’s payments system and deliver payments education, accreditation, and advisory services.”
Source: www.nacha.org
Much of this information is mimicked from the Electronic Payments Core of Knowledge (EPCOR) ACH Quick Reference Guide. A copy of the full Guide is available upon request.
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 (addenda/description) 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 (FI) as proper handling of entries will mitigate any potential losses associated with human error. Commonly used SEC codes are listed below with their use.
CCD SEC | 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 locations 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 application can 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.
CTX SEC | Corporate Trade Exchange | The Corporate Trade Exchange (CTX) application provides the ability to collect and disburse funds and information between companies. This SEC 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 FIs of participating companies. Up to 9,999 payment-related data fields may be added to CTX files.
PPD SEC | 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 if proper notice is provided.
Authorization Requirements
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. 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.
CCD SEC | Debit or Credit Entry Type | Agreement required for transfers between companies; written authorization implied. Written and Signed (wet signature or electronic) authorization form strongly encouraged.
CTX SEC | Debit or Credit Entry Type | Agreement required for transfers between companies; written authorization implied. Written and Signed (wet signature or electronic) authorization forms strongly encouraged.
PPD SEC | Credit Entry Type | Authorization required. Oral or non-written means (i.e., voided check) accepted.
PPD SEC | Debit Entry Type | Authorization required. Written, Signed, or Similarly Authenticated. (Electronic signature, in accordance with E-Sign Act) Authorization for Return Fee Entries may be obtained by providing notice to the consumer when the original debit is presented for payment.
Notifications of Change (NOC)
Occasionally, a FI will receive an ACH entry that contains incorrect information (i.e., account number, account name, etc.). While the FI may be able to identify the intended account holder and post the transaction, some errors may cause the item to reject. In these instances, the Receiving Depository Financial Institution (RDFI) may send an NOC or return the entry. The NOC application allows the RDFI to send a message requesting the correction of information, prior to the next live file, without returning the value of the entry. By initiating a 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. ODFIs must report NOC information to Originators within two banking days from receipt of NOC information. Originators of Recurring entries must make the NOC 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.
ACH Reversal Rules
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/business’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 or Originator 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.
ACH Returns
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 is how it works:
In the above example, the RDFI returned the entry on the first banking day following the Settlement Date, or within 24 hours of receipt, to meet the required timeframe. Unauthorized Corporate transactions (CCD) are limited to the “24-hour” deadline.
Extended return entries for disputed transactions (i.e., revoked authorization or unauthorized) may be returned up to sixty calendar days from settlement, dependent on the SEC code of the transaction. These entries require a Written Statement of Unauthorized Debit to be completed prior to the entry being returned.
Risk Management and Assessment
Risk management is every FI’s responsibility. There are three key types of risk affecting ACH payment processing that Originators, ODFIs and RDFIs 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.
Personnel Practices | The following are suggestions regarding practices and procedures that contribute to risk fraud management:
- Internal dual control practices (one User initiates file, separate User reviews/approves file).
- Develop internal policies surrounding check writing (ex: invoices over certain dollar thresholds are required to be paid via ACH, two signatures required on checks issued).
- Mandate physical security (individual passwords on computers and phones, store sensitive information in secure locations, physical locks, etc.).
- Require call back verification for all payment requests received via email.
- Update software, including apps, web browsers, and operating systems (encrypt devices).
ACH Origination Rules Revision
Effective March 20, 2026, the following descriptors are required to be included in the ACH file “Description” for the below file types:
- “PAYROLL” for wages, salaries, and similar types of compensation
- “PURCHASE” for e-commerce or the purchase of goods or services
To include, simply key in “PAYROLL” or “PURCHASE” in the “Description” line shown below when originating a new ACH file.
Fraud Monitoring Rules for ACH Originators
Effective June 22, 2026, all ACH Originators must establish and maintain documented, risk-based processes and procedures designed to identify and respond to unusual or potentially fraudulent ACH activity. These processes must be reviewed and updated at least annually to reflect evolving fraud trends.
While the ACH Rules do not prescribe a specific format or checklist for an Originator’s internal procedures, they emphasize the critical role Originators play in fraud detection, particularly through their control over authorization and transmission of ACH entries. Because most ACH fraud attempts involve either:
- the creation of a new authorization, or
- a change to existing authorization or account information,
Originators should focus their risk-based controls on key triggering events, including but not limited to the following:
- New ACH Receivers: ACH transactions involving receivers that have never previously been paid or debited
- Changes to Existing Receiver Information: Updates to bank account numbers, routing numbers, or other critical payment details for an established ACH Receiver
- Abnormal or Unusual Activity: Transactions that are inconsistent with historical behavior, such as:
- unusually large dollar amounts
- sudden increases in transaction frequency
- grouped or batched transaction requests outside normal patterns
Verification and Secure Communication
When a triggering event occurs, Originators should:
- Independently verify the request by contacting the authorized individual using contact information already on file, not information included in the change email or fax request
- Use direct phone calls or other out-of-band verification methods to confirm legitimacy
- Transmit sensitive information only through secure or encrypted channels, reducing the risk of interception or email compromise
Responding to Suspected Fraud
This Rules change is not limited to identifying suspicious transactions — it also requires businesses to define how they will respond when potential fraud is detected. Documented procedures should clearly outline:
- escalation steps,
- decision-making authority,
- transaction holds or delays, and
- communication and reporting expectations.
What “Risk-Based” Means
Risk-based processes are those designed to align controls with the level of risk associated with a transaction. The ACH Rules intentionally allow flexibility — what is appropriate for one business may differ for another based on size, transaction volume, customer base, and risk tolerance.
At the ACH Fraud Monitoring Rules core, the question is:
Based on the level of risk, is the business doing enough to reasonably prevent ACH fraud?
At a minimum, businesses should: Stop, Think and Thoroughly Verify email-based ACH requests.
These simple steps alone can prevent fraudulent ACH entries from ever being initiated.
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.
RDFIs 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.
Supplementing Data Security Requirements
This rule applies to all Originator merchants, billers, businesses, governments and third parties that send 2 million or more ACH (electronic) payments (items, not dollars) per year, debits, or credits, regardless of FI used for sending. The existing security framework for the ACH Network is being supplemented to require parties with large volumes to protect an account number that is used in an ACH payment. The account number must be rendered unreadable anywhere the sender has stored it electronically while not in use.
This rule does not cover data beyond the account number or payment methods other than ACH. The rule does not prescribe a specific method of protection, but requires that a commercially reasonable method be used. Options include but are not limited to:
- Encryption
- Truncation / Masking
- Tokenization
- Financial Institution – hosted storage solutions
Please do not hesitate to email grandbusiness@grandsavingsbank.com for any questions related to Business Online Banking. Thank you for choosing Grand Savings Bank!