dfi to dfi messaging - nacha messaging... · other uses for dfi to dfi messaging. 20. dfi to dfi...
TRANSCRIPT
© 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
© 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.
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
© 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.
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.
© 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.
4
Request For Information Components
• Summary Presentation
• Survey
– Word Version
– Online Survey
• Technical Document
– Provides batch solution examples to support messaging
use cases
© 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
Part 1 – Messaging Concept and Use Cases
© 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.
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
© 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.
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
© 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.
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
© 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.
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)
© 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.
10
Use Cases for DFI to DFI Messaging
• 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
© 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.
11
Use Cases for DFI to DFI Messaging
• 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
© 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.
12
Use Cases for DFI to DFI Messaging
• 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)
– 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
© 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.
13
Use Cases for DFI to DFI Messaging
• 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
• The requested document could be delivered using contact information contained in the addenda record of the original message entry
© 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.
14
Use Cases for DFI to DFI Messaging
• 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
© 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.
15
Use Cases for DFI to DFI Messaging
• 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
– 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 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
© 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.
16
Use Cases for DFI to DFI Messaging
• 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
© 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.
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
© 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.
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
© 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.
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
© 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.
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
© 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.
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
© 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.
22
DFI to DFI Messaging Anticipated Benefits
• 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
© 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.
23
DFI to DFI Messaging Anticipated Benefits
• 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.)
© 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.
24
DFI to DFI Messaging Anticipated Benefits
• 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
© 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.
25
DFI to DFI Messaging Anticipated Benefits
• 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
© 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.
26
DFI to DFI Messaging Anticipated Benefits
• 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
© 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.
27
DFI to DFI Messaging Anticipated Benefits
• 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
© 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.
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
© 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.
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?
© 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.
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?
© 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
Part 2 – Technical and Implementation
Considerations
© 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.
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
© 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.
33
Technical Components
• 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
© 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.
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
Technical Components
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.
© 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.
35
Technical Components
• 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
© 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.
36
Technical Components
• 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
© 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.
37
Technical Components
• 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
© 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.
38
Technical Components
• 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
© 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.
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
© 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.
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
© 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.
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