ISO20022 standard Message Implementation

Frequent Asked Questions (FAQ):

1. What is ISO 20022 standard?

 ISO 20022 - Universal financial industry message scheme (which used to be also called "UNIFI") is the international standard
that defines the ISO platform for the development of financial message standards. Its business modelling approach allows users and
developers to represent financial business processes and underlying transactions in a formal but syntax-independent notation.
These business transaction models are the "real" business standards. They can be converted into physical messages in the desired
syntax. At the time ISO 20022 was developed, XML (eXtensible Mark-up Language) was already the preferred syntax for e-
communication. Therefore, the first edition of ISO 20022 proposes a standardized XML-based syntax for messages. The standard
was developed within the Technical Committee TC68 - Financial Services of ISO - the International Organization for
Standardization.
 The Standard is issued by ISO Technical Committee 68 (TC68), which is responsible for Financial Services in ISO.
 The Standard is managed by Working Group 4 (WG4), a sub-group of TC68 whose charter is "the management of ISO
20022".
 The Standard defines a Repository Management Group who manages the content of the Repository.
 SWIFT is the Registration Authority for ISO 20022.

2. Why was ISO 20022 developed?

The need for ISO 20022 standard arose in the early 2000’s with the widespread growth of Internet Protocol (IP) networking, the
emergence of XML as the 'de facto' open technical standard for electronic communications and the appearance of a multitude of
uncoordinated XML-based standardization initiatives, each having used their own "XML dialect". On top of offering a common way of
using XML, the new standard shields investments from future syntax changes by proposing a common business modelling
methodology (using UML - Universal Modelling Language) to capture, analyze and syntax-independently describe the business
processes of potential users and their information needs.

3. What are the parts of ISO 20022 message?

The ISO 20022 Business Message consists of two parts:

Reserve Bank of India 1|Page

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

(1) ISO 20022 Business Application Header

(2) ISO 20022 Messages

4. What are the ISO messages defined in this document?

i) head.001.001.01 Business- Application Header

ii) pacs.008.001.03 FIToFICustomerCreditTransferV03 : for Customer Credit transfer.
iii) pacs.009.001.03 - FinancialInstitutionCreditTransferV03 : for Interbank transfer, for defining the MNSB request & defining the
Own account transfer in NG-RTGS.
iv) camt.054.001.03 BankToCustomerDebitCreditNotificationV03: for Customer Credit Debit Notification.
v) pacs.002.001.04, FIToFIPaymentStatusReportV04 : for MNSB Response & Own Account Transfer Response in NG-RTGS.
vi) pacs.004.001.03 PaymentReturnV03: to undo a payment previously settled.
vii) camt.053 BankToCustomerStatement end-of-day NG-RTGS statements to the Participants
viii) camt.998.001.02 to transmit various free format information to the Participants
ix) MX admi.004.001.01 SystemEventNotificationV01: to notify the occurrence of an event in a central system.

5. What is the Business Application Header?

The Business Application Header is a header that has been defined by the ISO 20022 community that form part of an ISO 20022
business message. Specifically, the BAH is an ISO20022 message definition (head.001.001.01) which can be combined with any
other ISO20022 message definition to form a business message. It gathers together, in one place, data about the message, such as
which organisation has sent the business message, which organisation should be receiving it, the identity of the message itself, a
reference for the message and so on.

6. Whether all messages will have BAH?

All messages listed above will have the BAH attached to it.

7. What is the purpose of the BAH?

The purpose of the BAH is to provide a consistent and predictable way for this data to be conveyed with the message, regardless of
implementation factors such as the choice of network. This does not prevent such data being conveyed either within the ISO 20022
message definition itself, or as part of a network header.

8. What’s in the BAH?

Reserve Bank of India 2|Page
FAQ on NG-RTGS
 ISO20022 standard Message Implementation

The BAH consist of 9 building blocks

From: This mandatory field contain the details about the organisation that sent the message.
In NG-RTGS the inward messages will always be originated from RBI because of the ‘V’ topology, hence this field will always have
the IFSC of RTGS for all inward messages to the bank..
To: This mandatory field contains the details about the organisation that should receive the message.
In NG-RTGS the outward messages will always directed to RBI because of the ‘V’ topology, hence this field will always have the
IFSC of RTGS for all outward messages from the bank.
Business Message Identifier: a unique identifier for this particular message instance, as defined by the sending application or
system;
Message Definition Identifier: the identity of the message definition
BusinessService: To identify the Business service.
Creation Date: the creation date (and time) for the data in the BAH;
Copy Duplicate and Possible Duplicate: fields to aid the identification of duplicate data;
Signature: Contains the digital signature of the Business Entity authorised to sign this Business Message.
Related: Specifies the Business Application Header of the Business Message to which this Business Message relates. Can be used
when replying to a query; can also be used when canceling or amending.

9. What is the member identification used in BAH?

Member identification is a mandatory field. The existing 11 character IFSC (Indian Financial System Code) is used
as Member Identification. It is formed as below
Character Information Remarks
position
First four Bank code Four Characters of bank Code
characters
Fifth Zero Reserved for future use
character
Last six Branch code Banks to use their existing codes with
characters no white spaces(zeroes prefixed)

10. What is the BusinessMessageIdentifier in BAH?

Reserve Bank of India 3|Page

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

. It is a mandatory field which uniquely identifies the message. It is defined as 22 character unique number as given
below:
XXXX – Sender IFSC [4] first four characters of the IFSC
YYYYMMDD – creation date [8]
X – channel identification [1]
Nnnnnnnnn Sequence Number [9]

The Channel Identifier (X) may be used to identify channels such as Internet banking, Cash Management, Treasury, ATM, etc.

The values suggested are:

Channel ID Values
NG-RTGS 9
Internet Banking 1
Cash 2
Management
Treasury 3
ATM 4
Other 5

11. What is MessageDefinitionIdentifier?

It is a mandatory field which defines the name of the Business Message as published on the ISO 20022 website.
E.g. pacs.008.001.03

12. What is BusinessService?

It is a mandatory field specifying the business service agreed between the two MessagingEndPoints under which rules this Business
Message is exchanged. It comprises a fixed value of “RTGS”, and in the case of BAH for pacs.008 and pacs.009 the fixed value of
“RTGS” must be followed by the local instrument name, i.e.
for RTGS, BAH for pacs.008: ‘RTGSFIToFICustomerCredit’.
For RTGS, BAH for pacs.004; ‘RTGSPaymentReturn’

For RTGS, BAH for pacs.009:-‘RTGSFIToFICredit’ or -‘RTGSOwnAccTtransfer’ or -‘RTGSNetSettlementXXzNN’

Reserve Bank of India 4|Page

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

Where ‘XX’ is the clearing type which may take values ‘GC’, ‘IB’, ‘FX’, MC, SE, OT & so on.

‘z’ is the indicator which may take values C –Original, R-Return, L-Last Return.
“NN” is the return serial.

“GC” stands for guaranteed settlement of Securities and CBLO segment.

"IB" stands for guaranteed settlement of FOREX segment.
"FX" stands for non guaranteed settlement.
“MC” Stands for MICR Clearing
“SE” stands for non-guaranteed MNSB
“OT” stands for Other MNSB

13. How to define CreationDate?

It is a mandatory field which is defined as the Date and time when this Business Message (header) was created. The
format is yyyy-mm-ddThh:mm:ss. Time upto second is recorded.

14. How CopyDuplicate is used in BAH?

It indicates whether the message is a Copy, a Duplicate or a copy of a duplicate of a previously sent ISO
20022 Message DUPL Duplicate(Message is for information/ confirmation purposes. It is a duplicate of a message previously sent).
Valid Values are:
CODU
COPY
DUPL

15. What is stored in Signature field?

It contains the digital signature of the Business Entity authorised to sign this Business Message(payload). The Sgntr block contains
the following elements.

Message item XML Tag

SHA2 Signatures <XML Sgntrs>

Reserve Bank of India 5|Page

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

16. How the end-to-end security is ensured in NG-RTGS transactions.

The RequestPayload will be used as single message tag which will contain both BAH along with signed and encrypted Business
Message. The signature is attached in the BAH in <XML Sgntrs> tag before transmitting the message to NG-RTGS system by the
bank. Further, the business message will be encrypted before it is transmitted over the Wide Area Network (WAN).

17. Can the bank use Straight Through Processing (STP) between CBS and NG-RTGS?
The banks can use STP between CBS and NG-RTGS in two possible ways
The STP between the CBS and NG-RTGS is faciliated by either the SFMS thick client or by the implementation of the web-service
API provided it is PKI enabled. For the API option the requirements on the bank’s CBS are:
- Implementation of a client for the API (or purchase an equivalent commercial product) and integration of the client with the
CBS
- Owning a valid certificate to be able to connect to the NG-RTGS.

For the thick client the SFMS infrastructure (updated with the latest patch for the MI client as provided by IDRBT) may be
upgraded with proper sizing if required.

18. When the field Related can be used?

The Related field can be used while replying to a query; can also be used when canceling or amending a transaction. This field must
be present when CopyDuplicate field is present.

19. How a FIToFICustomerCreditTransfer message is defined?

FinancialInstitutionToFinancialInstitutionCustomerCreditTransfer message is sent by the debtor agent to the creditor agent, directly
or through other agents and/or a payment clearing and settlement system. It is used to move funds from a debtor account to a
creditor. The FIToFICustomerCreditTransfer message is composed of two building blocks (i) Group Header (ii) Credit Transfer
Transaction Information.

(i) Group Header: This building block is mandatory and present once. It contains elements such as MessageIdentification and
CreationDateAndTime.
Reserve Bank of India 6|Page
FAQ on NG-RTGS
 ISO20022 standard Message Implementation

(ii) Credit Transfer Information: This building block is mandatory and for RTGS it will be present only once. It contains
elements related to the debit and credit side of the transaction such as Creditor, CreditorAgent, Debtor and DebtorAgent.

20. What is MessageIdentification?

It is a mandatory field and is same as the BusinessMessageIdentifier defined in the BAH above.

21. What is CreationDateTime and how it is different from the CreationDate defined in BAH?
CreationDateTime is the mandatory filed containing date and time at which this message was created and the CreationDate is the
date and time at which the message header is created. The format of the date time is same throughout the message.
.

22. How the field NumberOfTransactions <NbOfTxs> is defined?

It provides the number of individual transactions contained in the message. The default value is 1 for Pacs.008 and Pacs.009
messages and ten(10) or more for NEFT. In some situations, viz. at the end of the batch or end of day, the number of NEFT
transactions can be less than 10. In MNSB request this is defined as the number of participants in the batch. The datatype is
numeric. It is a mandatory field.

23. What the field TotalInterbankSettlementAmount <TtlIntrBkSttlmAmt> used for?

This mandatory field 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 7|Page
FAQ on NG-RTGS
 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:
<TtlIntrBkSttlmAmt Ccy='INR'>2345</TtlIntrBkSttlmAmt>

24. What is InterbankSettlementDate <IntrBkSttlmDt>?

It is a mandatory field providing the settlement date.
Data Type: ISODate

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

26. 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 ClearingSystem Settlement is done through a payment clearing system.

COVE CoverMethod Settlement is done through a cover payment.
INDA InstructedAgent Settlement is done by the agent instructed to execute a
payment instruction.
INGA InstructingAgent 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.

Reserve Bank of India 8|Page

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

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

28. What is FinancialInstitutionIdentification field used for?

This is a mandatory field which provides the identification of the Financial Institute referred to.

29. What details to be entered in ClearingSystemMemberIdentification field?

This mandatory field is used to enter the details of the participating bank. The mandatory sub-field MemberIdentification is used to
provide IFSC of the concern participant. In case of InstructingAgent this field contains the IFSC of sending bank, while for the
InstructedAgent this field contain the IFSC of the receiving bank.

30. What is InstructedAgent?

This mandatory field gives information about agent that is instructed by the previous party in the chain to carry out the (set of)
instruction(s). It is defined by using FinancialInstitutionIdentification- ClearingSystemMemberIdentification- MemberIdentification. It is
mandatory in RTGS implementation.
In case of Own Account Transfer this field provides the RBI IFSC.

31. How to use the field CreditTransferTransactionInformation ?

It is mandatory and is a set of elements providing information on individual transactions. Only one occurrence allowed for Customer
Payment in RTGS system and 10 or more for NEFT. In case of Pacs.009 used for MNSB request multipal occurrence based on
number of participants is allowed.
The elements are: PaymentIdentification <PmtId>, PaymentTypeInformation <PmtTpInf>, ChargesInformation <ChrgsInf>,
Debtor <Dbtr>, DebtorAccount, <DbtrAcct>, DebtorAgent <DbtrAgt>, Purpose <Purp>, ……., RemittanceInformation <RmtInf>.

32. How to use PaymentIdentification <PmtId> field?

It is a mandatory field giving set of elements used to reference a payment instruction.
Type: This message item is composed of the following PaymentIdentification element(s):
Message Item <XML Tag> Mult. Represent./
Type
InstructionIdentification <InstrId> [0..1] Text
EndToEndIdentification <EndToEndId> [1..1] Text
Reserve Bank of India 9|Page
FAQ on NG-RTGS
 ISO20022 standard Message Implementation

TransactionIdentification <TxId> [1..1] Text

i) InstructionIdentification <InstrId>

Presence: [0..1]
Definition: Unique identification, as assigned by an instructing party for an instructed party, to unambiguously
identify the instruction.
Usage: The instruction identification is a point to point reference that can be used between the instructing
party and the instructed party to refer to the individual instruction. It can be included in several messages
related to the instruction.
Data Type: Max35Text
Format: maxLength: 35
minLength: 1

During the transition of existing member systems to the new ISO message formats, it is used for supplementary identification, such
as the legacy transaction reference number (R41/R42.2020).

ii) EndToEndIdentification <EndToEndId>

Presence: [1..1]
Definition: Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is
passed on, unchanged, throughout the entire end-to-end chain.
Usage: The end-to-end identification can be used for reconciliation or to link tasks relating to the transaction.
It can be included in several messages related to the transaction.
Usage: In case there are technical limitations to pass on multiple references, the end-to-end identification must be passed on
throughout the entire end-to-end chain.
During the transition of existing member systems to the new ISO message formats, the EndToEndId 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:

 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)
Reserve Bank of India 10 | P a g e
FAQ on NG-RTGS
 ISO20022 standard Message Implementation

iii) TransactionIdentification <TxId> This is a mandatory field.

Definition: Unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is passed
on, unchanged, throughout the entire interbank chain.
Usage: The transaction identification can be used for reconciliation, tracking or to link tasks relating to the transaction on the
interbank level.
Usage: The instructing agent has to make sure that the transaction identification is unique for a pre-agreed period.
Data Type: Max35Text
Format: maxLength: 35
minLength: 1

In our case it is the Unique Transaction Reference (UTR) which would be of 22 characters
Format is:
XXXX- Sender IFSC [4]
X-Payment System [1]
X-Channel [1]
YYYYMMDD-Date [8]
nnnnnnnn- Sequence Number [8]

The Channel Identifier (X) may be used to identify channels such as Internet banking, Cash Management, Treasury, ATM, etc.

The values suggested are:

Channel ID Values
NG-RTGS 9
Internet Banking 1
Cash 2
Management
Treasury 3
ATM 4
Other 5

33. What data is to be provided in PaymentTypeInformation <PmtTpInf>

Reserve Bank of India 11 | P a g e
FAQ on NG-RTGS
 ISO20022 standard Message Implementation

This mandatory field contains set of elements used to further specify the type of transaction.
Type: This message item is composed of the following PaymentTypeInformation element(s):
Message Item and <XML Tag> Mult. Represent/ Type
InstructionPriority <InstrPrty> [1..1] Code
ServiceLevel <SvcLvl> [0..1]
LocalInstrument <LclInstrm> [1..1]
CategoryPurpose <CtgyPurp> [1..1]

i) InstructionPriority <InstrPrty>
Presence: [1..1]
Definition: Indicator of the urgency or order of importance that the instructing party would like the instructed party to apply to the
processing of the instruction.
Data Type: Code
The default priority assigned to every message is HIGH.

Code Name Definition

HIGH High Priority level is high
.
NORM Normal 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./
Item Type
2.11 Proprietary <Prtry> [1..1] Text

Proprietary <Prtry>
Presence: [1..1]

Reserve Bank of India 12 | P a g e

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

Definition: Specifies a pre-agreed service or level of service between the parties, as a proprietary code. For RTGS processing
priority is in range 00 – 99. This field also contain the Transaction Type code (TTC) along with the priority value. TTC values will be
used to differentiate the transactions within the same type of transaction. e.g. in the pacs.009 transaction message the MNSB Own
account transfer and Interbank transaction will have different TTC values.

Use: To be used for managing queues by sending bank before settlement.

Data Type: Max35Text
Format: maxLength: 35: For RTGS lower the number highest will be the priority.
For Banks priority range is from 11 to 99. Priority from 00 to 10 is reserved for RBI.
<SvcLvl>
<Prtry>
[TTC=xxxx],[PRI=xx]
</Prtry>
</SvcLvl>

Value 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 accounts 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,
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 accounts only.
5021 This applies to the original request sent by NG-RTGS to CBS (step 3)

Reserve Bank of India 13 | P a g e

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

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

Presence: [1..1]
Definition: User community specific instrument.
Usage: This element is used to specify a local instrument, local clearing option and/or further qualify the
service or service level.
Type: This message item is composed of one of the following LocalInstrument2Choice element(s):

Index Message <XML Tag> Mult. Represent./

Item Type
2.14 Proprietary <Prtry> [1..1] Text

Proprietary <Prtry>
Presence: [1..1]
Definition: Specifies the local instrument, as a proprietary code. Type of local instrument.
For RTGS pacs.008 use:
- ‘RTGSFIToFICustomerCredit’
For RTGS, pacs.009 use:
-- ‘RTGSFIoFICredit’
-- ‘RTGSOwnAccTransfer’
- -- ‘RTGSNetSettlementXXzNN’
For Return Payment use:
- ‘RTGSPaymentReturn’
Reserve Bank of India 14 | P a g e
FAQ on NG-RTGS
 ISO20022 standard Message Implementation

Data Type: Max35Text

Format: maxLength: 35

iv) CategoryPurpose <CtgyPurp>

Presence: [1..1]
Definition: Specifies the high level purpose of the instruction based on a set of pre-defined categories. Purpose of the Instrument.
Payment purpose must be a value listed in ISO category purpose code
Type: This message item is composed of one of the following CategoryPurpose Choice element(s):
Index Message <XML Tag> Mult. Represent./
Item Type
2.16 Code <Cd> [1..1] Code

Code <Cd>
Presence: [1..1]
Definition: Category purpose, as published in an external category purpose code list.
Data Type: ExternalCategoryPurpose1Code
Format: maxLength: 4
minLength: 1
Default value: CASH

FROM ISO 20022External Code list

The following codes are available.

CASH: CashManagementTransfer
CORT: TradeSettlementPayment
DIVI: Dividend
GOVT: GovernmentPayment
HEDG: Hedging
INTC: IntraCompanyPayment
INTE: Interest
LOAN: Loan
Reserve Bank of India 15 | P a g e
FAQ on NG-RTGS
 ISO20022 standard Message Implementation

PENS: PensionPayment
SALA: SalaryPayment
SECU: Securities
SSBE: SocialSecurityBenefit
SUPP: SupplierPayment
TAXS: TaxPayment
TRAD: Trade
TREA: TreasuryPayment
VATX: ValueAddedTaxPayment
WHLD: WithHolding

The generic code for the normal funds transfer may be 'CASH'.
Example: <CtgyPurp><Cd>CASH</Cd></CtgyPurp>

34. How the funds are pushed and sweep back at the time of SOD (Start of Day) and EOD(End of Day) respectively?
The message format used for balance sweeping is Pacs.009 MNSB transaction.

a) For SOD:
- one debit against the settlement account of RBI in amount equal to the sum of all credits
- multiple credits against the settlement accounts of the Participants that have their balances initialized

b) For EOD:
- multiple debits against the settlement accounts of all Participants with a non-zero balance in NG-RTGS
- one credit against the settlement account of RBI in amount equal to the sum of all debits
Distinct TTC values are used for these two transactions
For SOD the TTC value is 5050 whereas for EOD the TTC is 5051

35. What data is 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.

36. What is meant by ChargeBearer field?

Reserve Bank of India 16 | P a g e
FAQ on NG-RTGS
 ISO20022 standard Message Implementation

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.

37. What is ChargesInformation?

This optional field 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).

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

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

40. 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 is mandatory.
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.
41. How to use the DebtorAccount field?
This mandatory field provides the identification of the account of the debtor to which a debit entry will be made as a result of the
transaction. It consists of the following sub elements

Reserve Bank of India 17 | P a g e

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

Identification: Mandatory field having a sub field named ‘Other’ in which a field named ‘Identification’ will have the debtor’s account
number.

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

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

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

45. How to give the creditor account details?

The CreditorAccount field is used to provide the creditor’s account details. This mandatory field is used for identification of the
account of the creditor to which a credit entry will be posted as a result of the payment transaction.

46. 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) Code <Cd>

(ii) InstructionInformation <InstrInf>

47. How to use the code field <Cd> ?

The coded information related to the processing of the payment instrument, provided by the initiating party is given in this field. The
following codes are used:

Reserve Bank of India 18 | P a g e

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

PHOB = Phone Beneficiary

TELB=Telecom
CHQB= PayCreditorByCheque
HOLD= HoldCashForCreditor

48. How to use InstructionInformation field <InstrInf> ?

Further information complementing the coded instruction or instruction to the next agent that is bilaterally agreed or specific to a user
community. It is of Datatype Max140Text.

49. Where to give the sender to receiver 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.

50. How to use the field Notification?

This field notifies the debit and credit entries for the account. This block is composed of the following elements:
Identification: Unique identification, as assigned by the account servicer to unambiguously identify the account notification.
CrationDatatime: ISO date time
Account: Unambiguous identification of the account to which credit and debit entries are made.
Entry: Set of elements used to specify an entry in the debit credit notification. At least one reference must be provided to identify the
entry and its underlying transaction(s).

51. What is TransactionInformationAndStatus <TxInfAndSts>?

It is related to pacs.002.001.04, FIToFIPaymentStatusReport. It is the Information concerning the original transactions, to which the
status report message referred to.

52. How to use the field OriginalGroupInformationAndStatus?

This field provides the original group information concerning the group of transactions, to which the status report message refers to.
It has the following sub fields
OriginalMessageIdentification <OrgnlMsgId>: Mandatary field for point to point reference, as assigned by the original instructing
party, to unambiguously identify the original message.

Reserve Bank of India 19 | P a g e

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

OriginalMessageNameIdentification <OrgnlMsgNmId>: This mandatory field specifies the original message name identifier to which
the message refers.

OriginalCreationDateAndTime <OrgnlCreDtTm> This mandatory field provides Date & time at which the original message was
created.

GroupStatus <GrpSts> Madatory field which specifies the status of a group of transactions.
Status code- CSC/ACSP/ACTC/ACPT/PDNG/RCVD/RJCT/ACCR /ACWC.

ACSC: AcceptedSettlementCompleted
ACSP: AcceptedSettlementInProcess
ACTC: AcceptedTechnicalValidation
ACCR: AcceptedCancellationRequest
ACPT: Accepted
ACWC: AcceptedWithChange
PDNG: Pending
RCVD: Received
RJCT: Rejected

For details on status code, pl refer to para 2.6 of documentation “Payment Clearing & Settlement – Maintenance 2012 by ISO”.

53. What is StatusReasonInformation field?

This optional field provides detailed information on the status reason. (Reason for success / failure).

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

55. How the messages will flow from bank’s CBS to the thick client?
The RTGS message will flow in the same manner as the SFMS messages except that The RequestPayload will be used as single
message tag which will contain both BAH along with signed and encrypted Business Message. The signature is attached in the BAH

Reserve Bank of India 20 | P a g e

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

in <XML Sgntrs> tag before transmitting the message to NG-RTGS system by the bank. Further, the business message will be
encrypted before it is transmitted over the Wide Area Network (WAN).

56. Is XML signature used for digitally signing the message?

XML signature are not needed and the messages will be signed with PKI based SHA2 signature.

57. In case we opt to route the RTGS Messages through SFMS, do we require PI Server?
Ans: SFMS will provide a patch for the existing SFMS application. Once this patch is installed on the SFMS gateway server the
same server can act as the thick client Member Interface (MI) for NG-RTGS. PI server will not be needed in the NG-RTGS
environment, however; the banks may decide about the up-keeping of the PI server depending upon the archival policy of the
respective bank.

58. In case we don’t require PI Server, whether HSM is required?

Ans: Currently the SFMS application is not using the HSM card for cryptography; however, IDRBT has planned to upgrade the
SFMS application to facilitate the hardware based encryption. Hence, the HSM cards may be required in the new version of SFMS
application.

59. If HSM also is not required, how can we sign the outgoing RTGS messages? Will it be using Class2 or Class 3
certificate?
Ans: It is expected from the banks to sign the messages in the CBS application itself. However, in the absence of CBS application
being able to generate the ISO 20022 standard message formats and signed the same, the MI client will digitally sign and encrypt
the message.
The messages will carry a class 2 signature if the bank is using maker checker concept and if the process is STP the bank should
use class 3 server signatures to sign the outgoing messages.

60. If we can use Class2, whether we can use the same certificate as the one used for NEFT.
Ans: As explained above the class 2 signature can be used in the maker checker concept.

61. In the present situation, we are supposed to fetch the certificates of other banks periodically. How this can be done in
Next Gen RTGS?

Reserve Bank of India 21 | P a g e

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

Ans: The certificate containing the public key of the signer will be embedded in the signer information of the digital signature, so
that there is no need to distribute public keys separately. However, the banks will have to maintain the CRL list as published by
IDRBT CA.

62. Whether there’s any chance of a DR Drill for RTGS alone once the new system comes in to effect and we use SFMS to
route the RTGS messages?
Ans: The DR drill will be conducted as per the RBI BCP policy.

63. Whether we will have SOD/EOD concept?

Ans: There will not be any EOD/SOD for Web API Services client as this will be based on a pull mechanism. Usual EOD/SOD will
happen in the thick client provided by IDRBT.

64. How the Message archiving will be done in the new scenario in case we don’t have SOD/EOD?
Ans: The Web API services will be granted throughout the day, even before SOD and after EOD. The bank may design the Web
API Server client with or without the database. The management of the Web API Server client database if any, will be handled by
the banks.

65. What are the specification for Web API Services client?
Please refer to the Annex –I

66. As discussed, our Bank has RTGS Membership but we have not yet started the RTGS Participation. We would like to go
for Next Gen RTGS. Kindly provide us some guidelines, information on the same. Also request you to add my name in
future programme, session, training, workshop related to Next Gen RTGS also others technology which may be useful.
Ans: As we are maintaining the address details of all RTGS members, you would be receiving operation manuals and software and
other details after you fulfil the membership criteria asked by the Bank. Regarding NG-RTGS, we would be sharing the information
to all members of existing RTGS system. No separate request for NG-RTGS is required.

67. In our case, the RTGS and NEFT applications inward / outward messages are settling through STP (Straight Trough
Process) and the CBS is maintained by HO team. The NG-RTGS is web / browser based in that case how messages are
routing to CBS and vice versa.
Ans. At any given point of time only one NG-RTGS client will be operating at the banks’ end. If the messages are settling through
STP mode then the browser based client can only be used for viewing the reports. No transaction can be initiated through it.
Reserve Bank of India 22 | P a g e
FAQ on NG-RTGS
 ISO20022 standard Message Implementation

68. Kindly share RTGS migration plan to enable us to request same with HO team.
Ans: Migration plan will be shared shortly.

69. Is there any PI equivalent acknowledgements in NG RTGS viz R90 message?

The MX admi.004.001.01 SystemEventNotification will be used in place of R90. The following code will be used in the response
message

F20 – Acknowledgement Message

F25 - Negative Acknowledgement
F23 - Delivery Notification message
F22 - Non-delivery Warning message
F27- Bank API Response Message

70. Will RBI send settlement notification (Pacs.002.001.04) for all customer (pacs.008.001.03) and interbank
(pacs.009.001.03) payment messages i.e. Positive and Negative settlement notification?
RBI will send camt.054 message as debit and credit notification for all customer transactions and will send pacs.002 message for
MNSB response and Own Account transfer response.

71. RBI settlement acknowledgement will be based on <EndToEndId> 16 digit or <MsgId> 22 digit?
The settlement acknowledgement will contain both the IDs <EndToEndId> and <TxId> transaction identification.

72. Is there any validations on the ISO message received from Banks performed at RBI system, if yes then what are the
validations?
The message validation will be performed at RBI system for all fields defined in the message format. In case of thick client, the thick
client will verify the ISO message before sending it to RBI. In case of Web based API services, the API client will verify the message
before sending it to RBI.

73. Does NG RTGS allow Banks to warehouse transactions at RBI e.g. Future dated transactions
The facility of Future value dated transaction will be made available after the policy decision.

Reserve Bank of India 23 | P a g e

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

74. What is the security class certificate to be attached to NG RTGS ISO messages?
All messages will be signed by the banks before it reach the NG-RTGS system. If the bank is adopting maker checker concept the
class II user certificates will be attached to the message and in case of STP the class 3 server certificates will be used.

75. What is the encryption method for ISO Messages?

The Member Interface (MI) will encrypt the message in the same manner as that of SFMS messages. Currently the messages will
be encrypted using software based encryption, however, IDRBT will be upgrading the SFMS application for using hardware based
encryption.

76. By when the mapping document of Rxx-MX will provided to the banks.
Ans: The mapping document is available on the RBI website.

77. By when all business rules would be ready in view of the revision in the message format document.
Ans: The business rules are published on the RBI website.

78. If a bank is sending XML transactions via SFMS application server, also can the bank User will be allowed login to Web
browser and Create/approve OAT transactions ?
Ans: There would be three modes of access for accessing NG-RTGS application. i.e., Thick Client, Web API Server and Browser
based Client. All these modes will be made available over INFINET for the present. As a part of BCP Strategy, in case INFINET is
down, browser based client through Internet will be enabled for Banks. All these modes of Access will be PKI enabled. Banks need
to define their primary terminal and Secondary terminal at the time of participating in NG-RTGS. Initiation of transactions would
happen at Primary Access mode of the bank. Browser based clients would be provided to all the banks for querying the status of the
transaction irrespective of their choice of access mode. However, at any point of time, banks would be allowed to initiate their
financial transaction using only one access mode which will be declared by the banks and accordingly configured in the NG-RTGS
application and would be used for the purpose of routing in normal case. Secondary mode of access will be allowed only in case
failure of primary mode of access.

79. Will an existing PI user's e-Token with a digital certificate can be used to access NG-RTGS system as well?
Ans: Yes. The Web API Server client will be fully STP based hence no user will be involved. In the browser based client and thick
client for maker-checker process the e-tokens can be used. The existing e-tokens, if supported by the NG-RTGS application can be
used.

Reserve Bank of India 24 | P a g e

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

80. For default Purpose code, earlier it was mentioned that 'OTHR' has been included in the list of code and can be used as
a default code. However in the revised document, we can't locate OTHR code and also default code has been identified as
'CASH'. Kindly clarify?
Ans: The revised formats are frozen for the development. However, the codes may undergo addition/changes depending upon the
same registered with the ISO Registration Authority.

81. For Web API Services interface between CBS and NG-RTGS system, can we know whether the interface will ride on MQ
or https connectivity?
Ans:The Web API interface will be based on HTTPS protocol only. For Connecting to NG-RTGS system Web API Server would be
provided by NG-RTGS solution provider. However, building necessary interface from CBS of your banks to the Web API Server
rests on the bank.

82. Earlier in the present system (PI System) RTGS and message hub used to lie at RBI. Now the message hub is lying at
IDRBT or at RBI?
The message hub would reside at both the locations IDRBT and RBI. However, it does not matter to the user.

83. Return Payment Flow-Failures (Unsuccessful settlement) – In the current RTGS setup the returns are by the way of R42
message, but whereas in NG-RTGS returns are by way of R41 message. Which format is used currently?
A separate message format pacs.004.001.03 PaymentReturnV03 will be used for return payment in the NG-RTGS system.

84. What is the difference between Y topology & V topology?

RBI opted for V topology to implement NG-RTGS in multiple channels. In the Y topology the core RTGS application acts as the
settlement engine and all other jobs are performed by the routing application (in our case IFTP). The IFTP was stripping the
message and holding the information till the message is processed at RTGS system. All the communication from the banks with the
RTGS happened only through the IFTP. In the V topology the full message as sent from the bank is received, processed and
responded by the central RTGS system
RBI has opted for V topology to enable multiple channels in NG-RTGS.

85. R-20/F-20 and R23/F23 remains same as NEFT?

Please refer to Q. 68.

Reserve Bank of India 25 | P a g e

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

86. Validation of IFSC-Some branches initially enabled only for NEFT then for RTGS. IFSC type is SFMS. Are you going to
introduce some more IFSC’s?
NEFT IFSC’s are validated with NEFT IFSC’s only.

87. Is there any new field which is there in xml and which is not there in earlier message formats?
Kindly see the mapping document as available on RBI website.

88. Every message received from NG-RTGS forwarded to core banking. Can we hold the messages at SFMS, if in case
CBS is not able to process the messages?
SFMS will not hold the message, after initial validations it will pass on the message to the next node i.e. CBS.

89. Dash Board is available for all messages. Not differentiating between RTGS & NEFT messages?
Separate dashboard will be available for both the applications.(SFMS team to confirm)

90. Regarding multiple application – Can we push transactions for multiple back offices for RTGS?
Multiple Back office applications can interface with CBS of the Bank and then in turn can interface with NGRTGS.

91. RTGS messages mandatorily signed at CBS at Block A or at Block 4?

Currently the signature is put in Block 5 however, in the NG-RTGS the signature will be put in the tag <XML Sgntrs> in BAH.

92. Is there any flag to put the regular signature in the Current R series message?
Structure is Block A, Block 4 and Block 5A. Block 5A contains signature.

93. If bank’s application is not ready for ISO message then bank will send MT message to MI. MI will convert the message
to ISO format then whether that signature is valid at bank end or not?
MI after receiving the signed MT message will validate that signature with content of data, if the validations are successful then it will
generate xml message and sign with the server certificate of MI.

94. Details about the changes in MQ in new environment?

Guidelines will be given to configure MQ in new environment for the thick client. The Web API services will only use HTTPS
protocol.
Reserve Bank of India 26 | P a g e
FAQ on NG-RTGS
 ISO20022 standard Message Implementation

95. Plan of RBI for transmitting xml and text format in parallel?
NG-RTGS will only use ISO20022 standard message format for receiving and sending the messages. If converters are used at bank
end then the bank has to send and accept R series message to and from the convertor.

96. Is RBI planning to use any converters?

IDRBT will be providing a patch for the SFMS application which will convert the R series messages into ISO 20022 standard
message format. However, use of convertor is only for interim period till bank migrate to ISO 20022 formats and share its plan of
migration with RBI.

97. Details of the time when RBI test setup should be available for the banks.
By March 2013 the RBI NG-RTGS system will be available for testing

98. Primary dealer (type B member) of existing RTGS system who do not have NEFT or SFMS. Whether existing RTGS will
be discontinued or they need to move SFMS as a fresh?
These members can move to thin client as the transaction volume is not high.

99. Banks are having two servers one for SFMS and the other for RTGS and using same infinite network for incoming
messages. All their messages will be directed through the same network or not?
It is technically feasible to use the same network however, a document will be provided after thorough testing.

100. What is the size of the ISO message?

The full ISO message size is 6Kb - (full xml – (2K), business header – (0.8K) and signature – (3K))

101. Time frame for implementation ?

Pilot testing of the application will begin on April 1, 2013 with selected Banks.

102. At treasury level (Settlement Account) will there be any change at the bank end?
No. Liquidity Reservation facility is available in the application. Banks has to decide whether they want this facility or not.

103. Own Account transfer through E-kuber will be available or banks have to use NG-RTGS only?
Both applications will have OAT facility, banks can use anyone of them.
Reserve Bank of India 27 | P a g e
FAQ on NG-RTGS
 ISO20022 standard Message Implementation

104. How LAF will be conducted?

Currently LAF is settling in E-kuber. It will continue to settle in E-kuber. A policy decision will be taken on the continuation of LAF in
E-Kuber application. RBI will intimate the banks accordingly.

105. Message creation facility is available in PI system in the current RTGS application. Will such facility be available in
NG-RTGS?
In NG- RTGS PO systems is available through which one can originate the transaction.

106. In PI banks have right to reject or cancel any transaction? Is this facility available in NG-RTGS?
Transaction level visibility will be available in the application. Further, there is two level authentication available for each
transaction. The transaction can be cancelled before settlement.

107. Any transactions originated by branches can be cancelled in MI?

Transaction cancellation facility is available till the transaction is not settled.

108. Will there be any second level authorization for STP transactions at MI level?
For STP mode there is no need to authorize. However, an alert gets displayed for very high value transactions.

109. Can the Alert be configured?

Alerts are configured centrally and set by RBI. In NG-RTGS there will be visibility of bank’s accounting position.

110. What will be the Logic for CBS to generate the signature?
CBS will digitally sign the ISO 20022 message in the <XML Sgntrs> tag to provide authenticity and non-repudiation by the bank.

111. Whether the digital signature has to be done by the banks at ground level or can it be done centrally?
Banks can take this policy decision, however, the NG-RTGS application accept a digitally signed ISO 20022 message only.

112. What is the Reverse Repo Code for IDL?

The reverse Repo Transaction Type code (TTC) for IDL is 5031.

113. RBI Accounts (Existing and Proposed settlement accounts)?)

Reserve Bank of India 28 | P a g e
FAQ on NG-RTGS
 ISO20022 standard Message Implementation

Each participant will have one Settlement Account in the NG-RTGS system. Participants may also use reserve accounts to put
funds aside for specific purposes, as described in Figure below:

114. What is the equivalent ISO 20022 message for R09? (Notification after settlement)
‘camt.054.001.003 BankToCustomerDebitCreditNotification’ will be used to send a debit notification to the sending bank. Except for
MNSB transactions, no credit notification will be sent for successful transactions.

115. Is there any need to upgrade the existing infrastructure for NG-RTGS?
The banks which will be using MI thick client may take the policy decision depending upon their transaction volume and scalability of
the SFMS infrastructure at their end.

Reserve Bank of India 29 | P a g e

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

116. Whether a bank has to purchase message broker application from IDRBT or they can choose from outside vendors?
No message broker solution is required for thick client.
117. What will be the cost involved for participating in NG-RTGS?
For using the PO client, zero cost will be incurred by the bank if they are having INFINET connection.
For using Web API services, the bank will have to build an interface for STPing the transactions to the central web API server.
For using MI thick client, the bank if required will upgrade the hardware as per the sizing requirement.

118. What will be the prerequisite for the existing SFMS for accommodating NG-RTGS?
IDRBT will release the new patches for accommodating the NGRTGS requirements in the SMFS infrastructure. These patches will
be part of the SFMS AMC.

119. Whether SFMS module patch will also take care of digital signature provided the banks take the signature from IDRBT
or will that have to be incorporated at the separate level?
The SFMS module can take care of the digital signature however, RBI except the bank to sign the messages through their CBS
application.

120. Whether network connection is a Broadband Connection or INFINET connection?

The IFINET connections will be used for network.

121. In NG-RTGS, where the database will be maintained?

The NG-RTGS application will have live data of last 7 days. However, the RBI Data warehouse CDBMS will store the older data.

122. Whether small banks do not require the MQ series and other things to connect to the NG-RTGS?
The small banks can connect through PO client which only needs an INFINET connection.
123. Whether the user administration of the PO will be with the Bank or RBI?
The PO user administration will reside with the banks.

Reserve Bank of India 30 | P a g e

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

For the PO, the user management will take place centrally in the PO application. Here, every user will have a profile and a
password. Also, he/she will be required to have a certificate stored on a e-Token. The bank can assign a security officer who can
manage the user profile for that bank, revoking or assign new functions to their users as found appropriate.

124. In case of thin client database will be at RBI end. But in case of thick client whether bank needs to mount the database
locally.
The database holding the messages entered in PO and the rest of the information is central, at RBI. . The messages received by the
NG-RTGS via the API will be stored in the same central database as the messages received directly from the thick client.

The existing SFMS infrastructure will be used for the thick client. Hence, the database for thick client will reside locally at bank end.

125. In the current scenario we are having production NR and DR. So in this case can we eliminate the NR factor over
here?
This policy decision may be taken by the banks.

126. In the current scenario FINACLE is sending message to RBI through MQ. In NG-RTGS what will be the media?
The Messaging middle ware will be MQ for the thick client. Banks need to develop an interface to the Web API server.

127. Can we merge the existing database in NG-RTGS?

No.

128. From end-to-end successful payment message, how many acknowledgement messages are we going to get?
Kindly see the message flow document.

129. If ISO validation failed in the message, then how it will be responded?
The invalid message cannot be submitted. The ISO validation will be performed by the thick client or Web API Services client.

130. Are there any options available to set a slab wise authorization labels?
User management will be available with the banks, through which they can set the authorization levels.

Reserve Bank of India 31 | P a g e

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

131. Do we have any similar features in PO & Thick client? Or is there any difference?
The thick client can directly be connected to the CBS application for STP. Further it will have its own database and the processing
capacity will be high as compare to PO.
The transaction details needs to be keyed-in in the PO client, the STP facility will not be available here. The transaction response
will be pushed to the thick client, where as the PO and API client will need to pull the response from RBI.
The reports will be only available from NG-RTGS browser access and not from the thick client.

132. In PO module can there be still any integration with CBS?

No, the PO module is meant for manual entry in the application.

133. Whether there is any need to convert the existing data to ISO XML format for future reference?
No, depending upon the data archival policy of the banks, the banks have to maintain and manage the PI server database
for the required time period.

134. How performance of the system will improve in NG-RTGS?

The NG-RTGS system is designed to handle 10 lakh transactions in a day with a peak volume of 2.5 lakh transactions in an hour.

135. In the ISO message structure how does one know what are mandatory and optional fields?
In the ISO message formats the mandatory field has the ISO multi defined as [1..n] while for the optional field it is defined as
[0..n].

136. Internet based message creation can we give it to client directly?

No. the access to the secured site will only be provided to banks.

137. Whether this entire architecture IPV6 Compliant?

Yes.

138. What type of client is to be selected?

NG-RTGS Access Guidelines:
Category I: Top Banks covering 90 percent of RTGS Business or having more than 2000 RTGS transactions per day -Thick Client
- Compulsory

Reserve Bank of India 32 | P a g e

FAQ on NG-RTGS
 ISO20022 standard Message Implementation

Category II: Mid-Sized Banks having RTGS transaction volume of more than 50 transactions per day and less than 2000
transactions per day -Web API Services Client
Category III: Small Banks having less than or equal to 50 RTGS transactions per day -PO module access
Category II and Category III banks can also opt for thick client depending on their expected RTGS transaction volume in future.
Every Member Bank can opt for minimum two Modes of Access for NG-RTGS as proposed in the enclosed excel sheet.
Members who opt for Web API mode of Access need to integrate their Core Banking Solution with Web API. To Implement Web
API, please refer Annex-I.

Reserve Bank of India 33 | P a g e

FAQ on NG-RTGS