"Banking Payment SWIFT Online Session" WhatsApp to +918237151992

Monday, 31 January 2022

Session 7 ISO 20022 SOME WIDELY USED EXISTING STANDARDS in SWIFT Payments



ISO 15022 is currently the predominant securities standard in

cross-border settlement, reconciliation and corporate action processing. It was introduced around 1998 to replace ISO 7775, which was much less structured and often omitted crucial settlement

information. The adoption of ISO 15022, mandated in 2003, has led to a dramatic increase in Straight Through Processing (STP) rates. In settlement messages, for example, it is common to come

across STP rates of more than 95 per cent. One of the standard’s advantages is its data dictionary based approach, which enables reuse and standardization of data across all messages. About half of the 20 million messages that are exchanged on the SWIFT network every day are ISO 15022.


ISO 8583 is used for almost all credit and debit card transactions,

including ATMs. Several hundred million ISO 8583 messages are

exchanged daily between issuing and acquiring banks.


FIX is the predominant standard of the securities front office.

Millions of indications of interest, trade instructions, executions

and so on are sent each day using the FIX protocol.


FpML stands for Financial products Markup Language. It uses the

XML syntax and was specifically developed to describe the often complicated contracts that form the base of financial derivative products.

It is widely used between broker-dealers and other securities industry

players to exchange information on Swaps, CDOs, and so on.


SWIFT proprietary, also known as MT messages, are the standard

for messaging in correspondent banking, foreign exchange and

documentary credits. Over 10,000 financial institutions around the

world use this standard to exchange millions of messages per day

over the SWIFT network.


DTCC Proprietary domestic standards are also widely used. DTCC is an

example of a market infrastructure using proprietary standards.

Each day some 40 million messages are exchanged with DTCC to

clear and settle US domestic securities trades. ..


XBRL is a flexible XML based standard for exchanging business

information, which specializes in providing easy automation for

information found in unstructured documents.


Group - https://www.linkedin.com/groups/9322201/

Blog - https://bankingpayments.blogspot.com/

VBLOG- https://www.youtube.com/@LoveBanking

#jobsbeanbag #lovebanking #prashantpaymentspost


ISO20022 standard Message Implementation Knowledge Question Answer Phase1–11 to 20 Question

 


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’

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 signat

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

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


Group - https://www.linkedin.com/groups/9322201/

Blog - https://bankingpayments.blogspot.com/

VBLOG- https://www.youtube.com/@LoveBanking

#jobsbeanbag #lovebanking #prashantpaymentspost


Session 1 - ISO20022 standard Message Implementation Knowledge Question Answer Phase1, 10 Question



ISO20022 standard Message Implementation Knowledge Question Answer Phase1–10 Question

Q1. What is ISO 20022 standard? 

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


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

Q3 . What are the parts of ISO 20022 message?

The ISO 20022 Business Message consists of two parts: (1) ISO 20022 Business Application Header (2) ISO 20022 Messages


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


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


Q6. Whether all messages will have BAH? All messages listed above will have the BAH attached to it.


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

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 position Information Remarks First four characters Bank code Four Characters of bank Code Fifth character Zero Reserved for future use Last six characters Branch code Banks to use their existing codes with no white spaces(zeroes prefixed)


10. What is the BusinessMessageIdentifier in BAH?

ISO20022 standard Message Implementation Reserve Bank of India 4 | P a g e FAQ on NG-RTGS . 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 Management 2

Treasury 3

ATM 4