Customer Documentation Administration Messages

Transcription

1 Customer Documentation Administration Messages Version 2.3 April 2018

2 THIS DOCUMENT ( DOCUMENT ) IS PROVIDED UNDER THE TERMS OF THIS RTP DOCUMENTATION AGREEMENT ("AGREEMENT"). ANY USE OR REPRODUCTION OF THE DOCUMENT CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT. This Agreement is an agreement between Recipient and The Clearing House Payments Company, L.L.C. ( Payco ). Capitalized terms used but not defined in this Agreement shall have the meanings given to such terms in the Real-Time Payments Operating Rules or Real-Time Payments Participation Rules released by Payco from time to time (collectively, the Rules ) which are available for download at Payco s website, For purposes of this Agreement, Recipient means the person who receives this Document from Payco or, if the person who receives this Document from Payco is the representative of a juristic person, that juristic person. Subject to the terms of this Agreement, Payco hereby grants Recipient a worldwide, nonassignable, non-sublicensable, non-transferable, non-exclusive, royalty-free copyright license to reproduce this Document and prepare derivative works of this Document that are products and services that integrate with the Real-Time Payments service provided by Payco ( Works ) and publicly display, publicly perform, distribute and sublicense the Works (the License ). As a condition to exercising the rights and licenses granted hereunder, Recipient hereby assumes sole responsibility to secure any other intellectual property rights needed, if any. For example, if a third party patent license is required to allow Recipient to distribute the Works, it is Recipient's responsibility to acquire that license before distributing the Works. The Document is the property of Payco and Payco retains all right, title, and interest in and to the proprietary rights expressed in this document and the information contained therein. Recipient shall not disclose the Document to any third party and no rights in the Document are granted other than those specifically authorized by the License. Any reproduction of the Document must reproduce this Agreement, including partial copies. The Document must be returned to Payco or the Works and Document must be destroyed immediately, upon Payco s request. In the event of such a request, Recipient will provide a certification if it is a natural person, or a certification of a senior officer or executive if it is a representative of a juristic person, that all copies of the Document and Works have been destroyed or returned to Payco as required. If you are a Participant, you acknowledge and agree that this agreement and the licenses granted hereunder are subject to your Participant Agreement and the Rules, and you agree that nothing herein shall relieve you of your obligation to comply with the foregoing. In the event of a conflict between this Agreement and the Participant Agreement or the Rules, the Participant Agreement or the Rules, as applicable, shall control. EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE DOCUMENT IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON The Clearing House Payments Company L.L.C 2

3 INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Recipient is solely responsible for determining the appropriateness of using the Document and assumes all risks associated with its exercise of rights under this Agreement, including but not limited to the risks and costs of program errors, compliance with applicable laws, damage to or loss of data, programs or equipment, and unavailability or interruption of operations. Recipient shall, at its sole cost and expense, indemnify and hold Payco and its affiliates harmless from and against any and all damages arising out of or related to Recipient s use and reproduction of the document and works. PAYCO SHALL HAVE NO LIABILITY FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OR REPRODUCTION OF THE DOCUMENT OR THE EXERCISE OF ANY RIGHTS GRANTED HEREUNDER BY RECIPIENT, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. If any provision of this Agreement is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this Agreement, and without further action by the parties hereto, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable. If Recipient institutes patent litigation against Payco or any affiliate of Payco (including a crossclaim or counterclaim in a lawsuit) alleging infringement of Recipient's patent(s), then the License of this Agreement shall terminate as of the date such litigation is filed. All Recipient's rights under this Agreement shall terminate if it fails to comply with any of the material terms or conditions of this Agreement and does not cure such failure in a reasonable period of time after becoming aware of such noncompliance. If all Recipient's rights under this Agreement terminate, Recipient agrees to cease use of the Document and Works as soon as reasonably practicable. However, Recipient's obligations under this Agreement shall continue and survive. This Agreement is governed by the laws of the State of New York and the intellectual property laws of the United States of America. Each party waives its rights to a jury trial in any resulting litigation The Clearing House Payments Company L.L.C 3

4 CHANGES VERSION 2.1 TO VERSION 2.2 Section Change 1.6 Updated Table: 1.7 The value A1 serves as the identifier for a TPSP. This was clarified from identifier of a participant (as a TPSP) ; ; ; ; ; ; & Message Identification examples were changed in include 0BROADCAST0 as the embedded participant ID, as these messages are broadcast messages by their nature Format definition of Connection ID updated, as connection ID no longer has to be 13 characters in length. Connection ID is variable in length and typically alphanumeric. The example connection ID was also changed to reflect a more likely ID Updated description of the values which may be present in the event parameter for Default Status. The value DEFAULT BOTH indicates the participant is suspended while the value NORMAL indicates the participant is not suspended ; ; ; ; ; ; & & Updated to indicate that all dollar values have an implied decimal: All dollar values within the message have an implied decimal point to the left of the last two digits. For example, a value of within the message represents $1,000, Updated examples to show a sample SNM that carries an active limit of $25, Previous example displayed what the SNM would look like if TCH disabled limit checking, which is not applicable in any TCH environment Updated the description of the event parameters: Opening Prefunded Balance and Available Prefunded Balance Noted that the event parameter Net Position may be either positive or negative and updated the example to reflect a negative net position, which is much more likely in the case of an SNM 994. Updated the example values throughout the message to be more representative of conditions under which the SNM would be sent Updated the description of the event parameter New Reconciliation Window Date. Noted that in 2018 The Clearing House Payments Company L.L.C 4

5 TCH s production environment, with only one reconciliation window per calendar day, this value will always equal the value of Previous Reconciliation Window Date Updated example of full admi.002 message Added a note to the detailed description of index 2.82: Added note from that TPSP does not have a mechanism to sign-off from the system. Note: Sign-on and Sign-off messages are performed at the Participant level. Third-Party Service Providers (TPSP) may submit these messages on behalf of a Participant, but TPSPs do not have a mechanism to sign-on or sign-off of RTP Removed references to Participant throughout the scope description. Echoes are exchanged between the system and connections, which can be owned by TPSPs or Participants Added that echoes are exchanged between the system and a Participant or TPSP connection. CHANGES VERSION 2.2 TO VERSION 2.3 Section Change Comments All Anonymized the RTP system ID RTP System ID of XXXXXXXXXXX is used throughout the document Echo Response (Index 2.0) XML Tag was updated from EchoResp to EchoResponse The value given in the example in section was correct. The value previously given in the table in section was incorrect The Clearing House Payments Company L.L.C 5

6 CONTENTS Changes Version 2.1 to Version CHANGES VERSION 2.2 TO VERSION Contents INTRODUCTION Document Purpose Scope Acronyms Message Format Description and Overall Message Structure Occurrence Information Date / Time Format Reference Number & Message Identification Example Usage for Participant Identifier MESSAGE STRUCTURE ADMINISTRATION System Event Notification admi Scope Message Structure Description Detail Message Field Description Notification Data Structure Message Reject admi Scope Message Structure Description Detailed Message Field Description of Message Reject Sign-On Request admn Scope Message Structure Description Detailed Message Field Description Sign-On Response admn Scope The Clearing House Payments Company L.L.C 6

7 Message Structure Description Detailed Message Field Description Sign-Off Request admn Scope Message Structure Description Detailed Message Field Description Sign-Off Response admn Scope Message Structure Description Detailed Message Field Description Echo Request admn Scope Message Structure Description Detailed Message Field Description Echo Response admn Scope Message Structure Description Detailed Message Field Description The Clearing House Payments Company L.L.C 7

8 1 INTRODUCTION 1.1 Document Purpose 1.2 Scope This document defines the standard and proprietary message formats used within RTP, a realtime payment system from The Clearing House, for sending and receiving Administration messages between RTP and Participants using the System. Participants should use this document as a reference as they develop their messaging systems to send and receive real-time messages in the defined ISO standard and proprietary formats. This document provides an understanding of the following: The ISO message structure of the admi.002 (Message Reject) and the admi.004 (System Event Notification) The proprietary structure of the admn.001 through admn.006 messages for Sign- On/Sign-Off and Echo messages used in RTP The required data types and usage rules of the data fields in the messages Example layouts of the defined message format This document does not include message flows for Administrative messages. 1.3 Acronyms Acronym BAH ET ISO TPSP UNIFI XML Description Business Application Header Eastern Time International Standards Organization Third Party Service Provider Universal Financial Industry Message scheme Extensible Mark-up Language 2018 The Clearing House Payments Company L.L.C 8

9 1.4 Message Format Description and Overall Message Structure Administration Messages 2.3 Information about the message format and the overall message structure are provided in the document TCH RTP Application Header Specification chapters: 2 Message Format Description 3 Overall Message Structure Occurrence Information The Message Structure Description and Detail Message Field Description Sections include an Occurrence definition that indicates how each field is to be used within RTP. These occurrence notations have two element. The first character is a binary indicator to show whether a field is mandatory (1) or optional (0). The second character indicates how many occurrences of the field are allowed within RTP usage. This starts at 1 occurrence and can extend to an unlimited number n. Notation Description [1..1] Is a mandatory single field with one occurrence [0..1] Is an optional field with one occurrence [0..n] Is an optional field with unlimited occurrences Please note that RTP product usage of each field is consistent with, but not always equal to, ISO defined occurrence. For example, ISO may define a field as optional with one occurrence [0..1], but such field may be defined as required with one occurrence [1..1] within RTP. Further, if a field is a mandatory sub-element of an optional field, the occurrence represents the nature of the sub-element should the optional field be present. For example, while Date and Place of Birth (Index within the Credit Transfer (pacs.008) message) is an optional field, if it is present, Birth Date, City of Birth, and Country of Birth must also be present. Therefore, these fields are represented as being mandatory with a single occurrence ([1..1]) even though they may not be present in every Credit Transfer message. Index XML Tag Element Name Occurr. Length M/O/C DtAndPlcOfBirth Date And Place Of Birth [0..1] C BirthDt Birth Date [1..1] 10 C CityOfBirth City Of Birth [1..1] 35 C CtryOfBirth Country Of Birth [1..1] 2 C 1 M mandatory / O optional / C - conditional 2018 The Clearing House Payments Company L.L.C 9

10 1.5 Date / Time Format All message processing dates are required to be set to Eastern Time (Eastern Standard Time or Eastern Daylight Time, as applicable under the Energy Policy Act of 2005) by the message sender. This includes the following fields: Creation Date Time Interbank Settlement Date (set by RTP) Date field within the Business Reference field Date field within the Message Identification field Date field within the Instruction Identification field Date field within the Transaction Identification field Date Time field in the Event Time 1.6 Reference Number & Message Identification For administration and system messages, the point to point reference number is in the format described below. Note: the structure of the reference number for administration and system messages is different to that of business messages (e.g. Credit Transfer pacs.008, Request for Payment pain.013). This is because, unlike business messages, these administration and system messages reference numbers are system generated and do not have a business context. Format: YYYYMMDDHHMMSSbbbbbbbbbbbXXXXXXXXXX Designation Description Length/Format YYYYMMDDHHMMSS File creation date and time 14 numeric characters Bbbbbbbbbbb Identifier for the receiving participant 11 characters (Participant ID or TPSP ID) or 0BROADCAST0 in the case of a broadcast System Notification Message XXXXXXXXXX Message serial no 10 alphanumeric characters Example: B61NHTCSG6 1.7 Example Usage for Participant Identifier In the examples used throughout this documentation the following Participant Identifiers are being used XXXXXXXXXXX for identification of RTP for identification of Participant 2018 The Clearing House Payments Company L.L.C 10

11 A1 for identification of a TPSP for identification of Participant 2 MESSAGE STRUCTURE ADMINISTRATION 2.1 System Event Notification admi Scope RTP will use the System Event Notification message to inform Participants of an event that is either going to occur or has occurred in the System. The System Notification Message will contain either structured or unstructured data information. The System Notification Message is used to: Notify all Participants when a system wide event occurs (e.g. a Participant is now Available or Unavailable for receiving messages) Notify specific Participant of events that are unique to that Participant (e.g. change to prefunded balance) Provide the system operator with the ability to send free format messages to either a specific Participant or all Participants Message Structure Description Index XML Tag Element Name Occurr. Length M/O/C 2 SysEvtNtfctn System Event Notification V02 [1..1] M 1.0 EvtInf Event Information [1..1] M 1.1 EvtCd Event Code [1..1] 4 M 1.2 EvtParam Event Parameter [1..n] 35 M 1.3 EvtDesc Event Description [0..1] 1000 O 1.4 EvtTm Event Time [1..1] 19 M Detail Message Field Description The following chapter in this document provides the detailed information of each element used in the System Event Notification Message for RTP. In some cases, a single field has two different meanings: the ISO Definition, and the RTP Product Usage. In these instances, the first definition is based on the ISO specification provided by the ISO RMG group. The second definition is the definition The Clearing House developed for the product usage of this element within the 2 M mandatory / O optional / C - conditional 2018 The Clearing House Payments Company L.L.C 11

12 RTP implementation. The second definition is only provided where the RTP product usage is different from the ISO group specification, or where more detailed information of the usage of this field is required. For the ISO Definition and further detail on the message itself please refer to the official ISO website ( System Event NotificationV02 Event Information EvtInf Detailed information about a system event. Index: 1.0 <EvtInf> Event Code EvtInf +EvtCd Product Usage: Index: 1.1 Proprietary code used to specify an event that occurred in a system. Message Type. Refer to SNM Data Elements identified in the defined data structures below for the list of supported events. <EvtCd> Example: <EvtCd>971</EvtCd> Event Parameter EvtInf +EvtParam Describes the parameters of an event which occurred in a system. Product Usage: Describes the parameters of the event that occurred in RTP. The first <EvtParam> will always be the Message ID The second <EvtParam> will always be the class of Message (Notification or Broadcast). Index: 1.2 <EvtParam> Occurrences: [1..n] Note: Detailed specifications for the values required for each type of Event are detailed in the section below. Example: <EvtParam>M H </EvtParam> 2018 The Clearing House Payments Company L.L.C 12

13 Event Description EvtInf +EvtDesc Product Usage: Index: 1.3 Free text used to describe an event which occurred in a system. This item may contain structured or unstructured data information. <EvtDesc> Occurrences: [0..1] Example: <EvtDesc>There will be a scheduled test on 20 Mar 2016</EvtDesc> Event Time EvtInf +EvtTm Date and time at which the event occurred. Product Usage: Index: 1.4 Date and time the message was created by RTP. <EvtTm> Note: Example: The date is required to be set to Eastern Time (ET). <EvtTm> T10:09:33</EvtTm> Notification Data Structure The following sections provide details on the structure and required field values of the various System Notification Message (SNM) generated by the System. Note: The examples below do not include the Business Application Header (BAH). This is covered separately in the BAH Specification document The Clearing House Payments Company L.L.C 13

14 Connectivity Status Broadcast (960) Informs all Participants of a change in the status of a Participant s default receive Connection. This broadcast message will be sent if the System detects that a Participant s network connectivity becomes unavailable or is restored from an unavailable status. Name M/O Usage Value Event Code M Message Type 960 Event Parameter (multiple) Message Identification M Message Identification assigned by RTP Switch generated ID Message Class M Message Classification Broadcast Connection Owner Identification M Participant Identifier (11 characters) of the owner of the Technical Connection (either a Participant or TPSP). e.g Connection Identification Availability (connectivity) M M Connection Identification of the Technical Connection that has had a status change Indicates whether the technical connection has become available or is now unavailable Event Date Time M Date and time when the message was created in the format: YYYY-MM-DDThh:mm:ss Note T is a fixed value representing the time e.g. TESTCON1 AVAILABLE or UNAVAILABLE Example Connectivity Status Broadcast message (XML Format) <SystemNotificationEvent> <ne:admi xmlns:ne="urn:iso:std:iso:20022:tech:xsd:admi "> <ne:evtinf> <ne:evtcd>960</ne:evtcd> <ne:evtparam> broadcast </ne:evtparam> <ne:evtparam>broadcast</ne:evtparam> <ne:evtparam> </ne:evtparam> <ne:evtparam>testcon1</ne:evtparam> <ne:evtparam>unavailable</ne:evtparam> <ne:evttm> t11:59:28</ne:evttm> </ne:evtinf> </ne:admi > </SystemNotificationEvent> e.g T11:59: System Status Broadcast (971) Informs all Participants if the System changes its status to either suspended or available: Name M/O Usage Value Event Code M Message Type 971 Event Parameter (multiple) Message Identification M Message Identification assigned by RTP Switch generated ID Message Class M Message Classification Broadcast 2018 The Clearing House Payments Company L.L.C 14

15 New Service Status M The new status of the System NORMAL or SUSPENDED Event Date Time M Date and time when the message was created in the format: YYYY-MM-DDThh:mm:ss Note T is a fixed value representing the time e.g T11:59:28 Example: System Status Broadcast Message (XML format) <SystemNotificationEvent> <ne:admi xmlns:ne="urn:iso:std:iso:20022:tech:xsd:admi "> <ne:evtinf> <ne:evtcd>971</ne:evtcd> <ne:evtparam> broadcast </ne:evtparam> <ne:evtparam>broadcast</ne:evtparam> <ne:evtparam>normal</ne:evtparam> <ne:evttm> t11:59:28</ne:evttm> </ne:evtinf> </ne:admi > </SystemNotificationEvent> Participant Suspend Broadcast (972) Informs all Participants if a Participant s status is changed to Suspended or has returned to normal: Name M/O Usage Value Event Code M Message Type 972 Event Parameter (multiple) Message Identification M Message Identification assigned by RTP Switch generated ID Message Class M Message Classification Broadcast Currency M The currency of the settlement USD Member Identification M Participant Identifier (11 characters) e.g P1 Bank Name M Name of the Participant e.g. BofXYZ Default Status M Displays the Participant s current status. DEFAULTBOTH (participant is suspended) or NORMAL (participant has been reinstated) Event Date Time M Date and time when the message was created in the format: YYYY-MM-DDThh:mm:ss Note T is a fixed value representing the time e.g T11:59: The Clearing House Payments Company L.L.C 15

16 Example: Participant Suspend Broadcast message (XML Format) Administration Messages 2.3 <SystemNotificationEvent> <ne:admi xmlns:ne="urn:iso:std:iso:20022:tech:xsd:admi "> <ne:evtinf> <ne:evtcd>972</ne:evtcd> <ne:evtparam> broadcast </ne:evtparam> <ne:evtparam>broadcast</ne:evtparam> <ne:evtparam>usd</ne:evtparam> <ne:evtparam> p1</ne:evtparam> <ne:evtparam>bofxyz</ne:evtparam> <ne:evtparam>normal</ne:evtparam> <ne:evttm> t11:59:28</ne:evttm> </ne:evtinf> </ne:admi > </SystemNotificationEvent> Settlement Individual Transaction Limit Status / Change Broadcast (975) Informs Participants that the System-wide, maximum permitted amount for any payment type has been changed (i.e. the System wide limit for Credit Transfers has been changed). It should be noted that RTP only permits Credit Transfer payments and as such the SITL will always be the same as the STL. Name M/O Usage Value Event Code M Message Type 975 Event Parameter (multiple) Message Identification M Message Identification assigned by RTP Switch generated ID Message Class M Message Classification Broadcast Currency M The currency of the settlement USD Currency Status M Status of the Currency ACTIVE or INACTIVE New Currency Limit M Value of new Settlement Individual Transaction Limit (SITL) to the penny with an implied decimal to the left of the last two digits (e.g = $25,000.00) Event Date Time M Date and time when the message was created in the format: YYYY-MM-DDThh:mm:ss Note T is a fixed value representing the time If status is INACTIVE this must be 0 (zero) e.g T11:59:28 Example: Settlement Individual Transaction Limit Status/ Change Broadcast message (XML Format) <SystemNotificationEvent> <ne:admi xmlns:ne="urn:iso:std:iso:20022:tech:xsd:admi "> <ne:evtinf> <ne:evtcd>975</ne:evtcd> <ne:evtparam> broadcast </ne:evtparam> <ne:evtparam>broadcast</ne:evtparam> <ne:evtparam>usd</ne:evtparam> <ne:evtparam>active</ne:evtparam> <ne:evtparam> </ne:evtparam> 2018 The Clearing House Payments Company L.L.C 16

17 <ne:evttm> t11:59:28</ne:evttm> </ne:evtinf> </ne:admi > </SystemNotificationEvent> Security Transaction Limit Change Broadcast (976) Informs Participants that the System-wide maximum permitted amount for a specific payment type (Security Transaction Limit STL) has been changed (i.e. the maximum allowable amount in a Credit Transfer payment message). It should be noted that RTP only permits Credit Transfer payments and as such the STL will always be the same as the SITL. Name M/O Usage Value Event Code M Message Type 976 Event Parameter (multiple) Message Identification M Message Identification assigned by RTP Switch generated ID Message Class M Message Classification Broadcast Currency M The currency of the settlement USD Payment Type M The type of payment for which the CREDITTRANSFER change is being made Global Limit Status M Status of the Security Transaction Limit ACTIVE INACTIVE New Global Limit Value of new Security Transaction Limit to the penny with an implied decimal to the left of the last two digits (e.g = $25,000.00) Event Date Time M Date and time when the message was created in the format: YYYY-MM-DDThh:mm:ss Note T is a fixed value representing the time Example: Security Transaction Limit Change Broadcast message (XML Format) <SystemNotificationEvent> <ne:admi xmlns:ne="urn:iso:std:iso:20022:tech:xsd:admi "> <ne:evtinf> <ne:evtcd>976</ne:evtcd> <ne:evtparam> broadcast </ne:evtparam> <ne:evtparam>broadcast</ne:evtparam> <ne:evtparam>usd</ne:evtparam> <ne:evtparam>credittransfer</ne:evtparam> <ne:evtparam>active</ne:evtparam> <ne:evtparam> </ne:evtparam> <ne:evttm> t11:59:28</ne:evttm> </ne:evtinf> </ne:admi > </SystemNotificationEvent> If status is INACTIVE this must be 0 (zero) e.g T11:59: The Clearing House Payments Company L.L.C 17

18 Free Format Broadcast or Notification (981) The System has the ability to allow the RTP Operator to send a message to either one or all System Participant(s). The System Operator decides whether the message is for all Participants or a single Participant when the message is created. For a message to a single Participant, the message class shall be Notification. If the message is meant for all Participants, the message class shall be Broadcast. Name M/O Usage Value Event Code M Message Type 981 Event Parameter (multiple) Message Identification M Message Identification assigned by RTP Switch generated ID Message Class M Message Classification Broadcast or Notification Member Identification O Participant Identifier (11 characters) e.g only used if Message Class is Notification Bank Name O Name of the Participant only used if e.g. BofXYZ Message Class is Notification Event Description (Free format text) M Any free format unstructured text up to 1000 characters e.g. There will be a scheduled test on 20 Mar 2016 Event Date Time M Date and time when the message was created in the format: YYYY-MM-DDThh:mm:ss Note T is a fixed value representing the time e.g T11:59:28 Example: Free Format message (XML Format) Broadcast: <SystemNotificationEvent> <ne:admi xmlns:ne="urn:iso:std:iso:20022:tech:xsd:admi "> <ne:evtinf> <ne:evtcd>981</ne:evtcd> <ne:evtparam> broadcast </ne:evtparam> <ne:evtparam>broadcast</ne:evtparam> <ne:evtdesc>there will be a scheduled test on 20 Mar 2016</ne:EvtDesc> <ne:evttm> t11:59:28</ne:evttm> </ne:evtinf> </ne:admi > </SystemNotificationEvent> 2018 The Clearing House Payments Company L.L.C 18

19 Notification: <SystemNotificationEvent> <ne:admi xmlns:ne="urn:iso:std:iso:20022:tech:xsd:admi "> <ne:evtinf> <ne:evtcd>981</ne:evtcd> <ne:evtparam> </ne:evtparam> <ne:evtparam>notification</ne:evtparam> <ne:evtparam> </ne:evtparam> <ne:evtparam>bofxyz</ne:evtparam> <ne:evtdesc>there will be a scheduled test on 20 Mar 2016</ne:EvtDesc> <ne:evttm> t11:59:28</ne:evttm> </ne:evtinf> </ne:admi > </SystemNotificationEvent> Participant Status Broadcast (982) The System sends notification to all Participants as a result of a Participant sending a Sign-on or Sign-off message (either direct or via TPSP). Name M/O Usage Value Event Code M Message Type 982 Event Parameter (multiple) Message Identification M Message Identification assigned by RTP Switch generated ID Message Class M Message Classification Broadcast Participant Identification M Participant Identifier (11 characters) e.g Participant Name M Name of the Participant that has had a change in status Sign-on M Indicates whether the FI is Signed-on or Signed-off from System Event Date Time M Date and time when the message was created in the format: YYYY-MM-DDThh:mm:ss Note T is a fixed value representing the time Example: Participant Status Broadcast message (XML Format) e.g. BofXYZ SIGNON or SIGNOFF Sign-on <SystemNotificationEvent> <ne:admi xmlns:ne="urn:iso:std:iso:20022:tech:xsd:admi "> <ne:evtinf> <ne:evtcd>982</ne:evtcd> <ne:evtparam> broadcast </ne:evtparam> <ne:evtparam>broadcast</ne:evtparam> <ne:evtparam> </ne:evtparam> <ne:evtparam>bofxyz</ne:evtparam> <ne:evtparam>signon</ne:evtparam> <ne:evttm> t11:59:28</ne:evttm> </ne:evtinf> </ne:admi > </SystemNotificationEvent> e.g T11:59: The Clearing House Payments Company L.L.C 19

20 Available Prefunded Balance Warning Notification (993) This message informs a Participant that their Available Prefunded Balance has either: dropped below the established Low Watermark threshold or has returned to a normal level (High Watermark) following a Low Watermark warning. It should be noted that if the Low Watermark notification is ignored, it could result in a payment transaction being rejected due to insufficient funds. Note: All Participants will be able to define their own Low and High Watermark values for alerts as either a percentage of their Prefunded Balance at the opening of the current reconciliation window or a fixed dollar value. These alerts can be used by the Participant to help manage the Participant s liquidity in the System. All dollar values within the message have an implied decimal point to the left of the last two digits. For example, a value of within the message represents $1,000, Name M/O Usage Value Event Code M Message Type 993 Event Parameter (multiple) Message M Message Identification assigned by RTP Switch generated ID Identification Message Class M Message Classification Notification Member M Participant Identifier (11 characters) e.g Identification Bank Name M Name of Participant e.g. BofXYZ Currency M The currency of the settlement USD Available Prefund Balance Status M The status of the Prefunded Balance for the specified currency NORMAL (above High Watermark) or EXCEEDED (below Low Watermark) Opening Prefunded Balance Low Watermark Value High Watermark Value Available Prefunded Balance M M M The Opening Prefunded Balance of the Participant at the beginning of the current Reconciliation Window. Value below which balance warning is triggered Value above which returns the status to NORMAL Available Prefunded Balance on the site from which the SNM was generated Event Date Time M Date and time when the message was created in the format: YYYY-MM-DDThh:mm:ss Note T is a fixed value representing the time e.g e.g e.g e.g or e.g T11:59: The Clearing House Payments Company L.L.C 20

21 Example: Available Prefunded Balance Notification message (XML Format) <SystemNotificationEvent> <ne:admi xmlns:ne="urn:iso:std:iso:20022:tech:xsd:admi "> <ne:evtinf> <ne:evtcd>993</ne:evtcd> <ne:evtparam> </ne:evtparam> <ne:evtparam>notification</ne:evtparam> <ne:evtparam> </ne:evtparam> <ne:evtparam>bofxyz</ne:evtparam> <ne:evtparam>usd</ne:evtparam> <ne:evtparam>exceeded</ne:evtparam> <ne:evtparam> </ne:evtparam> <ne:evtparam> </ne:evtparam> <ne:evtparam> </ne:evtparam> <ne:evtparam> </ne:evtparam> <ne:evttm> t11:59:28</ne:evttm> </ne:evtinf> </ne:admi > </SystemNotificationEvent> Prefunded Balance Breach Notification (994) This message informs a Participant that a transaction was rejected due to their Available Prefunded Balance being insufficient to cover the payment transaction. In such a scenario the payment is rejected and in addition to the pacs.002 rejecting the payment, this advice is also sent so that the Participants Operations staff can alert their Treasury department and provide required supplemental funding. All dollar values within the message have an implied decimal point to the left of the last two digits. For example, a value of within the message represents $1,000, Name M/O Usage Value Event Code M Message Type 994 Event Parameter (multiple) Message M Message Identification assigned by RTP Switch generated ID Identification Message Class M Message Classification Notification Member M Participant Identifier (11 characters) e.g Identification Bank Name M Name of Participant e.g. BofXYZ Currency M The currency of the settlement USD Prefunded M The reason for the message PAYMENT RJCT Balance Breach Status Prefunded M The value of the Available Prefunded e.g Balance Balance on the site processing the payment request Net Position M The value of the Participant Net Position on the site processing the payment request at the time the payment request e.g The Clearing House Payments Company L.L.C 21

22 Name M/O Usage Value was blocked (this may be a positive or negative number, depending on the net of credit transfers sent and received during the current reconciliation window) Instruction Id M The unique identifier of the payment that would have caused the Prefunded Balance to be breached. Field Instruction Identification from pacs.008. Payment Amount M The amount of the payment that would have caused a breach of the Prefunded Balance Residual Prefunded Balance Position M The difference between the Prefunded Balance and the FI s Net Position on the site processing the payment request. This is always a positive number. Event Date Time M Date and time when the message was created in the format: YYYY-MM-DDThh:mm:ss Note T is a fixed value representing the time Example: Prefunded Balance Breach Notification message (XML Format) e.g BFFF e.g e.g e.g T11:59:28 <SystemNotificationEvent> <ne:admi xmlns:ne="urn:iso:std:iso:20022:tech:xsd:admi "> <ne:evtinf> <ne:evtcd>994</ne:evtcd> <ne:evtparam> </ne:evtparam> <ne:evtparam>notification</ne:evtparam> <ne:evtparam> </ne:evtparam> <ne:evtparam>bofxyz</ne:evtparam> <ne:evtparam>usd</ne:evtparam> <ne:evtparam>payment BLOCKED</ne:EvtParam> <ne:evtparam> </ne:evtparam> <ne:evtparam> </ne:evtparam> <ne:evtparam>m brt </ne:evtparam> <ne:evtparam>250000</ne:evtparam> <ne:evtparam>100000</ne:evtparam> <ne:evttm> t11:59:28</ne:evttm> </ne:evtinf> </ne:admi > </SystemNotificationEvent> Prefunded Requirement Change Notification (996) This message informs a Participant that their Prefunded Requirement has been changed. Such a change will alter the allowable amount for a disbursement from the participant s current prefunded position. All dollar values within the message have an implied decimal point to the left of the last two digits. For example, a value of within the message represents $1,000, The Clearing House Payments Company L.L.C 22

23 Name M/O Usage Value Administration Messages 2.3 Event Code M Message Type 996 Event Parameter (multiple) Message Identification M Message Identification assigned by RTP Switch generated ID Message Class M Message Classification Notification Participant Identification M Participant Identifier (11 characters) e.g Participant Name M Name of the Participant e.g. BofXYZ Currency M The currency of the settlement USD New Prefunded M Value of new Prefunded Requirement e.g Requirement Previous Prefunded M Value of previous Prefunded e.g Requirement Requirement Event Date Time M Date and time when the message was created in the format: YYYY-MM-DDThh:mm:ss Note T is a fixed value representing the time e.g T11:59:28 Example: Prefunded Requirement Change Notification message (XML Format) <SystemNotificationEvent> <ne:admi xmlns:ne="urn:iso:std:iso:20022:tech:xsd:admi "> <ne:evtinf> <ne:evtcd>996</ne:evtcd> <ne:evtparam> </ne:evtparam> <ne:evtparam>notification</ne:evtparam> <ne:evtparam> </ne:evtparam> <ne:evtparam>bofxyz</ne:evtparam> <ne:evtparam>usd</ne:evtparam> <ne:evtparam>success</ne:evtparam> <ne:evtparam>30000</ne:evtparam> <ne:evtparam>10000</ne:evtparam> <ne:evttm> t11:59:28</ne:evttm> </ne:evtinf> </ne:admi > </SystemNotificationEvent> Prefunded Balance Change Notification (998) This message informs a Participant that their Prefunded Balance has been changed. This will occur as a result of an ad-hoc addition of supplemental funds or disbursement of funds by the Participant. All dollar values within the message have an implied decimal point to the left of the last two digits. For example, a value of within the message represents $1,000, The Clearing House Payments Company L.L.C 23

24 Name M/O Usage Value Event Code M Message Type 998 Event Parameter (multiple) Administration Messages 2.3 Message Identification M Message Identification assigned by RTP Switch generated ID Message Class M Message Classification Notification Member Identification M Participant Identifier (11 characters) e.g Bank Name M Name of the Participant e.g. BofXYZ Currency M The currency of the settlement USD Prefunded Balance M Status of the change request SUCCESS or FAILURE Change Status New Prefunded Balance M Value of new balance e.g Previous Prefunded M Value of previous balance e.g Balance Event Date Time M Date and time when the message was created in the format: YYYY-MM-DDThh:mm:ss Note T is a fixed value representing the time e.g T11:59:28 Example: Prefunded Balance Change Notification message (XML Format) <SystemNotificationEvent> <ne:admi xmlns:ne="urn:iso:std:iso:20022:tech:xsd:admi "> <ne:evtinf> <ne:evtcd>998</ne:evtcd> <ne:evtparam> </ne:evtparam> <ne:evtparam>notification</ne:evtparam> <ne:evtparam> </ne:evtparam> <ne:evtparam>bofxyz</ne:evtparam> <ne:evtparam>usd</ne:evtparam> <ne:evtparam>success</ne:evtparam> <ne:evtparam>30000</ne:evtparam> <ne:evtparam>10000</ne:evtparam> <ne:evttm> t11:59:28</ne:evttm> </ne:evtinf> </ne:admi > </SystemNotificationEvent> Reconciliation Status Notification (999) The System sends an automated notification to all Participants when a Reconciliation Window has been closed and a new one opened. The notification includes: The Previous (Closed) Reconciliation Window ID The New (Open) Reconciliation Window ID 2018 The Clearing House Payments Company L.L.C 24

25 The Opening Available Balance for the Participant as at the start of the New Reconciliation Window Number and Value of supplemental funding or drawdowns Note: a Prefunded Balance Change Notification (998) is not sent when the system changes to a new Reconciliation Window. All dollar values within the message have an implied decimal point to the left of the last two digits. For example, a value of within the message represents $1,000, Name M/O Usage Value Event Code M Message Type 999 Event Parameter (multiple) Message Identification M Message Identification assigned by RTP Switch generated ID Message Class M Message Classification Notification Previous Reconciliation Window Date M The end date of the Reconciliation Window for which this report is provided. Format YYYY-MM-DD. e.g Previous Reconciliation Window ID Previous Reconciliation Window Status Reconciliation Checkpoint Cut Off Date and Time New Reconciliation Window Date New Reconciliation Window ID New Reconciliation Window Status M M M M M M The identifier for the Reconciliation Window for which this report is provided. Shows the status of the Reconciliation Window for which this report is provided. Date and time when the message was created in the format YYYY-MM-DDThh:mm:ss Note T is a fixed value representing the time The date the new Reconciliation Window was started in the format YYYY-MM-DD. Please note, because RTP only has one Reconciliation Window per day in production, the value for New Reconciliation Window Date will always equal the value of Previous Reconciliation Window Date. The identifier for the new Reconciliation Window Shows the status of the new Reconciliation Window. e.g. 001 COMPLETE e.g T11:00:00 e.g e.g. 001 INPROGRESS Currency M The currency of the settlement in Reconciliation USD Window Member Identification M Participant Identifier (11 characters) e.g Bank Name M Name of the Participant e.g. BofXYZ Previous Opening Prefunded Balance M Value of the Opening Prefunded Balance at the start of the closed Reconciliation Window e.g The Clearing House Payments Company L.L.C 25

26 Name M/O Usage Value New Opening Prefunded Balance Number of Credit Transfer received and accepted Value of Credit Transfer received and accepted Number of Credit Transfer received and rejected Value of Credit Transfer received and rejected Number of Credit Transfer sent and accepted Value of Credit Transfer sent and accepted Number Credit Transfer sent and rejected Value of Credit Transfer sent and rejected M M M M M M Value of the Opening Prefunded Balance at the start of the new Reconciliation Window. Total Number of Credit Transfer received and accepted Total Value of Credit Transfer received and accepted Total Number of Credit Transfer received and rejected Total Value of Credit Transfer received and rejected Total Number of Credit Transfer send and accepted e.g e.g. 105 e.g e.g. 4 e.g. 443 e.g. 605 M Total Value of Credit Transfer send and accepted e.g M Total Number of Credit Transfer send and e.g. 15 rejected M Total Value of Credit Transfer send and rejected e.g Net Position M Net Position at the start of the new Reconciliation Window Count of supplemental funding Gross value of supplemental funding M M Number of supplemental funding transactions made during the previous Reconciliation Window Value of supplemental funding transactions made during the previous Reconciliation Window Count of disbursements M Number of disbursement transactions made during the previous Reconciliation Window Gross value of disbursements M Value of disbursement transactions made during the previous Reconciliation Window Event Date Time M Date and time when the message was created in the format: YYYY-MM-DDThh:mm:ss Note T is a fixed value representing the time e.g e.g. 1 e.g e.g. 1 e.g e.g T11:59:28 Example: Reconciliation Status Notification message (XML Format) <SystemNotificationEvent> <ne:admi xmlns:ne="urn:iso:std:iso:20022:tech:xsd:admi "> <ne:evtinf> <ne:evtcd>999</ne:evtcd> <ne:evtparam> </ne:evtparam> <ne:evtparam>notification</ne:evtparam> <ne:evtparam> </ne:evtparam> <ne:evtparam>001</ne:evtparam> 2018 The Clearing House Payments Company L.L.C 26

27 <ne:evtparam>complete</ne:evtparam> <ne:evtparam> t12:00:00z</ne:evtparam> <ne:evtparam> </ne:evtparam> <ne:evtparam>001</ne:evtparam> <ne:evtparam>inprogress</ne:evtparam> <ne:evtparam>usd</ne:evtparam> <ne:evtparam> </ne:evtparam> <ne:evtparam>bofxyz</ne:evtparam> <ne:evtparam>30000</ne:evtparam> <ne:evtparam>200000</ne:evtparam> <ne:evtparam>105</ne:evtparam> <ne:evtparam>150000</ne:evtparam> <ne:evtparam>4</ne:evtparam> <ne:evtparam>443</ne:evtparam> <ne:evtparam>605</ne:evtparam> <ne:evtparam>50000</ne:evtparam> <ne:evtparam>15</ne:evtparam> <ne:evtparam>63443</ne:evtparam> <ne:evtparam>100000</ne:evtparam> <ne:evtparam>1</ne:evtparam> <ne:evtparam>80000</ne:evtparam> <ne:evtparam>1</ne:evtparam> <ne:evtparam>10000</ne:evtparam> <ne:evttm> t11:59:28</ne:evttm> </ne:evtinf> </ne:admi > 2.2 Message Reject admi Scope RTP and Participants will use the Message Reject message to indicate the rejection of a message that has been received and cannot be interpreted. This message will be used if: An incoming message cannot be parsed according to the XSD specification The Digital Signature of a message cannot be verified A calculated Digital Signature does not match the Digital Signature of the message Note: Detailed information about Digital Signature is provided in the Real-Time Payments System Interface Guide Message Structure Description Index XML Tag Element Name Occurr. Length M/O/C 3 MsgRjct Message Reject V01 [1..1] M 1.0 RltdRef Related Reference [1..1] M 1.1 Ref Reference [1..1] 35 M 2.0 Rsn Reason [1..1] M 2.1 RjctgPtyRsn Rejecting Party Reason [1..1] 35 M 2.5 AddtlData Additional Data [1..1] M 3 M mandatory / O optional / C - conditional 2018 The Clearing House Payments Company L.L.C 27

28 2.2.3 Detailed Message Field Description of Message Reject Message Reject V01 Related Reference RltdRef Refers to the identification of the message previously received and for which the rejection is notified. Index: 1.0 <RltdRef> Reference RltdRef +Ref Business reference of the present message assigned by the party issuing the message. This reference must be unique amongst all messages of the same name sent by the same party. Product Usage: The unique ID for the Rejection Message as assigned by the Instructing FI or the System creating the rejection message. The entity that is initiating the rejection message (the Instructing FI or RTP) is responsible for ensuring the uniqueness of this field. Index: 1.1 <Ref> Format: Format: YYYYMMDDHHMMSSbbbbbbbbbbbXXXXXXXXXX The first 25 characters of this field are validated for structural Rules: alignment in accordance with the format specification. Reason Codes: If structural validation fails, reject with reason code 650 in Administration Advice message (admi.002). Note: Identification of the original sender of the rejected message is provided in the additional data field copied from the original message, if possible. Example: <Ref> XXXXXXXXXXXDBAA2HJH4O</Ref> Reason Rsn General information about the reason of the message rejection. Index: 2.0 <Rsn> 2018 The Clearing House Payments Company L.L.C 28

29 Rejecting Party Reason Rsn +RjctgPtyRsn Product Usage: Index: 2.1 Rules: Example: Reason of the rejection provided by the rejecting party. Message Reject Code <RjctgPtyRsn> Expected values: "650" = cannot parse the message "690" = signature mismatch or signature verification error. <RjctgPtyRsn>690</RjctgPtyRsn> Additional Data Rsn +AddtlData Additional information related to the rejection and meant to allow for the precise identification of the rejection reason. This could include a copy of the rejected message in part or in full. Product Usage: Index: 2.5 XML Tag Original Message captured in CDATA to allow the message contents to be examined by the instructing party (Participant that sent the message that is now being rejected). <AddtlData> Rules: Note: Example: The original message which the Participant or RTP could not parse must be provided in this field with the CDATA definition. CDATA stands for Character Data and any data in between the CDATA TAGS / element identifies data that could be interpreted as XML. Provided data can be read as XML but will not be parsed as an XML information even it is part of the overall message. While all text in an XML document will be parsed by the parser, the information inside a CDATA section will be seen as free text. <AddtlData><![CDATA[<Message mlns="urn:tch"><apphdr><head:fr xmlns:head="urn:iso:std:iso:20022:tech:xsd:head "><head :FIId><head:FinInstnId>... </ps: FIToFIPmtStsRpt></PaymentStatus></Message>]]</AddtlData> 2018 The Clearing House Payments Company L.L.C 29