NACHA Rule Changes 2013 / 2014

1. NACHA Rule Changes 2013 / 2014 Don Jackson, AAP, CTP Senior Vice President, First Tennessee Bank, N.A.

2. NACHA Rule Changes – 2013 / 2014 DISCUSSION TOPICS • NACHA Rule Making Process • ACH Security Framework • Heathcare Payments • P2P Transactions • Same Day ACH – Market Survey • Expanded Addenda Records - RFI

3. NACHA Rule Making Process • Current Structure of the Rulemaking Process became effective January 1, 2012 • Guiding principles • Hierarchy, roles and composition of groups • Participation policies • Process flow and annual timeline • Benefits and considerations • Interpretative Rules Process • Pilot and Opt-in Program Approval Processes

4. Guiding Principles for the Rulemaking Process • Efficient, effective use of members’ and volunteers’ time and resources • Consensus reached in order to achieve voting thresholds • Inclusive of members and other stakeholders • Open to participation • Solicit and respond to feedback • Federal Reserve and Treasury incorporation of NACHA rules is predicated on an open process

5. NACHA Rule Making Process - Balance

6. NACHA Rule Making Process - Hierarchy

7. NACHA Rule Making Process – SRG Roles

8. NACHA Rule Making Process - SRG Roles

9. NACHA Rule Making Process Flow

10. NACHA Rule Making Process • Product Innovation may release RFCs/Ballots as needed • Rules with no software impacts may implement as needed • December implementation date available but rarely used

11. NACHA Rule Making Process - Pilots • Purpose: Allows NACHA to test an application and impacts on FIs (their clients and customers) to determine whether to move into rulemaking - generally involves determining whether to adopt a new SEC Code • Baseline Assumption: There is a need for a new SEC Code or changes to the Rules that would require industry-wide participation, and that a pilot would be needed to test technological, operational and customer service impacts before going into rulemaking • Term: Defined start and end dates • Business Case: • Industry level preliminary business case needed to justify pilot • Pilot to demonstrate benefits and impacts • Full business case needed to move into rulemaking (typically for a new SEC Code)

12. NACHA Rule Making Process – Opt In Programs • Purpose: Allows FIs to utilize the ACH Network, under the auspices of NACHA, where there may not be a need by all FIs on the Network, and where there is no immediate need for a broad-based Rule. • Baseline Assumption: Not all FIs may need functionality, so there is no need for a new SEC Code or broad-based changes to the Rules. This utilization will bring new volume onto the Network or prevent volume from moving off the Network, while still being governed under the auspices of NACHA • Term: No defined end dates • Business Case: • No direct impact beyond opt-in group of FIs participating and their customers • Each FI develops its own business case - no industry-wide assessment required • Limited NACHA resources to support if outside annual Plan of Work

13. NACHA Rule Making Process – Opt In Programs Rules proposals are categorized as: • Major impact to Network (Category A), • Moderate impact to Network (Category B), or • Minor impact to Network (Category C).

14. NACHA Rule Changes 2013 / 2014 DISCUSSION TOPICS • ACH Security Framework • Heathcare Payments • P2P Transactions • Same Day ACH – Market Survey • Expanded Addenda Records - RFI

15. NACHA Rule Changes 2013 ACH Security Framework • This amendment is aimed at protecting the security and integrity of ACH data throughout it’s lifetime. • Participants are required to establish, implement and update Security Policies, Procedures and systems to initiate, process or store ACH entries • ODFIs are required to establish the identity of Originators and Third Parties using the ACH Network • All DFIs, Third Party Service Providers and Third Party Senders are required to conduct and annual audit of compliance with this amendment.

16. NACHA Rule Changes 2013 Healthcare Payment via ACH • The Patient Protection and Affordability Care Act (AKA Obama care) requires standards for healthcare electronic funds transfers. • Use if the CCD+ NACHA standard entry class with addenda has been adopted as the standard • Use of the EDI TRN segment has been adopted to contain the “reassociation number” • Providers must contact their FIs to receive • CCD Batch Header to contain HCCLAIMPMT to identify the entry as a health care transaction • CCD Batch Header to contain a Company Name that is easily recognizable by the receiver

17. NACHA Rule Changes 2014 P2P Payments via ACH • Standardize the use of the ACH Network for person-to-person payments • Previously, the WEB Standard Entry Class only allowed debit entries • WEB Standard Entry Class for credit entries is restricted to P2P • Unlike other origination activity, an Originator of a P2P entry is not required to have an origination agreement with the ODFI • The Sender of the credit entry is identified within the Individual ID field and the P2P Service Provider is identified in the Company Name field of the Batch Header record

18. Same Day ACH Market Survey • Potential Rule “Strawman” • ODFIs to submit files by 10:00 a.m. ET and 3:00 p.m. ET, available to RDFIs by 11:00 a.m. ET and 4:00 p.m. ET • Phase I – ACH Credits only, limited to $25,000 or less, proposed effective date of September 2016, Settlement at 5:00 p.m. ET • Phase II – ACH Credits and Debits, limited to $25,000 or less, proposed effective date of September 2017, Settlement at 5:00 p.m. ET • Phase III – ACH Credits and Debits, limited to $25,000 or less, proposed effective date of March 2018, Settlement at noon ET and 5:00 p.m. ET • Survey gathers data from RDFIs regarding the incremental expenses incurred under the above Strawman. Staff, potential risk, and to bank’s P&L.

19. Expanded Addenda Records Request for Information • Payments plus Information - Expansion of Addenda Records • All Standard Entry Classes with the exception of CTX are limited to one addenda record with 80 characters of available space for additional information. • The RFI considers increasing the number of records for 1 to 9 and possibly removing the restriction 9,999 records on CTX. • Modifications are also considered that would include a type code to indicate if the addenda contains free text, URL, HML, etc.

20. QUESTIONS?