NACHA - What s Next After Same Day ACH EPCOR Payments Conference

Transcription

1 NACHA - What s Next After Same Day ACH EPCOR Payments Conference Jane Larimer EVP ACH Network Administration General Counsel NACHA The Electronic Payments Association

2 2 Supporting and Connecting All FIs The Commons What common infrastructure is required for all FIs to stay relevant?

3 Total ACH Transaction Volume Includes On-Us Payments within a Single Financial Institution 3 ACH Payment Volume (Billions) 30 More than 24 Billion ACH Transactions in 2015, up 5.65% over Year

4 4 The 2012 ACH Blueprint Looking out 7-10 years The ACH Blueprint, developed with the industry in 2012, is a resource for NACHA s periodic strategic planning, and guides NACHA in priority and resource planning Actions will be developed each year to explore, decision or implement initiatives related to each ACH Blueprint attribute The ACH Blueprint will be reviewed on a three-year basis to assist in strategic planning and to check the viability of the long term goals This allows for flexibility in order to: Respond to changes in the financial services environment To respond to regulatory changes and the Strategy regulatory environment Plan work efforts and infrastructure Strategy changes in the most efficient way Strategy

5 Survey respondents affirmed the importance of continued work in key areas to help ensure future payments are frictionless, safe and secure, viewing account validation and tokenization as areas of highest importance 5 Importance of Continued Work by NACHA in Following Areas to Address Future ACH Payment Needs (1 = Nominally Important / 10 = Extremely Important) (Weighted average responses) Tokenization Payments Information & Messaging ISO Adoption 7.1 Directory Services 7.9 Account Validation

6 Same Day ACH Implementation

7 Phased Approach to Same Day Implementation 7 PHASE 1 September 2016 Credits only RDFI sets receiver funds availability PHASE 2 September 2017 Credits and debits RDFI sets receiver funds availability PHASE 3 March 2018 Credits and debits Receiver funds available at 5 PM RDFI local time Note: 5 PM RDFI (Receiving Depository Institution or payee s bank) local time funds availability in Phase 3 is a minimum requirement for receiver funds availability. Your financial institution may exceed this requirement, and provide funds availability earlier, and/or may adjust depository balance throughout the day in any of the Phases. 7

8 Same Day ACH Implementation Placeholder For Current Data

9 Same Day ACH and Real-time Payments are two distinct, complementary ways to speed payments 9 Same Day ACH Improved online billpay Hourly payroll and Emergency Payroll Expedited B2C (e.g. insurance payouts) Cash management Faster B2B Accelerated card merchant settlement Real-Time Payments P2P Urgent A2A Immediate billpay with acknowledgment Temporary payroll Emergency B2C (e.g. disaster) Just-in-time B2B Type of Payment Credit or Debit Credit Only Notification to Receiver Other Messaging Same-day (receipt of transaction) Extensive remittance data can be included with the payment Immediate Receiver acknowledgment, request for payment, remittance data, others TBD Payment Finality Reversals and Returns Allowed Irrevocable Receiver Availability Same-day Immediate

10 Today s work can help the industry move forward as a bridge to tomorrow 10 Standards / Formats Risk & fraud processes Payments information Directories Proxies

11 Application Programming Interfaces (APIs) In Payments Innovation

12 12 Background In 2015, usage of APIs began to influence industry conversations on payments innovation, improved security, and user experience During 2015, NACHA Board and Board Advisory Group discussions, APIs were discussed as potential solutions for account validation, data security and improved originator experiences 2016 has also delivered case studies from financial institutions and fintech companies Better enablement of electronic payments Improved efficiency Improved security Improved customer experience

13 13 Financial Institution APIs U.S. Financial Institutions are leveraging different types of APIs Private APIs are closed to a single organization that is leveraging softwa internal systems to talk more efficiently Partner APIs are opened to selected partners based on bilateral agreem Member APIs not yet leveraged, but a topic for further dialogue Could APIs be a component to help reach goals of the ACH Blueprint? Eliminate friction or make change easier Provide improved banking customer enablement Help enable faster ACH information Validate payment routing information

14 Efforts Global learnings Case study reviews NACHA executive discussions Collaboration, meetings, discussions with IFX Forum standards membership 2016 Payments Conference Open APIs discussion June 2016 NACHA Board dialogue Continued exploration with Members

15 Tokenization

16 16 Tokenization Tokenization is the process in which sensitive information is replaced with a unique token or symbol that cannot be mathematically reversed A token is an encrypted or random value that replaces an account number

17 17 Potential Benefits of Tokenization for the ACH Scenarios that prompt review of tokenization for the ACH: Customers provide their bank account information to employers, billers, wallets, merchants and many, many others Data breaches are a continuing threat and large amounts of data are at rest in many different places with differing levels of security Benefits will ultimately depend on how tokenization is implemented on the ACH Network; Benefits may include: Replacing large caches of account data thereby protecting data at rest Mitigating risks to Originator, ODFI, RDFI and consumer in cases of data breach Preventing fraud shift from cards to ACH (as the card systems move to tokenization) Being able to cut off access to a consumer account by turning off the token (depending on model) Implications for situations when an Originator fails to stop sending transactions to an account Some account validation functionality

18 Parallel Baseline Work Efforts will Help us to Move Through a Rules Process for Tokenization on the ACH 18 Efforts to educate the industry on tokenization are underway: Tokenization workshop at PAYMENTS 2016 Webinar introducing topic held May 19 NACHA groups have been formed to further define goals, benefits and impacts by scenarios Payments Innovation Alliance Tokenization Task Force kicked off RMAG group formed and kicked off assessing tokenization as a risk mitigator Staff have engaged Novantas to both broadly assess the issue of securing account information and then look at tokenization more narrowly for the ACH within that context Use cases, costs, benefits and alternatives

19 19 Questions to be Answered During Assessment What precisely is the problem we are trying to solve? Will tokenization actually solve the problem? What is the cost to implement and maintain tokenization on the ACH? What are the impacts on existing fraud systems? Are there alternative ways to solve the problem that are less costly/complex? What are the implications for the DDA and other payment systems that access the DDA?

20 Account Validation

21 21 Why Are We Focused on Account Validation? Routing Data Validation is one of the eight attributes defined by the 2012 ACH Blueprint. Area of Focus: Enable Originators or ODFIs to validate routing data as a way to reduce exceptions and facilitate new payment applications, while protecting data privacy and security. Rationale: Routing data validation will provide a means to reduce exceptions, mitigating operational impediments to change. Routing data validation is an enabler of credit payment models, and is a value-added service that may provide business opportunities for ODFIs and RDFIs. Additionally, pseudo-dda (e.g. alias) routing provides a way to reduce the burden on RDFIs for implementation of new entry types by reducing errors and the need for exception procedures.

22 To help protect your privacy, PowerPoint has blocked automatic download of this picture. 22 Account Validation White Papers Issued in 2016 Help to educate the industry Highlight why account validation is important: Reduce exceptions Reduce fraud Provide positive customer experience Reduce Costs Helping Your Originators Understand Account Validation, and Account Validation: A Tool for Businesses to Improve ACH Transactions

23 23 White Paper: Current Methods of Account Validation Manual These methods work, but are time consuming and don t scale well. ACH Prenote It s faster but probably still not fast enough Minimal information provided Relies on waiting period vs positive or negative responses Sign In Applications Requires customer to share sensitive FI Login information Customer assumes risks since not bank supported Dual Deposits Shared Database Services Customer resistance to use Makes the enrollment process take to long Not used for one time ACH payments Scoring technology still new and not widely available to corporates Can be viewed as cost prohibitive May not be an option for mid-size and small financial institutions

24 24 Moving Forward with Account Validation Although specific needs vary, the industry agrees that ACH transactions (both debits and credits) could be better served if there was a way to validate the bank account numbers Our goal: Continue to make progress Incrementally respond to the need for account validation by highlighting what is available today, while continuing to explore future options DFI and Originator Account Validation White Papers for use by Industry Possible future options: same day prenote and FI APIs for account validation

25 25 Exploring Future Options Prenote Improvements Create Same Day transaction Require a yes or no response Look at validating last name Some sort of identifier and first four letters of last name Use of Standardized APIs to enable fast validation Banks develop APIs which allow service providers or companies to code to that API to access bank data for a customer

26 ISO 20022

27 The ACH Network Payments Plus Information The ACH Network in the U.S. differs from many other ACH systems due to its ability to support extensive remittance information and its wide variety of uses. 27

28 ISO strategies for the U.S. ACH network includes the integration of and/or conversion of the network 28 ACH Integration ACH Conversion Industry tools and solutions that allow ACH users to leverage the ISO Payment Message standard for both electronic payments initiation and remittance without making changes to the current U.S. ACH formats and with the support of the NACHA Operating Rules. Current U.S. ACH file formats are converted to ISO Payment Messages for all ACH payment types to all endpoints and supported by the NACHA Operating Rules. 28

29 As opposed to the U.S. Wire timeline, the ACH Network is not converting to ISO by The focus is currently on supporting integration. 29 Continued development of more extensive mapping guides Explore incremental changes to U.S. ACH Identify and ensure consistency between Wire ISO formats and ACH to ISO mapping Continue ISO educational efforts with U.S. industry stakeholders Continue collaboration with U.S. industry stakeholders to assess needs that may trigger conversion of U.S. ACH network to ISO 29

30 Will the U.S. ever convert its ACH Network to an ISO format? Dialogue with the industry in 2016 and 2017 will continue to ensure: Gaps created by ISO ACH integration are documented and assessed 30 Support for end-users and financial institutions is provided for those who want to support integration across all low value payments Software providers and financial institutions will work together with businesses to provide straight-through processing Supported by case study illustrations on integration We continue to monitor impacts to users and the changing payments landscape in order to plan future steps that may trigger conversion

31 FI-to-FI Messaging

32 32 FI-to-FI Messaging Use ACH-formatted messages for requesting and/or providing ACHrelated information between FIs. Examples include: Request for Written Statement of Unauthorized Debit Request for Proof of Authorization Request for copies of source documents ODFI request to RDFI to return a transaction Other status messages Request for a payment Current processes for requesting and obtaining this information are manual and time consuming Uncertainty how to contact other parties, verify receipt of request, and verify timing of receipt and response High costs for manually processing requests and responses NACHA work groups are developing a Request for Information that can be issued this fall

33 33 FI-to-FI Messaging Concept Potential Benefits Reduce costs for existing manual tasks Enable requests to any FI in the Network (ubiquity) Greater certainty on timing of receipt of requests and responses Can reduce response time Enable better compliance with times allowed by Rules Better ability to pass requests to customers Allows for automation, and handling within existing processes Records of requests and responses retained as ACH entries

34 The Future 34 Focus on Meeting Customer Needs Adding value to all parts of the payment chain Staying current with regulations, while controlling cost

35 Appendix 35

36 36 Resource Material is Available NACHA Web micro-site for Same Day ACH information: Landing page for NACHA Same Day ACH information Rule description and FAQs Supplemental documents on Effective Entry Date and Return Processing, and use of Optional Same Day Indicator Implementation Checklists Corporate Toolkit The site continues to grow with information that will be helpful for implementation check it from time to time

37 37 Industry Education, Dialogue & Input Education: ISO Resource Center Introduction to ISO for Financial Institutions White Paper (750 company downloads) Webinars Dialogue and Input: Ongoing input to create and assess Mapping Guides Outreach to develop user case studies dialogue with businesses, vendors and financial institutions Drivers to enable/support ISO Capabilities required by each party Facilitation tools available Canada to US B2B use case analysis Continued participation in domestic and international forums to promote standardized ISO implementations for payments systems