NOTICE OF AMENDMENTS TO THE 2013 NACHA OPERATING RULES AND GUIDELINES April 19, 2013 SUPPLEMENT #1-2013 NACHA Operating Rules Effective Date: March 15, 2013 1. ODFI Warranties Compliance with Foreign Payment System Rules Effective Date: September 20, 2013 2. Originator Obligations with Respect to Notifications of Change for Single Entries 3. Stop Payments - Effective Period of Stop Payment for Non-Consumer Account Effective Date: March 21, 2014 4. Identification of Additional Parties to an IAT Entry 5. Identification of Country Names Within IAT Entries 6. Person-to-Person Payments via ACH Effective Date: September 19, 2014 7. Proof of Authorization for Non-Consumer Entries Effective Date March 20, 2015 8. Dishonored Returns and Contested Dishonored Returns Related to an Unintended Credit to a Receiver NACHA Operating Guidelines 1. General Rules 2. ODFI Risk Management 2013 NACHA The Electronic Payments Association. All rights reserved. No part of this material may be used without the prior written permission of NACHA. This material is not intended to provide any warranties, legal advice, or professional assistance of any kind.
Supplement #1-2013 to the NACHA Operating Rules SUPPLEMENT #1-2013 TO THE NACHA OPERATING RULES On March 7, 2013, NACHA s Voting Membership approved eight amendments to the NACHA Operating Rules (Rules). The effective dates for these rule changes cover a two-year period between March 15, 2013 and March 20, 2015. The effective date for each specific change is indicated below. This supplement provides ACH Network participants with a summary of the key components of each change, along with details regarding the technical changes to Rules language. To ensure compliance with the most current rules, this Supplement should be used in conjunction with the 2013 edition of the Rules. 2
ODFI Warranties Compliance with Foreign Payment System Rules (Approved March 7, 2013 Effective March 15, 2013) SUMMARY This Rule revised the ODFI s warranty of compliance with foreign payment system rules (for Outbound IAT Entries), narrowing its scope to focus only on authorization of the Entry when such authorization is required by the laws or payment system rules of the receiving country. The narrower warranty also limits the scope of the ODFI s indemnity for breach of warranty. KEY COMPONENTS OF RULE AMENDMENT ODFI Warranty for Outbound IAT Entries - Compliance with Foreign Laws or Payment System Rules Regarding Authorization Effective March 15, 2013, ODFIs transmitting Outbound IAT Entries warrant only that they are in compliance with foreign laws or payment system rules regarding authorization of the Entry, if authorization is required. ODFIs presumably will pass this warranty to their Originators in order to confirm that Originators have obtained any authorization required for their Outbound IAT Entries. Assumption of Risk by ODFI/Originator Regardless of this narrowing of the ODFI s warranty, Gateways should not have to bear the risk that foreign law or payment system rules may prohibit the processing of a transaction, possibly resulting in the seizure of funds. As a result, this Rule specifically allocates to the Originator of an Outbound IAT Entry (credit or debit) the risk that foreign law or payment system rules may prohibit the processing of that transaction. Under the revised rules, the risk is borne by the ODFI in the relationship between the ODFI and the Gateway, and by the Originator in the relationship between the Originator and the ODFI. Any loss therefore would ultimately accrue to the Originator unless there is an agreement between the Originator and the ODFI, or between the ODFI and the Gateway, to allocate the risk of loss differently (or a different result is required by applicable law or regulation). It is incumbent upon Originators to understand the nature of sending payments to or seeking payments from other countries and the potential risk that international payments processing entails. IMPACT TO PARTICIPANTS Originators/ODFIs/Gateways: The narrowing of the ODFI warranty with respect to Outbound IAT Entries should have no operational impact on ACH participants. The reduction in the scope of the warranty and new statement regarding allocation of risk are expected to remove perceived barriers to entry into the international payments arena. It is important to keep in mind, however, the need for Gateways, ODFIs, and Originators to work closely together to ensure that all participants have a sound understanding of international payments processing and any potential risks that such activity entails. TECHNICAL SUMMARY Below is a summary of the impact of this rule change on the NACHA Operating Rules. Sections of the Rules that are affected by this amendment are also included below and reflect rule language as it will read upon implementation in highlighted, italicized text. Article Two, Subsection 2.5.8.4 (Additional ODFI Warranties for Outbound IAT Entries) narrows the scope of subsection 2.5.8.4(b) to limit the requirement to comply with foreign laws and payment system rules to authorization requirements only. 3
Article Two, Subsection 2.5.8.7 (Assumption of Risk) adds a new subsection 2.5.8.7 addressing the assumption of risk for Outbound IAT Entries. Implementation Date: March 15, 2013 As approved March 7, 2013, effective March 15, 2013, the Rules are modified as follows for the rule changes specific to ODFI Warranties for Outbound IAT Entries: ARTICLE TWO Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders SUBSECTION 2.5.8.4 Additional ODFI Warranties for Outbound IAT Entries In addition to the other warranties contained within these Rules, an ODFI initiating an Outbound IAT Entry warrants to each RDFI, ACH Operator, and Gateway: (a) Compliance with U.S. Legal Requirements. The Originator and ODFI are in compliance with U.S. Legal Requirements with respect to the IAT Entry, including their obligations under programs administered by the U.S. Department of the Treasury s Office of Foreign Assets Control (OFAC) and the Financial Crimes Enforcement Network (FinCEN). (b) Compliance with Foreign Payment System Rules. The origination of the IAT Entry complies with the laws and payment system rules of the receiving country. (b) Compliance with Foreign Laws or Payment System Rules Regarding Authorization. If the laws or payment system rules of the receiving country require authorization with respect to an IAT Entry, the ODFI warrants that the authorization of the IAT Entry complies with the laws and payment system rules of the receiving country. SUBSECTION 2.5.8.7 Assumption of Risk (new subsection) As between the ODFI and the Gateway of an Outbound IAT Entry, the ODFI bears the risk that the laws of the receiving country prohibit or otherwise preclude the processing, settlement, or transfer of the proceeds of the Entry, including through blocking or other sequestration or seizure of funds, unless otherwise agreed between the Gateway and the ODFI. As between the Originator and the ODFI, the Originator bears all such risk, unless otherwise agreed between the Originator and the ODFI or required by Legal Requirements. 4
Originator Obligations with Respect to Notifications of Change for Single Entries (Approved March 7, 2013 Effective September 20, 2013) SUMMARY This Rule makes the Originator s response to Notifications of Change (NOCs) for Single Entry payments optional. KEY COMPONENTS OF RULE AMENDMENT Originator Discretion to Act on NOCs Related to Single Entries This Rule makes an Originator s action on changes requested by NOCs related to Single Entries optional, at the Originator s discretion and based on its particular business model. Specifically, the Rule defines Originator action on NOCs related to the following SEC Codes as optional: ARC, BOC, POP, 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). RDFI s Right to Transmit NOCs Related to Single Entries The Rule does not change an RDFI s right to initiate an NOC for any Entry, including those identifiable as Single Entries; however, RDFIs must recognize that changes requested for Single Entries are not required to be made by the Originator. IMPACT TO PARTICIPANTS Originators: Originators of Single Entry payments will have discretion in deciding whether to act on changes related to one-time payments, based on their own industry needs and business models. Originators with repeat Single Entry customers (those making weekly grocery purchases or paying monthly utility bills, for example) could benefit from continuing to make changes included in NOCs, while Originators with true one-time purchasers may not find it efficient to maintain the infrastructure needed to house and support corrected data. Each Originator should consider the nature of its business and the likelihood of receiving repeat transactions involving the same customer when determining whether to act on NOCs related to Single Entries. RDFIs: RDFIs that transmit NOCs in response to Single Entries need to be aware that action on such requests by Originators is optional, at the Originator s discretion, and that correction to future one-time payments is not guaranteed. RDFIs should take the opportunity to review and ensure the accuracy of checks and other documents available to account holders to obtain routing and account information for ACH Entries. Because checks are the most commonly used source of banking information for ACH Entries, financial institutions are specifically encouraged to verify the validity of check MICR information for ACH processing. TECHNICAL SUMMARY Below is a summary of the impact of this rule change on the NACHA Operating Rules. The rule language as it will read upon implementation is shown below. 5
Article Two, Subsection 2.11.1 (ODFI and Originator Action on Notification of Change (NOC)) adds language making the requirement to act on NOCs for specific Single Entry NOCs optional, at the discretion of the Originator. Implementation Date: September 20, 2013 As approved March 7, 2013, effective September 20, 2013, the Rules are modified as follows for the rule changes specific to NOCs for Single Entry payments. ARTICLE TWO Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders SUBSECTION 2.11.1 ODFI and Originator Action on Notification of Change (NOC) An ODFI must accept a Notification of Change (also known as NOC and COR Entry ) or a corrected NOC that complies with the requirements of Appendix Five (Notification of Change) and is Transmitted by the RDFI within the time limits established by these Rules, unless otherwise provided for in this Section 2.11. For each NOC or corrected NOC it receives, an ODFI must provide the Originator with the following minimum information within two Banking Days of the Settlement Date of the NOC or corrected NOC: (a) company name; (b) company identification; (c) company Entry description; (d) effective Entry date; (e) DFI account number; (f) individual name/receiving company name; (g) individual identification number/identification number; (h) change code; (i) (j) original Entry trace number; original RDFI identification; and (k) corrected data. The Originator must make the changes specified in the NOC or corrected NOC within six Banking Days of receipt of the NOC information or prior to initiating another Entry to the Receiver s account, whichever is later. 6
Except as noted below, the Originator must make the changes specified in the NOC or corrected NOC within six Banking Days of receipt of the NOC information or prior to initiating another Entry to the Receiver s account, whichever is later. The Originator may choose, at its discretion, to make the changes specified in any NOC or corrected NOC received with respect to any ARC, BOC, POP, RCK, Single-Entry TEL, Single-Entry WEB, and XCK Entry. 7
Stop Payments Effective Period of Stop Payment for a Non-Consumer Account (Approved March 7, 2013 Effective September 20, 2013) SUMMARY This Rule expands language regarding the effective period of a stop payment order related to a debit Entry to a Non-Consumer Account, incorporating two additional conditions under which a stop order would lapse. KEY COMPONENTS OF RULE AMENDMENT This Rule establishes a separate subsection addressing an RDFI s obligations for maintaining a stop payment order on an Entry to a Non-Consumer Account. In addition to the existing six-month expiration of a stop order, the Rule also recognizes two additional conditions under which an RDFI could remove such a stop payment order: (1) the withdrawal of the stop payment order by the Receiver, or (2) the return of the debit Entry to which the stop payment order relates. The Rule does not impact the existing reference to the six-month effective time period for a stop payment order on an Entry to a Non-Consumer Account, but recognizes that a stop order will lapse at the earliest of one of these three conditions. IMPACT TO PARTICIPANTS Since this Rule change reflects current industry practice, there are no expected impacts to ACH participants. TECHNICAL SUMMARY Below is a summary of the impact of this rule change on the NACHA Operating Rules. Sections of the Rules that are affected by this amendment are also included below and reflect rule language as it will read upon implementation. Article Three, Subsection 3.7.2 (RDFI Obligation to Stop Payment of Entries to Non-Consumer Accounts) deletes from this subsection the reference to the effective time period for a stop payment order to a Non-Consumer Account. Article Three, Subsection 3.7.2.1 (Effective Period of Stop Payment Orders) establishes a new subsection specifically addressing the duration of stop payment orders on Entries to Non-Consumer Accounts. Implementation Date: September 20, 2013 As approved March 7, 2013, effective September 20, 2013, the Rules are modified as follows for the rule changes specific to the Effective Period of a Stop Payment Order on a Non-Consumer Account. 8
ARTICLE THREE Rights and Responsibilities of RDFIs and Their Receivers SUBSECTION 3.7.2 RDFI Obligation to Stop Payment of Entries to Non-Consumer Accounts An RDFI must honor a stop payment order regarding any debit Entry initiated or to be initiated to a non- Consumer Account that is provided by a Receiver at such time and in such manner as to allow the RDFI a reasonable opportunity to act upon the stop payment order prior to acting on the debit Entry. The RDFI must comply with a verbal stop payment order only for a period of fourteen calendar days unless the order is confirmed in writing within that fourteen-day period. A written stop payment order regarding any debit Entry initiated or to be initiated to a non-consumer Account will remain in effect for six months unless it is renewed in writing. An RDFI must honor a stop payment order regarding any debit Entry initiated or to be initiated to a non- Consumer Account that is provided by a Receiver at such time and in such manner as to allow the RDFI a reasonable opportunity to act upon the stop payment order prior to acting on the debit Entry. The RDFI must comply with a verbal stop payment order only for a period of fourteen calendar days unless the order is confirmed in writing within that fourteen-day period. SUBSECTION 3.7.2.1 Effective Period of Stop Payment Orders (New Subsection) A written stop payment order regarding any debit Entry initiated or to be initiated to a non-consumer Account will remain in effect until the earliest of: (a) the withdrawal of the stop payment order by the Receiver; (b) the return of the debit Entry; or, (c) six months from the date of the stop payment order, unless it is renewed in writing. 9
Identification of Additional Parties to an International Payment Transaction (Approved March 7, 2013 Effective March 21, 2014) SUMMARY This Rule establishes a Gateway obligation and standard formatting requirements for identifying, within an Inbound IAT Entry, the ultimate foreign beneficiary of the proceeds from a debit Inbound IAT Entry or the foreign party ultimately funding a credit Inbound IAT Entry. Background The IAT application was originally developed on the basis of a two-party payment model where funds are transferred directly from the payer to the beneficiary. In support of that payment model, the IAT format was designed to convey the name, address, and banking information of both the payer and beneficiary of the funds, with one as the Originator and the other as the Receiver. In most cases, these formatting requirements are sufficient to identify all parties to the payment transaction. However, the industry has determined that international payments can also involve more parties than the two traditionally identified as Originator and Receiver. These are commonly known as split-transaction payments or for-furthercredit-to payments, where a third-party service provider originates and settles two separate transactions to complete the underlying payment transaction on behalf of the parties. To support the split transaction payment model, the IAT rules need updating to identify key information on all parties to the payment transaction and eliminate the potential risk to ACH participants of doing business with a blocked party. Unlike the more traditional debit Inbound IAT Entry, for example, in which the ultimate payer and ultimate beneficiary are identified as parties to the transaction (i.e., Receiver and Originator, respectively), in the split transaction model, the Originator of the debit Inbound IAT Entry is not the ultimate foreign beneficiary of the funds transfer. Rather, the Originator is a service provider, collecting funds from a U.S. Receiver for further credit to an ultimate foreign beneficiary. Two separate transactions are created and settled to complete the funds transfer one between the Originator of the debit IAT Entry (the independent service provider) and the party from which funds are being transferred (the Receiver of the debit Inbound IAT Entry), and one between the Originator (the independent service provider) and the ultimate foreign beneficiary of the funds transfer. In this version of the split transaction model, only half of the underlying payment transaction (the domestic debit from the service provider to the U.S. Receiver) is visible within the payment record. The ultimate foreign beneficiary of the funds is not identified, and ACH participants are exposed to the potential risk of indirectly doing business with a blocked party. Consider the following international split transaction example. Mexican Bank provides a service allowing individuals in the U.S. to send funds easily and economically to relatives and other persons living in Mexico. Mr. Garcia, who lives in El Paso, Texas, uses the service to send money to his mother, Maria Garcia, who lives in Mexico City. Mr. Garcia logs onto Mexican Bank s website and instructs it to make a payment to Maria at her bank in Mexico City. Mr. Garcia provides Mexican Bank with Maria s name, physical address, and banking information for the funds transfer. He also provides Mexican Bank with his own banking information (i.e., the routing number and his account number from which funds will be debited at Southwest Bank) and his address in El Paso. 10
Mexican Bank originates a SWIFT payment instruction to its U.S. correspondent bank, Trust Bank, in New York, requesting it to originate a debit IAT Entry to Mr. Garcia at Southwest Bank and to credit Mexican Bank s correspondent account at Trust Bank with the amount of the funds. Trust Bank initiates the ACH transaction, as requested, and credits Mexican Bank s correspondent account. Mexican Bank subsequently does a book entry transfer to move the funds to Mexico for further credit to Maria. Although both Originator (Mexican Bank) and Receiver (Mr. Garcia) are identified as part of the IAT transaction, the ultimate foreign beneficiary of the funds transfer (Maria Garcia) is not visible to the U.S. RDFI and cannot be screened for OFAC compliance. In this case, the RDFI is not able to determine if its customer is doing business with a blocked party in violation of OFAC sanctions policies and is potentially exposed to significant risk. The transaction flow of this example is illustrated below. This Rule reduces the RDFI s risk of doing business with a blocked party by ensuring that the ultimate foreign beneficiary or foreign payee in an international for further credit to arrangement is identified within an Inbound IAT Entry. These changes add clarity to the Rules and facilitate more accurate screening and compliance with OFAC sanctions policies by ACH Participants involved with this payments model. United States Mexico Mexico Mr. Garcia initiates request to send money to Maria Garcia via web service at Mexican Bank. Provides US RTN/Acct # and all information on Maria Garcia. Mexican Bank sends IAT debit to Southwest Bank and credits own bank account. In second transaction, Mexican Bank sends domestic or book transfer credit to Ultimate Beneficiary s bank/account. Credit Credit to account of Maria Garcia Southwest Bank receives IAT Debit to Mr. Garcia. IAT Transaction Identifies: 1. IAT Originator Mexican Bank 2. IAT Receiver Mr. Garcia at US RDFI IAT Transaction Does Not Identify: 1. Ultimate Beneficiary Maria Garcia 11
KEY COMPONENTS OF RULE AMENDMENT Gateway Obligation to Identify Ultimate Foreign Beneficiary/Payer in Inbound IAT Entry This Rule establishes a Gateway obligation to identify within an Inbound IAT Entry (1) 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 (2) the foreign party ultimately funding a credit Inbound IAT Entry when that party is not the Originator of the credit IAT Entry. It is important to emphasize that the Gateway (as the party with the direct relationship with the foreign country (either via the foreign Gateway and/or the foreign originator directly)) has the obligation to ensure that all parties to the transaction are appropriately identified within the IAT Entry. Gateways should ensure that their agreements with parties in the foreign country include provisions for the identification of all parties to the payment transaction. Remittance Addenda Record Formatting Requirements for Payment Related Information Field The Rule 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. Because no more than two remittance addenda records can be included with an IAT Entry, there may be situations in which remittance data and foreign beneficiary/payer data compete for the same space. The identification of the ultimate foreign beneficiary or payer takes priority in any case where a for further credit to debit or credit Inbound IAT Entry also contains other payment related information. In other words, a Gateway may need to truncate or supersede other remittance data that would be conveyed within the Payment Related Information field of an IAT remittance addenda record in order to include required information on the ultimate beneficiary/payer of the funds. IMPACT TO PARTICIPANTS Gateways/ODFIs: This Rule reduces Gateways /ODFIs risk of doing business with blocked parties in violation of OFAC sanctions policies by ensuring that all parties to the payment transaction (including the ultimate beneficiary or payer of the funds) and the countries to/from which such funds are transmitted are clearly identified. Gateways may incur costs related to educating foreign customers on properly identifying parties and places connected to the funds transfer. ACH software may require modification in order to include the ultimate foreign beneficiary s/payer s information in the proper format within the Payment Related Information Field of an Inbound IAT Entry. Costs associated with such changes are expected to be minimal. By contrast, the cost of not including the information on the ultimate beneficiary/payer and having a financial institution receive an OFAC sanction and penalty for indirectly doing business with a blocked party can be monetarily significant, in addition to having a negative impact to the reputation of the financial institution and the ACH Network. The Rules do not require mandatory compliance with this change until March 21, 2014; however, Gateways are encouraged to adopt this change as soon as practical to minimize the potential for violations of OFAC sanctions policies. RDFIs: This Rule reduces RDFIs risk of doing business with blocked parties in violation of OFAC sanctions policies by ensuring that all parties to the payment transaction (including the ultimate beneficiary or payer of the funds) and the countries to/from which such funds are transmitted are clearly identified. 12
ACH software may require modification in order to include the ultimate foreign beneficiary s/payer s information in the proper format within the Payment Related Information Field of an Inbound IAT Entry. Costs associated with such changes are expected to be minimal. By contrast, the cost of not including the information on the ultimate beneficiary/payer and having a financial institution receive an OFAC sanction and penalty for indirectly doing business with a blocked party can be monetarily significant, in addition to having a negative impact to the reputation of the financial institution and the ACH Network. The Rules do not require mandatory compliance with this change until March 21, 2014; however, RDFIs are encouraged to adopt this change as soon as practical to minimize the potential for violations of OFAC sanctions policies. TECHNICAL SUMMARY Below is a summary of the impact of this rule change on the NACHA Operating Rules. Sections of the Rules that are affected by this amendment are also included below and reflect rule language as it will read upon implementation in highlighted, italicized text. Article Five, Subsection 5.1.3 (Gateway Obligation to Identify Ultimate Foreign Beneficiary or Payer of Funds in Inbound IAT Entry) adds a new subsection requiring Gateways to populate the Payment Related Information field with the name and address of the ultimate foreign beneficiary of funds from in Inbound IAT debit or the ultimate foreign payer of funds for an Inbound IAT credit when that party is not the Originator of the IAT Entry. Appendix Three (ACH Record Format Specifications), Subpart 3.2.2 (Glossary of Data Elements) Payment Related Information revises the Payment Related Information field description to require the ultimate foreign beneficiary/payer to be identified within this field when the payment is part of a split transaction payment model. Implementation Date: March 21, 2014 As approved March 7, 2013, effective March 21, 2014, the Rules are modified as follows for the rule changes specific to the Identification of Additional Parties to an International Payment Transaction. ARTICLE FIVE Rights and Responsibilities of Gateways for IAT Entries Subsection 5.1.3 Gateway Obligation to Identify Ultimate Foreign Beneficiary or Payer of Funds in Inbound IAT Entry (New Subsection) A Gateway must identify within an Inbound IAT Entry (1) 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 (2) the foreign party ultimately funding a credit Inbound IAT Entry when that party is not the Originator of the credit IAT Entry. The Gateway must include the ultimate foreign beneficiary s or payer s name, street address, city, state/province, postal code, and two-character alphabetic ISO country code (as defined within the International Organization for Standardization s 3166-1-alpha-2 code list) within the Payment Related Information Field of the IAT Remittance Addenda Record, as required by Appendix Three (ACH Record Format Specifications) of these Rules. 13
APPENDIX THREE ACH Record Format Specifications Subpart 3.2.2 Glossary of Data Elements Payment Related Information: 80 Positions Addenda Record Optional (ACK, ATX, CCD, CIE, CTX, DNE, ENR, IAT, PPD, TRX, WEB) In the Addenda Records of ACK, ATX, CCD, CIE, ENR, IAT, PPD, and WEB Entries, an asterisk ( * ) must be used as the delimiter between the data elements, and the backslash or tilde ( ~ ) must be used as the terminator at the end of a data segment. ACK, ATX: This field contains the ANSI ASC X12 REF (Reference) data segment. This REF segment is used to convey the Identification Number contained within the original CCD or CTX Entry, and/or other information of significance to the Originator. CCD, PPD, WEB: Addenda Records contain payment related ANSI ASC X12 data segments or NACHA endorsed banking conventions (i.e., Tax Payment, Child Support, or Electronic Dealer Drafting). For CCD Entries that are Health Care EFT Transactions, this field must contain the ASC X12 835 TRN (Reassociation Trace Number) data segment, which conveys the Reassociation Trace Number used by the Health Care Provider to match the payment to remittance data. Example: Example: TRN*1*12345*1512345678*999999999\ TRN*1*12345*1512345678*999999999~ CIE: This field contains payment related ANSI ASC X12 data segments to further identify the payment or Transmit additional remittance information. For Example: N1*BT*JohnDoe\N3*12MainStreet\N4*21070\ CTX: This field contains information formatted in accordance with the syntax of ANSI ASC X12.5 and X12.6, an ASC X12 transaction set containing a BPR or BPS data segment, or payment related UN/ EDIFACT syntax. ANSI ASC X12.5 ( Interchange Control Structure ) means the standard to define the control structures for the electronic interchange of business transactions encoded in ASC X12-based syntax. This standard provides the interchange envelope of a header and trailer for the electronic interchange through a data transmission, a structure to acknowledge the receipt and processing of this envelope, and optional, interchange-level service request structures. ANSI ASC X12.6 ( Application Control Structure ) means the standard used to define the structure of business transactions for computer-to-computer interchange. This structure is expressed using a symbolic representation of X12 data in terms of both the design and use of X12 structures, independent of the physical representation (e.g., character set encoding). BPR or BPS Data Segment ( Beginning Segment for Payment Order/Remittance Advice ) means the beginning segment for the payment order/remittance advice used in ASC X12-based syntax to indicate the beginning of a payment-related transaction set that contains the necessary banking information to process the transaction. 14
DNE: Addenda Records contains the following NACHA endorsed banking convention starting in position 04: DATE OF DEATH*MMDDYY*CUSTOMERSSN* #########*AMOUNT*$$$$.cc\ The date of death always appears in positions 18-23. If the Social Security Number (SSN) is not available, positions 38-46 contain zeros. The amount of the expected beneficiary payment always begins in position 55. ENR: This field contains the following NACHA endorsed banking convention: All information in this field pertains to the account holder on whose behalf the Automated Enrollment Entry is initiated. Transaction Code This field contains the Transaction Code of the account holder s account. This field contains 22 (Demand Credit), 27 (Demand Debit), 32 (Savings Credit), or 37 (Savings Debit). (2 positions) Receiving DFI Identification Number -- This field contains the routing number used to identify the DFI at which the account holder maintains its account. (8 positions) Check Digit This field contains the check digit pertaining to the routing number for the DFI at which the account holder maintains its account. (1 position) DFI Account Number This field contains the account holder s account number. (1-17 positions) Individual Identification Number/Identification Number For automated enrollments initiated on behalf of consumers, this field contains the consumer s Social Security Number. For automated enrollments initiated on behalf of companies, this field contains the company s Taxpayer Identification Number. (9 positions) Individual Name (Surname)/Company Name This field contains the consumer s surname or the first fifteen characters of the Company Name. (1-15 positions) Individual Name (First Name)/Company Name This field contains the consumer s first name or the next seven characters of the Company Name. (1-7 positions). Representative Payee Indicator/Enrollee Classification Code For enrollments for Federal Government benefit payments, this field contains 0 (zero) meaning no or 1 (one) meaning yes to denote whether the authorization is being initiated by someone other than the named beneficiary. For all other enrollments, this field contains A to indicate that the enrollee is a consumer, or B to indicate that the enrollee is a company. (1 position) For Example: 22*12200004*3*123987654321*777777777*DOE*JOHN*0\ 22*12200004*3*987654321123*876543210*ABCCOMPANY**B\ 27*12200004*3*987654321123*876543210*ABCELECTRONICIN*DUSTRIE*B\ 15
IAT: This field contains 80 characters of payment related information. (Note: A maximum of two optional Addenda Records may be used for IAT remittance information.) Identification of Ultimate Foreign Beneficiary/Payer - For Inbound IAT Entries, this field must contain the ultimate foreign beneficiary s or payer s name, street address, city, state/province, postal code, and two-character alphabetic ISO country code (as defined within the International Organization for Standardization s 3166-1-alpha-2 code list) when: (1) 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 (2) the funding for a credit Inbound IAT Entry is ultimately from a foreign party that is not the Originator of the credit IAT Entry. The identification of the ultimate foreign beneficiary (of the debit) or ultimate foreign payer (of the credit) takes priority over the inclusion of other payment related information. For example: Johann Schmidt*Mainzer Landstrasse 201*60326 Frankfurt am Main*DE\ When the Transaction Type Code Field within the First IAT Addenda Record contains ARC, BOC, or RCK, this field must contain the Check Serial Number starting in position 04: CHECK SERIAL NUMBER\ For example: 3349809002\ When the Transaction Type Code Field within the First IAT Addenda Record contains POP, this field must contain the following NACHA-endorsed banking convention starting in position 04: CHECK SERIAL NUMBER (MAXIMUM OF 9 CHARACTERS)*TERMINAL CITY (MAXIMUM OF 4 CHARACTERS)*TERMINAL STATE/FOREIGN COUNTRY (2 CHARACTERS)\ For example: 123456789*PARI*FR\ When the Transaction Type Code Field within the First IAT Addenda Record contains MTE, POS, or SHR, this field must contain the following NACHA-endorsed banking convention starting in position 04: TERMINAL IDENTIFICATION CODE(MAXIMUM OF 6 CHARACTERS)*TERMINAL LOCATION (MAXIMUM OF 27 CHARACTERS)*TERMINAL CITY)MAXIMUM OF 15 CHARACTERS) *TERMINAL STATE/FOREIGN COUNTRY (2 CHARACTERS)\ For example: 200509*321 EAST MARKET STREET*ANYTOWN*VA\ 367802*10TH & VINE STREETS*LONDON*UK\ TRX: This field contains information formatted in accordance with National Association for Check Safekeeping syntax. 16
Identification of Country Names Within IAT Entries (Approved March 7, 2013 Effective March 21, 2014) SUMMARY This Rule clarifies the manner in which countries must be identified within an IAT Entry, eliminating the potential for ambiguity in identifying countries to or from which IAT entries are directed. KEY COMPONENTS OF RULE AMENDMENT This Rule requires an Originator, Third-Party Sender, ODFI, or Gateway transmitting an IAT Entry to identify any country named within the IAT Entry by that country s 2-digit alphabetic ISO Country Code, as defined by the International Organization for Standardization s (ISO) 3166-1-alpha-2 code list. This clarification affects the following fields: ISO Destination Country Code (IAT Company/Batch Header Record) Originator Country & Postal Code (Third IAT Addenda Record) Originating DFI Branch Country Code (Fourth IAT Addenda Record) Receiving DFI Branch Country Code (Fifth IAT Addenda Record) Receiver Country & Postal Code (Seventh IAT Addenda Record) Payment Related Information Field (IAT Addenda Record for Remittance Information) Foreign Correspondent Bank Branch Country Code (IAT Addenda Record for Foreign Correspondent Bank Information) The potential for errors, both in populating the fields and in screening for OFAC compliance, is substantially reduced by the use of standardized codes within the Originator Country and Postal Code field and the Receiver Country and Postal Code field (the third and the seventh addenda records, respectively), which currently are ambiguous with respect to the formatting of the country name. Clarifying the specific ISO country code list to be used in fields already requiring a 2-digit country code ensures a consistent manner of identification for any country listed within an IAT Entry. IMPACT TO PARTICIPANTS All ACH Participants: This Rule reduces ACH participants risk of doing business with blocked parties in violation of OFAC sanctions policies by ensuring that the countries to/from which such funds from payment transactions are transmitted are clearly identified. The Rule improves the efficiency of the OFAC screening process by establishing a single standard for identifying countries involved in the payment transaction. In particular, clear identification of the countries in the third and seventh addenda records through the use of ISO Country Codes improves the efficiency of interdiction software and reduces false positives related to country identification. This Rule is not expected to have any direct impact on ACH formats or systems; however, some ACH participants may choose to make coding changes to their software to enable drop-down menus from which Originators, ODFIs, and Gateways may choose the appropriate ISO country code, and ACH participants may incur costs related to software modifications needed to adopt the standardized list of 17
country codes. Gateways may incur costs related to educating foreign customers on properly identifying parties and places connected to the funds transfer. Software modifications may be needed to OFAC interdiction software to ensure that only ISO codes are used to identify countries within ACH transactions. Mandatory compliance with this change is not required until March 21, 2014; however, ACH participants are encouraged to adopt this change as soon as practical to minimize the potential for violations of OFAC sanctions policies. TECHNICAL SUMMARY Below is a summary of the impact of this rule change on the NACHA Operating Rules. Sections of the Rules that are affected by this amendment are also included below and reflect rule language as it will read upon implementation in highlighted, italicized text. Appendix Three (ACH Record Format Specifications), Subpart 3.2.2 (Glossary of Data Elements) revises the field descriptions listed below to require use of ISO s 2-digit alphabetic country code values from its 3166-1-alpha-2 country code list when identifying any country within an IAT Entry: ISO Destination Country Code Originator Country & Postal Code Originating DFI Branch Country Code Receiving DFI Branch Country Code Receiver Country & Postal Code Payment Related Information Field Foreign Correspondent Bank Branch Country Code Implementation Date: March 21, 2014 As approved March 7, 2013, effective March 21, 2014, the Rules are modified as follows for the rule changes specific to the Identification of Country Names within IAT Entries. APPENDIX THREE ACH Record Format Specifications SUBPART 3.2.2 Glossary of Data Elements Foreign Correspondent Bank Branch Country Code: 3 positions Addenda Record Mandatory (IAT) This field contains a 2-character code as approved by the International Organization for Standardization (ISO) used to identify the country in which the branch of the Foreign Correspondent Bank is located. This field contains a two-character alphabetic country code, as defined within the International Organization for Standardization s (ISO) 3166-1-alpha-2 code list, to identify the country in which the branch of the Foreign Correspondent Bank is located. ISO Destination Currency Code: 3 Positions Company/Batch Header Record Mandatory (IAT, Returns, COR) 18
This field contains the three-character code, as approved by the International Organization for Standardization (ISO), to identify the currency denomination in which the Entry is to be received. This field contains the two-character alphabetic country code, as defined within the International Organization for Standardization s (ISO) 3166-1-alpha-2 code list, to identify the country in which the Entry is to be received. Originating DFI Branch Country Code: 3 Positions Addenda Record Mandatory (IAT) This field contains a 2-character code, as approved by the International Organization for Standardization (ISO), to identify the country in which the branch of the bank that originated the Entry is located. This code must correspond to the country in which the bank branch identified within the Originating DFI Identification field of the Fourth IAT Addenda Record is located. This field contains a two-character alphabetic country code, as defined within the International Organization for Standardization s (ISO) 3166-1-alpha-2 code list, to identify the country in which the branch of the bank that originated the Entry is located. This code must correspond to the country in which the bank branch identified within the Originating DFI Identification field of the Fourth IAT Addenda Record is located. Originator Country and Postal Code: 35 Positions Addenda Record Mandatory (IAT) This field contains the country and postal code of the Originator. An asterisk ( * ) must be used as the delimiter between the data elements, and the backslash ( \ ) must be used as the terminator following the last data element. This field contains the two-character alphabetic country code, as defined within the International Organization for Standardization s 3166-1-alpha-2 code list, and the postal code of the Originator. An asterisk ( * ) must be used as the delimiter between the data elements, and the backslash ( \ ) or the tilde ( ~ ) must be used as the terminator following the last data element. Payment Related Information: 80 Positions Addenda Record Optional (ACK, ATX, CCD, CIE, CTX, DNE, ENR, IAT, PPD, TRX, WEB) In the Addenda Records of ACK, ATX, CCD, CIE, ENR, IAT, PPD, and WEB Entries, an asterisk ( * ) must be used as the delimiter between the data elements, and the backslash or tilde ( ~ ) must be used as the terminator at the end of a data segment. ACK, ATX: This field contains the ANSI ASC X12 REF (Reference) data segment. This REF segment is used to convey the Identification Number contained within the original CCD or CTX Entry, and/or other information of significance to the Originator. CCD, PPD, WEB: Addenda Records contain payment related ANSI ASC X12 data segments or NACHA endorsed banking conventions (i.e., Tax Payment, Child Support, or Electronic Dealer Drafting). For CCD Entries that are Health Care EFT Transactions, this field must contain the ASC X12 835 TRN (Reassociation Trace Number) data segment, which conveys the Reassociation Trace Number used by the Health Care Provider to match the payment to remittance data. Example: TRN*1*12345*1512345678*999999999\ Example: TRN*1*12345*1512345678*999999999~ 19
CIE: This field contains payment related ANSI ASC X12 data segments to further identify the payment or Transmit additional remittance information. For Example: N1*BT*JohnDoe\N3*12MainStreet\N4*21070\ CTX: This field contains information formatted in accordance with the syntax of ANSI ASC X12.5 and X12.6, an ASC X12 transaction set containing a BPR or BPS data segment, or payment related UN/ EDIFACT syntax. ANSI ASC X12.5 ( Interchange Control Structure ) means the standard to define the control structures for the electronic interchange of business transactions encoded in ASC X12-based syntax. This standard provides the interchange envelope of a header and trailer for the electronic interchange through a data transmission, a structure to acknowledge the receipt and processing of this envelope, and optional, interchange-level service request structures. ANSI ASC X12.6 ( Application Control Structure ) means the standard used to define the structure of business transactions for computer-to-computer interchange. This structure is expressed using a symbolic representation of X12 data in terms of both the design and use of X12 structures, independent of the physical representation (e.g., character set encoding). BPR or BPS Data Segment ( Beginning Segment for Payment Order/Remittance Advice ) means the beginning segment for the payment order/remittance advice used in ASC X12-based syntax to indicate the beginning of a payment-related transaction set that contains the necessary banking information to process the transaction. DNE: Addenda Records contains the following NACHA endorsed banking convention starting in position 04: DATE OF DEATH*MMDDYY*CUSTOMERSSN* #########*AMOUNT*$$$$.cc\ The date of death always appears in positions 18-23. If the Social Security Number (SSN) is not available, positions 38-46 contain zeros. The amount of the expected beneficiary payment always begins in position 55. ENR: This field contains the following NACHA endorsed banking convention: All information in this field pertains to the account holder on whose behalf the Automated Enrollment Entry is initiated. Transaction Code This field contains the Transaction Code of the account holder s account. This field contains 22 (Demand Credit), 27 (Demand Debit), 32 (Savings Credit), or 37 (Savings Debit). (2 positions) Receiving DFI Identification Number This field contains the routing number used to identify the DFI at which the account holder maintains its account. (8 positions) Check Digit This field contains the check digit pertaining to the routing number for the DFI at which the account holder maintains its account. (1 position) 20
DFI Account Number This field contains the account holder s account number. (1-17 positions) Individual Identification Number/Identification Number For automated enrollments initiated on behalf of consumers, this field contains the consumer s Social Security Number. For automated enrollments initiated on behalf of companies, this field contains the company s Taxpayer Identification Number. (9 positions) Individual Name (Surname)/Company Name This field contains the consumer s surname or the first fifteen characters of the Company Name. (1-15 positions) Individual Name (First Name)/Company Name This field contains the consumer s first name or the next seven characters of the Company Name. (1-7 positions). Representative Payee Indicator/Enrollee Classification Code For enrollments for Federal Government benefit payments, this field contains 0 (zero) meaning no or 1 (one) meaning yes to denote whether the authorization is being initiated by someone other than the named beneficiary. For all other enrollments, this field contains A to indicate that the enrollee is a consumer, or B to indicate that the enrollee is a company. (1 position) For Example: 22*12200004*3*123987654321*777777777*DOE*JOHN*0\ 22*12200004*3*987654321123*876543210*ABCCOMPANY**B\ 27*12200004*3*987654321123*876543210*ABCELECTRONICIN*DUSTRIE*B\ IAT: This field contains 80 characters of payment related information. (Note: A maximum of two optional Addenda Records may be used for IAT remittance information.) IAT: This field contains 80 characters of payment related information. When the payment related information for an IAT Entry includes the identification of a country, that country must be identified using that country s two-character alphabetic country code, as defined within the International Organization for Standardization s 3166-1-alpha-2 code list. (Note: A maximum of two optional Addenda Records may be used for IAT remittance information.) When the Transaction Type Code Field within the First IAT Addenda Record contains ARC, BOC, or RCK, this field must contain the Check Serial Number starting in position 04: CHECK SERIAL NUMBER\ For example: 3349809002\ When the Transaction Type Code Field within the First IAT Addenda Record contains POP, this field must contain the following NACHA-endorsed banking convention starting in position 04: CHECK SERIAL NUMBER (MAXIMUM OF 9 CHARACTERS)*TERMINAL CITY (MAXIMUM OF 4 CHARACTERS)*TERMINAL STATE/FOREIGN COUNTRY (2 CHARACTERS)\ For example: 123456789*PARI*FR\ 21
When the Transaction Type Code Field within the First IAT Addenda Record contains MTE, POS, or SHR, this field must contain the following NACHA-endorsed banking convention starting in position 04: TERMINAL IDENTIFICATION CODE(MAXIMUM OF 6 CHARACTERS)*TERMINAL LOCATION (MAXIMUM OF 27 CHARACTERS)*TERMINAL CITY)MAXIMUM OF 15 CHARACTERS) *TERMINAL STATE/FOREIGN COUNTRY (2 CHARACTERS)\ For example: 200509*321 EAST MARKET STREET*ANYTOWN*VA\ 367802*10TH & VINE STREETS*LONDON*UK\ TRX: This field contains information formatted in accordance with National Association for Check Safekeeping syntax. Receiver Country and Postal Code: 35 Positions Addenda Record Mandatory (IAT) This field contains the country and postal code of the Receiver. An asterisk ( * ) must be used as the delimiter between the data elements, and the backslash ( \ ) must be used as the terminator following the last data element. This field contains the two-character alphabetic country code, as defined within the International Organization for Standardization s 3166-1-alpha-2 code list, and the postal code of the Receiver. An asterisk ( * ) must be used as the delimiter between the data elements, and the backslash ( \ ) or the tilde ( ~ ) must be used as the terminator following the last data element. Receiving DFI Branch Country Code: 3 Positions Addenda Record Mandatory (IAT) This field contains a 2-character code, as approved by the International Organization for Standardization (ISO), to identify the country in which the branch of the bank that receives the Entry is located. This field contains the two-character alphabetic country code, as defined within the International Organization for Standardization s (ISO) 3166-1-alpha-2 code list, to identify the country in which the branch of the bank that received the Entry is located. 22