Ng Rtgiso20022 2q15a

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 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 Reserve Bank of India FAQ on NG-RTGS

6|Page

ISO20022 standard Message Implementation 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: 2345 22. What is InterbankSettlementDate ? 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

Name

Definition

CLRG COVE INDA

ClearingSystem CoverMethod InstructedAgent

INGA

InstructingAgent

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 Reserve Bank of India FAQ on NG-RTGS

7|Page

ISO20022 standard Message Implementation

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 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 , PaymentTypeInformation , ChargesInformation , Debtor , Debtor, , DebtorAgent , Purpose , ……., RemittanceInformation . 30. How to use PaymentIdentification 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 [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 ed on, unchanged, throughout the entire end-to-end chain. Reserve Bank of India FAQ on NG-RTGS

8|Page

ISO20022 standard Message Implementation 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 on multiple references, the end-to-end identification must be ed 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 Bank’s 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 Definition: Unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is ed 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 Reserve Bank of India FAQ on NG-RTGS

9|Page


Cash Management Treasury ATM Other

2 3 4 5

31. What data to be provided in PaymentTypeInformation 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 [1..1] Code ServiceLevel <SvcLvl> [0..1] LocalInstrument [1..1] CategoryPurpose [1..1] i) InstructionPriority 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

Name High

NORM

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./ Reserve Bank of India FAQ on NG-RTGS

10 | P a g e


2.11

Item Proprietary

[1..1]

Type Text

Proprietary 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 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> [TTC=xxxx],[PRI=xx]

Value

Remarks

4000

Value shared for all pacs.008 payments sent from CBS

4001

Value shared for all pacs.009 payments sent from CBS as interbank transfers.

4010

Used for any OAT initiated in CBS to credit the settlement s of the participants.

5001, 5002…

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.

5011, 5012…

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,

Reserve Bank of India FAQ on NG-RTGS

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

To be used only for MNSB files containing current s only.

5021

This applies to the original request sent by NG-RTGS to CBS (step 3)

5030

IDL Request (Repo)message initiated at RTGS

5031

IDL response(Reverse Repo) message initiated at CBS

5032

IDL reversal message initiated at RTGS

5050

Balance sweeping at SOD message initiated at CBS

5051

Balance sweeping at EOD message initiated at RTGS

5022

IDL outstanding message initiated at CBS

iii) LocalInstrument Definition: 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>

Mult.

[1..1]

Represent./ Type Text

Proprietary 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: Reserve Bank of India FAQ on NG-RTGS

12 | P a g e

ISO20022 standard Message Implementation -- ‘RTGSFIoFICredit’ -- ‘RTGSOwnAccTransfer’ -- ‘RTGSNetSettlementXXzNN’ For Return Payment use: - ‘RTGSPaymentReturn’ Data Type: Max35Text Format: maxLength: 35 iv) CategoryPurpose 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 [1..1] Code Code 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 Reserve Bank of India FAQ on NG-RTGS

13 | P a g e

ISO20022 standard Message Implementation 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: CASH 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 of RBI in amount equal to the sum of all credits - multiple credits against the settlement s of the Participants that have their balances initialized b) For EOD: - multiple debits against the settlement s of all Participants with a non-zero balance in NG-RTGS - one credit against the settlement 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. Reserve Bank of India FAQ on NG-RTGS

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 customer’s name Postal Address: ordering customer’s 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 Debtor field? Reserve Bank of India FAQ on NG-RTGS

15 | P a g e

ISO20022 standard Message Implementation This mandatory field provides the identification of the 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 debtor’s 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 details? The Creditor field is used to provide the creditor’s details. This mandatory field is used for identification of the 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 InstructionInformation

45. How to use the code field ? 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: Reserve Bank of India FAQ on NG-RTGS

16 | P a g e


PHOB = Phone Beneficiary TELB=Telecom CHQB= PayCreditorByCheque HOLD= HoldCashForCreditor 46. How to use InstructionInformation field ? Further information complementing the coded instruction or instruction to the next agent that is bilaterally agreed or specific to a 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 . This block is composed of the following elements: Identification: Unique identification, as assigned by the servicer to unambiguously identify the notification. CrationDatatime: ISO date time : Unambiguous indiatification of the 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 ? 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 : 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

ISO20022 standard Message Implementation OriginalMessageNameIdentification : This mandatory field specifies the original message name identifier to which the message refers. OriginalCreationDateAndTime This mandatory field provides Date & time at which the original message was created. GroupStatus Madatory field which specifies the status of a group of transactions. Status code- CSC/ACSP/ACTC/AT/PDNG/RCVD/RJCT/ACCR /ACWC. ACSC: AcceptedSettlementCompleted ACSP: AcceptedSettlementInProcess ACTC: AcceptedTechnicalValidation ACCR: AcceptedCancellationRequest AT: 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 i.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

Message Item

<XML Tag>

Mult.

Message root

[1..1]

Message Item

<XML Tag>

Mult.

1.0

EventInformation

<EvtInf>

[1..1]

1.1

EventCode

<EvtCd>

[1..1]

Text

1.2

EventParameter

<EvtParam>

[0..n]

Text

1.3

EventDescription

<EvtDesc>

[0..1]

Text

1.4

EventTime

<EvtTm>

[0..1]

DateTime

Index

Or

Or

Represent./ Type

Rule/ Guid. No.

Represent./ Type

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 g and encryption not required.

Business Example Narrative The central system sends out general information to the s.

Business Description Element Content EventInformation Event F23

XML Instance

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

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 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

<XML Tag>

Mult.

Represent ./Type

Message root

[1..1]

1.0

GroupHeader

[1..1]

1.1

MessageIdentification

<MsgId>

[1..1]

Text

1.2

CreationDateTime

[1..1]

DateTime

1.4

MessagePagination

<MsgPgntn>

[0..1]

±

2.0

Statement

<Stmt>

[1..1]

2.1

Identification

[1..1]

Text

2.2

StatementPagination

<StmtPgntn>

[0..1]

±

2.3

ElectronicSequenceNumber

<ElctrncSeqNb>

[1..1]

Quantity

2.5

CreationDateTime

[1..1]

DateTime

2.11

[1..1]

±

2.24

Balance

[1..*]

±

2.46

Entry

[0..*]

±

Rule/Gui d no.

R1

R1

G3

1.1MessageIdentification<MsgId> Presence: [1..1] Definition: Point to point reference, as assigned by the servicing institution, and sent to the owner or the party authorized to receive the message, to unambiguously identify the message. Usage: The servicing institution has to make sure that MessageIdentification is unique per 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 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

Message Item

<XML Tag>

Mult.

Represent./Type

9.2.0

PageNumber

[1..1]

Text

9.2.1

LastPageIndicator

[1..1]

Indicator

9.2.0 PageNumber Presence: [1..1] Definition: Page number. Data Type: Max5NumericText Format: [0-9]{1,5} 9.2.1 LastPageIndicator 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 . Only one statement per message will be produced by NG-RTGS.

2.1 Identification Presence: [1..1] Definition: Unique identification, as assigned by the servicer, to unambiguously identify the 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

<XML Tag>

Mult.

Represent./Type

PageNumber

[1..1]

Text

LastPageIndicator

[1..1]

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 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 Presence: [1..1] Definition: Date and time at which the message was created. Data Type: ISODateTime

2.11 Presence: [1..1] Definition: Unambiguous identification of the to which credit and debit entries are made. Type: This message item is composed of the following Cash25element(s): Or

Message Item

<XML Tag>

Mult.

Identification

[1..1]

Currency

[1..1]

Represent./Type

Code

Identification Presence: [1..1] Definition: Unique and unambiguous identification for the between the owner and the servicer. Or

Message Item Identification Other

<XML Tag>

Mult.

[1..1]

[1..1]

Represent./Type

Other Presence: [1..1] Definition: Unique identification of an , as assigned by the servicer, using an identification scheme. Datatype: "Max34Text" Or

Message Item Identification

<XML Tag>

Mult. [1..1]

Represent./Type Text

2.24 Balance Presence: [1..*] Definition: Set of elements used to define the balance as a numerical representation of the net increases and decreases in an at a specific point in time. Ref

Or

Message Item

<XML Tag>

Mult.

Represent./Type

3.1.0

Type

[1..1]

3.1.10

Amount

[1..1]

Amount

3.1.11

CreditDebitIndicator

[1..1]

Code

3.1.12

Date

[1..1]

3.1.14

DateTime

[1..1]

DateTime

3.1.0 Type Presence: [1..1] Definition: Specifies the nature of a balance. Type: This message item is composed of the following BalanceType12element(s): Ref

Or

3.1.1

Message Item CodeOrProprietary

<XML Tag>

Mult.

Represent./Type

[1..1]

3.1.1 CodeOrProprietary Presence: [1..1] Definition: Coded or proprietary format balance type. Type: This message item is composed of one of the following BalanceType5Choiceelement(s): Ref

Or

3.1.2

Message Item Code

<XML Tag>

Mult.

Represent./Type

[1..1]

Code

3.1.2 Code 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 at the end of the preagreed reporting period. It is the sum of the opening booked balance (which is always zero for a settlement in NGRTGS) at the beginning of the period and all entries booked to the during the pre-

agreed reporting period. 3.1.10 Amount 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 ed, or have already been ed. Valid active or historic currency codes are ed 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 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

Name

Definition

CRDT

Credit

Operation is an increase.

DBIT

Debit

Operation is a decrease.

3.1.12 Date

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

Or

Message Item

3.1.14

DateTime

<XML Tag>

Mult.

Represent./Type

[1..1]

DateTime

3.1.14 DateTime Presence: [1..1] Definition: Specified date and time. Data Type: ISODateTime

2.26 Entry 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

Or

Message Item

<XML Tag>

Mult.

Represent./Type

5.1.1

Amount

[1..1]

Amount

5.1.2


[1..1]

Code

5.1.4

Status

<Sts>

[1..1]

Code

5.1.8

ValueDate

[1..1]

[1..1]

5.1.9

Date

5.1.18

BankTransactionCode

[1..1]

5.1.234

EntryDetails

[0..*]

5.1.1 Amount 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 Presence: [1..1] Definition: Indicates whether the entry is a credit or a debit entry.

DateTime

DataType: Code One of the following CreditDebitCodevalues must be used: Code

Name

Definition

CRDT

Credit

Operation is an increase.

DBIT

Debit

Operation is a decrease.

5.1.4 Status <Sts> Presence: [1..1] Definition: Status of an entry on the books of the servicer. DataType: Code One of the following EntryStatus2Code values must be used: Code

Name

BOOK

Definition

Booked

Booked means that the transfer of money has been completed between servicer and owner. Usage: Status Booked imply finality of money.

5.1.8 ValueDate Presence: [0..1] Definition: Date and time at which assets become available to the owner in case of a credit entry, or cease to be available to the owner in case of a debit entry. Type: This message item is composed the following Date element. 5.1.9 Date

Presence: [1..1] This message item is part of choice 5.1.8 ValueDate. Definition: Specified date. DataType: ISODate 5.1.18 BankTransactionCode 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>

Mult. [0..1]

Represent./Type

5.1.24 Proprietary 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

Or

5.1.25

Message Item Code

<XML Tag>

Mult.

Represent./Type

[1..1]

Text

5.1.25 Code 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 Presence: [0..*] Definition: Provides details on the entry. Type: This message item is composed of the following EntryDetails2element(s): Ref

Or

5.1.241

Message Item TransactionDetails

<XML Tag>

Mult.

Represent./Type

[0..*]

5.1.241 TransactionDetails Presence: [0..*] Definition: Provides information on the underlying transaction(s). Type: This message item is composed of the following EntryTransaction3 element(s): Ref

Or

Message Item

<XML Tag>

Mult.

5.1.242

References

[0..1]

5.1.259

Amount

[1..1]

5.1.260


[1..1]

Represent./Type

Amount

5.1.242 References Presence: [0..1] Definition: Provides the identification of the underlying transaction. Type: This message item is composed of the following TransactionReferences3 element(s):

Ref

Or

Message Item

<XML Tag>

Mult.

Represent./Type

5.1.247

EndToEndIdentification

<EndToEndId>

[1..1]

Text

5.1.248

TransactionIdentification

[1..1]

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 ed 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 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 <MsgId>HDFC201212011234567890 2012-12-18T17:00:00 <MsgPgntn> 1 true <Stmt> HDFC201212011234567890 <StmtPgntn>

1 true <ElctrncSeqNb>1 2012-12-18T17:00:00 50000000054910000003 INR CLBD 500000 CRDT

2012-12-18T19:30:00

10000000.50 CRDT <Sts>BOOK

2010-10-18

FIToFICustomerCredit <EndToEndId>MY REFERENCE 101 ABCD201212101234567890 Ccy="INR">10000000.50 CRDT 20000000 CRDT <Sts>BOOK

2010-10-18

FIToFICustomerCredit <EndToEndId>MY REFERENCE 102

ABCD201212101234567891 Ccy="INR">20000000 DBIT

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

<XML Tag>

Mult.

Message root

[1..1]

1.0


<MsgId>

[1..1]

1.1

Reference

[1..1]

1

Represent ./Type

Text

Rule/Gui d no.

Index 4.0 4.1 5.0

Or

Message Item Other Reference ProprietaryData

<XML Tag>

Mult.

[1..1]

[1..1]

[1..1]

Represent ./Type

Rule/Gui d no.

Text

1.0MessageIdentification<MsgId> Presence: [1..1] Data Type: Max35Text Format: maxLength: 35 minLength: 1

1.1Reference 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 Presence: [1..1] Definition: This will hold the -defined subject of the message.

4.1Reference Definition: Business reference of the present message assigned by the 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 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

Message Item

<XML Tag>

Mult.

Represent./Type Text

5.1

Type

[1..1]

5.2

Any

( defined)

[1..1]

5.1Type This is a mandatory fixed field. Its content is: NG-RTGS Notification 5.2 defined This section contains the actual message to be sent to the receiver. Or

Message Item

<XML Tag>

Document Root tag Message Content

Mult.

[1..1]

[1..1]

Represent./Type

Max2000Text

The message content is an unstructured free text of up to 2000 characters long.

Example <MsgId> HDFC201212011234567890 Notification subject NG-RTGS Notification This is a free format message.

3

ISO20022 standard Message Implementation ISO20022 Business Application Header ISO Message: “head.001.001.01 BusinessApplicationHeaderV01” ISO20022 Message head.001.001.01 BusinessApplicationHe aderV01 Message Item

XML tag

Description

<AppHdr>

Root tag The sending MessagingEndpoin t that has created this Business Message for the receiving MessagingEndpoin t that will process this Business Message.

FinancialInstitutionIde ntification


ClearingSystemMemb erIdentification

Member Identification

<MmbId>

From

ISO Multi

RTGS /NEFT Multi

2.0

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

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

Identification of a financial institution.

2.34

[0..1]

[1..1]

Identification of a financial institution ClearingSystemM emberIdentificati on IFSC of the Sending participant

2.35

[0..1]

[1..1]

2.37

[0..1]

[1..1]

2.41

[1..1]

[1..1]

Reserve Bank of India ISO Message, “head.001.001.01 BusinessApplicationHeaderV01”

Index

1

Rules

Example

Data Type

<MmbId>CANB0239777

Max35Te xt

ISO20022 standard Message Implementation ISO20022 Message head.001.001.01 BusinessApplicationHe aderV01 Message Item To

XML tag

Description

Index

ISO Multi

RTGS /NEFT Multi

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

3.34

[1..1]

[1..1]


3.35

[0..1]

[1..1]

ClearingSystemMemb erIdentification

3.37

[0..1]

[1..1]


<MmbId>

Identification of a financial institution. Identification of a financial institution ClearingSystemM emberIdentificati on IFSC of the Sending participant

3.41

[1..1]

[1..1]

Rules

Example

Data Type

MmbId> HDFC0239777

Max35Te xt

Validation are:

BusinessMessageIden

Uniquely


4.0

[1..1]

[1..1]

Same as MessageIdentification

2

Character position First four characters Fifth character

Information

R

Bank code

F

Last six characters

Branch code

Zero

HDFC201210180000000

R B no w Max35Te

ISO20022 standard Message Implementation ISO20022 Message head.001.001.01 BusinessApplicationHe aderV01 Message Item tifier

XML tag

MessageDefinitionIde ntifier

<MsgDefIdr>

BusinessService

Description

identifies the business message Message Identifier

Specifies the business service agreed between the two MessagingEndPoi nts under which rules this Business Message is exchanged.

Index

ISO Multi

RTGS /NEFT Multi

5.0

[1..1]

[1..1]

6.0

[0..1]

[1..1]

Rules

Example

Data Type

<MsgId> in the associated business message

218

xt

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’

<MsgDefIdr> pacs.008.001.03

Max35Te xt

RTGSFIToFICustomerCredit

Max35Te xt

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 Reserve Bank of India ISO Message, “head.001.001.01 BusinessApplicationHeaderV01”

3

ISO20022 standard Message Implementation ISO20022 Message head.001.001.01 BusinessApplicationHe aderV01 Message Item

XML tag

Description

Index

ISO Multi

RTGS /NEFT Multi

Rules

Example

Data Type

2012-09-30T09:50Z

ISONorm alisedDat eTime

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

CreationDate

CopyDuplicate

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]

8.0

[0..1]

[0..1]

“OT” stands for Other MNSB Time up to seconds only

DUPL Duplicate(Message is for information/ confirmation purposes. It is a duplicate of a message previously sent). Valid Values are: CODU COPY DUPL

4

DUPL

Code

ISO20022 standard Message Implementation ISO20022 Message head.001.001.01 BusinessApplicationHe aderV01 Message Item Signature

XML tag

Description

Index

ISO Multi

RTGS /NEFT Multi

Rules

<Sgntr>

Contains the digital signature of the Business Entity authorised to sign this Business Message.

11.0

[0..1]

[1..1]

SHA2 digital signature http://www.w3.org/2000/09/xml dsig#

XMLSignatures

<XMLSgntrs>

[1..1]

[1..1]

Related

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.

[0..1]

[0..1]


12.0

5

Example

Data Type

ISO20022 standard Message Implementation ISO20022 Message head.001.001.01 BusinessApplicationHe aderV01 Message Item From

XML tag

Description

Index

ISO Multi

RTGS /NEFT Multi

Rules

Element description is same as that provided for the same element above. This message item is the part of the Rltd block.

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.


The sending Messaging Endpoint that has created this Business Message for the receiving Messaging Endpoint that will process this Business Message.

12.36

[1..1]

[1..1]



12.37

[1..1]

[1..1]

ClearingSystemMembe rIdentification

12.87

[0..1]

[1..1]


<MmbId>

12.88

[1..1]

[1..1]

To

-As Above-

12.53

[1..1]

[1..1]


The Messaging Endpoint designated by the sending Messaging

[1..1]

[1..1]


Example

Data Type

Max35Te xt -As Above-

6

ISO20022 standard Message Implementation ISO20022 Message head.001.001.01 BusinessApplicationHe aderV01 Message Item

XML tag

Description

Index

ISO Multi

RTGS /NEFT Multi

[1..1]

[1..1]

Rules

Example

Data Type

Endpoint to be the recipient who will ultimately process this Business Message. FinancialInstitutionIden tification

ClearingSystemMembe rIdentification

[0..1]

[1..1]


<MmbId>

[1..1]

[1..1]

BusinessMessageIden tifier MessageDefinitionIde ntifier Business Service

-As Above-

12.104

[1..1]

[1..1]

-As Above-

<MsgDefIdr>

-As Above-

12.105

[1..1]

[1..1]

-As Above-

-As Above-

12.106

[0..1]

[0..1]

-As Above-

CreationDate

-As Above-

12.107

[1..1]

[1..1]

-As Above-

CopyDuplicate

-As Above-

12.108

[0..1]

[0..1]

-As Above-



7

Max35Te xt Max35Te xt Max35Te xt Max35Te xt ISONorm alisedDat eTime Code

ISO20022 standard Message Implementation 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

ISO20022 standard Message Implementation ISO 20022 Message

Message Identification

GROUP HEADER - GROUP HEADER

Map ping

ISO20022 Message FIToFICustomerCre ditTransferV03 Message Item FIToFICustomerCred itTransfer

XML tag

Description

GroupHeader

MessageIdentificati on

<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


Index

ISO Multi

RTGS/ NEFT Multi

1.0

[1..1]

[1..1]

1.1

[1..1]

[1..1]

Rules

Example

Data Type

Uniquely identifies message

<MsgId> HDFC201210181000000218

Max35Text

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

2|Page

Settlement Settlement Information

No. of Txs.

Creation Date & Time


CreationDateTime

NumberOfTransacti ons

TotalInterbankSettl ementAmount

InterbankSettlemen tDate SettlementInformat ion

<SttlmInf>

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)


1.2

[1..1]

[1..1]

Time up to seconds only

2011-0424T09:30:32

ISODateTime

1.4

[1..1]

[1..1]

Always 1 for customer payment in RTGS system and 10 or more for NEFT

1

Max15Numer icText

1.6

[0..1]

[1..1]

3400.00

Amount

Currency as per the ISO 4217 list

1.7

[0..1]

[1..1]

1.8

[1..1]

[1..1]

Settlement date

2011-0424

ISODate

3|Page


SettlementMethod

<SttlmMtd>

between the instructing agent and the instructed agent is completed. Method used to settle the (batch of) payment instructions.

[1..1]

[1..1]

Must be CLRG (i.e., Settlement done through a payment clearing system)

<SttlmMtd>CLRG

Code

Max35Text

Other Codes are: CLRG, COVE, INDA, INGA InstructingAgent

FinancialInstitutionI dentification

ClearingSystemMe mberIdentification

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]

[1..1]

[1..1]

[0..1]

[1..1]

[1..1]

[1..1]

Mandatory in RTGS implementation

Sender IFSC

4|Page

ISO20022 standard Message Implementation Identification

InstructedAgent




<MmbId>

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

1.22

[0..1]

[1..1]

[1..1]

[1..1]

[0..1]

[1..1]

[1..1]

[1..1]


Receiver IFSC

<MmbId>HDFC02397 77

Max35Text

5|Page

ISO20022 standard Message Implementation CreditTransferTrans actionInformation

Set of elements providing information specific to the individual credit transfer(s)).

2.0

[1..n]

[1..1]

PaymentIdentificati on

Set of elements used to reference a payment instruction.

2.1

[1..1]

[1..1]

2.2

[0..1]

[0..1]

Only one occurrence allowed for Customer Payment in RTGS system and 10 or more for NEFT.

Payment Identification

The PmtId block contains the following elements: i) InstructionIdentifica tion ii) EndToEndIdentificat ion <EndToEndId> iii) TransactionIdentific ation

InstructionIdentifica tion

Unique identification, as assigned by an instructing party for an instructed party, to unambiguously identify the instruction.


May be used for supplementary identification, such as the legacy transaction reference number (R41.2020).

Max35Text

6|Page

ISO20022 standard Message Implementation EndToEndIdentificat ion

TransactionIdentific ation

<EndToEndId >

Unique identification, as assigned by the bank’s customer, to unambiguously identify the transaction. This identification is ed 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 )

2.3

Unique identification, as assigned by the first instructing agent, to unambiguously

2.4


[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:

<EndToEndId>/XUTR/ HDF12115000023

Max35Text

HDFCR12012042400000023

Max35Text

The format is: i)Participant System ID (First four Characters of sending Bank’s 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)

[1..1]

[1..1]

Use UTR (Unique Transaction Reference) format (22 characters) XXXX- Sender IFSC [4] X-Payment System [1] X-Channel [1]

In FAQ Channels are mentioned as ATM, Internet

7|Page

ISO20022 standard Message Implementation identify the transaction that is ed 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.

Payment Information

PaymentTypeInfor mation

Set of elements used to further specify the type of transaction.

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.

2.6

[0..1]

[1..1]

Priority is mandatory in RTGS implementation

The PmtTpInf block contains the following elements: i) InstructionPriority ii) ServiceLevel <SvcLvl> iii) LocalInstrument iv) CategoryPurpose


8|Page


InstructionPriority

ServiceLevel

<SvcLvl>

Proprietary

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

HIGH

Code

<SvcLvl>

Max35Text

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. 2.9

[0..1]

[0..1]

2.11

[0..1]

[1..1]

For RTGS processing priority is in range 00 – 99.

9|Page

ISO20022 standard Message Implementation 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

Proprietary

CategoryPurpose

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]

2.13

[0..1]

[1..1]

2.15

[0..1]

[1..1]

Type of local instrument. For RTGS pacs.008 use: - ‘RTGSFIToFICustomerCredit’

[TTC=xxxx],[PRI=xx] For More information, Pl refer to FAQ.

RTGSFIToFICustomerCredit

Max35Text

10 | P a g e

ISO20022 standard Message Implementation Code

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

CASH

Code

Default value may be ‘CASH’.

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.


11 | P a g e

Interbank Settlement Amt

ISO20022 standard Message Implementation InterbankSettlemen tAmount

ChargeBearer

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]

2.33

[1..1]

[1..1]

Codes used are:

3400.00

Amount

DEBT

Code

CRED/DEBT/SHAR/SLEV

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).

Charge Bearer

SHAR-> Shared ( 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


Charges Information

ChargesInformation

Provides information on the charges to be paid by the charge bearer(s) related to the payment transaction.

2.34

[0..*]

[0..1]

2.35

[1..1]

[1..1]

2.36

[1..1]

[1..1]

The ChrgsInf block contains the following elements: i) Amount ii) Agent .

Amount

Agent

Transaction charges to be paid by the charge bearer. Agent that takes the transaction charges or to which the transaction charges are due.


5000.00

Amount

13 | P a g e



<MmbId>

Debtor

Name

PostalAddress

AddressLine

Debtor

Debtor's A/c (Ordering Customer's A/C)

Debtor (Ordering Customer)

ISO20022 standard Message Implementation FinancialInstitution 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 within a clearing system. Identification of a member of a clearing system. ORDERING CUSTOMER Ordering Customer’s Name Ordering Customer’s Postal Address Adress in free form text Identification of the of the debtor to which a debit entry will be


2.49

2.50

[1..1]

[1..1]

[0..1]

[1..1]

[1..1]

[1..1]

[1..1]

[1..1]

[0..1]

[1..1]

[0..1]

[0..1]

[0..7]

[0..4]

[0..1]

[1..1]

Max35Text

Name is mandatory

Umesh Kapoor

Max140Text

Number of occurrences is restricted to 4 in RTGS implementation.

Boulevard Road

Max70Text

14 | P a g e

ISO20022 standard Message Implementation Identification

Other

Identification

Type

Proprietary

made as a result of the transaction. Unique and unambiguous identification for the between the owner and the servicer. Unique identification of an , as assigned by the servicer, using an identification scheme. Identification assigned by an institution. (Debtor's number).

[1..1]

[1..1]

[1..1]

[1..1]

[1..1]

[1..1]

Specifies the nature, or use of the .

[0..1]

[0..1]

Nature or use of the in a proprietary form.

[1..1]

[1..1]


265385644663

To be used to accommodate NEFT type information. This is also useful to document NRE type for the RTGS.

Max34Text

Text

15 | P a g e

Debtor's Agent (ORDERING INSTITUTION)

ISO20022 standard Message Implementation Currency

Identification of the currency in which is held.

DebtorAgent

Financial institution servicing an for the debtor.


ClearingSystemIden tification


<MmbID>

[0..1]

[0..1]

For NG-RTGS, “INR” is the only currency that can be specified.

[1..1]

[1..1]

Pl see FAQ for more details on DebtorAgent (i.e Sub-Member) For Participant, IFSC

[1..1]

[1..1]

2.1.6

[0..1]

[1..1]

2.1.6

[1..1]

[1..1]

2.51

(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. (IndianFinancial SystemCodeIde ntifier for participants / Name and Identification for non Participants is


For Participant, IFSC code to be keyed in. For Non- Participant, IFSC, or Name and Other Identification with optional Address.

INR

Code

<MmbId>HDFC02397 77>

16 | P a g e

Creditor's Agent (BENEFICIARY INSTITUTION)

ISO20022 standard Message Implementation Name

PostalAddress

AddressLine

CreditorAgent



mandatory). Ordering Institution Name Ordering Institution Postal Address Address in free format text

Financial institution serving an 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

3.37

[0..1]

[0..1]

[0..1]

[0..1]

[0..7]

[0..4]

[1..1]

[1..1]

[1..1]

[1..1]

[0..1]

[1..1]

Optional. To be filled if Ordering Customer is other than the Sender of the msg.

Bank A

Max140Text

Number of occurrences is restricted to 4 in RTGS implementation

Corn Exchange 5th Floor Mark Lane 55 EC3R7NE London GB

Max70Text

17 | P a g e


<MmbId>

Name

Creditor

Name

PostalAddress

AddressLine

Credito r's A/c (BENEFI CIARY CUSTO MER's A/C)

Creditor (BENEFICIARY CUSTOMER)


Creditor

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 of the creditor to


2.55

2.56

[1..1]

[1..1]

[0..1]

[0..1]

[1..1]

[1..1]

[0..1]

[1..1]

[0..1]

[0..1]

[0..7] [0..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.

<MmbId>HDFC02397 77 <

Max35Text

Bank B

Max140Text

Mandatory in view of Indian Context (Ref. Circular issued by RBI)

A R Roy

Max140Text

[0..4]

Number of occurrence is restricted to 4.

Boulevard Road

Max70Text

[1..1]


18 | P a g e

ISO20022 standard Message Implementation which a credit entry will be posted as a result of the payment transaction. (Beneficiary Customer ) The CdtrAcct block contains the following elements: i) Identification ii) Currency

Identification

Other

Identification

Unique and unambiguous identification for the between the owner and the servicer. Unique identification of an , as assigned by the servicer, using an identification scheme. Identification assigned by an institution.


[1..1]

[1..1]

[1..1]

[1..1]

[1..1]

[1..1]

Existing number

2147743292

Max34Text

19 | P a g e

Instruction For Creditor Agent

ISO20022 standard Message Implementation Type

Proprietary

Currency

InstructionForCredit orAgent

Code

InstructionInformati on

Specifies the nature, or use of the . Nature or use of the in a proprietary form. Identification of the currency in which 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]

[0..1]

[0..1]

2.58

[0..n]

[0..2]

2.59

[0..1]

[0..1]

To be used to accommodate NEFT type information. This is also useful to document NRE type for the RTGS. For NG-RTGS, “INR” is the only currency that can be specified.

PHOB = Phone Beneficiary TELB=Telecom CHQB= PayCreditorByCheque HOLD= HoldCashForCreditor

Text

INR

Code

PHOB

Code

Pl see FAQ for details.

2.63

[0..1]

[0..1]

Max140Text

20 | P a g e

Beneficiary Information


RemittanceInforma tion

Unstructured

<Ustrd>

the coded instruction or instruction to the next agent that is bilaterally agreed or specific to a community. Beneficiary Customer's Postal Address Remittance Information 140 characters up to 4 can be used Sender to Receiver Information

2.69

[0..1]

[0..1]

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 Transfer.




ISO 20022 Message Reserve Bank of India ISO Messages, “camt.054.001.03 BanktoCustomerDebitCreditNotificationV03”

1|Page

ISO20022 standard Message Implementation ISO20022 Message camt.054.001.03 BankToCustomerDebitCredit NotificationV03 Message Item

XML tag

Description

Root tag

GroupHeader


<MsgId>

CreationDateTime

Notification

Index

ISO Multi

RTGS /NEFT Multi

[1..1]

[1..1]

Common information for the message. Point to point reference, as assigned by the servicing institution, and sent to the owner or the party authorised to receive the message, to unambiguously identify the message. Usage: The servicing institution has to make sure that MessageIdentificati on is unique per owner for a pre-agreed period. Date and time at which the message was created.

1.0

[1..1]

[1..1]

1.1

[1..1]

[1..1]

1.2

[1..1]

[1..1]

Notifies debit and credit entries for the .

2.0

[1..n]

[1..1] or [1..10]

Rules

Example

Data Type


<MsgId> HDFC201210181000000218

Max35Text

2011-04-24T09:30:32

ISODateTim e

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

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

This msg element is

Reserve Bank of India ISO Messages, “camt.054.001.03 BanktoCustomerDebitCreditNotificationV03”

2|Page


XML tag

Description

Index

ISO Multi

RTGS /NEFT Multi

Example

Data Type

2.1

[1..1]

[1..1]

EODZERO

Max35Text

2.5

[1..1]

[1..1]

2011-04-24T07:30:32

ISODateTim e

2.11

[1..1]

[1..1]

[1..1]

[1..1]

[1..1]

[1..1]

[1..1]

[1..1]

353565651234

Max34Text

Rules

the part of the Ntfctn block.

Identification

CreationDateTime

Identification

Other

Identification

Unique identification, as assigned by the servicer, to unambiguously identify the notification. Date and time at which the message was created. This msg element is the part of the Ntfctn block. Unambiguous identification of the to which credit and debit entries are made. This msg element is the part of the Ntfctn block. Unique and unambiguous identification for the between the owner and the servicer. Unique identification of an , as assigned by the servicer, using an identification scheme.

Identification assigned by an


3|Page


XML tag

Description

Index

ISO Multi

RTGS /NEFT Multi

2.45

[0..n]

[1..1]

[1..1]

[1..1]

[1..1]

[1..1]

[1..1]

[1..1]

Example

Data Type

10000.00

Amount

Codes to be used are: CRDT: Credit -> Operation is an increase DBIT: Debit -> Operation is a decrease

DBIT

Code

Always BOOK meaning booked amount. Booked means that the transfer of money has been completed between servicer and 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

Code

Rules

institution. (Settlement number) Entry

Amount


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.

Indicates whether the entry is a credit or a debit entry. This msg element is the part of the Ntry block.

Status

<Sts>

Status of an entry on the books of the service Provider. Code for status BOOK/INFO/PDNG/F UTR This msg element is the part of the Ntry block.


4|Page


XML tag

Description

Index

ISO Multi

RTGS /NEFT Multi

Rules

Example

Data Type

2010-1018T13:15:00

ISODateTim e

0001

Max35Text

For more details pl refer para 2.81 of ISO documentation “Payment Maintenance 2009.pdf”. ValueDate

DateTime

BankTransactionCode

Proprietary

Code

Date and time at which assets become available to the owner in case of a credit entry, or cease to be available to the 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

[0..1]

[1..1]

[0..1]

[1..1]

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.

[1..1]

[1..1]

[1..1]

[1..1]

[1..1]

[1..1]


Settlement time

5|Page

ISO20022 standard Message Implementation ISO20022 Message camt.054.001.03 BankToCustomerDebitCredit NotificationV03 Message Item EntryDetails

XML tag

Description

Provides details on the entry

Index

ISO Multi

RTGS /NEFT Multi

[0..n]

[1..1]

[0..n]

[1..1]

[0..1]

[1..1]

5.1.246

[0..1]

[0..1]

May be used for supplementary identification, such as the legacy transaction reference number (R41R42.2020).

5.1.247

[0..1]

[1..1]

It should follow the 16 digits UTR pattern of the existing RTGS system,

Rules

Example

Data Type

This msg element is the part of the Ntry block. TransactionDetails

References

InstructionIdentification


<EndToEndId>

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 ed 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


Max35Text


Max35Text

identified with the 6 character codeword prefix “/XUTR/”.. The existing UTR format is: i)Participant System ID (First four Characters of sending Bank’s 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


TransactionIdentification

XML tag

Description

messages related to the transaction. Usage: In case there are technical limitations to on multiple references, the end-to-end identification must be ed 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 ed 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

Index

ISO Multi

RTGS /NEFT Multi

Rules

Example

Data Type

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]

HDFCR12012042400000023

Max35Text


For Further Information, pl refer to FAQ on Channel.

7|Page


XML tag

Description

Index

ISO Multi

RTGS /NEFT Multi

[1..1]

[1..1]

[1..1]

[1..1]

Rules

Example

Data Type

10000.00

Amount

DBIT

Code

unique for a preagreed period.

Amount


RelatedParties

Debtor

Identification

OrganisationIdentification

Other

(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

5.1.260

Codes are DBIT & CRDT. Codes DBIT CRDT

5.1.418

[0..1]

[1..1]

5.1.462

[0..1]

[1..1]

[0..1]

[1..1]

[1..1]

[1..1]

[0..n]

[1..1]


Meanings Debit Credit

Must reflect the pacs.008 and pacs.009 structure for BOTH Debtor and Creditor

8|Page


XML tag

Identification

Purpose

Proprietary

Description

Index

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.

ISO Multi

RTGS /NEFT Multi

[1..1]

[1..1]

[0..1]

[0..1]

[1..1]

[1..1]

Rules

Code values are: REPO or REVREPO OR SODBAL or EODZERO or MNSB

Example

Data Type

CAN B0239777

Max35Text

Max35Text

If code word is not MNSB, then it will be treated as normal. RemittanceInformation

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


XML tag

Description

Index

ISO Multi

RTGS /NEFT Multi

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

ISO20022 standard Message Implementation ISO 20022 Message ISO20022 Message - pacs.009.001.03FinancialInstitution CreditTransferV03 Message Item

XML tag

Description

FinancialInstitution CreditTransfer

Root tag

GroupHeader

MessageIdentificati on

<MsgId>

Message Identification Creation Date & Time

GROUP HEADER - GROUP HEADER

Map ping

CreationDateTime

Index

ISO RTGS Multi Multi

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]

1.1

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

Date and time at which the message was created.

1.2

Rules

Example

Data Type


<MsgId> HDFC201210181000000218

Max35T ext

2011-0424T09:30:32

ISODateT ime

Recommend MessageIdentification be structured as: XXXX- Sender IFSC [4] YYYYMMDD - Creation Date Reverse [8] X – Channel [1] nnnnnnnnnn- Sequence Number [9]


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

The values of Channel Identification (X) is the same as defined for TransactionIdentification Time up to seconds only local time format (YYYY-MMDDThh:mm:ss.sss) Note on the time format: Beginning / end of calendar day

2|Page


Settlement Information

No. of Txs.

00:00:00 = the beginning of a calendar day 24:00:00 = the end of a calendar day

NumberOfTransacti ons

Number of transactions

1.4

[1..1] 1..1]

Always 1 for Interbank payment in RTGS

1

Max15N umericTe xt

TotalInterbankSettl ementAmount

1.6

[0..1] [1..1]

Total amount transferred between debtor and creditor.

3400

Amount

InterbankSettlemen tDate

Total amount of money moved between the instructing agent and the instructed agent. (Total Settlement Amount + Currency) Settlement Date

1.7

[0..1] [1..1]

2011-0424

ISODate

SettlementInformat ion

<SttlmInf >

Specifies the details on how the settlement of the transaction(s) between the instructing agent and the instructed agent is completed.

1.8

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

SettlementMethod

<SttlmMt d>

Method used to settle the (batch of) payment instructions.

1.9

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

<SttlmMtd>CLRG

Code

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 )


Agent that instructs the next

1.21


[0..1] [1..1]

3|Page

ISO20022 standard Message Implementation party in the chain to carry out the (set of) instruction(s). FinancialInstitutionI dentification



<MmbId >

InstructedAgent


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]

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).

[1..1]

[1..1]

1.22

Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary


[0..1] [1..1]

Sender IFSC.

<MmbId>HDFC0239777

Max35Te xt


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

4|Page


Payment Identification

CREDIT TRANSFER INFORMATION

identification scheme.



<MmbId>

CreditTransferTran sactionInformation

PaymentIdentificati on

InstructionIdentific ation

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 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.

[0..1] [1..1]

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

Receiver IFSC

2.0

[1..n] [1..1]

Only one occurrence allowed for Interbank Payment

2.1

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

2.2

[0..1]


[0..1]

May be used for supplementary identification, such as the legacy transaction reference number (R42.2020).

<MmbId>HDFC0239777

Max35Te xt

Max35T ext

5|Page

ISO20022 standard Message Implementation EndToEndIdentifica tion

<EndToE ndId>

Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is ed 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 on multiple references, the endto-end identification must be ed on throughout the entire end-to-end chain. (Related Reference)

2.3


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



Max35Te xt

The format is: i)Participant System ID (First four Characters of sending Bank’s 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


Payment Information

TransactionIdentific ation

PaymentTypeInfor mation

Unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is ed 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


2.6

[1..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]

HDFCR12012042400000023

Max35Te xt


[0..1] [1..1]

The PmtTpInf block contains the following elements. i) InstructionPriority


7|Page

ISO20022 standard Message Implementation ii) ServiceLevel <SvcLvl> iii) LocalInstrument iv) CategoryPurpose

InstructionPriority

Priority

2.7

[0..1] [1..1]

HIGH / NORM

HIGH

Code

<SvcLvl> [TTC=xxxx],[PRI=xx]

Max35Te xt

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. ServiceLevel

<SvcLvl>

Proprietary

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.

For More information, Pl refer to FAQ. LocalInstrument

community specific instrument. Usage: This element is used to

2.12


[0..1]

[1..1]

8|Page


Proprietary

CategoryPurpose

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)

2.13

[0..1]

[1..1]

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.

RTGSFIToFICredit

Max35Te xt

9|Page


Interbank Settlement Amt

Code

InterbankSettleme ntAmount

Category purpose, as published in an external category purpose code list.

Amount of money moved between the instructing agent and the instructed agent. (Settlement Amount +

2.16

[1..1]

[1..1]

FROM ISO 20022External Code list

CASH Default code may be ‘CASH’.

Code

3400

Amount

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

2.18


[1..1]

[1..1]

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

10 | P a g e


Debtor (ORDERING INSTITUTION)

Currency)

Debtor




<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.

2.40

[1..1]

[1..1]

[1..1]

[1..1]

[0..1]

[1..1]

[1..1]

[1..1]

<MmbId>HDFC0239777< /ClrSysMmbId>

Max35Te xt

[0..1]

[0..1]

Bank A

Max140T ext

(IndianFinancialSyst emCodeIdentifier for participants / Name and Identification for non Participants is mandatory).

Name

Name by which an agent is known and which is usually used to identify that


11 | P a g e

Creditor (BENEFICIARY INSTITUTION)


Creditor


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.

2.46

[1..1]

[1..1]

[1..1]

[1..1]

[0..1]

[1..1]

The FinInstnId block contains the following elements: i) ClearingSystemMembe rIdentification II) Name iii) PostalAddress iv) Other


Information used to identify a


12 | P a g e

ISO20022 standard Message Implementation 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)

[1..1]

[1..1]

< MmbId>HDFC0239777

Max35Te xt

Name

[0..1]

[0..1]

Bank b

Max140T ext

PostalAddress

Information that locates and identifies a specific address, as defined by postal services. (Beneficiary Institution Postal Address)

[0..1]

[0..1]

AddressLine

Information that locates and identifies a specific address, as defined by postal services, presented in free format text.

[0..7]

[0..4]

Boulevard Road

Max70Te xt


Number of occurrence is restricted to 4

13 | P a g e

ISO20022 standard Message Implementation Other

Unique identification of an agent, as assigned by an institution, using an identification scheme. (Used when correspondents are involved).

[0..1]

[0..1]

Identification

Identification assigned by an institution.

[1..1]

[1..1]

Creditor

[0..1]

[0..1]

Identification

Unambiguous identification of the of the creditor to which a credit entry will be posted as a result of the payment transaction. (Beneficiary Customer identification). Unique and unambiguous identification for the between the owner and the servicer. ( number of Beneficiary).

[1..1]

[1..1]

[1..1]

[1..1]

Other

2.47

Unique identification of an , as assigned by the servicer,


Max35Te xt

14 | P a g e


Remittance Information

Identification

RemittanceInforma tion Unstructured <Ustrd>

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

[1..1]

[1..1]

2.55

[0..1]

[0..1]

2.56

[0..n]

[0..4]

It must be used for recording number for the beneficiary bank for STP process.

0510085


Max34Te xt"

Max140T ext

Note:- [1..1] -> Mandatory; [0..1] -> Optional ; [1..n] -> Mandatory and n times repeated ; [0..n] -> Optional and n times repeated;


15 | P a g e

ISO20022 standard Message Implementation 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. *Corresponds to R12 in current RTGS.




ISO 2002 Message

Reserve Bank of India ISO Messages, “pacs.009.001.03 FinancialInstitutionCreditTransferV03”

1|Page

ISO20022 standard Message Implementation ISO20022 Message pacs.009.001.03 FIToFICustomerCreditT ransferV03 Message Item

XML tag

Description

Root tag

GroupHeader


<MsgId>

Index

ISO Multi

RTGS Multi

[1..1]

[1..1]

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]

[1..1]

Rules

Example

Data Type


<MsgId> CCIL201210181000000218

Max35Text

2011-04-24T09:30:32

ISODateTime

3

Max15Numeri cText

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

CreationDateTime

Date and time at which the message was created.

1.2

[1..1]

[1..1]

NumberOfTransaction s

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.

2|Page


XML tag

TotalInterbankSettlem entAmount

InterbankSettlementD ate

SettlementInformation

<SttlmInf>

SettlementMethod

<SttlmMtd>

Description

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.

Index

ISO Multi

RTGS Multi

1.6

[0..1]

[1..1]

1.7

[0..1]

[1..1]

1.8

[1..1]

[1..1]

1.9

[1..1]

[1..1]

Example

Data Type

3400.00

Amount

Value date of payment must be same as RTGS date. Mandatory in RTGS implementation

2011-04-24

ISODate

Must be CLRG (i.e., Settlement done through a payment clearing system). The Code “CLRG” should be default.

<SttlmMtd>CLRG

Code

Rules


Agent that instructs the next party in the

1.21

[0..1]


[1..1]

3|Page


XML tag

Description

Index

ISO Multi

RTGS Multi

Rules

Example

Data Type

[1..1]

[1..1]

[0..1]

[1..1]

[1..1]

[1..1]

Sender IFSC

<M mbId>CCIL0PI0001

Max35Text

[0..1]

[1..1]

[1..1]

[1..1]

[0..1]

[1..1]

[1..1]

[1..1]

Receiver IFSC

<M mbId>RBIS0RTGS00

Max35Text

[1..n]

[1..n]

Multiple occurrence based on number of participants

chain to carry out the (set of) instruction(s).

FinancialInstitutionId entification ClearingSystemMem berIdentification Member Identification

<MmbId>

InstructedAgent

FinancialInstitutionId entification

ClearingSystemMem berIdentification


<MmbId>

CreditTransferTransact ionInformation

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.22

2.0


4|Page


XML tag

PaymentIdentification


<EndToEndI d>

TransactionIdentificati on

Description

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 ed 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 on multiple references, the end-toend identification must be ed 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 ed on, unchanged,

Index

ISO Multi

RTGS Multi

2.1

[1..1]

[1..1]

2.3

[1..1]

[1..1]

Rules

Example

Data Type



Max35Text

CCILR12012042400000023

Max35Text

The format is: i)Participant System ID (First four Characters of sending Bank’s 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).

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]


5|Page


XML tag

Description

Index

ISO Multi

RTGS Multi

throughout the entire interbank chain.

Rules

Example

Data Type

NORM

Code

YYYYMMDD-Date [8] nnnnnnnn- Sequence Number [8]

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


2.6

[0..1]

[1..1]

InstructionPriority

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.7

[0..1]

[1..1]


HIGH / NORM Priority “NORM” will result in liquidity Savings. HIGH: Priority Level is high. NORM: Priority Level is normal.

6|Page


XML tag

Description

Index

ISO Multi

RTGS Multi

ServiceLevel

<SvcLvl>

Agreement under which or rules under which the transaction should be processed.

2.9

[0..1]

[0..1]

Proprietary

Ng Rtgiso20022 2q15a

Overview 26281t

More details 6y5l6z