NG Rtgiso20022

ISO20022 standard Message Implementation
Frequent Asked Questions (FAQ):
1.
What is ISO 20022 standard?
ISO 20022 - Universal financial industry message scheme (which used to be also called "UNIFI") is the international standard that defines the ISO platform for the development of financial message standards. Its business modelling approach allows users and developers to represent financial business processes and underlying transactions in a formal but syntax-independent notation. These business transaction models are the "real" business standards. They can be converted into physical messages in the desired syntax. At the time ISO 20022 was developed, XML (eXtensible Mark-up Language) was already the preferred syntax for ecommunication. Therefore, the first edition of ISO 20022 proposes a standardized XML-based syntax for messages. The standard was developed within the Technical Committee TC68 - Financial Services of ISO - the International Organization for Standardization. The Standard is issued by ISO Technical Committee 68 (TC68), which is responsible for Financial Services in ISO. The Standard is managed by Working Group 4 (WG4), a sub-group of TC68 whose charter is "the management of ISO 20022". The Standard defines a Repository Management Group who manages the content of the Repository. SWIFT is the Registration Authority for ISO 20022. 2. Why was ISO 20022 developed?
The need for ISO 20022 standard arose in the early 2000s with the widespread growth of Internet Protocol (IP) networking, the emergence of XML as the 'de facto' open technical standard for electronic communications and the appearance of a multitude of uncoordinated XML-based standardization initiatives, each having used their own "XML dialect". On top of offering a common way of using XML, the new standard shields investments from future syntax changes by proposing a common business modelling methodology (using UML - Universal Modelling Language) to capture, analyze and syntax-independently describe the business processes of potential users and their information needs. 3. What are the parts of ISO 20022 message?
The ISO 20022 Business Message consists of two parts: (1) ISO 20022 Business Application Header (2) ISO 20022 Messages
Reserve Bank of India FAQ on NG-RTGS
1|Page
4.
What are the ISO messages defined in this document?
i) head.001.001.01 Business- Application Header

ii) pacs.008.001.03 FIToFICustomerCreditTransferV03 : for Customer Credit transfer. iii) pacs.009.001.03 - FinancialInstitutionCreditTransferV03 : for Interbank transfer, for defining the MNSB request & defining the Own account transfer in NG-RTGS. iv) camt.054.001.03 BankToCustomerDebitCreditNotificationV03: for Customer Credit Debit Notification. v) pacs.002.001.04, FIToFIPaymentStatusReportV04 : for MNSB Response & Own Account Transfer Response in NG-RTGS. vi) pacs.004.001.03 PaymentReturnV03: to undo a payment previously settled. 5. What is the Business Application Header? The Business Application Header is a header that has been defined by the ISO 20022 community that form part of an ISO 20022 business message. Specifically, the BAH is an ISO20022 message definition (head.001.001.01) which can be combined with any other ISO20022 message definition to form a business message. It gathers together, in one place, data about the message, such as which organisation has sent the business message, which organisation should be receiving it, the identity of the message itself, a reference for the message and so on. 6. What is the purpose of the BAH? The purpose of the BAH is to provide a consistent and predictable way for this data to be conveyed with the message, regardless of implementation factors such as the choice of network. This does not prevent such data being conveyed either within the ISO 20022 message definition itself, or as part of a network header. 7. Whats in the BAH? The BAH consist of 9 building blocks From: the organisation that sent the message; To: the organisation that should receive the message; Business Message Identifier: a unique identifier for this particular message instance, as defined by the sending application or system; Message Definition Identifier: the identity of the message definition BusinessService: To identify the Business service. Creation Date: the creation date (and time) for the data in the BAH;
2|Page

Copy Duplicate and Possible Duplicate: fields to aid the identification of duplicate data; Signature: Contains the digital signature of the Business Entity authorised to sign this Business Message. Related: Specifies the Business Application Header of the Business Message to which this Business Message relates. Can be
used when replying to a query; can also be used when canceling or amending.
8. What is the member identification used in BAH? Member identification is a mandatory field. The existing 11 character IFSC (Indian Financial System Code) is used as Member Identification. It is formed as below Character Information Remarks position First four Bank code Four Characters of bank Code characters Fifth Zero Reserved for future use character Last six Branch code Banks to use their existing codes with characters no white spaces(zeroes prefixed) 9. What is the BusinessMessageIdentifier in BAH? The Business MessageIdentifier in BAH is same as the MessageIdentifier defined in the related business message. It is a mandatory field which uniquely identifies the message. It is defined as 22 character unique number as given below: XXXX Sender IFSC [4] first four characters of the IFSC YYYYMMDD creation date [8] X channel identification [1] Nnnnnnnnn Sequence Number [9] The Channel Identifier (X) may be used to identify channels such as Internet banking, Cash Management, Treasury, ATM, etc. The values suggested are: Channel ID Internet Banking Cash Management
Values 1 2 3|Page
Treasury ATM Other
3 4 5
10. What is MessageDefinitionIdentifier? It is a mandatory field which defines the Business Message as published on the ISO 20022 website. E.g. pacs.008.001.03 11. What is BusinessService? It is a mandatory field specifying the business service agreed between the two MessagingEndPoints under which rules this Business Message is exchanged. It comprises a fixed value of RTGS, and in the case of BAH for pacs.008 and pacs.009 the fixed value of RTGS must be followed by the local instrument name, i.e. for RTGS, BAH for pacs.008: RTGSFIToFICustomerCredit. For RTGS, BAH for pacs.004; RTGSPaymentReturn For RTGS, BAH for pacs.009:-RTGSFIToFICredit or -RTGSOwnAccTtransfer or -RTGSNetSettlementXXzNN Where XX is the clearing type which may take values GC, IB, FX, MC, SE, OT & so on. z is the indicator which may take values C Original, R-Return, L-Last Return. NN is the return serial. GC stands for guaranteed settlement of Securities and CBLO segment. "IB" stands for guaranteed settlement of FOREX segment. "FX" stands for non guaranteed settlement. MC Stands for MICR Clearing SE stands for non-guaranteed MNSB OT stands for Other MNSB 12. How to define CreationDate? It is a mandatory field which is defined as the Date and time when this Business Message (header) was created. The format is yyyy-mm-ddThh:mm:ss. Time upto second is recorded. 13. How CopyDuplicate is used in BAH? 4|Page

It indicates whether the message is a Copy, a Duplicate or a copy of a duplicate of a previously sent ISO 20022 Message DUPL Duplicate(Message is for information/ confirmation purposes. It is a duplicate of a message previously sent). Valid Values are: CODU COPY DUPL 14. What is stored in Signature field? It is mandatory field. It contains the digital signature of the Business Entity authorised to sign this Business Message(payload). The Sgntr block contains the following elements. Message item XML Tag XMLSignatures <XML Sgntrs> 15. How the end-to-end security is ensured in NG-RTGS transactions. The RequestPayload will be used as single message tag which will contain both BAH along with the encrypted Business Message. The signature is attached in the BAH at the time of creation of the Business Message. However, the RequestPayload is created at the thick client and it will include the encrypted Business Message. 16. When the field Related can be used? The Related field can be used while replying to a query; can also be used when canceling or amending a transaction. This field must be present when CopyDuplicate field is present.
17.
How a FIToFICustomerCreditTransfer message is defined?
FinancialInstitutionToFinancialInstitutionCustomerCreditTransfer message is sent by the debtor agent to the creditor agent, directly or through other agents and/or a payment clearing and settlement system. It is used to move funds from a debtor account to a creditor. The FIToFICustomerCreditTransfer message is composed of two building blocks (i) Group Header (ii) Credit Transfer Transaction Information. (i) Group Header: This building block is mandatory and present once. It contains elements such as MessageIdentification and CreationDateAndTime.
5|Page
(ii) Credit Transfer Information: This building block is mandatory and for RTGS it will be present only once. It contains elements related to the debit and credit side of the transaction such as Creditor, CreditorAgent, Debtor and DebtorAgent. 18. What is MessageIdentification? It is a mandatory field and is same as the BusinessMessageIdentifier defined in the BAH above. 19. What is CreationDateTime and how it is different from the CreationDate defined in BAH? CreationDateTime is the date and time at which this message was created and the CreationDate is the date and time at which the message header is created. The format of the date time is same throughout the message. Further, The creation date in the BAH applies to the entire Business Message whereas other creation dates apply to only parts of the Businesss Message. 20. How the field NumberOfTransactions <NbOfTxs> is defined? It provides the number of individual transactions contained in the message. The default value is 1 for Pacs.008 and Pacs.009 messages and ten(10) or more for NEFT. In MNSB request this is defined as the number of participants in the batch. The datatype is numeric. It is a mandatory filed. 21. What the field TotalInterbankSettlementAmount <TtlIntrBkSttlmAmt> used for? It gives the total amount of money moved between the instructing bank and the instructed bank. Data Type: ActiveCurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by ActiveCurrencyCode. Format: Amount MinInclusive 0 TotalDigits 18 fractionDigits 2 Maximum digits = 18. Decimal mark excluded from count. Note: The decimal separator is a dot. ActiveCurrencyCode ActiveCurrency
6|Page

The currency code must be a valid active currency code of three (3) contiguous letters. For Indian Rupee the active currency code is INR Example: <TtlIntrBkSttlmAmt Ccy='INR'>2345</TtlIntrBkSttlmAmt> 22. What is InterbankSettlementDate <IntrBkSttlmDt>? It is a mandatory field providing the settlement date. Data Type: ISODate 23. How SettlementInformation <SttlmInf> is defined? This is a mandatory element defined as: Definition: Specifies the details on how the settlement of the transaction(s) between the instructing bank and the instructed bank is completed. 24. How to define SettlementMethod <SttlmMtd>? It is the method used to settle the (batch of) payment instructions with Data Type: Code It is a mandatory field. One of the following SettlementMethod1Code values must be used: Code CLRG COVE INDA INGA Name ClearingSystem CoverMethod InstructedAgent InstructingAgent Definition Settlement is done through a payment clearing system. Settlement is done through a cover payment. Settlement is done by the agent instructed to execute a payment instruction. Settlement is done by the agent instructing and forwarding the payment to the next party in the payment chain.
For the NG-RTGS system the default value is CLRG.
25. How to interpret InstructingAgent? It is the agent that instructs the next party in the chain to carry out the (set of) instruction(s). It is mandatory in RTGS implementation
7|Page
26. What is FinancialInstitutionIdentification field used for? This is a mandatory filed which provides the identification of the Financial Institute referred to. 27. What details to be entered in ClearingSystemMemberIdentification field? This mandatory filed is used to entered the details of the sender bank. The sub-field MemberIdentification is used to provide IFSC of the Sending participant. 28. What is InstructedAgent? Agent that is instructed by the previous party in the chain to carry out the (set of) instruction(s). It is defined by using FinancialInstitutionIdentification- ClearingSystemMemberIdentification- MemberIdentification. It is mandatory in RTGS implementation. In case of Own Account Transfer this field provides the RBI IFSC. 29. How to use the field CreditTransferTransactionInformation ? It is mandatory and is a set of elements providing information on individual transactions. Only one occurrence allowed for Customer Payment in RTGS system and 10 or more for NEFT. In case of Pacs.009 used for MNSB request multipal occurrence based on number of participants is allowed. The elements are: PaymentIdentification <PmtId>, PaymentTypeInformation <PmtTpInf>, ChargesInformation <ChrgsInf>, Debtor <Dbtr>, DebtorAccount, <DbtrAcct>, DebtorAgent <DbtrAgt>, Purpose <Purp>, ., RemittanceInformation <RmtInf>. 30. How to use PaymentIdentification <PmtId> field? It is a mandatory field giving set of elements used to reference a payment instruction. Type: This message item is composed of the following PaymentIdentification element(s): Message Item <XML Tag> Mult. Represent./ Type EndToEndIdentification <EndToEndId> [1..1] Text TransactionIdentification <TxId> [1..1] Text i) EndToEndIdentification <EndToEndId> Presence: [1..1] Definition: Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain.
8|Page

Usage: The end-to-end identification can be used for reconciliation or to link tasks relating to the transaction. It can be included in several messages related to the transaction. Usage: In case there are technical limitations to pass on multiple references, the end-to-end identification must be passed on throughout the entire end-to-end chain. It should follow the 16 digits UTR pattern of the existing RTGS system. The format is: Participant System ID (First four Characters of sending Banks IFSC Code) Service Tag (One Character) Example : H for host Unique-ID comprising of Date (Julian date YYDDD) & Sequence Number (6 digits numeric)
ii) TransactionIdentification <TxId> Definition: Unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is passed on, unchanged, throughout the entire interbank chain. Usage: The transaction identification can be used for reconciliation, tracking or to link tasks relating to the transaction on the interbank level. Usage: The instructing agent has to make sure that the transaction identification is unique for a pre-agreed period. Data Type: Max35Text Format: maxLength: 35 minLength: 1 In our case it is the Unique Transaction Reference (UTR) which would be of 22 characters Format is: XXXX- Sender IFSC [4] X-Payment System [1] X-Channel [1] YYYYMMDD-Date [8] nnnnnnnn- Sequence Number [8] The Channel Identifier (X) may be used to identify channels such as Internet banking, Cash Management, Treasury, ATM, etc. The values suggested are: Channel ID Values Internet Banking 1
9|Page
Cash Management Treasury ATM Other
2 3 4 5
31. What data to be provided in PaymentTypeInformation <PmtTpInf> It contains set of elements used to further specify the type of transaction. Type: This message item is composed of the following PaymentTypeInformation element(s): Message Item and <XML Tag> Mult. Represent/ Type InstructionPriority <InstrPrty> [1..1] Code ServiceLevel <SvcLvl> [0..1] LocalInstrument <LclInstrm> [1..1] CategoryPurpose <CtgyPurp> [1..1] i) InstructionPriority <InstrPrty> Presence: [1..1] Definition: Indicator of the urgency or order of importance that the instructing party would like the instructed party to apply to the processing of the instruction. Data Type: Code The default priority assaigned to every message is HIGH. Code HIGH NORM Name High Normal Definition Priority level is high . Priority level is normal.
ii) ServiceLevel <SvcLvl> Presence: [0..1] Definition: Agreement under which or rules under which the transaction should be processed. Type: This message item is composed of one of the following ServiceLevel Choice element(s): Index Message <XML Tag> Mult. Represent./
10 | P a g e

Item Proprietary Type Text
2.11
<Prtry>
[1..1]
Proprietary <Prtry> Presence: [1..1] Definition: Specifies a pre-agreed service or level of service between the parties, as a proprietary code. For RTGS processing priority is in range 00 99. This field also contain the Transaction Type code (TTC) along with the priority value. TTC values will be used to differentiate the transactions within the same type of transaction. e.g. in the pacs.009 transaction message the MNSB Own account transfer and Interbank transaction will have different TTC values. Use: To be used for managing queues by sending bank before settlement. Data Type: Max35Text Format: maxLength: 35: For RTGS lower the number highest will be the priority. For Banks priority range is from 11 to 99. Priority from 00 to 10 is reserved for RBI.
<SvcLvl> <Prtry> [TTC=xxxx],[PRI=xx] </Prtry> </SvcLvl>
Value 4000 4001 4010 5001, 5002 5011, 5012
Remarks Value shared for all pacs.008 payments sent from CBS Value shared for all pacs.009 payments sent from CBS as interbank transfers. Used for any OAT initiated in CBS to credit the settlement accounts of the participants. Used for the MNSB files directly received by NG-RTGS from a clearing entity and then forwarded to CBS. Each clearing entity has a differently associated TTC. If more than one clearing entity will submit its MNSBs through CBS interface, multiple TTC values are required, thus multiple parameters will be provided in NG-RTGS (e.g. CBS_MIXED_MNSB_TTC_1,
11 | P a g e
CBS_MIXED_MNSB_TTC_2 etc.) All messages from the same source need to have the same TTC, irrespective of its category. 5020 5021 5030 5031 5032 5050 5051 5022 To be used only for MNSB files containing current accounts only. This applies to the original request sent by NG-RTGS to CBS (step 3) IDL Request (Repo)message initiated at RTGS IDL response(Reverse Repo) message initiated at CBS IDL reversal message initiated at RTGS Balance sweeping at SOD message initiated at CBS Balance sweeping at EOD message initiated at RTGS IDL outstanding message initiated at CBS
iii) LocalInstrument <LclInstrm> Definition: User community specific instrument. Usage: This element is used to specify a local instrument, local clearing option and/or further qualify the service or service level. Type: This message item is composed of one of the following LocalInstrument2Choice element(s): Index 2.14 Message Item Proprietary <XML Tag> <Prtry> Mult. [1..1] Represent./ Type Text
Proprietary <Prtry> Presence: [1..1] Definition: Specifies the local instrument, as a proprietary code. Type of local instrument. For RTGS pacs.008 use: RTGSFIToFICustomerCredit For RTGS, pacs.009 use:
12 | P a g e

-- RTGSFIoFICredit -- RTGSOwnAccTransfer -- RTGSNetSettlementXXzNN For Return Payment use: - RTGSPaymentReturn Data Type: Max35Text Format: maxLength: 35 iv) CategoryPurpose <CtgyPurp> Definition: Specifies the high level purpose of the instruction based on a set of pre-defined categories. Purpose of the Instrument. Payment purpose must be a value listed in ISO category purpose code Type: This message item is composed of one of the following CategoryPurpose Choice element(s): Index Message <XML Tag> Mult. Represent./ Item Type 2.16 Code <Cd> [1..1] Code Code <Cd> Presence: [1..1] Definition: Category purpose, as published in an external category purpose code list. Data Type: ExternalCategoryPurpose1Code Format: maxLength: 4 minLength: 1 Default value: CASH FROM ISO 20022External Code list The following codes are available. CASH: CashManagementTransfer CORT: TradeSettlementPayment DIVI: Dividend GOVT: GovernmentPayment HEDG: Hedging
13 | P a g e

INTC: IntraCompanyPayment INTE: Interest LOAN: Loan PENS: PensionPayment SALA: SalaryPayment SECU: Securities SSBE: SocialSecurityBenefit SUPP: SupplierPayment TAXS: TaxPayment TRAD: Trade TREA: TreasuryPayment VATX: ValueAddedTaxPayment WHLD: WithHolding The generic code for the normal funds transfer may be 'CASH'. Example: <CtgyPurp><Cd>CASH</Cd></CtgyPurp> 32. How the funds are pushed and sweep back at the time of SOD(Start of Day) and EOD(End of Day) respectively? The message format used for balance sweeping is Pacs.009 MNSB transaction. a) For SOD: - one debit against the settlement account of RBI in amount equal to the sum of all credits - multiple credits against the settlement accounts of the Participants that have their balances initialized b) For EOD: - multiple debits against the settlement accounts of all Participants with a non-zero balance in NG-RTGS - one credit against the settlement account of RBI in amount equal to the sum of all debits Distinct TTC values are used for these two transactions For SOD the TTC value is 5050 whereas for EOD the TTC is 5051 33. What data to be entered in InterbankSettlementAmount field? This mandatory field is used to provide details about the amount of money moved between the instructing agent and instructed agent. Settlement amount + currency. Datatype is amount.
14 | P a g e
34. What is ment by ChargeBearer field? It is a mandatory field providing details about the party bearing the transaction charges. Data type is code.it is defined as DEBT charges borne by Debtor CRED charges borne by Creditor SHAR-charges are shared SLEV following service level. As per the current RBI policy the charges are borne by the Debtor. 35. What is ChargesInformation? This optional filed specifies which party will bear the charges associated with the processing of the payment transaction. If ChargeBearer contains DEBT, then all transaction charges are to be borne by the debtor. At present scenario, the charges are borne by the Debtor. If ChargeBearer contains CRED, then at least one occurrence of ChargesInformation must be present. If ChargeBearer contains SHAR, then in a credit transfer context, means that transaction charges on the sender side are to be borne by the debtor, transaction charges on the receiver side are to be borne by the creditor. In a direct debit context, means that transaction charges on the sender side are to be borne by the creditor, If ChargeBearer contains SLEV, then Charges are to be applied following the rules agreed in the service level and/or scheme). 36. How to use the Amount field? This mandatory field stores the transaction charges to be paid by the charge bearer. The data type is amount. 37. How to use the field Agent? It is the agent that takes the transaction charges or to which the transaction charges are due. This is a mandatory field. 38. What details are provided for debtor? Providing debtor details is mandatory in RTGS. Under this element the following data is provided: Name: ordering customers name Postal Address: ordering customers postal address. This contains a sub-element named AddressLine which can be used for adding the address in free format. The number of occurrences is restricted to 4 in RTGS implementation. 39. How to use the DebtorAccount field?
15 | P a g e

This mandatory field provides the identification of the account of the debtor to which a debit entry will be made as a result of the transaction. it consist of the following sub elements Identification: Mandatory filed having a sub field named Other in which a field named Identification will have the debtors account number. 40. What is DebtorAgent? This is a mandatory field providing the details about the Ordering Institute. For RTGS participant the IFSC is provided while for non participant name and other identification with address is provided. 41. What is CreditorAgent? This is a mandatory field providing the details about the Beneficiary Institute. For RTGS participant the IFSC is provided while for non participant name and other identification with address is provided. 42. Where to give the beneficiary customer details? The beneficiary Customer details are given in the Creditor field. This is a mandatory field consisting of Name Beneficiary customer name Postal Address beneficiary customer address 43. How to give the creditor account details? The CreditorAccount field is used to provide the creditors account details. This mandatory field is used for identification of the account of the creditor to which a credit entry will be posted as a result of the payment transaction. 44. What information is provided in InstructionFoCreditorAgent field? Further Information related to the processing of the payment instruction, provided by the initiating party, and intended for the creditor agent is given in this optional field. It has following subfields (i) (ii) Code <Cd> InstructionInformation <InstrInf>
45. How to use the code field <Cd> ? The coded information related to the processing of the payment instrument, provided by the initating party is given in this field. The following codes are used:
16 | P a g e
PHOB = Phone Beneficiary TELB=Telecom CHQB= PayCreditorByCheque HOLD= HoldCashForCreditor 46. How to use InstructionInformation field <InstrInf> ? Further information complementing the coded instruction or instruction to the next agent that is bilaterally agreed or specific to a user community. It is of Datatype Max140Text. 47. Where to give the sender to reciver information? This information is given in RemittanceInformation field. The sub field Unstructured is used to give the remittance information of 4 lines of 140 character each. 48. How to use the field Notification? This field notifies the debit and credit entries for the account. This block is composed of the following elements: Identification: Unique identification, as assigned by the account servicer to unambiguously identify the account notification. CrationDatatime: ISO date time Account: Unambiguous indiatification of the account to which credit and debit entries are made. Entry: Set of elements used to specify an entry in the debit credit notification. At least one reference must be provided to identify the entry and its underlying transaction(s). 49. What is TransactionInformationAndStatus <TxInfAndSts>? It is related to pacs.002.001.04, FIToFIPaymentStatusReport. It is the Information concerning the original transactions, to which the status report message referred to. 50. How to use the field OriginalGroupInformationAndStatus? This field provides the original group information concerning the group of transactions, to which the status report message refers to. It has the following sub fields OriginalMessageIdentification <OrgnlMsgId>: Mandatary field for point to point reference, as assigned by the original instructing party, to unambiguously identify the original message.
17 | P a g e

OriginalMessageNameIdentification <OrgnlMsgNmId>: This mandatory field specifies the original message name identifier to which the message refers. OriginalCreationDateAndTime <OrgnlCreDtTm> This mandatory field provides Date & time at which the original message was created. GroupStatus <GrpSts> Madatory field which specifies the status of a group of transactions. Status code- CSC/ACSP/ACTC/ACPT/PDNG/RCVD/RJCT/ACCR /ACWC. ACSC: AcceptedSettlementCompleted ACSP: AcceptedSettlementInProcess ACTC: AcceptedTechnicalValidation ACCR: AcceptedCancellationRequest ACPT: Accepted ACWC: AcceptedWithChange PDNG: Pending RCVD: Received RJCT: Rejected For details on status code, pl refer to para 2.6 of documentation Payment Clearing & Settlement Maintenance 2012 by ISO. 51. What is StatusReasonInformation field? This optional field provides detailed information on the status reason. (Reason for success / failure). 52. How to use the field Reason? This mandatory field in Payment Status Report provides the reason for the status report. Reason for the status, in a proprietary form is added in the subfield Proprietary (Actual reason code and reason description)
18 | P a g e
SystemEventNotificationV01
MX admi.004.001.01 SystemEventNotificationV01
Message Scope and Usage
Scope
The SystemEventNotification message is sent by a central system to notify the occurrence of an event in a central system.
Usage
The message can be used by a central settlement system to inform its participants of an event that is going to occur in the system, for instance that the system will be down at a certain time, etc.
Outline
The SystemEventNotification message is composed of 1 building block: A. Event Information This building block is mandatory and present once. It contains elements such as event code, event description and event time.
Message Structure
Index Or Message Item Message root <XML Tag> <admi.004.001.01> Mult. [1..1] Represent./ Type Rule/ Guid. No.
Index 1.0 1.1 1.2 1.3 1.4
Or
Message Item EventInformation EventCode EventParameter EventDescription EventTime
<XML Tag> <EvtInf> <EvtCd> <EvtParam> <EvtDesc> <EvtTm>
Mult. [1..1] [1..1] [0..n] [0..1] [0..1]
Represent./ Type Text Text Text DateTime
Rule/ Guid. No.
Rule -1
Rules : Rule-1
EventTime <EvtTm> is mandatory if the Eventcode <EvtCd> exists.
Page 1
Message Items Description

The following section identifies the elements of the SystemEventNotificationV01 message.
1.0 EventInformation <EvtInf>

Presence: [1..1] Definition: Detailed information about a system event. Type: The EventInformation block is composed of the following Event1 element(s):
1.1 EventCode <EvtCd>

Presence: [1..1] Definition: Proprietary code used to specify an event that occurred in a system. Data Type: Max4AlphaNumericText Format: [a-zA-Z0-9]{1,4} List of APPLICABLE Codes
F20 Acknowledgement Message F25 - Negative Acknowledgement F23 - Delivery Notification message F22 - Non-delivery Warning message F27- Bank API Response Message
1.2 EventParameter <EvtParam>

Presence: [0..n] Definition: Describes the parameters of an event which occurred in a system. Data Type: Max35Text Format: maxLength: 35 minLength: 1
Reason codes for NACk < To be provided >
1.3 EventDescription <EvtDesc>

Presence: [0..1] Definition: Free text used to describe an event which occurred in a system. Data Type: Max350Text Format: maxLength: 350 minLength: 1
1.4 EventTime <EvtTm>

Presence: [0..1] Definition: Date and time at which the event occurred. Data Type: ISODateTime
Page 2
Security
This is system event message and hence digital signing and encryption not required.
Business Example
Narrative
The central system sends out general information to the users.
Business Description
Element Content EventInformation Event F23
XML Instance
<SysEvtNtfnV01> <EvtInf> <EvtCd>F23</EvtCd> <EvtTm>2002-07-21T08:35:30</EvtTm> </EvtInf> </SysEvtNtfnV01>
Page 3
Statement Message for Participants

Introduction
This document describes the format specifications of the message camt.053 which will be used to convey the end-of-day NG-RTGS statements to the Participants over the SWIFT and INFINET networks, via the SWIFT and IDRBT messaging hubs. The message format is based on the standard ISO camt.053 with just some of the optional fields removed. Hence, the format is going to be fully compliant with the ISO standard.
Format specifications
The BankToCustomerStatement camt.053 message is composed of two building blocks: A. Group Header This building block is mandatory and present once. It contains elements such as Message Identification and CreationDateTime. B. Statement This building block is mandatory and repetitive. It should be repeated for each account on which a statement is provided. The report contains components such as Balance and Entry. Also, the message will be prefixed by a regular Business Application Header (BAH) as defined by RBI.
Structure
Index Or Message Item Message root 1.0 1.1 1.2 1.4 2.0 2.1 2.2 2.3 2.5 2.11 2.24 2.46 GroupHeader MessageIdentification CreationDateTime MessagePagination Statement Identification StatementPagination ElectronicSequenceNumber CreationDateTime Account Balance Entry <XML Tag> <BkToCstmrStmt> <GrpHdr> <MsgId> <CreDtTm> <MsgPgntn> <Stmt> <Id> <StmtPgntn> <ElctrncSeqNb> <CreDtTm> <Acct> <Bal> <Ntry> Mult. [1..1] [1..1] [1..1] [1..1] [0..1] [1..1] [1..1] [0..1] [1..1] [1..1] [1..1] [1..*] [0..*] Text Quantity DateTime G3 R1 Text DateTime R1 Represent ./Type Rule/Gui d no.
1.1MessageIdentification<MsgId>
Presence: [1..1] Definition: Point to point reference, as assigned by the account servicing institution, and sent to the account owner or the party authorized to receive the message, to unambiguously identify the message. Usage: The account servicing institution has to make sure that MessageIdentification is unique per account owner for a pre-agreed period. The format of the id follows closely the general 22-charcter long schema agreed for the NG-RTGS project: XXXX- Sender IFSC [4] YYYYMMDD - Creation Date Reverse [8] nnnnnnnnnn- Sequence Number [10] Data Type: Max35Text Format: maxLength: 35 minLength: 1
1.2 CreationDateTime<CreDtTm>
Presence: [1..1] Definition: Date and time at which the message was created. Data Type: ISODateTime
1.4 MessagePagination<MsgPgntn>
Presence: [0..1] Impacted by: R1 Definition: Number used to sequence pages when it is not possible for data to be conveyed in a single message and the data has to be split across several pages (messages). It provides details on the page number of the message. Usage: The pagination of the message is only allowed when agreed between the parties. This field will be present only if the statement is delivered over the SWIFT Interact service and due to the size constraints it has to be divided it across multiple messages. If the message is going to use the SWIFT FileAct service, this field could be omitted as the splitting is required in this case. A decision will be made after the typical size of a statement message will be asses. Or 9.2.0 9.2.1 Message Item PageNumber LastPageIndicator <XML Tag> <PgNb> <LastPgInd> Mult. [1..1] [1..1] Represent./Type Text Indicator
9.2.0 PageNumber<PgNb> Presence: [1..1] Definition: Page number. Data Type: Max5NumericText Format: [0-9]{1,5} 9.2.1 LastPageIndicator<LastPgInd> Presence: [1..1] Definition: Indicates the last page. Data Type: One of the followingYesNoIndicatorvalues must be used: MeaningWhenTrue: Yes MeaningWhenFalse: No
2.0 Statement <Stmt>

Presence: [1..1] Definition: Reports on booked entries and balances for a cash account. Only one statement per message will be produced by NG-RTGS.
2.1 Identification <Id>

Presence: [1..1] Definition: Unique identification, as assigned by the account servicer, to unambiguously identify the account statement. For NG-RTGS, this will be identical with the message identification value. Data Type: Max35Text Format: maxLength: 35 minLength: 1
2.2 StatementPagination<StmtPgntn>
Presence: [0..1] Impacted by: R1 Definition: Provides details on the page number of the statement. Usage: The pagination of the statement is only allowed when agreed between the parties. This field is required if MessagePagination is required. Or Message Item PageNumber LastPageIndicator <XML Tag> <PgNb> <LastPgInd> Mult. [1..1] [1..1] Represent./Type Text Indicator
For more details please see section 1.4 MessagePagination<MsgPgntn>
2.3 ElectronicSequenceNumber<ElctrncSeqNb>
Presence: [1..1] Definition: Sequential number of the statement, as assigned by the account servicer (i.e. NG-RTGS). Usage: The sequential number is increased incrementally for each statement sent electronically. Data Type: Number Format: fractionDigits: 0 totalDigits: 18
2.5 CreationDateTime<CreDtTm>
Presence: [1..1] Definition: Date and time at which the message was created. Data Type: ISODateTime
2.11 Account <Acct>

Presence: [1..1] Definition: Unambiguous identification of the account to which credit and debit entries are made. Type: This message item is composed of the following CashAccount25element(s): Or Message Item Identification Currency <Id> <Ccy> <XML Tag> Mult. [1..1] [1..1] Code Represent./Type
Identification Presence: [1..1] Definition: Unique and unambiguous identification for the account between the account owner and the account servicer. Or Message Item Identification Other Other Presence: [1..1] Definition: Unique identification of an account, as assigned by the account servicer, using an identification scheme. Datatype: "Max34Text" Or Message Item Identification <Id> <XML Tag> Mult. [1..1] Represent./Type Text <Id> <Othr> <XML Tag> Mult. [1..1] [1..1] Represent./Type
2.24 Balance <Bal>

Presence: [1..*] Definition: Set of elements used to define the balance as a numerical representation of the net increases and decreases in an account at a specific point in time. Ref 3.1.0 3.1.10 3.1.11 3.1.12 3.1.14 Or Type Amount CreditDebitIndicator Date DateTime Message Item <Tp> <Amt> <CdtDbtInd> <Dt> <DtTm> <XML Tag> Mult. [1..1] [1..1] [1..1] [1..1] [1..1] DateTime Amount Code Represent./Type
3.1.0 Type <Tp> Presence: [1..1] Definition: Specifies the nature of a balance. Type: This message item is composed of the following BalanceType12element(s): Ref 3.1.1 Or Message Item CodeOrProprietary <XML Tag> <CdOrPrtry> Mult. [1..1] Represent./Type
3.1.1 CodeOrProprietary<CdOrPrtry> Presence: [1..1] Definition: Coded or proprietary format balance type. Type: This message item is composed of one of the following BalanceType5Choiceelement(s): Ref 3.1.2 Or Code Message Item <Cd> <XML Tag> Mult. [1..1] Represent./Type Code
3.1.2 Code <Cd> Presence: [1..1] Definition: Balance type, in a coded form. Data Type: Code One of the following BalanceType12Code values must be used: Code CLBD Name ClosingBooked Definition Balance of the account at the end of the preagreed account reporting period. It is the sum of the opening booked balance (which is always zero for a settlement account in NGRTGS) at the beginning of the period and all entries booked to the account during the pre-
agreed account reporting period. 3.1.10 Amount <Amt> Presence: [1..1] Definition: Amount of money of the cash balance. Data Type: ActiveOrHistoricCurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 ActiveOrHistoricCurrencyCode [A-Z]{3,3} Rule(s): ActiveOrHistoricCurrencyAndAmount CurrencyAmount The number of fractional digits (or minor unit of currency) must comply with ISO 4217. Note: The decimal separator is a dot. ActiveOrHistoricCurrencyCode ActiveOrHistoricCurrency The Currency Code must be registered, or have already been registered. Valid active or historic currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3) contiguous letters, and may be or not be withdrawn on the day the message containing the Currency is exchanged. 3.1.11 CreditDebitIndicator<CdtDbtInd> Presence: [1..1] Definition: Indicates whether the balance is a credit or a debit balance. Usage: A zero balance is considered to be a credit balance. Data Type: Code Code CRDT DBIT Credit Debit Name Definition Operation is an increase. Operation is a decrease.
3.1.12 Date <Dt> Presence: [1..1] Definition: Indicates the date (and time) of the balance. Type: This message item is composed of one of the following DateAndDateTimeChoice element(s): Ref Or Message Item <XML Tag> Mult. Represent./Type
Ref 3.1.14
Or
Message Item DateTime
<XML Tag> <DtTm>
Mult. [1..1]
Represent./Type DateTime
3.1.14 DateTime<DtTm> Presence: [1..1] Definition: Specified date and time. Data Type: ISODateTime
2.26 Entry <Ntry>

Presence: [0..*] Impacted by: G3 Definition: Set of elements used to specify an entry in the statement. Usage: At least one reference must be provided to identify the entry and its underlying transaction(s). Type: This message item is composed of the following ReportEntry3element(s): Ref 5.1.1 5.1.2 5.1.4 5.1.8 5.1.9 5.1.18 5.1.234 Or Message Item Amount CreditDebitIndicator Status ValueDate Date BankTransactionCode EntryDetails <XML Tag> <Amt> <CdtDbtInd> <Sts> <ValDt> <Dt> <BkTxCd> <NtryDtls> Mult. [1..1] [1..1] [1..1] [1..1] [1..1] [1..1] [0..*] DateTime Represent./Type Amount Code Code
5.1.1 Amount <Amt> Presence: [1..1] Definition: Amount of money in the cash entry. DataType: ActiveOrHistoricCurrencyAndAmount Format: ActiveOrHistoricCurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 ActiveOrHistoricCurrencyCode [A-Z]{3,3} 5.1.2 CreditDebitIndicator<CdtDbtInd> Presence: [1..1] Definition: Indicates whether the entry is a credit or a debit entry.
DataType: Code One of the following CreditDebitCodevalues must be used: Code CRDT DBIT Credit Debit Name Definition Operation is an increase. Operation is a decrease.
5.1.4 Status <Sts> Presence: [1..1] Definition: Status of an entry on the books of the account servicer. DataType: Code One of the following EntryStatus2Code values must be used: Code BOOK Booked Name Definition Booked means that the transfer of money has been completed between account servicer and account owner. Usage: Status Booked imply finality of money. 5.1.8 ValueDate<ValDt> Presence: [0..1] Definition: Date and time at which assets become available to the account owner in case of a credit entry, or cease to be available to the account owner in case of a debit entry. Type: This message item is composed the following Date element. 5.1.9 Date <Dt> Presence: [1..1] This message item is part of choice 5.1.8 ValueDate. Definition: Specified date. DataType: ISODate 5.1.18 BankTransactionCode<BkTxCd> Presence: [1..1] Definition: Set of elements used to fully identify the type of underlying transaction resulting in an entry. Type: This message item is composed of the following BankTransactionCodeStructure4 element(s): Ref 5.1.24 Or Message Item Proprietary <XML Tag> <Prtry> Mult. [0..1] Represent./Type
5.1.24 Proprietary <Prtry> Presence: [0..1] Definition: Bank transaction code in a proprietary form, as defined by the issuer. Type: This message item is composed of the following proprietary BankTransactionCodeStructure1 element(s): Ref 5.1.25 Or Code Message Item <Cd> <XML Tag> Mult. [1..1] Represent./Type Text
5.1.25 Code <Cd> Presence: [1..1] Definition: Proprietary bank transaction code to identify the underlying transaction. It will copy the original message type of the respective transaction entry: FIToFICustomerCredit, RTGSFIToFICredit,
RTGSOwnAccTtransfer, RTGSNetSettlementXXzNN, FIToFIPaymentReturn.
DataType: Max35Text Format: maxLength: 35 minLength: 1 5.1.234 EntryDetails<NtryDtls> Presence: [0..*] Definition: Provides details on the entry. Type: This message item is composed of the following EntryDetails2element(s): Ref 5.1.241 Or Message Item TransactionDetails <XML Tag> <TxDtls> Mult. [0..*] Represent./Type
5.1.241 TransactionDetails<TxDtls> Presence: [0..*] Definition: Provides information on the underlying transaction(s). Type: This message item is composed of the following EntryTransaction3 element(s): Ref 5.1.242 5.1.259 5.1.260 Or Message Item References Amount CreditDebitIndicator <XML Tag> <Refs> <Amt> <CdtDbtInd> Mult. [0..1] [1..1] [1..1] Amount Represent./Type
5.1.242 References <Refs> Presence: [0..1] Definition: Provides the identification of the underlying transaction. Type: This message item is composed of the following TransactionReferences3 element(s):
Ref 5.1.247 5.1.248
Or
Message Item EndToEndIdentification TransactionIdentification
<XML Tag> <EndToEndId> <TxId>
Mult. [1..1] [1..1]
Represent./Type Text Text
5.1.247EndToEndIdentification<EndToEndId> Presence: [1..1] Definition: Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain. Usage: The end-to-end identification can be used for reconciliation or to link tasks relating to the transaction. It can be included in several messages related to the transaction. Data Type: Max35Text Format: maxLength: 35 minLength: 1 5.1.248 TransactionIdentification<TxId> Presence: [0..1] Definition: This holds the unique UTR (22 character long) of the message received by the Participant from NG-RTGS. DataType: Max35Text Format: maxLength: 35 minLength: 1
Example
<BkToCstmrStmt> <GrpHdr> <MsgId>HDFC201212011234567890</MsgId> <CreDtTm>2012-12-18T17:00:00</CreDtTm> <MsgPgntn> <PgNb>1</PgNb> <LastPgInd>true</LastPgInd> </MsgPgntn> </GrpHdr> <Stmt> <Id>HDFC201212011234567890</Id> <StmtPgntn>
<PgNb>1</PgNb> <LastPgInd>true</LastPgInd> </StmtPgntn> <ElctrncSeqNb>1</ElctrncSeqNb> <CreDtTm>2012-12-18T17:00:00</CreDtTm> <Acct> <Id> <Othr> <Id>50000000054910000003</Id> </Othr> </Id> <Ccy>INR</Ccy> </Acct> <Bal> <Tp> <CdOrPrtry> <Cd>CLBD</Cd> </CdOrPrtry> </Tp> <AmtCcy="INR">500000</Amt> <CdtDbtInd>CRDT</CdtDbtInd> <Dt> <DtTm>2012-12-18T19:30:00</DtTm> </Dt> </Bal> <Ntry> <AmtCcy="INR">10000000.50</Amt> <CdtDbtInd>CRDT</CdtDbtInd> <Sts>BOOK</Sts> <ValDt> <Dt>2010-10-18</Dt> </ValDt>
<BkTxCd> <Prtry> <Cd>FIToFICustomerCredit</Cd> </Prtry> </BkTxCd> <NtryDtls> <TxDtls> <Refs> <EndToEndId>MY REFERENCE 101</EndToEndId> <TxId>ABCD201212101234567890</TxId> </Refs> <Amt>Ccy="INR">10000000.50</Amt> <CdtDbtInd>CRDT</CdtDbtInd> </TxDtls> </NtryDtls> </Ntry> <Ntry> <AmtCcy="INR">20000000</Amt> <CdtDbtInd>CRDT</CdtDbtInd> <Sts>BOOK</Sts> <ValDt> <Dt>2010-10-18</Dt> </ValDt> <BkTxCd> <Prtry> <Cd>FIToFICustomerCredit</Cd> </Prtry> </BkTxCd> <NtryDtls> <TxDtls> <Refs> <EndToEndId>MY REFERENCE 102</EndToEndId>
<TxId>ABCD201212101234567891</TxId> </Refs> <Amt>Ccy="INR">20000000</Amt> <CdtDbtInd>DBIT</CdtDbtInd> </TxDtls> </NtryDtls> </Ntry> </Stmt> </BkToCstmrStmt>
Free Format Message for Participants

Introduction
This document describes the format specifications of the message camt.998.001.02 which will be used to transmit various free format information to the Participants over the SWIFT and INFINET networks, via the SWIFT and IDRBT messaging hubs.
Outline
The message type will have a Business Application Header (BAH) that follows the general specifications of the BAH as defined already by RBI. The Receipt message is composed of five building blocks. A. MessageIdentification This building block is optional in the standard but for NG-RTGS this will be made mandatory. B. RelatedReference This building block is optional. This will not be used by NG-RTGS. C. PreviousReference This building block is optional. This will not be used by NG-RTGS. D. OtherReference This building block is optionalin the standard but for NG-RTGS this will be made mandatory. E. ProprietaryData This building block is mandatory. This will contain the actual text message conveyed to the Participants.
Format specifications
The first 4 building blocks of the message are standard, without any modifications from the ISO standard. The MessageIndentification tag will follow the same definition as per the rest of the ISO messages defined for NG-RTGS. (e.g. XXXX- Sender IFSC [4], YYYYMMDD - Creation Date [8], X Channel [1], nnnnnnnnn- Sequence Number [9])
Structure
Index Or Message Item Message root 1.0 1.1 MessageIdentification Reference <XML Tag> <PrtryMsg> <MsgId> <Ref> Mult. [1..1] [1..1] [1..1] Text Represent ./Type Rule/Gui d no.
Index 4.0 4.1 5.0
Or Other
Message Item
<XML Tag> <Othr> <Ref> <PrtryData>
Mult. [1..1] [1..1] [1..1]
Represent ./Type
Rule/Gui d no.
Reference ProprietaryData
Text
1.0MessageIdentification<MsgId>
Presence: [1..1] Data Type: Max35Text Format: maxLength: 35 minLength: 1
1.1Reference<Ref>
Presence: [1..1] Definition: Uniquely identifies the message. The same schema for the id is used as for the rest of the messages processed by NG-RTGS. That is:
XXXX- Sender IFSC [4] YYYYMMDD - Creation Date Reverse [8] nnnnnnnnn- Sequence Number [10]
Data Type: Max35Text Format: maxLength: 35 minLength: 1
4.0 Other<Othr>
Presence: [1..1] Definition: This will hold the user-defined subject of the message.
4.1Reference<Ref>
Definition: Business reference of the present message assigned by the user issuing the message. This reference must be unique amongst all messages of the same name sent by the same party. DataType: Max35Text Format: maxLength: 35 minLength: 1 5.0 ProprietaryData<PrtryData> Presence: [1..1] Definition: Business content of this element is not specified. 2
Type: This message item is composed of the following ProprietaryDataelement(s): Or 5.1 5.2 Type Any Message Item <XML Tag> <Tp> (User defined) Mult. [1..1] [1..1] Represent./Type Text
5.1Type<Tp> This is a mandatory fixed field. Its content is: NG-RTGS Notification 5.2User defined<Document> This section contains the actual message to be sent to the receiver. Or Message Item Document Root tag Message Content <XML Tag> <Doc> <DocCont> Mult. [1..1] [1..1] Max2000Text Represent./Type
The message content is an unstructured free text of up to 2000 characters long.
Example
<PrtryMsg> <MsgId> <Ref>HDFC201212011234567890</Ref> </MsgId> <Othr> <Ref>Notification subject</Ref> </Othr> <PrtryData> <Tp>NG-RTGS Notification</Tp> <Doc> <DocCont> This is a free format message. </DocCont> </Doc> </PrtryData> </PrtryMsg>

ISO20022 Business Application Header
ISO Message: head.001.001.01 BusinessApplicationHeaderV01
ISO20022 Message head.001.001.01 BusinessApplicationHe aderV01 Message Item From XML tag Description Index ISO Multi RTGS /NEFT Multi Rules Example Data Type
<AppHdr> <Fr>
Root tag
The sending MessagingEndpoin t that has created this Business Message for the receiving MessagingEndpoin t that will process this Business Message.
2.0
[1..1] [1..1]
[1..1] [1..1]
FinancialInstitutionIde ntification FinancialInstitutionIde ntification ClearingSystemMemb erIdentification Member Identification
<FIId>
Identification of a financial institution. Identification of a financial institution ClearingSystemM emberIdentificati on IFSC of the Sending participant
2.34
[0..1]
[1..1]
<FinInstnId>
2.35
[0..1]
[1..1]
<ClrSysMmbI d> <MmbId>
2.37
[0..1]
[1..1]
2.41
[1..1]
[1..1]
<Fr><FIId><FinInstnId><ClrSysMmbI d><MmbId>CANB0239777</MmbId ><ClrSysMmbId></FinInstnId></FIId ></Fr>
Max35Te xt
Reserve Bank of India ISO Message, head.001.001.01 BusinessApplicationHeaderV01

ISO20022 Message head.001.001.01 BusinessApplicationHe aderV01 Message Item To XML tag Description Index ISO Multi RTGS /NEFT Multi Rules Example Data Type
<To>
The MessagingEndpoin t designated by the sending MessagingEndpoin t to be the recipient who will ultimately process this Business Message
3.0
[1..1]
[1..1]
FinancialInstitutionIden tification
<FIId>
FinancialInstitutionIde ntification ClearingSystemMemb erIdentification Member Identification
<FinInstnId>
<ClrSysMmbI d> <MmbId>
Identification of a financial institution. Identification of a financial institution ClearingSystemM emberIdentificati on IFSC of the Sending participant
3.34
[1..1]
[1..1]
3.35
[0..1]
[1..1]
3.37
[0..1]
[1..1]
3.41
[1..1]
[1..1]
<To></FIId><FinInstnId><ClrSysMmb Id>MmbId> HDFC0239777</MmbId></ClrSysMm bId><FinInstnId></FIId></To> Validation are:

Character position First four characters Fifth character Last six characters Information Bank code Zero Branch code
Max35Te xt
R B no w
Max35Te
BusinessMessageIden
<BizMsgIdr>
Uniquely
4.0
[1..1]
[1..1]
Same as MessageIdentification
<BizMsgIdr>HDFC201210180000000

ISO20022 Message head.001.001.01 BusinessApplicationHe aderV01 Message Item tifier XML tag Description Index ISO Multi RTGS /NEFT Multi Rules Example Data Type
MessageDefinitionIde ntifier
<MsgDefIdr>
identifies the business message Message Identifier
<MsgId> in the associated business message 5.0 [1..1] [1..1] Contains the MessageIdentifier that defines the Business Message as published on the ISO 20022 website. E.g. pacs.008.001.03 Comprises a fixed value of RTGS, and in the case of BAH for pacs.008 and pacs.009 the fixed value of RTGS must be followed by the local instrument name, i.e. for RTGS, BAH for pacs.008: RTGSFIToFICustomerCredit. For RTGS, BAH for pacs.004; RTGSPaymentReturn For RTGS, BAH for pacs.009: -RTGSFIToFICredit or -RTGSOwnAccTtransfer or -RTGSNetSettlementXXzNN Where XX is the clearing type which may take values GC, IB, FX, MC, SE, OT & so on. z is the indicator which may take values C Original, R-Return, L-Last Return. NN is the return serial. GC stands for guaranteed
218</BizMsgIdr>
xt
<MsgDefIdr> pacs.008.001.03</MsgDefIdr>
Max35Te xt
BusinessService
<BizSvc>
Specifies the business service agreed between the two MessagingEndPoi nts under which rules this Business Message is exchanged.
6.0
[0..1]
[1..1]
<BizSvc> RTGSFIToFICustomerCredit </BizSvc>
Max35Te xt

ISO20022 Message head.001.001.01 BusinessApplicationHe aderV01 Message Item XML tag Description Index ISO Multi RTGS /NEFT Multi Rules Example Data Type
settlement of Securities and CBLO segment. "IB" stands for guaranteed settlement of FOREX segment. "FX" stands for non guaranteed settlement. MC Stands for MICR Clearing SE stands for non-guaranteed MNSB OT stands for Other MNSB Time up to seconds only
CreationDate
<CreDt>
CopyDuplicate
<CpyDplct>
Date and time when this Business Message (header) was created. Indicates whether the message is a Copy, a Duplicate or a copy of a duplicate of a previously sent ISO 20022 Message.
7.0
[1..1]
[1..1]
<CreDt>2012-09-30T09:50Z</CreDt>
ISONorm alisedDat eTime Code
8.0
[0..1]
[0..1]
DUPL Duplicate(Message is for information/ confirmation purposes. It is a duplicate of a message previously sent). Valid Values are: CODU COPY DUPL
<CpyDplct>DUPL</CpyDplct>

ISO20022 Message head.001.001.01 BusinessApplicationHe aderV01 Message Item Signature XML tag Description Index ISO Multi RTGS /NEFT Multi Rules Example Data Type
<Sgntr>
Contains the digital signature of the Business Entity authorised to sign this Business Message. The XML signatures applied to the BusinessMessage . Specifies the Business Application Header of the Business Message to which this Business Message relates. It can be used when replying to a query; can also be used when canceling or amending.
11.0
[0..1]
[1..1]
SHA2 digital signature http://www.w3.org/2000/09/xml dsig#
XMLSignatures
<XMLSgntrs>
[1..1]
[1..1]
Related
<Rltd>
12.0
[0..1]
[0..1]

ISO20022 Message head.001.001.01 BusinessApplicationHe aderV01 Message Item From XML tag Description Index ISO Multi RTGS /NEFT Multi Rules Example Data Type
<Fr>
Element description is same as that provided for the same element above. This message item is the part of the Rltd block.
The sending Messaging Endpoint that has created this Business Message for the receiving Messaging Endpoint that will process this Business Message.
12.2
[1..1]
[1..1]
Content is identical to corresponding element content found in BAH of the message to which this BAH (and the business message) is in response to.
<FIId>
12.36
[1..1]
[1..1]
FinancialInstitutionIden tification ClearingSystemMembe rIdentification
<FinInstnId>
Identification of a financial institution.
12.37
[1..1]
[1..1]
<ClrSysMmbI d>
12.87 12.88 -As AboveThe Messaging Endpoint designated by the sending Messaging
[0..1] [1..1]
[1..1] [1..1]
Member Identification To
<MmbId> <To>
<FIId>
Max35Te xt -As Above-
12.53
[1..1]
[1..1]
[1..1]
[1..1]

ISO20022 Message head.001.001.01 BusinessApplicationHe aderV01 Message Item XML tag Description Index ISO Multi RTGS /NEFT Multi Rules Example Data Type
Endpoint to be the recipient who will ultimately process this Business Message. FinancialInstitutionIden tification ClearingSystemMembe rIdentification <FinInstnId>
Identification of a financial institution.
[1..1]
[1..1]
<ClrSysMmbI d>
[0..1] [1..1]
[1..1] [1..1]
Member Identification BusinessMessageIden tifier MessageDefinitionIde ntifier Business Service CreationDate
<MmbId> <BizMsgIdr> <MsgDefIdr> <BizSvc> <CreDt> -As Above-As Above-As Above-As Above12.104 12.105 12.106 12.107
[1..1] [1..1] [0..1] [1..1]
[1..1] [1..1] [0..1] [1..1]
-As Above-As Above-As Above-As Above-
CopyDuplicate
<CpyDplct>
-As Above-
12.108
[0..1]
[0..1]
-As Above-
Max35Te xt Max35Te xt Max35Te xt Max35Te xt ISONorm alisedDat eTime Code

Customer Credit Transfer
ISO Message: pacs.008.001.03 FIToFICustomerCreditTransferV03 * Applicable Areas: RTGS and NEFT
i) For defining Customer Transaction Messages in RTGS (ii) For defining Outward Debit Message in NEFT (iii) For Defining Credit List message in NEFT originating from RBI This message formats would replace the current R41 used in current RTGS.
*Corresponds to R41 in current RTGS, N06 and N02 in NEFT.
The ISO 20022 Business Message consists of two parts: (1) ISO 20022 Business Appl. Header (2) ISO 20022 Messages
Business Application Header is a business header and should not be confused with a file or transport header. It is created before the transport routing header is applied to the business message and is retained after the transport header is removed. So any parties between the two business applications that don't perform a business function are not mentioned in the BAH. Such 'technical' middle men don't open or change the Business Message; they only forward it to the correct business application. Although the BAH is not the transport header, data in the BAH can be used by transport applications to determine the routing header since it does contain the business sender, receiver and document details . It can also be used by the business applications to determine the appropriate process to perform on the business message.
Message fields description ISO Business Application Header Business Application Header (Refer related documentation RBI_NG_RTGS_ISO20022_BusinessApplicationHeader)
Reserve Bank of India ISO 20022 Message, pacs.008.001.03 FIToFICustomerCreditTransferV03
1|Page

ISO 20022 Message
Map ping ISO20022 Message FIToFICustomerCre ditTransferV03 Message Item FIToFICustomerCred itTransfer XML tag Description Index ISO Multi RTGS/ NEFT Multi Rules Example Data Type
<FIToFICstmr CdtTrf>
GroupHeader
<GrpHdr>
MessageIdentificati on GROUP HEADER - GROUP HEADER
<MsgId>
Message Root tag for FIToFICustomer CreditTransfer Fields common to all the transaction in the message Point to point reference, as assigned by the instructing party, and sent to the next party in the chain to unambiguously identify the message. Usage: The instructing party has to make sure that MessageIdentifi cation is unique per instructed party for a pre-agreed period. Usage: The instructing
1.0
[1..1]
[1..1]
1.1
[1..1]
[1..1]
Uniquely identifies message Recommend MessageIdentification be structured as: XXXX- Sender IFSC [4] YYYYMMDD - Creation Date Reverse [8] X Channel [1] nnnnnnnnn- Sequence Number [9] The values of Channel Identification (X) is the same as defined for TransactionIdentification <TxId>
<MsgId> HDFC201210181000000218</ MsgId>
Max35Text
Message Identification
2|Page

party has to make sure that MessageIdentifi cation is unique per instructed party for a preagreed period. Date and time at which the message was created. (Payment origination date time). Number of individual transactions contained in the message. Total amount of money moved between the instructing agent and the instructed agent. (Total Settlement Amount + Currency) Settlement Date Specifies the details on how the settlement of the transaction(s)
Creation Date & Time
CreationDateTime
<CreDtTm>
1.2
[1..1]
[1..1]
Time up to seconds only
<CreDtTm>2011-0424T09:30:32</CreDtTm>
ISODateTime
No. of Txs.
NumberOfTransacti ons
<NbOfTxs>
1.4
[1..1]
[1..1]
Always 1 for customer payment in RTGS system and 10 or more for NEFT
<NbOfTxs>1</NbOfTxs>
Max15Numer icText
TotalInterbankSettl ementAmount
<TtlIntrBkSttl mAmt>
1.6
[0..1]
[1..1]
<TtlIntrBkSttlmAmt Ccy='INR'>3400.00</TtlIntrBk SttlmAmt> Currency as per the ISO 4217 list
Amount
Settlement Settlement Information
InterbankSettlemen tDate SettlementInformat ion
<IntrBkSttlm Dt> <SttlmInf>
1.7 1.8
[0..1] [1..1]
[1..1] [1..1]
Settlement date
<IntrBkSttlmDt>2011-0424</IntrBkSttlmDt>
ISODate
3|Page

between the instructing agent and the instructed agent is completed. Method used to settle the (batch of) payment instructions.
SettlementMethod
<SttlmMtd>
[1..1]
[1..1]
Must be CLRG (i.e., Settlement done through a payment clearing system) Other Codes are: CLRG, COVE, INDA, INGA
<SttlmMtd>CLRG</SttlmMtd>
Code
InstructingAgent
<InstgAgt>
FinancialInstitutionI dentification
<FinInstnId>
ClearingSystemMe mberIdentification
<ClrSysMmbI d>
Member
<MmbId>
Agent that instructs the next party in the chain to carry out the (set of) instruction(s). Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme. Information used to identify a member within a clearing system. Identification of
1.21
[0..1]
[1..1]
Mandatory in RTGS implementation
[1..1]
[1..1]
[0..1]
[1..1]
[1..1]
[1..1]
Sender IFSC
<InstgAgt><FinInstnId><ClrSys
Max35Text
4|Page

Identification a member of a clearing system. (IFSC of the Sending participant). Agent that is instructed by the previous party in the chain to carry out the (set of) instruction(s). Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme. Information used to identify a member within a clearing system. Identification of a member of a clearing system. (IFSC of the Receiving participant MmbId><MmbId>HDFC02397 77</MmbId></ClrSysMmbId> </FinInstnId></InstgAgt>
InstructedAgent
<InstdAgt>
1.22
[0..1]
[1..1]
<FinInstnId>
[1..1]
[1..1]
<ClrSysMmbI d>
[0..1]
[1..1]
Member Identification
<MmbId>
[1..1]
[1..1]
Receiver IFSC
<InstdAgt><FinInstnId><ClrSys MmbId><MmbId>HDFC02397 77</MmbId></ClrSysMmbId> </FinInstnId></InstdAgt>
Max35Text
5|Page

CreditTransferTrans actionInformation <CdtTrfTxInf > Set of elements providing information specific to the individual credit transfer(s)). Set of elements used to reference a payment instruction.
The PmtId block contains the following elements:
i) InstructionIdentifica tion <InstrId> ii) EndToEndIdentificat ion <EndToEndId> iii) TransactionIdentific ation <TxId>
2.0
[1..n]
[1..1]
Only one occurrence allowed for Customer Payment in RTGS system and 10 or more for NEFT.
PaymentIdentificati on
<PmtId>
2.1
[1..1]
[1..1]
Payment Identification InstructionIdentifica tion
<InstrId>
Unique identification, as assigned by an instructing party for an instructed party, to unambiguously identify the instruction.
2.2
[0..1]
[0..1]
May be used for supplementary identification, such as the legacy transaction reference number (R41.2020).
Max35Text
6|Page

EndToEndIdentificat ion <EndToEndId > Unique identification, as assigned by the banks customer, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-toend chain to the beneficiary. Usage: The endto-end identification can be used for reconciliation or to link tasks relating to the transaction. It can be included in several messages related to the transaction. (Related Reference )
Unique identification, as assigned by the first instructing agent, to unambiguously
2.3
[1..1]
[1..1]
It should follow the 16 digits UTR pattern of the existing RTGS system, identified with the 6 character codeword prefix /XUTR/. The existing UTR format is: The format is: i)Participant System ID (First four Characters of sending Banks IFSC Code) ii)Service Tag (One Character) Example : H for host iii)Unique-ID comprising of Date (Julian date YYDDD) & Sequence Number (6 digits numeric)
<EndToEndId>/XUTR/ HDFCP12115000023</EndToE ndId>
Max35Text
TransactionIdentific ation
<TxId>
2.4
[1..1]
[1..1]
Use UTR (Unique Transaction Reference) format (22 characters) XXXX- Sender IFSC [4] X-Payment System [1] X-Channel [1]
<TxId> HDFCR12012042400000023</ TxId> In FAQ Channels are mentioned as ATM, Internet
Max35Text
7|Page

identify the transaction that is passed on, unchanged, throughout the entire interbank chain. Usage: The transaction identification can be used for reconciliation, tracking or to link tasks relating to the transaction on the interbank level. Usage: The instructing agent has to make sure that the transaction identification is unique for a preagreed period.
YYYYMMDD-Date [8] nnnnnnnn- Sequence Number [8]
banking etc., Codes for Payment System (X) are: R->RTGS N->NEFT A-> ACH For Further Information on Channel, pl refer to FAQ on Channel.
PaymentTypeInfor mation Payment Information
<PmtTpInf>
Set of elements used to further specify the type of transaction. The PmtTpInf block contains the following elements:
i) InstructionPriority <InstrPrty> ii) ServiceLevel <SvcLvl> iii) LocalInstrument <LclInstrm> iv) CategoryPurpose
2.6
[0..1]
[1..1]
Priority is mandatory in RTGS implementation
8|Page

<CtgyPurp>
InstructionPriority
<InstrPrty>
ServiceLevel
<SvcLvl>
Proprietary
<Prtry>
Indicator of the urgency or order of importance that the instructing party would like the instructed party to apply to the processing of the instruction. (Instruction Priority). Agreement under which or rules under which the transaction should be processed. Specifies a preagreed service
2.7
[0..1]
[1..1]
HIGH / NORM Indicator of the urgency or order of importance that the instructing party would like the instructed party to apply to the processing of the instruction at application level. Priority NORM will result in liquidity Savings. HIGH: Priority Level is high. NORM: Priority Level is normal Default is HIGH.
<InstrPrty>HIGH</InstrPrty>
Code
2.9
[0..1]
[0..1]
2.11
[0..1]
[1..1]
For RTGS processing priority is in range 00 99.
<SvcLvl> <Prtry>
Max35Text
9|Page

or level of service between the parties, as a proprietary code. To be used for managing queues by sending bank before settlement. (For RTGS lower the number highest will be the priority. For Banks priority range is from 11 to 99. Priority from 00 to 10 is reserved for RBI). LocalInstrument <LclInstrm> User community specific instrument. Usage: This element is used to specify a local instrument, local clearing option and/or further qualify the service or service level. Specifies the local instrument, as a proprietary code. Purpose of the Instrument. Payment purpose must be a value listed in ISO category purpose code 2.12 [0..1] [1..1] [TTC=xxxx],[PRI=xx] </Prtry> </SvcLvl> For More information, Pl refer to FAQ.
Proprietary
<Prtry>
2.13
[0..1]
[1..1]
Type of local instrument. For RTGS pacs.008 use: - RTGSFIToFICustomerCredit
<Prtry> RTGSFIToFICustomerCredit </Prtry>
Max35Text
CategoryPurpose
<CtgyPurp>
2.15
[0..1]
[1..1]
10 | P a g e

Code <Cd> ISO External category purpose code list. 2.16
[1..1]
[1..1]
FROM ISO 20022External Code list The following codes are available. CASH: CashManagementTransfer CORT: TradeSettlementPayment DIVI: Dividend GOVT: GovernmentPayment HEDG: Hedging INTC: IntraCompanyPayment INTE: Interest LOAN: Loan PENS: PensionPayment SALA: SalaryPayment SECU: Securities SSBE: SocialSecurityBenefit SUPP: SupplierPayment TAXS: TaxPayment TRAD: Trade TREA: TreasuryPayment VATX: ValueAddedTaxPayment WHLD: WithHolding For additional codes, please refer to document ExternalcodeLists_3Q2012_22 Oct2012_v4.xls available at www.iso20222.org Banks to suggest additional India Specific codes.
<Cd>CASH</Cd> Default value may be CASH.
Code
11 | P a g e

Interbank Settlement Amt
InterbankSettlemen tAmount
<IntrBkSttlm Amt>
ChargeBearer
<ChrgBr>
Amount of money moved between the instructing agent & instructed agent. (Settlement Amount + Currency). Specifies which party(ies) will pay charges due for processing of the instruction.
2.18
[1..1]
[1..1]
<IntrBkSttlmAmt Ccy='INR'>3400.00</IntrBkSttl mAmt>
Amount
2.33
[1..1]
[1..1]
Codes used are:

CRED/DEBT/SHAR/SLEV
<ChrgBr>DEBT</ChrgBr>
Code
Codes & meanings are: DEBT -> BorneByDebtor

( All transaction charges are to be borne by the debtor ).
CRED-> BorneByCreditor
(All transaction charges are to be borne by the creditor).
SHAR-> Shared
Charge Bearer
( In a credit transfer context, means that transaction charges on the sender side are to be borne by the debtor, transaction charges on the receiver side are to be borne by the creditor. In a direct debit context, means that transaction charges on the sender side are to be borne by the creditor,
transaction charges on the receiver side are to be borne by the debtor).
SLEV-> FollowingServiceLevel
(Charges are to be applied following the rules agreed in the service level and/or scheme).
12 | P a g e

ChargesInformation <ChrgsInf> Provides information on the charges to be paid by the charge bearer(s) related to the payment transaction.
The ChrgsInf block contains the following elements: i) Amount <Amt> ii) Agent <Agt>.
2.34
[0..*]
[0..1]
Charges Information
Amount
<Amt>
Agent
<Agt>
Transaction charges to be paid by the charge bearer. Agent that takes the transaction charges or to which the transaction charges are due.
2.35
[1..1]
[1..1]
<Amt Ccy='IND'>5000.00</Amt>
Amount
2.36
[1..1]
[1..1]
13 | P a g e

FinancialInstitution Identification <FinInstnId> Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme. Information used to identify a member within a clearing system. Identification of a member of a clearing system. ORDERING CUSTOMER Ordering Customers Name Ordering Customers Postal Address Adress in free form text Identification of the account of the debtor to which a debit entry will be [1..1] [1..1]
<ClrSysMmbI d>
[0..1]
[1..1]
Member Identification Debtor

Debtor (Ordering Customer)
<MmbId>
[1..1]
[1..1]
Max35Text
<Dbtr> <Nm>
2.49
[1..1] [0..1] [0..1] [0..7]
[1..1] [1..1] [0..1] [0..4] [1..1]

Number of occurrences is restricted to 4 in RTGS implementation. <AdrLine>Boulevard Road</AdrLine> Max70Text Name is mandatory <Nm>Umesh Kapoor</Nm> Max140Text
Name
PostalAddress
<PstlAdr>
AddressLine
<AdrLine>
Debtor's A/c (Ordering Customer's A/C)
DebtorAccount
<DbtrAcct>
2.50
[0..1]
14 | P a g e

Identification <Id> made as a result of the transaction. Unique and unambiguous identification for the account between the account owner and the account servicer. Unique identification of an account, as assigned by the account servicer, using an identification scheme. Identification assigned by an institution. (Debtor's Account number). Specifies the nature, or use of the account. Nature or use of the account in a proprietary form.
[1..1]
[1..1]
Other
<Othr>
[1..1]
[1..1]
Identification
<Id>
[1..1]
[1..1]
<DbtrAcct><Id> <Othr> <Id>265385644663</Id></Oth r></Id></DbtrAcct>
Max34Text
Type
<Tp>
[0..1]
[0..1]
Proprietary
<Prtry>
[1..1]
[1..1]
To be used to accommodate NEFT Account type information. This is also useful to document NRE account type for the RTGS.
Text
15 | P a g e

Currency <Ccy> Identification of the currency in which account is held. Financial institution servicing an account for the debtor.
(ORDERING INSTITUTION) Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme.
[0..1]
[0..1]
For NG-RTGS, INR is the only currency that can be specified.
<Ccy>INR</Ccy>
Code
DebtorAgent
<DbtrAgt>
2.51
[1..1]
[1..1]
Pl see FAQ for more details on DebtorAgent (i.e Sub-Member) For Participant, IFSC
FinancialInstitutionI dentification Debtor's Agent (ORDERING INSTITUTION)
<FinInstnId>
[1..1]
[1..1]
ClearingSystemIden tification
<ClrSysMmbI d>
<MmbID>
Information used to identify a member within a clearing system. Identification of a member of a clearing system. (IndianFinancial SystemCodeIde ntifier for participants / Name and Identification for non Participants is
2.1.6
[0..1]
[1..1]
2.1.6
[1..1]
[1..1]
For Participant, IFSC code to be keyed in. For Non- Participant, IFSC, or Name and Other Identification with optional Address.
<DbtrAgt><FinInstnId><ClrSys MmbId><MmbId>HDFC02397 77</MmbId>></ClrSysMmbId ></FinInstnId></DbtrAgt>
16 | P a g e

Name <Nm> mandatory). Ordering Institution Name Ordering Institution Postal Address Address in free format text [0..1] [0..1] Optional. To be filled if Ordering Customer is other than the Sender of the msg. <Nm>Bank A</Nm> Max140Text
PostalAddress
<PstlAdr>
[0..1]
[0..1]
AddressLine
<AdrLine>
[0..7]
[0..4]
Number of occurrences is restricted to 4 in RTGS implementation
<AdrLine>Corn Exchange 5th Floor</AdrLine> <AdrLine>Mark Lane 55</AdrLine> <AdrLine>EC3R7NE London</AdrLine> <AdrLine>GB</AdrLine>
Max70Text
CreditorAgent
<CdtrAgt>
<FinInstnId>
<ClrSysMmbI d>
Financial institution serving an account for the creditor. (Beneficiary Institution identification) Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme. Information used to identify a member
2.53
[1..1]
[1..1]
Creditor's Agent (BENEFICIARY INSTITUTION)
[1..1]
[1..1]
3.37
[0..1]
[1..1]
17 | P a g e

Member Identification <MmbId> within a clearing system. Identification of a member of a clearing system. (IndianFinancial SystemCodeIde ntifier) Name by which an agent is known & which is usually used to identify that agent. (Beneficiary Institution Name) Beneficiary Customer Information Name by which a party is known and which is usually used to identify that party. (Beneficiary Customer Name) Beneficiary Customer's Postal Address Adress in free form text
Identification of the account of the creditor to
[1..1]
[1..1]
For Participant, IFSC code to be keyed in. For Non- Participant (i.e. Participant who do not have IFSC code), Name and Other Identification to be keyed in.
<CdtrAgt><FinInstnId><ClrSys MmbId><MmbId>HDFC02397 77</MmbId></ClrSysMmbId> <</FinInstnId></CdtrAgt>
Max35Text
Name
<Nm>
[0..1]
[0..1]
<Nm>Bank B</Nm>
Max140Text
Creditor Creditor (BENEFICIARY CUSTOMER)
<Cdtr>
2.55
[1..1]
[1..1]
Name
<Nm>
[0..1]
[1..1]
Mandatory in view of Indian Context (Ref. Circular issued by RBI)
<Nm>A R Roy</Nm>
Max140Text
PostalAddress
<PstlAdr>
[0..1]
[0..1]
AddressLine Credito r's A/c (BENEFI CIARY CUSTO MER's A/C) CreditorAccount
<AdrLine> <CdtrAcct>
[0..7]
2.56 [0..1]
[0..4]
[1..1]
Number of occurrence is restricted to 4. Mandatory in RTGS implementation
<AdrLine>Boulevard Road</AdrLine>
Max70Text
18 | P a g e

which a credit entry will be posted as a result of the payment transaction. (Beneficiary Customer Account) The CdtrAcct block contains the following elements: i) Identification <Id> ii) Currency <Ccy>
Identification
<Id>
Other
<Othr>
Identification
<Id>
Unique and unambiguous identification for the account between the account owner and the account servicer. Unique identification of an account, as assigned by the account servicer, using an identification scheme. Identification assigned by an institution.
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
Existing account number
<CdtrAcct><Id> <Othr> <Id>2147743292</Id></Othr> </Id></CdtrAcct>
Max34Text
19 | P a g e

Type <Tp> Proprietary <Prtry> Specifies the nature, or use of the account. Nature or use of the account in a proprietary form. Identification of the currency in which account is held Beneficiary Customer Information. Further information related to the processing of the payment instruction, provided by the initiating party, and intended for the creditor agent. Coded information related to the processing of the payment instrument, provided by the initiating party. Further information complementing [0..1] [0..1] [1..1] [1..1] To be used to accommodate NEFT Account type information. This is also useful to document NRE account type for the RTGS. For NG-RTGS, INR is the only currency that can be specified. Text
Currency
<Ccy>
[0..1]
[0..1]
<Ccy>INR</Ccy>
Code
InstructionForCredit orAgent
<InstrForCdtr Agt>
2.58
[0..n]
[0..2]
Instruction For Creditor Agent
Code
<Cd>
2.59
[0..1]
[0..1]
PHOB = Phone Beneficiary TELB=Telecom CHQB= PayCreditorByCheque HOLD= HoldCashForCreditor Pl see FAQ for details.
<Cd>PHOB</Cd>
Code
InstructionInformati on
<InstrInf>
2.63
[0..1]
[0..1]
Max140Text
20 | P a g e

the coded instruction or instruction to the next agent that is bilaterally agreed or specific to a user community. Beneficiary Customer's Postal Address Remittance Information 140 characters up to 4 can be used Sender to Receiver Information
Beneficiary Information
RemittanceInforma tion Unstructured
<RmtInf>
2.69
[0..1]
[0..1]
<Ustrd>
2.69
[0..n]
[0..4]
Size restricted to a maximum of 4 repeats of 140 characters.
Max140Text
Note:- [1..1] -> Mandatory; [0..1] -> Optional ; [1..n] -> Mandatory and n times repeated ; [0..n] -> Optional and n times repeated;
21 | P a g e
ISO20022 standard Message Implementation Customer Debit Credit Notification

ISO Message camt.054.001.003 BankToCustomerDebitCreditNotificationV03
Applicable Areas: RTGS & NEFT

1. 2. 3. 4. For defining Debit Notification in MNSB (RTGS) For defining Credit Notification in MNSB (RTGS) For defining Debit Notification by the NG-RTGS in response to a pacs.004, pacs,008, pacs.009. For defining Credit Notification by the NG-RTGS in response to a pacs.009 Own Account Transfer.
ISO 20022 Message

Reserve Bank of India ISO Messages, camt.054.001.03 BanktoCustomerDebitCreditNotificationV03
1|Page

ISO20022 Message camt.054.001.03 BankToCustomerDebitCredit NotificationV03 Message Item XML tag Description Index ISO Multi RTGS /NEFT Multi
Rules
Example
Data Type
GroupHeader
<BkToCstmrDbtC dtNtfctn> <GrpHdr>
Root tag
[1..1] 1.0 [1..1]
[1..1] [1..1]
MessageIdentification
<MsgId>
CreationDateTime
<CreDtTm>
Common information for the message. Point to point reference, as assigned by the account servicing institution, and sent to the account owner or the party authorised to receive the message, to unambiguously identify the message. Usage: The account servicing institution has to make sure that MessageIdentificati on is unique per account owner for a pre-agreed period. Date and time at which the message was created. Notifies debit and credit entries for the account.
This msg element is
1.1
[1..1]
[1..1]
Uniquely identifies message Recommend MessageIdentification be structured as: XXXX- Sender IFSC [4] YYYYMMDD - Creation Date Reverse [8] X Channel [1] nnnnnnnnn- Sequence Number
<MsgId> HDFC201210181000000218</MsgId>
Max35Text
[9] The values of Channel Identification (X) is the same as defined for TransactionIdentification <TxId>
1.2
[1..1]
[1..1]
Notification
<Ntfctn>
2.0
[1..n]
[1..1] or [1..10]
Time upto seconds only YYYY-MM-DDThh:mm:ss Beginning / end of calendar day 00:00:00 = the beginning of a calendar day 24:00:00 = the end of a calendar day Occurs once in RTGS, but [1..10] in NEFT
<CreDtTm>2011-04-24T09:30:32</CreDtTm>
ISODateTim e
2|Page

Rules
Example
Data Type
the part of the Ntfctn block.
Identification
<Id>
CreationDateTime
<CreDtTm>
Account
<Acct>
Identification
<Id>
Other
<Othr>
Unique identification, as assigned by the account servicer, to unambiguously identify the account notification. Date and time at which the message was created. This msg element is the part of the Ntfctn block. Unambiguous identification of the account to which credit and debit entries are made. This msg element is the part of the Ntfctn block. Unique and unambiguous identification for the account between the account owner and the account servicer. Unique identification of an account, as assigned by the account servicer, using an identification scheme.
2.1
[1..1]
[1..1]
<Id>EODZERO</Id>
Max35Text
2.5
[1..1]
[1..1]
ISODateTim e
2.11
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
Identification
<Id>
Identification assigned by an
[1..1]
[1..1]
<Acct><Id><Othr><Id>353565651234</Id></ Othr></Id></Acct>
Max34Text
3|Page

Rules
Example
Data Type
institution.
(Settlement account number) Entry <Ntry>
Set of elements used to specify an entry in the debit credit notification. Usage: At least one reference must be provided to identify the entry and its underlying transaction(s).
This msg element is the part of the Ntfctn block. Amount and currency This msg element is the part of the Ntry block.
2.45
[0..n]
[1..1]
Amount
<Amt>
[1..1]
[1..1]
<Amt Ccy="INR">10000.00</Amt>
Amount
CreditDebitIndicator
<CdtDbtInd>
Indicates whether the entry is a credit or a debit entry.

This msg element is the part of the Ntry block.
[1..1]
[1..1]
Codes to be used are: CRDT: Credit -> Operation is an increase DBIT: Debit -> Operation is a decrease
<CdtDbtInd>DBIT</CdtDbtInd>
Code
Status
<Sts>
Status of an entry on the books of the account service Provider.

Code for status BOOK/INFO/PDNG/F UTR This msg element is the part of the Ntry block.
[1..1]
[1..1]
Always BOOK meaning booked amount. Booked means that the transfer of money has been completed between account servicer and account owner. Status Booked is the only status that can be reversed. Others Code for status are: BOOK: Booked INFO: Information PDNG: Pending FUTR : Future
<Sts>BOOK</Sts>
Code
4|Page

Rules
Example
Data Type
For more details pl refer para 2.81 of ISO documentation Payment Maintenance 2009.pdf. ValueDate <ValDt> Date and time at which assets become available to the account owner in case of a credit entry, or cease to be available to the account owner in case of a debit entry. Usage: If entry status is pending and value date is present, then the value date refers to an expected/ requested value date. This msg element is the part of the Ntry block. Value date time Set of elements used to fully identify the type of underlying transaction resulting in an entry. This msg element is the part of the Ntry block. Bank transaction code in a proprietary form, as defined by the issuer. Proprietary bank transaction code to identify the underlying transaction. [0..1] [1..1]
DateTime BankTransactionCode
<DtTm> <BkTxCd>
[0..1] [1..1]
[1..1] [1..1]
Settlement time
<ValDt><DtTm>2010-1018T13:15:00</DtTm></ValDt>
ISODateTim e
Proprietary
<Prtry>
[1..1]
[1..1]
Code
<Cd>
[1..1]
[1..1]
<BkTxCd><Prtry><Cd>0001</Cd></Prtry></Bk TxCd>
Max35Text
5|Page

ISO20022 Message camt.054.001.03 BankToCustomerDebitCredit NotificationV03 Message Item EntryDetails XML tag Description Index ISO Multi RTGS /NEFT Multi
Rules
Example
Data Type
<NtryDtls>
Provides details on the entry

This msg element is the part of the Ntry block.
[0..n]
[1..1]
TransactionDetails
<TxDtls>
References
<Refs>
Provides information on the underlying transaction(s). Provides the identification of the underlying transaction.
Unique identification, as assigned by an instructing party for an instructed party, to unambiguously identify the instruction. Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain. Usage: The end-toend identification can be used for reconciliation or to link tasks relating to the transaction. It can be included in several 5.1.246
[0..n]
[1..1]
[0..1]
[1..1]
InstructionIdentification
<InstrId>
[0..1]
[0..1]
May be used for supplementary identification, such as the legacy transaction reference number (R41R42.2020).
It should follow the 16 digits UTR pattern of the existing RTGS system,
Max35Text
EndToEndIdentification
<EndToEndId>
5.1.247
[0..1]
[1..1]
<EndToEndId>/XUTR/ HDFCP12115000023</EndToEndId>
Max35Text
identified with the 6 character codeword prefix /XUTR/.. The existing UTR format is:
i)Participant System ID (First four Characters of sending Banks IFSC Code) ii)Service Tag (One Character) Example : H for host iii)Unique-ID comprising of Date (Julian date YYDDD) & Sequence Number (6 digits numeric)
6|Page

Rules
Example
Data Type
TransactionIdentification
<TxId>
messages related to the transaction. Usage: In case there are technical limitations to pass on multiple references, the end-to-end identification must be passed on throughout the entire end-to-end chain. (Transaction reference number). This msg element is the part of the Refs block. Unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is passed on, unchanged, throughout the entire interbank chain. Usage: The transaction identification can be used for reconciliation, tracking or to link tasks relating to the transaction on the interbank level. Usage: The instructing agent has to make sure that the transaction identification is
5.1.248
[0..1]
[1..1]
Use UTR (Unique Transaction Reference) format (22 characters) XXXX- Sender IFSC [4] X-Payment System [1] X-Channel [1] YYYYMMDD-Date [8] nnnnnnnn- Sequence Number [8]
<TxId> HDFCR12012042400000023</TxId> For Further Information, pl refer to FAQ on Channel.
Max35Text
7|Page

Rules
Example
Data Type
unique for a preagreed period. (Related reference number). This msg element is the part of the Refs block. Transaction amount This msg element is the part of the TxDtls block. Indicates whether the transaction is a credit or a debit transaction. This msg element is the part of the TxDtls block. Set of elements used to identify the parties related to the underlying transaction. This msg element is the part of the TxDtls block. IFSC of the participant which caused the credit Unique and unambiguous identification of a party. Unique and unambiguous way to identify an organisation. Unique identification of an organisation, as
Amount
<Amt>
[1..1]
[1..1]
<Amt Ccy="INR">10000.00</Amt>
Amount
CreditDebitIndicator
<CdtDbtInd>
5.1.260
[1..1]
[1..1]
Codes are DBIT & CRDT. Codes DBIT CRDT Meanings Debit Credit
<CdtDbtInd>DBIT</CdtDbtInd>
Code
RelatedParties
<RltdPties>
5.1.418
[0..1]
[1..1]
Debtor
<Dbtr>
5.1.462
[0..1]
[1..1]
Must reflect the pacs.008 and pacs.009 structure for BOTH Debtor and Creditor
Identification
<Id>
[0..1]
[1..1]
OrganisationIdentification
<OrgId>
[1..1]
[1..1]
Other
<Othr>
[0..n]
[1..1]
8|Page

Rules
Example
Data Type
Identification
<Id>
Purpose
<Purp>
assigned by an institution, using an identification scheme. Identification assigned by an institution. (IFSC) Underlying reason for the payment transaction. Usage: Purpose is used by the endcustomers, that is initiating party, (ultimate) debtor, (ultimate) creditor to provide information concerning the nature of the payment. This msg element is the part of the TxDtls block. Purpose, in a proprietary form.
[1..1]
[1..1]
<RltdPties><Dbtr><Id><OrgId><Othr><Id>CAN B0239777</Id></Othr></OrgId></Id></Dbtr> </RltdPties>
Max35Text
[0..1]
[0..1]
Proprietary
<Prtry>
[1..1]
[1..1]
Code values are: REPO or REVREPO OR SODBAL or EODZERO or MNSB If code word is not MNSB, then it will be treated as normal.
Max35Text
RemittanceInformation
<RmtInf>
Unstructured
<Ustrd>
Remittance Information. This msg element is the part of the TxDtls block. Remittance Information 140 characters up to 4 can be used
5.1.117 3
[0..1]
[0..1]
5.1.117 4
[0..n]
[1..4]
Max140Text
9|Page

Rules
Example
Data Type
Sender to Receiver Information
Note:- [1..1] -> Mandatory; [1..0] -> Optional ; [1..n] -> Mandatory and n times repeated ; [0..n] -> Optional and n times repeated
10 | P a g e
ISO20022 standard Message Implementation Interbank Transfer

ISO Message: pacs.009.001.03 - FinancialInstitutionCreditTransferV03 *
Applicable Areas: RTGS 1) For defining Interbank message in RTGS. The same is not applicable to NEFT as there is no concept of Interbank in NEFT. This message formats would replace the current R42 used in current RTGS.
*Corresponds to R42 in current RTGS.
Reserve Bank of India ISO Messages, pacs.009.001.03 - FinancialInstitutionCreditTransferV03
1|Page

ISO 20022 Message
Map ping ISO20022 Message - pacs.009.001.03FinancialInstitution CreditTransferV03 Message Item FinancialInstitution CreditTransfer GroupHeader XML tag Description Index ISO RTGS Multi Multi Rules Example Data Type
<FinInstn CdtTrf> <GrpHdr >
Root tag
Set of characteristics shared by all individual transactions included in the message. Point to point reference, as assigned by the instructing party, and sent to the next party in the chain to unambiguously identify the message. Usage: The instructing party has to make sure that MessageIdentificatio n is unique per instructed party for a pre-agreed period.
1.0
[1..1] [1..1]
GROUP HEADER - GROUP HEADER
MessageIdentificati on
Message Identification
<MsgId>
1.1
[1..1] [1..1]
Uniquely identifies message Recommend MessageIdentification be structured as: XXXX- Sender IFSC [4] YYYYMMDD - Creation Date Reverse [8] X Channel [1] nnnnnnnnnn- Sequence Number [9] The values of Channel Identification (X) is the same as defined for TransactionIdentification <TxId> Time up to seconds only
local time format (YYYY-MMDDThh:mm:ss.sss) Note on the time format: Beginning / end of calendar day
<MsgId> HDFC201210181000000218</MsgI d>
Max35T ext
Creation Date & Time
CreationDateTime
<CreDtT m>
Date and time at which the message was created.
1.2
[1..1] [1..1]
ISODateT ime
2|Page

00:00:00 = the beginning of a calendar day 24:00:00 = the end of a calendar day
No. of Txs.
NumberOfTransacti ons TotalInterbankSettl ementAmount
<NbOfTx s> <TtlIntrB kSttlmA mt>
Number of transactions
Total amount of money moved between the instructing agent and the instructed agent. (Total Settlement Amount + Currency) Settlement Date
1.4
[1..1] 1..1]
Always 1 for Interbank payment in RTGS Total amount transferred between debtor and creditor.
Max15N umericTe xt Amount
1.6
[0..1] [1..1]
<TtlIntrBkSttlmAmt Ccy='INR'>3400</TtlIntrBkSttlmAmt >
InterbankSettlemen tDate Settlement Information SettlementInformat ion
<IntrBkSt tlmDt> <SttlmInf >
1.7
[0..1] [1..1] [1..1] [1..1]
<IntrBkSttlmDt>2011-0424</IntrBkSttlmDt>
ISODate
Specifies the details on how the settlement of the transaction(s) between the instructing agent and the instructed agent is completed.
Method used to settle the (batch of) payment instructions.
1.8
SettlementMethod
<SttlmMt d>
1.9
[1..1] [1..1]
Must be CLRG (i.e., Settlement done through a payment clearing system) Default is CLRG (e.g., Settlement is
done through a payment clearing system )
Code
Other Codes are: CLRG, COVE, INDA, INGA InstructingAgent <InstgAgt > Agent that instructs the next 1.21 [0..1] [1..1]
3|Page

party in the chain to carry out the (set of) instruction(s). FinancialInstitutionI dentification <FinInstn Id>
Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme. Information used to identify a member within a clearing system.
[1..1]
[1..1]
ClearingSystemMe mberIdentification Member Identification
<ClrSysM mbId> <MmbId >
[0..1]
[1..1]
InstructedAgent
<InstdAgt >
Identification of a member of a clearing system. (IFSC of the Sending participant). Agent that is instructed by the previous party in the chain to carry out the (set of) instruction(s).
Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary
[1..1]
[1..1]
Sender IFSC.
<InstgAgt><FinInstnId><ClrSysMmb Id><MmbId>HDFC0239777</MmbI d></ClrSysMmbId></FinInstnId></I nstgAgt>
Max35Te xt
1.22
[0..1] [1..1]
<FinInstn Id>
[1..1] [1..1]
4|Page

identification scheme.
ClearingSystemMe mberIdentification Member Identification
<ClrSysM mbId> <MmbId>
Information used to identify a member within a clearing system. Identification of a member of a clearing system. (IFSC of the Receiving participant).
[0..1] [1..1]
[1..1] [1..1]
Receiver IFSC
<InstdAgt><FinInstnId><ClrSysMmb Id><MmbId>HDFC0239777</MmbI d></ClrSysMmbId></FinInstnId></I nstdAgt>
Max35Te xt
CreditTransferTran sactionInformation
<CdtTrfT xInf>
CREDIT TRANSFER INFORMATION
PaymentIdentificati on
<PmtId>
InstructionIdentific ation
<InstrId>
Set of elements providing information specific to the individual credit transfer(s). Set of elements used to reference a payment instruction. (Contains references to a payment). Unique identification, as assigned by an instructing party for an instructed party, to unambiguously identify the instruction.
2.0
[1..n] [1..1]
Only one occurrence allowed for Interbank Payment
2.1
[1..1] [1..1]
Payment Identification
2.2
[0..1]
[0..1]
Max35T ext
5|Page

EndToEndIdentifica tion <EndToE ndId>
Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain. Usage: The end-to-end identification can be used for reconciliation or to link tasks relating to the transaction. It can be included in several messages related to the transaction. Usage: In case there are technical limitations to pass on multiple references, the endto-end identification must be passed on throughout the entire end-to-end chain. (Related Reference)
2.3
[1..1] [1..1]
It should follow the 16 digits UTR pattern of the existing RTGS system, identified with the 6 character codeword prefix /XUTR/. The existing UTR format is: The format is: i)Participant System ID (First four Characters of sending Banks IFSC Code) ii)Service Tag (One Character) Example : H for host iii)Unique-ID comprising of Date (Julian date YYDDD) & Sequence Number (6 digits numeric).
Max35Te xt
6|Page

TransactionIdentific ation <TxId>
Unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is passed on, unchanged, throughout the entire interbank chain. Usage: The transaction identification can be used for reconciliation, tracking or to link tasks relating to the transaction on the interbank level. Usage: The instructing agent has to make sure that the transaction identification is unique for a preagreed period.
2.4
[1..1]
[1..1]
Max35Te xt
Payment Information
PaymentTypeInfor mation
<PmtTpI nf>
Set of elements used to further specify the type of transaction. The PmtTpInf block contains the following elements. i) InstructionPriority
2.6
[0..1] [1..1]
7|Page

<InstrPrty> ii) ServiceLevel <SvcLvl> iii) LocalInstrument <LclInstrm> iv) CategoryPurpose <CtgyPurp>
InstructionPriority
<InstrPrt y>
Priority
2.7
[0..1] [1..1]
HIGH / NORM Indicator of the urgency or order of importance that the instructing party would like the instructed party to apply to the processing of the instruction at application level. Priority NORM will result in liquidity Savings. HIGH: Priority Level is high. NORM: Priority Level is normal.
<InstrPrty>HIGH</InstrPrty>
Code
ServiceLevel
<SvcLvl>
Proprietary
<Prtry>
Agreement under which or rules under which the transaction should be processed. Specifies a preagreed service or level of service between the parties, as a proprietary code.
2.9
[0..1] [0..1]
2.11
[0..1]
[1..1]
For RTGS, it will be used to indicate RTGS processing priority in range 00 99. To be used for managing queues by sending bank before settlement.
<SvcLvl> <Prtry> [TTC=xxxx],[PRI=xx] </Prtry> </SvcLvl> For More information, Pl refer to FAQ.
Max35Te xt
LocalInstrument
<LclInstr m>
User community specific instrument. Usage: This element is used to
2.12
[0..1]
[1..1]
8|Page

specify a local instrument, local clearing option and/or further qualify the service or service level. Specifies the local instrument, as a proprietary code. Specifies the high level purpose of the instruction based on a set of pre-defined categories. Usage: This is used by the initiating party to provide information concerning the processing of the payment. It is likely to trigger special processing by any of the agents involved in the payment chain. (Payment purpose must be a value listed in ISO category purpose code)
Proprietary
<Prtry>
2.13
[0..1]
[1..1]
CategoryPurpose
<CtgyPur p>
2.15
[0..1]
[0..1]
Type of local instrument. For RTGS, pacs.009 use: - RTGSFIToFICredit There would be a rule which would make this interbank transaction message as mandatory.
<Prtry>RTGSFIToFICredit </Prtry>
Max35Te xt
9|Page

Code <Cd> Category purpose, as published in an external category purpose code list. 2.16 [1..1] [1..1] FROM ISO 20022External Code list The following codes are available. CASH: CashManagementTransfer CORT: TradeSettlementPayment DIVI: Dividend GOVT: GovernmentPayment HEDG: Hedging INTC: IntraCompanyPayment INTE: Interest LOAN: Loan PENS: PensionPayment SALA: SalaryPayment SECU: Securities SSBE: SocialSecurityBenefit SUPP: SupplierPayment TAXS: TaxPayment TRAD: Trade TREA: TreasuryPayment VATX: ValueAddedTaxPayment WHLD: WithHolding For additional codes, please refer to document ExternalcodeLists_3Q2012_22Oct 2012_v4.xls available at www.iso20222.org Banks to suggest additional India Specific codes . Amount transferred between participants <Cd>CASH</Cd> Default code may be CASH. Code
Interbank Settlement Amt
InterbankSettleme ntAmount
<IntrBkSt tlmAmt>
Amount of money moved between the instructing agent and the instructed agent. (Settlement Amount +
2.18
[1..1]
[1..1]
<IntrBkSttlmAmt Ccy='INR'>3400</IntrBkSttlmAmt>
Amount
10 | P a g e

Currency)
Debtor FinancialInstitutionI dentification
<Dbtr> <FinInstn Id>
Debtor (ORDERING INSTITUTION)
<ClrSysM mbId>
<MmbId >
ORDERING INSTITUTION Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme. Information used to identify a member within a clearing system. Identification of a member of a clearing system.
(IndianFinancialSyst emCodeIdentifier for participants / Name and Identification for non Participants is mandatory).
2.40
[1..1] [1..1]
[1..1] [1..1]
[0..1]
[1..1]
[1..1]
[1..1]
<Dbtr><FinInstnId><ClrSysMmbId> <MmbId>HDFC0239777</MmbId>< /ClrSysMmbId></FinInstnId></Dbtr >
Max35Te xt
Name
<Nm>
Name by which an agent is known and which is usually used to identify that
[0..1]
[0..1]
<Nm>Bank A</Nm>
Max140T ext
11 | P a g e

agent. (Ordering Institution Name). Financial institution that receives an amount of money from the financial institutional debtor. (Beneficiary Institution identification). Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme.
The FinInstnId block contains the following elements:
i) ClearingSystemMembe rIdentification <ClrSysMmbId> II) Name <Nm> iii) PostalAddress <PstlAdr> iv) Other <Othr>
Creditor
<Cdtr>
2.46
[1..1]
[1..1]
Creditor (BENEFICIARY INSTITUTION)
<FinInstn Id>
[1..1]
[1..1]
<ClrSysM mbId>
Information used to identify a
[0..1]
[1..1]
12 | P a g e

member within a clearing system. Member Identification <MmbId> Identification of a member of a clearing system. (IndianFinancialSy stemCodeIdentifie r for participants / Name and Identification for non Participants is mandatory) Name by which an agent is known and which is usually used to identify that agent. (Beneficiary Institution Name)
Information that locates and identifies a specific address, as defined by postal services. (Beneficiary Institution Postal Address)
[1..1]
[1..1]
<Cdtr><FinInstnId><ClrSysMmbId>< MmbId>HDFC0239777</MmbId></ ClrSysMmbId></FinInstnId></Cdtr>
Max35Te xt
Name
<Nm>
[0..1]
[0..1]
<Nm>Bank b</Nm>
Max140T ext
PostalAddress
<PstlAdr>
[0..1]
[0..1]
AddressLine
<AdrLine>
Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
[0..7]
[0..4]
Number of occurrence is restricted to 4
<AdrLine>Boulevard Road</AdrLine>
Max70Te xt
13 | P a g e

Other <Othr>
Unique identification of an agent, as assigned by an institution, using an identification scheme. (Used when correspondents are involved).
[0..1]
[0..1]
Identification
<Id>
Identification assigned by an institution.

Unambiguous identification of the account of the creditor to which a credit entry will be posted as a result of the payment transaction. (Beneficiary Customer account identification). Unique and unambiguous identification for the account between the account owner and the account servicer. (Account number of Beneficiary).
[1..1]
[1..1]
Max35Te xt
CreditorAccount
<CdtrAcct >
2.47
[0..1]
[0..1]
Identification
<Id>
[1..1]
[1..1]
Other
<Othr>
Unique identification of an account, as assigned by the account servicer,
[1..1]
[1..1]
14 | P a g e

using an identification scheme. Identification assigned by an institution. Remittance Information Remittance Information 140 characters up to 4 can be used Sender to Receiver Information
Identification
<Id>
[1..1]
[1..1]
It must be used for recording account number for the beneficiary bank for STP process.
<CdtrAcct><Id><Othr><Id>0510085 </Id></Othr></Id></CdtrAcct>
Max34Te xt"
Remittance Information
RemittanceInforma <RmtInf> tion Unstructured <Ustrd>
2.55 2.56
[0..1] [0..n]
[0..1] [0..4] Size restricted to a maximum of 4 repeats of 140 characters. Max140T ext
15 | P a g e

Multilateral Net Settlement Batch (MNSB) Request *
ISO message pacs.009.001.03 FinancialInstitutionCreditTransferV03 is used for defining the MNSB request. If clearing member in debit, the credit leg will have the clearing house identifier and vice versa.
This message formats would replace the current R12 used in current RTGS.
ISO 2002 Message
Reserve Bank of India ISO Messages, pacs.009.001.03 FinancialInstitutionCreditTransferV03
1|Page

ISO20022 Message pacs.009.001.03 FIToFICustomerCreditT ransferV03 Message Item XML tag Description Index ISO Multi RTGS Multi
Rules
Example
Data Type
GroupHeader
<FinInstnCd tTrf> <GrpHdr>
Root tag Fields common to all the transaction in the message Point to point reference, as assigned by the instructing party, and sent to the next party in the chain to unambiguously identify the message. Usage: The instructing party has to make sure that MessageIdentificatio n is unique per instructed party for a pre-agreed period. 1.0
[1..1] [1..1]
[1..1] [1..1]
<MsgId>
1.1
[1..1]
[1..1]
<MsgId> CCIL201210181000000218</MsgId>
Max35Text
CreationDateTime
<CreDtTm>
Date and time at which the message was created.
1.2
[1..1]
[1..1]
NumberOfTransaction s
<NbOfTxs>
Number of individual
1.4
[1..1]
[1..1]
Time upto seconds only. Date & time format: YYYY-MM-DDThh:mm:sss 00:00:00 = the beginning of a calendar day. 24:00:00 = the end of a calendar day. Equal to number of participants in the batch.
ISODateTime
Max15Numeri cText
2|Page

Rules
Example
Data Type
TotalInterbankSettlem entAmount
<TtlIntrBkS ttlmAmt>
transactions contained in the message. Total amount of money moved between the instructing agent and the instructed agent. Total Settlement Amount + Currency
Settlement Date will settle only current day Specifies the details on how the settlement of the transaction(s) between the instructing agent and the instructed agent is completed. Method used to settle the (batch of) payment instructions.
1.6
[0..1]
[1..1]
<TtlIntrBkSttlmAmt Ccy='INR'>3400.00</TtlIntrBkSttlmAmt>
Amount
InterbankSettlementD ate SettlementInformation
<IntrBkSttl mDt> <SttlmInf>
1.7
[0..1]
[1..1]
Value date of payment must be same as RTGS date. Mandatory in RTGS implementation
<IntrBkSttlmDt>2011-04-24</IntrBkSttlmDt>
ISODate
1.8
[1..1]
[1..1]
SettlementMethod
<SttlmMtd>
1.9
[1..1]
[1..1]
Must be CLRG (i.e., Settlement done through a payment clearing system). The Code CLRG should be default. Other Codes are: CLRG, COVE, INDA, INGA
Code
InstructingAgent
<InstgAgt>
Agent that instructs the next party in the
1.21
[0..1]
[1..1]
3|Page

Rules
Example
Data Type
chain to carry out the (set of) instruction(s).
FinancialInstitutionId entification ClearingSystemMem berIdentification Member Identification InstructedAgent
<FinInstnId > <ClrSysMm bId> <MmbId>
[1..1] [0..1]
[1..1] [1..1] [1..1] Sender IFSC <InstgAgt><FinInstnId><ClrSysMmbId><M mbId>CCIL0PI0001</MmbId></ClrSysMm bId></FinInstnId></InstgAgt> Max35Text
IFSC of the Sending participant

Agent that is instructed by the previous party in the chain to carry out the (set of) instruction(s). Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme. Information used to identify a member within a clearing system. Identification of a member of a clearing system. (IFSC of the Receiving participant) Set of elements providing
[1..1]
<InstdAgt>
1.22
[0..1]
[1..1]
FinancialInstitutionId entification
<FinInstnId >
[1..1]
[1..1]
ClearingSystemMem berIdentification Member Identification
<ClrSysMm bId> <MmbId>
[0..1]
[1..1]
[1..1]
[1..1]
Receiver IFSC
<InstdAgt><FinInstnId><ClrSysMmbId><M mbId>RBIS0RTGS00</MmbId></ClrSysMm bId></FinInstnId></InstdAgt>
Max35Text
CreditTransferTransact ionInformation
<CdtTrfTxInf >
2.0
[1..n]
[1..n]
Multiple occurrence based on number of participants
4|Page

Rules
Example
Data Type
PaymentIdentification
<PmtId>
information specific to the individual credit transfer(s). Set of elements used to reference a payment instruction.
Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain. Usage: The end-to-end identification can be used for reconciliation or to link tasks relating to the transaction. It can be included in several messages related to the transaction. Usage: In case there are technical limitations to pass on multiple references, the end-toend identification must be passed on throughout the entire end-to-end chain. (Related Reference) Unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is passed on, unchanged,
2.1
[1..1]
[1..1]
EndToEndIdentification
<EndToEndI d>
2.3
[1..1]
[1..1]
Max35Text
TransactionIdentificati on
<TxId>
2.4
[1..1]
[1..1]
Use UTR (Unique Transaction Reference) format (22 characters) XXXX- Sender IFSC [4] X-Payment System [1] X-Channel [1]
<TxId> CCILR12012042400000023</TxId> For Further Information, pl refer to FAQ on Channel.
Max35Text
5|Page

Rules
Example
Data Type
throughout the entire interbank chain.
Usage: The transaction identification can be used for reconciliation, tracking or to link tasks relating to the transaction on the interbank level. Usage: The instructing agent has to make sure that the transaction identification is unique for a preagreed period. Main clearing Reference Number for return clearing PaymentTypeInformat ion <PmtTpInf>
YYYYMMDD-Date [8] nnnnnnnn- Sequence Number [8]
Set of elements used to further specify the type of transaction.

Indicator of the urgency or order of importance that the instructing party would like the instructed party to apply to the processing of the instruction.
2.6
[0..1]
[1..1]
InstructionPriority
<InstrPrty>
2.7
[0..1]
[1..1]
HIGH / NORM Priority NORM will result in liquidity Savings. HIGH: Priority Level is high. NORM: Priority Level is normal.
<InstrPrty>NORM</InstrPrty>
Code
6|Page

Rules
Example
Data Type
ServiceLevel
<SvcLvl>
Agreement under which or rules under which the transaction should be processed. Specifies a preagreed service or level of service between the parties, as a proprietary code. User community specific instrument. Usage: This element is used to specify a local instrument, local clearing option and/or further qualify the service or service level.
2.9
[0..1]
[0..1]
Proprietary
<Prtry>
2.11
[0..1]
[1..1]
Used to indicate RTGS processing priority in range 00 99. To be used for managing queues by sending bank before settlement.
Max35Text
LocalInstrument
<LclInstrm>
2.12
[0..1]
[1..1]
Proprietary
<Prtry>
Specifies the local instrument, as a proprietary code.
2.13
[0..1]
[1..1]
Type of local instrument. For RTGS, pacs.009 use: -RTGSNetSettlementXXzNN Where XX is the clearing type which may take values GC, IB, FX, MC, SE, OT & so on. z is the indicator which may take values C Original, R-Return, L-Last Return.
<Prtry> RTGSNetSettlementMCC00 </Prtry>
Max35Text
7|Page

Rules
Example
Data Type
NN is the Return serial. GC stands for guaranteed settlement of Securities and CBLO segment. "IB" stands for guaranteed settlement of FOREX segment. "FX" stands for non guaranteed settlement. MC Stands for MICR Clearing. SE stands for non-guaranteed MNSB OT stands for Other MNSB
InterbankSettlementA mount <IntrBkSttlm Amt>
Amount of money moved between the instructing agent and the instructed agent.
Debtor
2.18
[1..1]
[1..1]
Settlement amount.
<IntrBkSttlmAmt Ccy='INR'>3400.00</IntrBkSttlmAmt>
Amount
Debtor
<Dbtr>
2.40
[1..1]
[1..1]
If net credit then RBI-RTGS IFSC. If net debit the Member IFSC If net debit of RBI current account then RBI-CBS IFSC. If net credit of RBI current account then RBI-RTGS IFSC.
<FinInstnId>
Unique and unambiguous identification of a financial institution, as assigned under an
[1..1]
[1..1]
8|Page

Rules
Example
Data Type
internationally recognised or proprietary identification scheme. ClearingSystemMembe rIdentification <ClrSysMm bId>
<MmbId>
Information used to identify a member within a clearing system. Identification of a member of a clearing system.
Unambiguous identification of the account of the debtor to which a debit entry will be made as a result of the transaction. Unique and unambiguous identification for the account between the account owner and the account servicer. Unique identification of an account, as assigned by the account servicer, using an identification scheme. 2.41
[0..1]
[1..1]
[1..1]
[1..1]
<Dbtr><FinInstnId><ClrSysMmbId><MmbId>H DFC0239777</MmbId></ClrSysMmbId></FinIn stnId></Dbtr>
Max35Text
DebtorAccount
<DbtrAcct>
[0..1]
[1..1]
Identification
<Id>
1.1.0
[1..1]
[1..1]
Other
<Othr>
1.1.2
[1..1]
[1..1]
9|Page

ISO20022 Message pacs.009.001.03 FIToFICustomerCreditT ransferV03 Message Item Identification XML tag Description Index ISO Multi RTGS Multi
Rules
Example
Data Type
<Id>
Creditor
<Cdtr>
Identification assigned by an institution. creditor
Max34Text
2.46
[1..1]
[1..1]
If net credit then Member IFSC. If net debit then RBI-RTGS IFSC. If net debit of RBI current account then RBI-RTGS IFSC. If net credit of RBI current account then RBI-CBS IFSC.
<FinInstnId>
Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme.
[1..1]
[1..1]
ClearingSystemMembe rIdentification Member Identification
<ClrSysMm bId> <MmbId>
Identification of a member of a clearing system.

IndianFinancialSyste mCodeIdentifier for participants. Unambiguous identification of the account of the creditor to which a credit entry will be posted as a result of the payment transaction. Unique and unambiguous 2.47
[0..1]
[1..1]
[1..1]
[1..1]
<Cdtr><FinInstnId><ClrSysMmbId><MmbId>HD FC0239777</MmbId></ClrSysMmbId></FinInst nId></Cdtr>
Max35Text
CreditorAccount
<CdtrAcct>
[0..1]
[1..1]
Identification
<Id>
1.1.0
[1..1]
[1..1]
10 | P a g e

Rules
Example
Data Type
Other
<Othr>
identification for the account between the account owner and the account servicer. Unique identification of an account, as assigned by the account servicer, using an identification scheme. Identification assigned by an institution. Remittance Information
1.1.2
[1..1]
[1..1]
Identification
<Id>
1.1.3
[1..1]
[1..1]
Max34Text
RemittanceInformatio n Unstructured
<RmtInf> <Ustrd>
2.75
[0..1]
[0..1]
Remittance 2.76 [0..n] [0..4] Size restricted to a maximum of 4 Information 140 repeats of 140 characters. characters up to 4 can be used Sender to Receiver Information Note:- [1..1] -> Mandatory; [0..1] -> Optional ; [1..n] -> Mandatory and n times repeated ; [0..n] -> Optional and n times repeated;
Max140Text
11 | P a g e
Own Account Transfer (OAT)*

ISO message pacs.009.001.03 FinancialInstitutionCreditTransferV03 is used for defining the Own account transfer in RTGS.
This message formats would replace the current R10 used in current RTGS.
Message fields description ISO Business Application Header Business Application Header (Refer related documentation RBI_NG_RTGS_ISO20022_BusinessApplicationHeader) ISO 20022 Message
ISO20022 Message pacs.009.001.03 FIToFICustomerCreditTr ansferV03 Message Item XML tag Description Index ISO Multi RTGS Multi
Rules
Example
Data Type
GroupHeader
<FinInstnCd tTrf> <GrpHdr>
Root tag Set of characteristics 1.0 [1..1] [1..1]
1|Page
ISO20022 Message pacs.009.001.03 FIToFICustomerCreditTr ansferV03 Message Item
XML tag
Description
Index
ISO Multi
RTGS Multi
Rules
Example
Data Type
shared by all individual transactions included in the message. MessageIdentification <MsgId>

Point to point reference, as assigned by the instructing party, and sent to the next party in the chain to unambiguously identify the message. Usage: The instructing party has to make sure that MessageIdentifica tion is unique per instructed party for a pre-agreed period.
1.1
[1..1]
[1..1]
<MsgId> HDFC201210181000000218</MsgId>
Max35T ext
(Uniquely identifies the message) CreationDateTime <CreDtTm> Date and time at which the message was created.
Number of individual transactions contained in the message.
1.2
[1..1]
[1..1]
Time upto seconds only
ISODateTi me
NumberOfTransactions
<NbOfTxs>
1.4
[1..1]
[1..1]
Always 1 for own account transfer
Max15Nu mericText
TotalInterbankSettleme
<TtlIntrBkSt
Total amount
1.6
[0..1]
[1..1]
Amount
2|Page
ISO20022 Message pacs.009.001.03 FIToFICustomerCreditTr ansferV03 Message Item ntAmount
XML tag
Description
Index
ISO Multi
RTGS Multi
Rules
Example
Data Type
tlmAmt>
InterbankSettlementDa te SettlementInformation
<IntrBkSttl mDt> <SttlmInf>
SettlementMethod
<SttlmMtd>
of money moved between the instructing agent and the instructed agent. (Total Settlement Amount + Currency) Settlement Date will settle only current day. Specifies the details on how the settlement of the transaction(s) between the instructing agent and the instructed agent is completed. Method used to settle the (batch of) payment instructions.
1.7
[0..1]
[1..1]
ISODate
1.8
[1..1]
[1..1]
1.9
[1..1]
[1..1]
Must be CLRG (i.e., Settlement done through a payment clearing system). Default Code will be CLRG. Other Codes are: CLRG, COVE, INDA, INGA Mandatory in RTGS implementation IFSC code of the bank initiating the Own A/C transfer.
Code
InstructingAgent
<InstgAgt >
Agent that instructs the next party in the chain to carry out the (set of)
1.21
[0..1]
[1..1]
3|Page
XML tag
Description
Index
ISO Multi
RTGS Multi
Rules
Example
Data Type
FinancialInstitutionIde ntification
<FinInstnI d>
ClearingSystemMemb erIdentification
<ClrSysM mbId>
instruction(s). Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme. Information used to identify a member within a clearing system.
[1..1]
[1..1]
[0..1]
[1..1]
Member Identification InstructedAgent
<MmbId>
IFSC of the Sending participant

Agent that is instructed by the previous party in the chain to carry out the (set of) instruction(s). Unique and unambiguous identification of a financial institution, as assigned under an internationally
[1..1]
[1..1]
<InstgAgt><FinInstnId><ClrSysMmbId><MmbI d>HDFC0239777</MmbId></ClrSysMmbId>< /FinInstnId></InstgAgt> Mandatory in RTGS Implementation
Max35Te xt
<InstdAgt >
1.22
[0..1]
[1..1]
IFSC of the RBI.
FinancialInstitutionIde ntification
<FinInstnI d>
[1..1]
[1..1]
4|Page
XML tag
Description
Index
ISO Multi
RTGS Multi
Rules
Example
Data Type
ClearingSystemMemb erIdentification
<ClrSysM mbId>
CreditTransferTransacti onInformation
<MmbId>
recognised or proprietary identification scheme. Information used to identify a member within a clearing system. IFSC of the Receiving participant Set of elements providing information specific to the individual credit transfer(s). Set of elements used to reference a payment instruction. 2.0
[0..1]
[1..1]
[1..1]
[1..n]
[1..1]
[1..1] Only one occurrence allowed for own account transfer
<InstdAgt><FinInstnId><ClrSysMmbId><MmbI d>RBIS0000001</MmbId></ClrSysMmbId></ FinInstnId></InstdAgt>
Max35Te xt
<CdtTrfTxIn f>
PaymentIdentification
<PmtId>
2.1
[1..1]
[1..1]
InstructionIdentificati on
<InstrId>
Unique identification, as assigned by an instructing party for an instructed party, to unambiguousl y identify the instruction.
2.2
[0..1]
[0..1]
Max35T ext
5|Page
XML tag
Description
Index
ISO Multi
RTGS Multi
Rules
Example
Data Type
EndToEndIdentificatio n
<EndToEn dId>
Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-toend chain. Usage: The endto-end identification can be used for reconciliation or to link tasks relating to the transaction. It can be included in several messages related to the transaction. Usage: In case there are technical limitations to pass on multiple references, the end-to-end identification must be passed
2.3
[1..1] [1..1]
Max35Te xt
6|Page
XML tag
Description
Index
ISO Multi
RTGS Multi
Rules
Example
Data Type
on throughout the entire endto-end chain. (Related Reference) TransactionIdentificatio n

<TxId> Unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is passed on, unchanged, throughout the entire interbank chain. Usage: The transaction identification can be used for reconciliation, tracking or to link tasks relating to the transaction on the interbank level. Usage: The instructing agent has to make sure that the transaction identification is unique for a preagreed period.
2.4
[1..1]
[1..1]
Max35Te xt
PaymentTypeInformati on
<PmtTpInf>
Set of elements used to further specify the type of transaction.
2.6
[0..1]
[1..1]
Priority is mandatory in RTGS implementation.
7|Page
ISO20022 Message pacs.009.001.03 FIToFICustomerCreditTr ansferV03 Message Item InstructionPriority
XML tag
Description
Index
ISO Multi
RTGS Multi
Rules
Example
Data Type
<InstrPrty>
Indicator of the urgency or order of importance that the instructing party would like the instructed party to apply to the processing of the instruction. Agreement under which or rules under which the transaction should be processed. Specifies a preagreed service or level of service between the parties, as a proprietary code. User community specific instrument. Usage: This element is used to specify a local instrument, local clearing option and/or
2.7
[0..1]
[1..1]
HIGH / NORM Priority NORM will result in liquidity Savings. HIGH: Priority Level is high. NORM: Priority Level is normal.
<InstrPrty>NORM</InstrPrty>
Code
ServiceLevel
<SvcLvl>
2.9
[0..1]
[0..1]
Proprietary
<Prtry>
2.11
[0..1]
[1..1]
For RTGS used to indicate RTGS processing priority in range 00 99. To be used for managing queues by sending bank before settlement.
Max35Te xt
LocalInstrument
<LclInstrm >
2.12
[0..1]
[1..1]
8|Page
XML tag
Description
Index
ISO Multi
RTGS Multi
Rules
Example
Data Type
Proprietary
<Prtry>
InterbankSettlementA mount
<IntrBkSttl mAmt>
Debtor FinancialInstitutionIdent ification
<Dbtr> <FinInstnId >
further qualify the service or service level. Specifies the local instrument, as a proprietary code. Amount of money moved between the instructing agent and the instructed agent. ORDERING INSTITUTION
Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme. Information used to identify a member within a clearing system.
2.13
[0..1]
[1..1]
Type of local instrument. For RTGS, pacs.009 use: - RTGSOwnAccTtransfer

Amount transferred between accounts
<Prtry> RTGSOwnAccTtransfer</Prtry>
Max35Te xt
2.18
[1..1]
[1..1]
<IntrBkSttlmAmt Ccy='INR'>3400.00</IntrBkSttlmAmt>
Amount
2.40
[1..1] [1..1]
[1..1] [1..1]
ClearingSystemMemberI dentification Member Identification
<ClrSysM mbId> <MmbId>
[0..1]
[1..1]

Unambiguous identification of the account of the debtor to which a
[1..1]
[1..1]
IFSC of participant sending the payment request Mandatory in RTGS implementation
<Dbtr><FinInstnId><ClrSysMmbId><MmbId>HDFC 0239777</MmbId></ClrSysMmbId></FinInstnId>< /Dbtr>
Max35Tex t
DebtorAccount
<DbtrAcct >
2.41
[0..1]
[1..1]
9|Page
XML tag
Description
Index
ISO Multi
RTGS Multi
Rules
Example
Data Type
Identification
<Id>
Other
<Othr>
Identification
<Id>
Currency
<Ccy>
debit entry will be made as a result of the transaction. Unique and unambiguous identification for the account between the account owner and the account servicer. Unique identification of an account, as assigned by the account servicer, using an identification scheme. Identification assigned by an institution. (Account Number) Identification of the currency in which the account is held.
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
From account of participant
<DbtrAcct><Id><Othr><Id>34545353</Id></Othr ></Id></DbtrAcct>
Max34Tex t
[0..1]
[0..1]
<Ccy>INR</Ccy>
Code
Creditor
<Cdtr>
Beneficiary Institution identification

Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification
2.46
[1..1]
[1..1]
FinancialInstitutionIdent ification
<FinInstnId >
[1..1]
[1..1]
10 | P a g e
XML tag
Description
Index
ISO Multi
RTGS Multi
Rules
Example
Data Type
scheme.
ClearingSystemMemberI <ClrSysMm dentification bId> Member Identification <MmbId>
Information used to identify a member within a clearing system.
[0..1]
[1..1]

Unambiguous identification of the account of the creditor to which a credit entry will be posted as a result of the payment transaction. Unique and unambiguous identification for the account between the account owner and the account servicer. Unique identification of an account, as assigned by the account servicer, using an identification scheme.
[1..1]
[1..1]
IFSC of participant receiving the payment request. Mandatory in RTGS implementation
<Cdtr><FinInstnId><ClrSysMmbId><MmbId>RBIS0 000001</MmbId></ClrSysMmbId></FinInstnId></ Cdtr>
Max35Tex t
CreditorAccount
<CdtrAcct>
2.47
[0..1]
[1..1]
Identification
<Id>
[1..1]
[1..1]
Other
<Othr>
[1..1]
[1..1]
Identification
<Id>
Identification assigned by an institution. (Account Number)

Identification of
[1..1]
[1..1]
To account of participant
<CdtrAcct><Id><Othr><Id>546545353</Id></Othr ></Id></CdtrAcct>
Max34Tex t
Currency
<Ccy>
[0..1]
[0..1]
<Ccy>INR</Ccy>
Code
11 | P a g e
XML tag
Description
Index
ISO Multi
RTGS Multi
Rules
Example
Data Type
the currency in which the account is held.
RemittanceInformation Unstructured
<RmtInf> <Ustrd>
Remittance Information Remittance Information 140 characters up to 4 can be used.
2.55 2.56
[0..1] [0..n]
[0..1] [0..4]
Max140T ext
12 | P a g e
ISO20022 standard Message Implementation Payment Return

ISO message pacs.004.001.03 PaymentReturnV03 Bank-to-Bank message, settlement already completed in NG-RTGS. Function of the pacs.004 message is sent by an agent to the previous agent in the payment chain to undo a payment previously settled.
This message formats would replace the current R42 for return & N07 in NEFT messages. *Corresponds to R42 in current RTGS & N07 in NEFT messages The ISO 20022 Business Message consists of two parts: (1) ISO 20022 Business Appl. Header (2) ISO 20022 Messages
Business Application Header is a business header and should not be confused with a file or transport header. It is created before the transport routing header is applied to the business message and is retained after the transport header is removed. So any parties between the two business applications that don't perform a business function are not mentioned in the BAH. Such 'technical' middle men don't open or change the Business Message; they only forward it to the correct business application. Although the BAH is not the transport header, data in the BAH can be used by transport applications to determine the routing header since it does contain the business sender, receiver and document details. It can also be used by the business applications to determine the appropriate process to perform on the business message.
Message fields description ISO Business Application Header Business Application Header (Refer related documentation RBI_NG_RTGS_ISO20022_BusinessApplicationHeader) ISO 20022 Message
Reserve Bank of India ISO message pacs.004.001.03 PaymentReturnV03
1|P a g e

Message Item ISO20022 Messages pacs.004.001.03 PaymentReturnV03 Message root GroupHeader XML tag Description Index ISO Multi NEFT/ RTGS multip licity Rules Example Data Type
<PmtRtr> <GrpHdr>
<MsgId>
Root tag for PaymentReturn Message Set of characteristics shared by all individual transactions included in the message. Point to point reference, as assigned by the instructing party and sent to the next party in the chain, to unambiguously identify the message. Usage: The instructing party has to make sure that MessageIdentification is unique per instructed party for a pre-agreed period.
[1..1] 1.0 [1..1]
1.1
[1..1]
[1..1]
<MsgId> HDFC201210181000 000218</MsgId>
CreationDateTime NumberOfTransactions
<CreDtTm> <NbOfTxs>
Date and time at which the message was created. Number of individual transactions contained in the message.
1.2 1.7
[1..1] [1..1]
[1..1] [1..1]
ISODateT ime Max15N umericTe xt
2|P a g e

Message Item ISO20022 Messages pacs.004.001.03 PaymentReturnV03 TotalReturnedInterban kSettlementAmount XML tag Description Index ISO Multi NEFT/ RTGS multip licity [1..1] Rules Example Data Type
<TtlRtrdIntrBkSttl mAmt>
Total amount of money moved between the instructing agent and the instructed agent in the return message.
1.10
[0..1]
Amount
InterbankSettlementDat e SettlementInformation
<IntrBkSttlmDt>
1.11
[0..1]
[1..1]
ISO Date
<SttlmInf>
SettlementMethod
<SttlmMtd>
Specifies the details on how the settlement of the transactions between the instructing agent and the instructed agent is completed. Method used to settle payments
1.12
[1..1]
[1..1]
[1..1]
[1..1]
Default value CLRG Other Codes are: CLRG, COVE, INDA, INGA
<SttlmMtd>CLRG</S ttlmMtd>
Code
OriginalGroupInform ation OriginalMessageIdentif ication
<OrgnlGrpInf>
<OrgnlMsgId>
OriginalMessageNameI dentification OriginalCreationDateTi me TransactionInformatio n
<OrgnlMsgNmId > <OrgnlCreDtTm> <TxInf>
Information concerning the original group of transactions, to which the message refers. Point to point reference, as assigned by the original instructing party, to unambiguously identify the original message. Specifies the original message name identifier to which the message refers. Date and time at which the original message was created. Information concerning the original transactions, to which the return message refers.
2.0
[0..1]
[0..1]
2.1
[1..1]
[1..1]
Max35T ext
2.2
[1..1]
[1..1]
Max35T ext ISODateT ime
2.3 3.0
[0..1] [0..n]
[0..1] [1..10] NEFT [1..1] RTGS
3|P a g e

Message Item ISO20022 Messages pacs.004.001.03 PaymentReturnV03 ReturnIdentification XML tag Description Index ISO Multi NEFT/ RTGS multip licity [1..1] Rules Example Data Type
<RtrId>
Transaction Identification, as assigned by an returning party for an sending party, to unambiguously Identify the returned transaction.
3.1
[0..1]
Transaction Reference Number of 22 Chars of Instucting Party Use UTR (Unique Transaction Reference) format (22 characters) XXXX- Sender IFSC [4] X-Payment System [1] X-Channel [1] YYYYMMDD-Date [8] nnnnnnnn- Sequence Number [8]
Max35T ext
OriginalInstructionIden tification
<OrgnlInstrId>
OriginalEndToEndIdenti fication
<OrgnlEndToEndI d>
OriginalTransactionIde ntification
<OrgnlTxId>
Unique identification, as assigned by the original initiating party, to unambiguously identify the original transaction. Unique identification, as assigned by the original initiating party, to unambiguously identify the original transaction. (Original End to End Identification assigned by the Initiating party). Unique Transaction reference , as assigned by the original first instructing agent(sender), to unambiguously identify the Transaction. This must contain Transaction Reference Number of the received inward credit message at bank branch that is returned.
3.6
[0..1]
[0..1]
Max35Te xt
3.7
[0..1]
[1..1]
Max35Te xt
3.8
[0..1]
[1..1]
Max35Te xt
4|P a g e

Message Item ISO20022 Messages pacs.004.001.03 PaymentReturnV03 ReturnedInterbankSettl ementAmount XML tag Description Index ISO Multi NEFT/ RTGS multip licity [1..1] Rules Example Data Type
<RtrdIntrBkSttlmA mt>
InstructingAgent
<InstgAgt>
<FinInstnId>
ClearingSystemMembe rIdentification MemberIdentification
<ClrSysMmbId> <Mmbid>
InstructedAgent
<InstdAgt>
<FinInstnId>
Amount being returned between instructing and instructed parties on account of returned transaction. This amount should be same as the amount requested by the originator as NEFT doesnt have concept of settling a part amount and returning the rest. Sender IFSC .This should be the IFSC that is sending the return request/message and not the branch that has sent the original instruction Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme. Information used to identify a member within a clearing system. Identification of a member of a clearing system. (This should contain the Sender IFSC of the transaction i.e., branch IFSC code). Receiver IFSC .This should be the IFSC to which the return transaction is being sent i.e. the IFSC which is receiving the return message Unique and unambiguous identification of a financial institution, as assigned under an
3.11
[1..1]
Amount
3.20
[0..1]
[1..1]
[1..1]
[1..1]
[0..1] [1..1]
[1..1] [1..1] Sending Branchs IFSC Max35Te xt
3.21
[0..1]
[1..1]
[1..1]
[1..1]
5|P a g e

Message Item ISO20022 Messages pacs.004.001.03 PaymentReturnV03 XML tag Description Index ISO Multi NEFT/ RTGS multip licity Rules Example Data Type
ClearingSystemIdentific ation MemberIdentification
<ClrSysMmbId> <Mmbid>
internationally recognised or proprietary identification scheme. Information used to identify a member within a clearing system. Identification of a member of a clearing system. (This should contain the Receiver IFSC of the transaction i.e. beneficiary branch where the account needs to be credited back because of return request).
Provides detailed information on the return reason.
[0..1] [1..1]
[1..1] [1..1] Beneficiary branchs IFSC Max35Te xt
ReturnReasonInformati on
<RtrRsnInf>
3.22
[0..n]
[1..1]
[This block RtrRsnInf consists of elements

i) Originator <Orgtr> ii) Reason <Rsn> iii) AdditionalInformation <AddtlInf> ]
Originator
<Orgtr>
Party that issues the return. (Originator of Remittance) [This message item is composed of the following PartyIdentification43 element(s). i.e., i) Name, ii) Postal Address, iii)Contact Details] Name by which a party is known and which is usually used to identify that party. Information that locates and
3.23
[0..1]
[0..1]
Name
<Nm>
[0..1]
[0..1]
Max140Te xt
PostalAddress
<PstlAdr>
[0..1]
[0..1]
6|P a g e

AddressLine
<AdrLine>
ContactDetails
<CtctDtls>
MobileNumber
<MobNb>
EmailAddress Reason Code
<EmailAdr> <Rsn> <Cd>
identifies a specific address, as defined by postal services. Information that locates and identifies a specific address, as defined by postal services, presented in free format text. Set of elements used to indicate how to contact the party. This message item consists of items i) MobileNumber <MobNb> ii) Email Address <EmailAdr] Collection of information that identifies a mobile phone number, as defined by telecom services. Address for electronic mail (e-mail). Specifies the reason for the return. Reason for the return, as published in an external reason code list. 3.24
[0..7]
[0..4]
Max70Tex t
[0..1]
[0..1]
[0..1]
[0..1]
PhoneNu mber Max2048 Text <Rsn><Cd>NARR</Cd></Rsn> Example:NARR: Narrative AC01: Incorrect Account Number AC02: Incorrect Debtor Account Number AC03: Incorrect Creditor Account Number AC04: Closed Account Number AC06: Blocked Account AC09: Invalid Account Currency AG07: Unsuccessful Direct Debit AM01: Zero Amount AM04: Insufficient Funds AM05: Duplication AM10: Invalid Control Sum AM12: Invalid Amount
[0..1] [0..1] [1..1]
[0..1] [1..1] [1..1]
Code
7|P a g e

BE04: Missing Creditor Address BE06: Unknown End Customer BE18: Invalid Contact Details CUST: Cancellation requested by the Debtor DS02: An Authorised user has cancelled the order DS04: Order was rejected by the bank side (for reasons concerning contents) DS06: Signer Certificate Revoked DS0D: SignerCertificateNotValid
For Other Reason Codes are: NARR, BE01, BE06, CUST, . For detail pl refer to External CodeLists_3Q2012_22Oct201 2_v4 AdditionalInformation <AddtlInf>
Further details on the return reason
3.27
[0..n]
[1..1]
<AddtlInf>RETURN DUE TO WRONG ACCOUNT CREDIT</AddtlInf>
Max105T ext
8|P a g e
ISO20022 standard Message Implementation Payment Status Report *

ISO message pacs.002.001.04, FIToFIPaymentStatusReportV04 Applicable Areas: RTGS 1) For defining MNSB Response in RTGS. 2) For defining Own Account Transfer Response in RTGS 3) Will also be used by the NG-RTGS as a response to the receipt by the NG-RTGS of an invalid pacs.004, pacs,008, pacs.009.
This message formats would replace the current R13 used in current RTGS for MNSB response & R40 used in Current RTGS for Own A/c Transfer (OAT) response.
*Corresponds to R13 & R 40 in current RTGS.
Business Application Header is a business header and should not be confused with a file or transport header. It is created before the transport routing header is applied to the business message and is retained after the transport header is removed. So any parties between the two business applications that don't perform a business function are not mentioned in the BAH. Such 'technical' middle men don't open or change the Business Message; they only forward it to the correct business application. Although the BAH is not the transport header, data in the BAH can be used by transport applications to determine the routing header since it does contain the business sender, receiver and document details. It can also be used by the business applications to determine the appropriate process to perform on the business message.
Message fields description ISO Business Application Header
Reserve Bank of India

ISO message pacs.002.001.04, FIToFIPaymentStatusReportV04
1|Page

Business Application Header (Refer related documentation RBI_NG_RTGS_ISO20022_BusinessApplicationHeader)
ISO 20022 Message

ISO20022 Message pacs.002.001.04 FIToFIPaymentStatusRep ortV04 Message Item XML tag Description Index ISO Multi RTGS
Rules
Example
Data Type
GroupHeader
<FIToFIPmtSts Rpt> <GrpHdr>
Root tag Fields common to all the transaction in the message Point to point reference, as assigned by the instructing party, and sent to the next party in the chain to unambiguously identify the message. Usage: The instructing party has to make sure that MessageIdentificat ion is unique per instructed party for a pre-agreed period. Date and time at which the message was created. 1.0
[1..1] [1..1]
[1..1] [1..1]
<MsgId>
1.1
[1..1]
[1..1]
Uniquely identifies message Recommend MessageIdentification be structured as: XXXX- Sender IFSC [4] YYYYMMDD - Creation Date Reverse [8]
<MsgId> HDFC201210181000000218</MsgId>
Max35Te xt
X Channel
nnnnnnnnn- Sequence Number
[1] [9]
The values of Channel Identification (X) is the same as defined for TransactionIdentification <TxId>
CreationDateTime
<CreDtTm>
1.2
[1..1]
[1..1]
Time upto seconds only Local time format (YYYY-MMDDThh:mm:ss). Beginning / end of calendar day 00:00:00 = the beginning of a calendar day
ISODateT ime

2|Page

ISO20022 Message pacs.002.001.04 FIToFIPaymentStatusRep ortV04 Message Item OriginalGroupInformatio nAndStatus XML tag Description Index ISO Multi RTGS
Rules
Example
Data Type
24:00:00 = the end of a calendar day <OrgnlGrpInfA ndSts>
Original group information concerning the group of transactions, to which the status report message refers to.
Point to point reference, as assigned by the original instructing party, to unambiguously identify the original message.
This msg element is part of OrgnlGrpInfAndSts block.
2.0
[1..1]
[1..1]
OriginalMessageIdentific ation
<OrgnlMsgId>
2.1
[1..1]
[1..1]
Max35Te xt
OriginalMessageNameId entification
<OrgnlMsgNmI d>
Specifies the original message name identifier to which the message refers.
2.2
[1..1]
[1..1]
<OrgnlMsgNmId>pacs.009.001.03</Orgn lMsgNmId>
Max35Te xt
OriginalCreationDateAnd Time
<OrgnlCreDtTm >
Date & time at which the original message was created.
2.3
[0..1]
[1..1]
<OrgnlCreDtTm>2011-0424T09:30:32</OrgnlCreDtTm>
ISODateT ime

3|Page

Rules
Example
Data Type
GroupStatus
<GrpSts>
Specifies the status of a group of transactions. Status codeACSC/ACSP/ACTC/ ACPT/PDNG/RCVD /RJCT/ACCR /ACWC.
2.6
[0..1]
[1..1]
Mandatory in RTGS implementation ACSC: AcceptedSettlementCompleted ACSP: AcceptedSettlementInProcess ACTC: AcceptedTechnicalValidation ACCR: AcceptedCancellationRequest ACPT: Accepted ACWC: AcceptedWithChange PDNG: Pending RCVD: Received RJCT: Rejected For details on status code, pl refer to para 2.6 of documentation Payment Clearing & Settlement Maintenance 2012 by ISO. Repeats only once
<GrpSts>ACSC</GrpSts>
Code
StatusReasonInformation
<StsRsnInf>
Provides detailed information on the status reason. (Reason for success / failure).
2.7
[0..n]
[0..1]
Reason
<Rsn>
Specifies the reason for the status report.
2.9
[0..1]
[1..1]

4|Page

ISO20022 Message pacs.002.001.04 FIToFIPaymentStatusRep ortV04 Message Item Proprietary XML tag Description Index ISO Multi RTGS
Rules
Example
Data Type
<Prtry>
Reason for the status, in a proprietary form.

(Actual reason code and reason description)
2.11
[1..1]
[1..1]
/!3x Reason desc
/012 No Liquidity
Max35Te xt
TransactionInformation AndStatus
<TxInfAndSts>
Original Transaction Reference
<OrgnlTxRef>
InterbankSettlementAmo unt
<IntrBkSttlmA mt>
Information concerning the original transactions, to which the status report message referred to. Key elements used to identify the original transaction that is being referred to. Amount of money moved between the instructing agent and the instructed agent. This msg element is the part of
OrgnlTxRef block
3.0
[0..*]
[1..1]
3.20
[0..1]
[1..1]
Mandatory in RTGS implementation for Net Clearing response
3.21
[0..1]
[1..1]
<IntrBkSttlmAmt Ccy="INR">10000.00</IntrBkSttlmAmt>
Amoun t
PaymentTypeInformatio n
<PmtTpInf>
Set of elements used to further specify the type of transaction. This msg element is the part of
[0..1]
[1..1]

5|Page

ISO20022 Message pacs.002.001.04 FIToFIPaymentStatusRep ortV04 Message Item LocalInstrument XML tag Description Index ISO Multi RTGS
Rules
Example
Data Type
OrgnlTxRef block.
<LclInstrm>
User community specific instrument. Usage:This element is used to specify a local instrument, local clearing option and/or further qualify the service or service level.
[0..1]
[1..1]
Proprietary
<Prtry>
Specifies the local instrument, as a proprietary code.
[0..1]
[1..1]
Type of Local Instrument. - RTGSFIToFICredit' or -RTGSFIToFICustomerCredit or -'RTGSOwnAccTtransfer' or - RTGSPaymentReturn or -'RTGSNetSettlementXXzNN' Where 'XX' is the clearing type which may take values 'GC', 'IB', 'FX', MC, SE, OT & so on. 'z' is the indicator which may take values C -Original, R-Return, L-Last Return. "NN" is the return serial. "GC" stands for guaranteed settlement of Securities and CBLO segment. "IB" stands for guaranteed settlement of FOREX segment. "FX" stands for non guaranteed settlement. "MC" Stands for MICR Clearing "SE" stands for non-guaranteed MNSB "OT" stands for Other MNSB.
Max35T ext

6|Page

ISO20022 Message pacs.002.001.04 FIToFIPaymentStatusRep ortV04 Message Item Debtor XML tag Description Index ISO Multi RTGS
Rules
Example
Data Type
<Dbtr>
Clearing party / sponsoring institution. This msg element is the part of

OrgnlTxRef block.
3.1.634
[0..1]
[0..1]
Mandatory in RTGS implementation for Own Account Transfer and Net Clearing response
Identification
<Id>
Unique and unambiguous identification of a party.
3.1.647
[0..1]
[1..1]
OrganisationIdentificat ion
<OrgId>
Unique and unambiguous way to identify an organisation.
3.1.648
[1..1]
[1..1]
Other
<Othr>
Unique identification of an organisation, as assigned by an institution, using an identification scheme. Identification assigned by an institution.
Unambiguous identification of the account of the debtor to which a debit entry will be
3.1.650
[0..*]
[1..1]
Identification
<Id>
[1..1] 3.1.651 3.1.677 [0..1]
[1..1]
Max35Te xt Mandatory in RTGS implementation for Own Account
DebtorAccount
<DbtrAcct>
[0..1]

7|Page

Rules
Example
Data Type
made as a result of the transaction. This msg element is the part of

OrgnlTxRef block.
Identification
<Id>
Unique and unambiguous identification for the account between the account owner and the account servicer.
[1..1]
[1..1]
Other
<Othr>
Identification
<Id>
Unique identification of an account, as assigned by the account servicer, using an identification scheme. Identification assigned by an institution.
(Account Number) Account currency
[1..1]
[1..1]
[1..1]
[1..1]
<DbtrAcct><Id><Othr><Id>34545353</Id ></Othr></Id></DbtrAcct>
Max34Te xt
Currency
<Ccy>
[0..1]
[1..1]
For NG-RTGS , INR is the only currency that can be specified.
<Ccy>INR</Ccy>
Code

8|Page

ISO20022 Message pacs.002.001.04 FIToFIPaymentStatusRep ortV04 Message Item Creditor XML tag Description Index ISO Multi RTGS
Rules
Example
Data Type
<Cdtr>
Clearing party / sponsoring institution. This msg element is the part of

OrgnlTxRef block.
3.1.799
[0..1]
[0..1]
Mandatory in RTGS implementation for Own Account Transfer and Net Clearing response
Identification
<Id>
OrganisationIdentificat ion
<OrgId>
Other
<Othr>
Identification
<Id>
CreditorAccount
<CdtrAcct>
Unique and unambiguous identification of a party. Unique and unambiguous way to identify an organisation. Unique identification of an organisation, as assigned by an institution, using an identification scheme. Identification assigned by an institution. Unambiguous identification of the account of the creditor to which a credit entry will be made as a result of the transaction. This msg element is the part of
3.1.812
[0..1]
[1..1]
3.1.813
[1..1]
[1..1]
3.1.815
[0..*]
[1..1]
3.1.816
[1..1]
[1..1]
Max35T ext
Mandatory in RTGS implementation for Own Account
3.1.842
[0..1]
[0..1]

9|Page

ISO20022 Message pacs.002.001.04 FIToFIPaymentStatusRep ortV04 Message Item Identification XML tag Description Index ISO Multi RTGS
Rules
Example
Data Type
OrgnlTxRef block.
<Id>
Other
<Othr>
Identification
<Id>
Currency
<Ccy>
Unique and unambiguous identification for the account between the account owner and the account servicer. Unique identification of an account, as assigned by the account servicer, using an identification scheme. Identification assigned by an institution. (Account Number) Account currency
3.1.843
[1..1]
[1..1]
3.1.845
[1..1]
[1..1]
3.1.846
[1..1]
[1..1]
<CdtrAcct><Id><Othr><Id>34545353</Id ></Othr></Id></CdtrAcct>
Max34Te xt
[0..1]
[1..1]
For NG-RTGS , INR is the only currency that can be specified.
<Ccy>INR</Ccy>
Code

10 | P a g e

NG Rtgiso20022

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NG Rtgiso20022

Uploaded by

Copyright:

Available Formats

ISO20022 standard Message Implementation

Frequent Asked Questions (FAQ):

What is ISO 20022 standard?

ISO20022 standard Message Implementation

What are the ISO messages defined in this document?

i) head.001.001.01 Business- Application Header

ISO20022 standard Message Implementation

ISO20022 standard Message Implementation

Treasury ATM Other

Reserve Bank of India FAQ on NG-RTGS

ISO20022 standard Message Implementation

How a FIToFICustomerCreditTransfer message is defined?

ISO20022 standard Message Implementation

ISO20022 standard Message Implementation

For the NG-RTGS system the default value is CLRG.

ISO20022 standard Message Implementation

ISO20022 standard Message Implementation

ISO20022 standard Message Implementation

Cash Management Treasury ATM Other

ISO20022 standard Message Implementation

Value 4000 4001 4010 5001, 5002 5011, 5012

Reserve Bank of India FAQ on NG-RTGS

ISO20022 standard Message Implementation

ISO20022 standard Message Implementation

ISO20022 standard Message Implementation

ISO20022 standard Message Implementation

ISO20022 standard Message Implementation

ISO20022 standard Message Implementation

Reserve Bank of India FAQ on NG-RTGS

ISO20022 standard Message Implementation

Reserve Bank of India FAQ on NG-RTGS

Index 1.0 1.1 1.2 1.3 1.4

Message Item EventInformation EventCode EventParameter EventDescription EventTime

<XML Tag> <EvtInf> <EvtCd> <EvtParam> <EvtDesc> <EvtTm>

Mult. [1..1] [1..1] [0..n] [0..1] [0..1]

Represent./ Type Text Text Text DateTime

Rule/ Guid. No.

Message Items Description

1.0 EventInformation <EvtInf>

1.1 EventCode <EvtCd>

1.2 EventParameter <EvtParam>

Reason codes for NACk < To be provided >

1.3 EventDescription <EvtDesc>

1.4 EventTime <EvtTm>

<SysEvtNtfnV01> <EvtInf> <EvtCd>F23</EvtCd> <EvtTm>2002-07-21T08:35:30</EvtTm> </EvtInf> </SysEvtNtfnV01>

Statement Message for Participants

2.0 Statement <Stmt>

2.1 Identification <Id>

For more details please see section 1.4 MessagePagination<MsgPgntn>

2.11 Account <Acct>

2.24 Balance <Bal>

Message Item DateTime

<XML Tag> <DtTm>

2.26 Entry <Ntry>

Ref 5.1.247 5.1.248

Message Item EndToEndIdentification TransactionIdentification

<XML Tag> <EndToEndId> <TxId>

Mult. [1..1] [1..1]

Represent./Type Text Text

<TxId>ABCD201212101234567891</TxId> </Refs> <Amt>Ccy="INR">20000000</Amt> <CdtDbtInd>DBIT</CdtDbtInd> </TxDtls> </NtryDtls> </Ntry> </Stmt> </BkToCstmrStmt>

Free Format Message for Participants

Index 4.0 4.1 5.0

<XML Tag> <Othr> <Ref> <PrtryData>