Article 1 of the ACH Rules applies to all participants who transmit and/or receive ACH entries. This section is applicable to all ACH participants and is considered general rules to participating in the ACH Network.
Compliance with the Rules
Each financial institution agrees to comply with the Rules and warrants it is legally able to do so. Through the ACHQ Payment Services Agreement and financial institution disclosures Originators also agree to comply with the Rules.
Electronic Record Creation and Retention
Records can be obtained and archived electronically if the electronic record accurately reflects the information contained in the original record AND the electronic record is capable of being reproduced accurately for later reference.
Electronic signatures are permitted if they comply with the Electronic Signatures in Global and National Commerce Act, more commonly known as the E-Sign Act.
All parties, including Originators, must be able to protect the confidentiality and integrity of protected information until its destruction. Originators should work to protect against anticipated threats to the security of the information (data breach) and unauthorized use of the information (fraud).
Banking information (routing numbers, account numbers, Social Security numbers, PIN numbers) contained in an ACH entry that is transmitted over an Unsecured Electronic Network (UEN – the Internet) must be either encrypted or sent via a secure session that provides commercially reasonable security that complies with applicable regulatory requirements.
Choice of Law
The Rules have adopted the State of New York’s version of Uniform Commercial Code Article 4A. This may be altered through agreement (e.g., ODFI/Originator Agreement, Deposit Agreement, etc.). (Section 1.8)
Authorizations and SEC Codes
An SEC code is a three letter code that describes how a payment was authorized by the consumer or business receiving an ACH transaction. SEC stands for 'Standard Entry Class'.
How do SEC Codes work in practice?
It is the responsibility of the ACHQ to include the correct SEC code in the ACH payment when originating a file. SEC codes are attached to the ACH payment request since they are a part of the NACHA file format.
It is also the responsibility of the the Originator, to have the proper authorization in place from the Receiver. The nature of this authorization depends on the SEC code and whether funds are being debited or credited. For example:
- Most ACH debits require written or electronic authorization from the recipient while most ACH credits do not.
- Debits authorized on a phone call need to use the SEC code TEL and require the company originating the payment maintain a recording of the customer's verbal authorization. Alternatively, they need to follow up with the customer for a written confirmation of the authorization before initiating the payment.
Including the incorrect SEC code could result in an ACH Return. The Originator is then responsible for any return fees and resubmitting the payment with the correct code.
Standard Entry Class (SEC) Codes
Your integration with ACHQ allows you to utilize the following subsection of SEC Codes:
|SEC CODE DESCRIPTION||APPLICATION USE|
|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.|
|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.|
|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 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.|
|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.|
In accordance with the Nacha Rules, you must obtain appropriate authorization from the owner of the bank account before initiating an ACH payment. As the Originator of the transaction, it is your sole responsibility to (1) verify the identity of your customer; (2) determine their eligibility to purchase your products or services; and (3) obtain appropriate authorization to initiate ACH debits from or ACH credits to their account.
As part of the authorization process, we suggest collecting and storing (digitally or in paper form) the following information for 2 years from the date of the last transaction covered by that authorization (at a minimum). However, refer to the Nacha Rules to ensure you are complying with your obligations.
- Customer consent – Authorization page or written document that clearly states you are obtaining the customer’s consent to debit their bank account for a particular transaction or for recurring transactions
- Transaction-specific information – Date and time of transaction, account information of debited account, item or service purchased, frequency of payment (if recurring), and IP address
- Customer account information – Name on the account, shipping details (if applicable), and any other ways to verify the customer’s identity
- Transaction receipt – Provide the customer a receipt of the transaction by sending them an e-mail receipt of the transaction and also giving them the ability to print the authorization to retain a copy
- Process to revoke authorization – Include a telephone number and e-mail address where your customer can contact you to do so, which should be on the authorization page and in the receipt
|SEC CODE||ENTRY TYPE||AUTHORIZATION REQUIREMENT|
|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.|
|Corporate Credit or Debit (CCD) (Corporate to Corporate)||Debits/ Credits||Agreement required for transfers between companies; written authorization implied.|
|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|
*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.
Updated 7 months ago