dfi to dfi messaging - nacha messaging... · other uses for dfi to dfi messaging. 20. dfi to dfi...

© 2017 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 or legal advice and is intended for educational purposes only.

DFI to DFI Messaging

Request for Information

February 9, 2017




2

Introduction

• NACHA invites respondents to provide information on a concept to

utilize the ACH Network for a new, ubiquitous capability to exchange

non-monetary messaging between financial institutions

• Currently, requests and responses for various types of ACH-related

documents and other related information are handled outside of the

ACH Network via manual processes




3

Introduction

• Today, NACHA is issuing this Request for Information to obtain

industry feedback on a new, conceptual ACH Network functionality,

and to stimulate industry thinking about the uses for moving

information and documents related to payments

• NACHA is accepting comments through Friday, March 24. NACHA

encourages responses from all ACH Network participants and

interested parties. For more information about the proposed rules

and how to submit comments, please visit www.nacha.org.

http://www.nacha.org/




4

Request For Information Components

• Summary Presentation

• Survey

– Word Version

– Online Survey

• Technical Document

– Provides batch solution examples to support messaging

use cases






Part 1 – Messaging Concept and Use Cases




6

Concept at a Glance

• Financial Institutions would utilize non-monetary ACH Entries and supporting

Addenda Records as messages and responses to request and provide various types

of information related to ACH transactions

– Proof of Authorization

– Converted check copy (Source Document)

– Written Statement of Unauthorized Debit

– ODFI-requested returns

– Additional information related to an Originator

– Trace Request

– Other

• Financial institutions receiving these messages also would respond via non-monetary

ACH Entries and Addenda Records, inclusive of records to tie the response to the

original request

• Currently, these types of requests and responses occur outside the ACH Network,

and are mostly manual with associated costs




7

Concept at a Glance

• The ACH Network currently supports several types of non-monetary

messages

– Prenotification – used to validate account information

– Notification of Change – corrects routing and/or account information

– Death Notification – allows federal government agencies to notify FIs of the

death of a beneficiary

• New non-monetary messages are similar in concept to these existing

messages and could lay the groundwork for other enhancements or

innovative uses of messaging in the ACH Network, such as:

– Positive responses to a prenotification

– Request for an ACH credit payment

– Others that could be identified in the future




8

Concept Origin

• In a previous RFI (Expanded Use of Addenda Records), NACHA

asked the industry about new uses of addenda information

– More than 80% of respondents indicated that there would be

benefit to using the ACH Network to pass information

electronically between Direct Financial Institutions (DFIs) in

support of Rules requirements

– The current processes for obtaining this information are manual

and time consuming




9

Use Cases for DFI to DFI Messaging

• The NACHA Operating Rules require that Financial

Institutions respond to inquires for copies of required

records within ten banking days

– Proof of Authorization

– Source Document/Converted Check Copy

– Written Statement of Unauthorized Debit (WSUD)




10


• In addition to sending and receiving copies of requests

for documents required under the Rules, an ACH

messaging framework could be used for other ACH-

related functions

– ODFI-Requested Returns

– Additional information related to an Originator

– Trace Messages




11


• Proof of Authorization

– Under the Rules, an ODFI must provide an RDFI with a record of a Receiver’s authorization within 10 banking days of receiving a written request (Subsection 2.3.2.5(b))

– Currently, an RDFI’s written request, and an ODFI’s provision of the record, take place manually outside the ACH Network

– A non-monetary ACH message entry could serve as the RDFI’s written request; and a non-monetary ACH message response entry could serve as the ODFI’s response that the requested document is being provided

• The requested document could be uploaded into a trusted document repository that the RDFI would access; or

• The requested document could be delivered using contact information contained in the addenda record of the original message entry




12


• Source Document/Converted Check– Under the Rules, an ODFI must provide an RDFI with a copy of a

Receiver’s Source Document (i.e., converted check) for an ARC or BOC entry within 10 banking days of receiving a written request (Subsections 2.5.1.5(d), 2.5.2.5 (i), respectively)


– A non-monetary ACH message entry could serve as the RDFI’s written request; and a non-monetary ACH message response entry could serve as the ODFI’s response that the requested document is being provided

• The requested document could be uploaded into a trusted document repository that the RDFI would access; or





13


• Written Statement of Unauthorized Debit (WSUD)

– Under the Rules, an RDFI must provide an ODFI with a copy of a Receiver’s WSUD within 10 banking days of receiving a written request (Subsection 3.12.7)

– Currently, an ODFI’s written request, and an RDFI’s provision of the WSUD, take place manually outside the ACH Network

– A non-monetary ACH message entry could serve as the ODFI’s written request; and a non-monetary ACH message response entry could serve as the RDFI’s response that the requested document is being provided

• The requested document could be uploaded into a trusted document repository that the ODFI would access; or





14


• ODFI Requested Returns

– Under the Rules, an ODFI may request that an RDFI return an

Erroneous Entry, or a credit entry originated without the

authorization of the Originator (Subsection 2.12.2)

• The RDFI has no obligation to respond, or to comply with request

• Currently, general industry practice is that RDFIs will require a Letter of

Indemnification from the ODFI, even though the Rules contain an

indemnification (Subsection 2.12.3)

– A non-monetary ACH message entry could serve as the ODFI’s

written request for a return, and serve the same purpose as the

Letter of Indemnification

• The RDFI could return the original monetary entry; or

• The RDFI could send a non-monetary ACH response message entry

that it is not returning the original monetary entry




15


• Additional Information About an Originator

– Under the Rules, regarding an entry to a non-Consumer Account, an ODFI must provide an RDFI with a record of a Receiver’s authorization within 10 banking days of receiving a written request, or provide contact information to identify the Originator (Subsection 2.3.3.3)

– This use case is extended beyond entries to a non-Consumer Account, allowing for the request of Originator information for any entry


– A non-monetary ACH message and response message would work just as with the Proof of Authorization use case;

• The requested information would be saved into a document that could be uploaded into a trusted document repository that the RDFI would access; or

• The requested document could be delivered using contact information contained in the original message




16


• Trace Messages

– Under the Rules, every ACH Entry and Return Entry includes a

unique Trace Number (Appendix Three – ACH Record Format

Specifications)

– ODFIs and RDFIs occasionally might have reason to inquire

about the status of a ACH Entry or Return Entry

– Currently, any such inquiries take place are manual and take

place outside the ACH Network

– A non-monetary ACH message entry could serve as either an

ODFI’s or RDFI’s written request about the status of a previous

ACH Entry or Return Entry; and a non-monetary ACH message

response entry could serve as the ODFI’s or RDFI’s response to

that inquiry




17

Other Uses for DFI to DFI Messaging

• In addition to the use cases described above, there may be other

opportunities to utilize messaging in the ACH Network, such as for:

– Prenotification responses

• Require a response to prenotifications on account validity

• Currently, RDFIs respond to prenotifications only when sending a

return, such as for invalid account number, or a Notification of

Change to provide corrected account information

• When the account information is valid, the ODFI does not receive a

response

• A positive response to a prenotification could indicate to the ODFI

that the RDFI has verified that the account information is valid




18

Other Uses for DFI to DFI Messaging

• Another opportunity to utilize messaging in the ACH Network could

be a Request for an ACH Credit Payment

– Popular in other parts of the world to facilitate the use of ACH credits

– Allows for a payee to send a message to a payor providing details

necessary to the payor to originate an ACH credit to the payee’s

account

– Could be used in business-to-business, person-to-person, or consumer-

to-business applications, in which the payee prefers to receive an ACH

credit

– Could include remittance details to tie the original request message to

the ACH credit payment made in response




19

Concept Rationale

• Current processes for handling requests between institutions for the

six use cases described above are manual and result in the

following consequences:

– Difficulty in ensuring the receipt of a request

• Difficulty in determining the appropriate staff to contact at any

counterpart DFI, how to contact, and timing of receipt

• Jeopardizes the ability to expect timely response and affecting, in

some instances, the ability to act upon customer inquiries

– Increased cost of ACH exception processing

• Duplicate/non-response processes established in ACH operation

areas




20

Concept Rationale

• Anecdotal information indicates that requests for copies

result in:

– Response times in excess of the Rules timeframes

– Additional staffing for handling duplicate and triplicate

requests

• NACHA is requesting information on:

– Number of requests received within and outside of

designated response times

– Processes in place to monitor requests

– Staffing and costs related to requests




21

DFI to DFI Messaging Anticipated Benefits

Automating the process for sending and responding to requests via the

ACH Network would provide the following benefits

• Certainty on how to make a request

• Known timeframe of receipt and traceability

• Consistent process - being able to make or respond to request from

any other financial institution in the ACH Network

• Potential ability to handle requests pertaining to multiple Entries

efficiently

• Ability to pass request downstream, especially to Originators

• Acceptance by regulators/auditors

• Additional security

• Mandatory response – negative or positive




22


• Known timeframe of receipt

– Certainty of electronic delivery and receipt would eliminate need

for duplicate requests (other than for non-response)

– Both DFIs to a request have identical information on the request

and when the clock starts

– Removes need to “slide” allowed response time due to non-

receipt

• Potential ability to handle requests pertaining to multiple Entries

efficiently

– Requests and Responses related to the same account and

Originator could be grouped together, increasing efficiencies for

all parties




23


• Ability to pass the request downstream:

– Electronic requests can be sent to:

• Various areas of within a financial institution

• Originators who need to respond to requests

– Reduces manual labor needed to move paper requests

– Decrease overall response time

– Cleaner process for end-user if they can obtain information at the

same location/through the same process as they obtain data

today (returns, NOCs, etc.)




24


• Consistent process/ubiquity

– Utilization of messaging for requests and responses is

anticipated to be mandatory

• Current, manual requests could be phased out

– Removes ambiguity in the submission process

• Current back office processes include determining submission

instructions (i.e., fax/mail/call, which department, which person, etc.)

for each financial institution

• All messages would include contact information for requesting and

responding parties to facilitate further inquiries

– Provides process consistency versus proprietary encrypted

email solutions

• Those that have tried to move the process forward have run into

barriers with firewall issues for individual solutions




25


• Acceptance by auditors

– Electronic messages provide a greater audit trail than the current

practices of manual requests and responses, including via paper

documents, forms and/or letters

– Potential to reduce or eliminate the need for supplemental

documentation (such as Letters of Indemnity) currently reviewed

during Financial Institution audits

• Letters of Indemnity are not required under the Rules, but are often

required by RDFIs as evidence of an ODFI’s request for a return




26


• Additional Security

– Respondents to the original RFI expressed concerns about data

security, especially regarding the provision of information links to

customers

• In this messaging concept, no information would be passed to

Receivers without their request

• The passing of data between DFIs was considered very secure

– The use of trusted repositories for documents could mitigate the risk

• System operators currently provide similar databases to provide

information in other payment channels

– Secure electronic access limits existing risk of unmasked personal

information potentially being exposed to unnecessary/unauthorized

parties




27


• Mandatory response – negative or positive

– A mandatory response could be required for any request that is sent

• There is currently no requirement to respond to a request that cannot be completed

• Responses would be included for:

– Misrouted requests

– Inability to comply with the request

• This would provide significant efficiencies in the tracking and follow-up for all requests

– The mandatory response capability could be applied to prenotifications

• Currently, RDFIs do not respond to prenotifications if account information is valid




28

Implementation Considerations

• A potential rule implementing new formats and processes is

considered to have considerable impact

• These impacts would be offset by the efficiencies gained by

substantially reducing or eliminating manual processes to make and

respond to requests, as well as the potential for future innovative

uses taking advantage of the groundwork completed

– While the ACH format work could be accomplished at once, additional

systems may need to be interfaced for full automation, as well as

procedural and client interface changes

– Information is being requested on implementation considerations, such

as phasing in mandatory use dates, perhaps by message type; and

phasing out manual processes




29

NACHA Requests Information and Input

• ACH Network participants are requested to respond and

provide information on the following aspects:

– What is the size of the opportunity?

• How many such requests are institutions making and receiving?

• What is the time and cost associated with making and

responding to the requests?

– Do you agree with the DFI to DFI Messaging concept overall?

• Are the use cases for messaging valid?

• Are there other use cases?

– Anticipated benefits

• How significant are the benefits?

• Is ubiquity necessary to achieve the desired benefits?




30

NACHA Requests Information and Input

• ACH Network participants are requested to respond and

provide information on the following aspects (continued):

– Implementation considerations

• Is it better to implement all messaging use cases at one time, or in

phases?

• Are any of the messaging use cases of higher or lower priority?

• Should existing manual processes be eliminated or phased out?

• Are one or more trusted document repositories necessary or desirable?

– Technical aspects

• Do you agree with the technical and ACH formatting recommendations?

• Do you agree with the approach to use a new SEC Code?

– Other

• Are there other, similar efficiencies that could be achieved in the ACH

Network environment?






Part 2 – Technical and Implementation

Considerations




32

Technical Components

• The Product Innovation Rules Work Group formed a

Project Technical Subgroup to document use cases of

messaging using the ACH Network

– The group was comprised of representatives from:

• Financial Institution ACH Operations

• A Third Party Sender/Service Provider

• Regional Payments Associations

– Details of the potential ACH Network messaging concepts,

functionality, and ACH formats and codes are available in

the supplemental Technical Documentation




33


• The technical subgroup recommended the use of non-

monetary ACH Entries with buildable addenda records to

pass messages (requests and responses)

– A Message Entry forward request would contain two

addenda records (per request) and the response would

maintain the original request addenda, adding two more

containing response information

– Each additional messaging addenda record would provide

information to create a trail, “linking” it to the previous entry




34

• Document Repository Concept

– For documentation requests, the use of a trusted third-

party repository could facilitate access to documents

• The rules groups consider the ACH Operators as entities that

should consider the feasibility of maintaining one or more

repositories for these functions


1 Responders would upload the requested document

to the repository.

2 Repository would create an encrypted key, inserted

into the response addenda record.

3 Upon receipt, the requesting financial institution

would utilize the encrypted key to securely access

the document.




35


• The following new ACH format and data elements are

being put forth for review:

– New Standard Entry Class Code – MSG

• Allows for segregation of messaging batches

– New Entry Description – DFIMESSAGE

• Allows for batching of messages of different types

– New Transaction Codes

– New Addenda Type Codes

– New Message Type Codes

– New Response Codes




36


• New Transaction Codes Identify

– Forward message request

– No Response Received follow-up

• Would only be utilized after the required response time has

elapsed

• Would not require a separate response

– Response to a message Entry; Dishonored Response; and

a Corrected Response




37


• New Addenda Type Codes identify addenda records

containing

– Forward request data

– Contact Information

– Response/Corrected Response data

– Exception responses

– Dishonored Responses

• New Message Type Codes identify the specific type of

message

– Allows for further routing inside the Financial Institution or

to Originators to take action




38


• New Response Codes provide consistent values for

– ACH Entry Trace Statuses

– Misrouted Messages

– Other Exception Responses

• Inability to comply

– Multiple reasons

• Permission to return

• Unreadable response

• Document not as requested




39

Messaging Flows – Documentation Requests

FI

Operator

FI

MSG EntryMSG Entry

• Proof of Authorization;

• Source Document Copy;

• Additional Originator Information; or

• WSUD Copy

Forward Request for:

• encrypted key to document or

• exception reasonResponse Message containing:

MSG Entry MSG Entry

Upload documentAccess document

Obtain key




40

Messaging Flows – ODFI Requested Return

ODFI

Operator

RDFI

MSG EntryMSG Entry

Forward Request for Return

Response Message containing exception response

Return Entry Return Entry

OROR

MSG EntryMSG Entry




41

Messaging Flows – ACH Trace

ODFI

Operator

RDFI

MSG EntryMSG Entry

Forward Request for ACH Trace

Response Message containing trace status response

MSG EntryMSG Entry

dfi to dfi messaging - nacha messaging... · other uses for dfi to dfi messaging. 20. dfi to dfi...

Documents