ACH Rules Update for Originating Companies

Transcription

1 2013 ACH Rules Update for Originating Companies EPCOR, as a Direct Member of NACHA, is a specially recognized and licensed provider of ACH education, publications and support. 2013, EPCOR Published by EPCOR All Rights Reserved 3100 Broadway, Suite 609, Kansas City, Missouri Conditions of use are within the control of individual users. There is no warranty, expressed or implied, in connection with making this publication available, and EPCOR is in no way responsible for any errors or omissions in this guide. NACHA owns the copyright for the NACHA Operating Rules and Guidelines ACH Rules Update for Originating Companies 1

2 Significant Impact to Originators TPP Operations Bulletin (Not an ACH Rules Change) Effective January 1, 2013 This NACHA ACH Operations Bulletin advises financial institutions, state revenue agencies and other parties that remit tax payments to state revenue agencies of a new Third-Party Tax Payment banking convention. NACHA recommends that the TPP convention be followed when formatting and transmitting remittance information in the addenda record of a CCD entry for certain third-party tax payments. Applications using the TPP banking convention include: payroll service providers making quarterly employment tax payments; income withholding payments made by pass-through entities on behalf of nonresident partners; garnishments; and other levies. IMPACT TO CORPORATE USERS: If Originators/Third-Party Senders are using the ACH Network to send payments to state revenue authorities, they may already be familiar with the TXP banking convention. If an Originator is using a Third-Party to make ACH payments to the state revenue authorities, they should be prepared to use the TPP banking convention to make these payments. Data Passing Rule This new Rule adds language to the ACH Rules that prohibits sharing of certain information by Originators and Third-Party Senders for purposes of initiating debit entries that are not covered by the original authorization. (OR7) Most data passing has been prohibited by the Restore Online Shoppers Confidence Act, however, the ACH Rules have been updated to prohibit the data passing of information regardless of how the original authorization was obtained (i.e. online, written, verbal) IMPACT TO CORPORATE USERS: Originators should ensure that they are not sharing ACH data for purposes of originating entries that are not covered in the original authorization. Originator Obligations with Respect to NOC for Single Entries Rule This Rules change makes optional the Originator response to Notifications of Change (NOCs) for Single Entry payments. The proposed Rules change would not disallow an RDFI s initiation of an NOC for a Single Entry, nor would it mandate the Originator to make the changes provided in such NOCs. The following SEC Codes would be affected by this proposal: ARC, BOC, POP, POS, RCK and XCK entries, as well as, TEL and WEB entries bearing a single entry indicator ( S or blank for TEL and S for WEB). IMPACT TO CORPORATE USERS: When an Originator/Third-Party Sender receives an NOC for a recurring ACH, they are REQUIRED to make the changes noted in the NOC. When an Originator/Third-Party Sender receives an NOC for a single-entry ACH, they may determine whether or not making the change noted in the NOC is beneficial. ACH Security Framework Rule This Rule has three elements in regard to protecting the security and integrity of certain ACH data throughout its lifecycle. 1. Protection of Sensitive Data and Access Controls (OR xliii) Requires Originators to establish, implement, and (as appropriate) update security procedures relating to the initiation, processing and storage of entries. IMPACT TO CORPORATE USERS: Each Originator will need to evaluate its current security policies, procedures and systems to ensure the company identifies safeguards for protected information - non-public information, including financial information of customers. Security policies, procedure and systems must: protect the confidentially and integrity of the protected information protect against anticipated threats or hazards to the security or integrity of protected information until its destruction protect against unauthorized use of protected information that could result in substantial harm to the customer. If the Originator does not have up-to-date security policies, procedures and systems to ensure the company identifies safeguards for protected information, they will need to be developed. If a corporate user accepts credit cards, controls like those set out in PCI should be developed and followed for ACH information. ACH Security Framework Rule continued on next page 2013 ACH Rules Update for Originating Companies 2

3 ACH Security Framework Rule continued from previous page 2. Self-Assessment (OR xliii) Adds criteria to the ACH Rules Compliance Audit to ensure financial institutions are following new ACH Data Security Rules. IMPACT TO CORPORATE USERS: While the ACH Rules do not require an Originator to compete an ACH Rules Compliance Audit, the ODFI/Originator Agreement allows the ODFI to audit corporate Originators. If an ODFI chooses to audit its Originators, the corporate user should be willing and able to prove compliance with the ACH Rules. 3. Verification of Third-Party Senders and Originators (OR xliv) Establishes a requirement that ODFIs must use a commercially reasonable method to determine the identity of each Originator when the ODFI enters into an ACH Agreement with the Originator. IMPACT TO CORPORATE USERS: Originators should be prepared to use commercially reasonable efforts to prove its identity when entering into an Agreement with an ODFI for ACH origination services. Healthcare Payments via ACH These amendments to the ACH Rules support payments made between health plans and healthcare providers when using the ACH Network to process healthcare claim payments. These new Rules help to standardize the health care EFTs as mandated by the Patient Protection and Affordable Care Act. Key components of the New Rules include: 1. Unique Identification of Healthcare EFTs This amendment requires Originators to clearly identify CCD Entries that are Health Care EFT transactions through the use of a specific identifier. Specifically, the new Rules require Originators of Health Care EFT Transactions to populate the Company Entry Description field of the CCD Entry with the value HCCLAIMPMT. IMPACT TO CORPORATE USERS: Corporate users who are originating Health Care EFTs should use the HCCLAIMPMT in the Company Entry Description field of the Company/Batch Header Record. 2. Company Name Formatting As is required for all ACH transactions, the Company Name field must be populated with information that is readily recognized by the Receiver, which in this case is most likely a healthcare provider. In situations where an organization is self-insured, this field could contain the name of the organization s third-party administrator that is recognized by the healthcare provider and to which the healthcare provider submits its claims. IMPACT TO CORPORATE USERS: Corporate users who are originating Health Care EFTs should populate the Company Name Field of the Company/Batch Header Record so that it will be recognized by the Receiver. 3. Addenda Record and Payment Related Information Requirements The new Rule requires Originators to include an addenda record with each CCD Entry used for a Health Care EFT Transaction. The Rule also requires Originators to populate the Payment Related Information field of the addenda record with the ANSI ASC X12 Version TRN (Reassociation Trace Number) data segment. IMPACT TO CORPORATE USERS: Corporate users who are originating Health Care EFTs should populate the Payment Related Field of the Addenda Record with the appropriate data segments. 4. Delivery of Payment Related Information The Rule requires an RDFI to provide or make available, either automatically (if such a service is established by the RDFI) or upon the request of a Receiver that is a healthcare provider, the CORE-required Minimum CCD+ Data Elements (amount, effective entry date and information contained within the payment-related field of the addenda record). The RDFI is required to provide or make available the Payment Related Information no later than the opening of business on the RDFI s second Banking Day following the Settlement Date of the Entry. The Rule also requires the RDFI to offer or make available to the healthcare provider an option to receive or access the Payment Related Information via a secure, electronic means that provides a level of security that, at a minimum, is equivalent to 128-bit RC4 encryption technology. IMPACT TO CORPORATE USERS: This Rule should have little impact on the corporate user. However, if the corporate user is a Health Care Provider, they should familiarize themselves with the Rule requirements in regard to receiving payment-related information from their financial institution. 5. Addition of New EDI Segment Terminator The Healthcare Payments via ACH changes provide for the use of a second data segment terminator, the tilde ( ~ ), to any data segments carried in the Addenda Record of the CCD Entry. IMPACT TO CORPORATE USERS: Corporate users who are originating Health Care EFTs should understand the addition of formatting characters in the Payment Related field of the Addenda Record ACH Rules Update for Originating Companies 3

4 Effective Period of Stop Payments for Non-Consumer Accounts Rule This Rule amends the ACH Rules to incorporate two additional conditions under which a stop payment order on an Entry to a Non-Consumer account would lapse. IMPACT TO CORPORATE USERS: When an Originator receives a return of a CCD or CTX entry as R08, they should assume that only that specific payment is being stopped, and not future payments to that Receiver. It is in the best interest of the Originator user to contact the corporate Receiver to fully understand the company s reason for stopping the payment. Incomplete Transactions Rule This Rule allows an RDFI to return a debit entry to a consumer account within 60 days of the Settlement Date when the entry is part of an Incomplete Transaction. Incomplete Transaction is defined as a transaction for which a Third-Party Sender debits a consumer s account to collect funds but does not complete the corresponding payment to the party which the payment is owed. (OR 44) IMPACT TO CORPORATE USERS: If an Originator receives a return as R10 Unauthorized Debit - they should be aware that this could be for the reason that the debit entry was part of an Incomplete Transaction. Also, since the Originator s customers are re-credited by the RDFI, these customers will be in a better position to make alternative payment arrangements with the intended recipient if the Originator did not receive the corresponding ACH payment. Proof of Authorization for Non-Consumer Entries Rule Effective September 19, 2014 This ACH Rule permits an RDFI to request proof of a non-consumer Receiver s authorization for a CCD or CTX entry, or inbound IAT entries; and requires that, upon receipt of an RDFI s written request, the ODFI must provide an accurate record of the Receiver s authorization, or Originator s name, phone number and address for inquiries to the RDFI within ten banking days without charge. IMPACT TO CORPORATE USERS: Originators of CCD, CTX or inbound IAT entries should be prepared to provide information to the RDFI about an authorization for ACH, if requested, within 10 banking days of the request. Originators/Third-Party Senders will need to work with their ODFIs to get this information to the appropriate parties when requested. IAT Modifications Rules Return Reason Code (R85) for Gateway Use with Incorrectly-Coded International Payments This change defines an additional Return Reason code (R85) for use by Gateways to clearly indicate that an ACH entry is being returned because it is part of an IAT transaction, but the SEC code has not been coded as such. IMPACT TO CORPORATE USERS:, if an Originator receives a return as R85 from the Gateway, it must either code the transaction with an IAT SEC code or find another payment channel to originate the payment. (OR 145) Notification of Change Code (C14) for Gateway Use with Incorrectly-Coded International Payments This amendment creates an additional Notification of Change code (C14) for use by Gateways to notify an Originator that an entry that is part of an IAT transaction has been processed, however, the SEC code has not been coded as such. IMPACT TO CORPORATE USERS:, if an Originator receives an NOC as C14 from the Gateway, it must either code future transactions with an IAT SEC code or find another payment channel to originate the payment. (OR 70) 2013 ACH Rules Update for Originating Companies 4

5 Corrected Data for IAT Entries This Rule clarifies that any country named within the Originator Country and Postal Code field within the third Addenda Record and the Receiver Country and Postal Code field within the seventh addenda record of an IAT entry must be identified using the county s ISO Country Code, as defined by the International Organization for Standardization. IMPACT TO CORPORATE USERS: Originators of IAT entries must ensure that ISO country codes are used in specific fields of the IAT addenda records. ODFI Warranties Compliance with Foreign Payment System Rules This Rule revises the current ODFI warranty of compliance with foreign payment system rules (for Outbound IAT Entries), narrowing the scope to focus only on authorization of the entry when such authorization is required by the laws or payment systems rules of the receiving country. IMPACT TO CORPORATE USERS: While the impact of this Rules change should be minimal to the corporate user, this Rules change is expected to reduce barriers to entries initiated into the IAT marketplace. Little or No Impact for Corporate Users IAT Use of Return Reason Code R16 to Identify OFAC-Related Returns Rule This amendment revises the description of R16 (Account Frozen) to also accommodate for the return of entries in response to instruction from OFAC. IMPACT TO CORPORATE USERS: Since implementing IAT, R16 has been the preferred return code for OFAC-related returns. However, effective March 15, 2013, the description of R16 was expanded to include such returns (OR 130). When an Originator/Third-Party Sender receives an ACH return as R16, they should ensure that they are not sending payments to individuals on the SDN list. ODFI Return Rate Reporting Rule This modification will reduce the reporting period which the ODFI has to reduce a return rate for unauthorized transactions below the 1% threshold from 60 days to 30 days. (OR 32-33). IMPACT TO CORPORATE USERS: Originators and Third-Party Senders with excessive return rates will be compelled by their ODFIs to take action to reduce the return rate for unauthorized transactions below the 1% threshold more quickly. P2P Payments Rule Effective March 21, March 20, 2015 Specifically, this Rule: Defines a P2P payment in the Rules; Allows a credit version of the WEB Standard Entry Class (SEC) Code to be used for a P2P credit transaction sent from a consumer s DDA; Establishes standardized formatting requirements for such a WEB credit; Ensures that for WEB credits - and WEB debits if used to fund P2P transactions - the Company Entry Description in the Company/Batch Header Record contains a value that lets the Receiver know that the entry is a P2P transaction; Clarifies in the Rules how Notifications of Change (NOCs) should be handled for P2P WEB credits and for bill payment CIEs; Creates a new Addenda Type Code to enable the Originator/ODFI to provide a URL link to additional payment related information; and, Allows an Addenda Record for a WEB credit to include up to 80 characters of payment related information in free form text. IMPACT TO CORPORATE USERS: Since this Rules change deals with Person-to-Person payments, it should have little to no impact on the corporate user ACH Rules Update for Originating Companies 5

6 Additional 2014 & 2015 Rules IAT Modifications - ID of Country Names within IAT Entries Effective March 21, 2014 This Rule clarifies that any country named within certain fields of an IAT entry must be identified using that country s 2-digit alphabetic ISO country code (as defined by the International Organization for Standardization). IMPACT TO CORPORATE USERS: If a corporate user originates IAT, they should ensure they are using the proper identification for country names in certain fields of the ACH record. IAT Modifications - ID of Additional Parties to an IAT Transaction Effective March 21, 2014 This Rule establishes a new Gateway obligation to identify within an Inbound IAT Entry: The ultimate foreign beneficiary of the funds transfer when the proceeds from a debit Inbound IAT Entry are for further credit to an ultimate foreign beneficiary that is a party other than the Originator of the debit IAT Entry, or The foreign party ultimately funding a credit Inbound IAT Entry when that party is not the Originator of the credit IAT Entry. This Rule also revises the description of the Payment Related Information Field as it relates to the IAT Remittance Addenda Record to establish specific formatting requirements for inclusion of the ultimate foreign beneficiary s/payer s name, street address, city, state/province, postal code and ISO Country Code. IMPACT TO CORPORATE USERS: If a corporate user originates IAT, they should ensure the proper identification for additional parties in the IAT file is being used. Dishonored Returns and Contested Dishonored Returns Related to Unintended Credit to a Receiver Rule Effective March 20, 2015 This Rule permits an ODFI to dishonor a return entry relating to an erroneous transaction provided that it can substantiate that it had also originated a reversing entry to correct the erroneous transaction. To support this ability this Rule defines a new dishonored return reason code R62 for use by the Originator/ODFI when the reversal process has resulted in an unintended payment to and enrichment of the Receiver. This Rule also defines a new contested dishonored return reason code R77 for use by the RDFI, when appropriate, in response to such dishonored returns when the RDFI has returned both the erroneous entry and the reversal. IMPACT TO CORPORATE USERS: When sending a reversing credit for a debit that was unintentionally sent, an Originator/Third-Party should be aware of their right to dishonor the return of the unintentional when the corresponding reversing credit entry is not returned ACH Rules Update for Originating Companies 6